Si trabajas en remoto o gestionas servidores de ficheros, seguramente te habrás peleado más de una vez con VPN lentas, puertos bloqueados y protocolos viejos que no dan la talla. SMB sobre QUIC llega precisamente para resolver ese quebradero de cabeza, permitiendo acceso remoto seguro a archivos a través de Internet sin necesidad de túneles VPN clásicos, y apoyándose en tecnologías modernas como TLS 1.3 y el protocolo QUIC del IETF.
Aunque suene muy “de nicho”, lo cierto es que SMB sobre QUIC está llamado a ser la forma estándar de publicar recursos compartidos de Windows hacia el exterior con seguridad y rendimiento. En este artículo vas a ver en detalle qué es, por qué es mucho más seguro que exponer SMB tradicional, qué necesitas para ponerlo en marcha, cómo configurarlo paso a paso (incluyendo certificados, KDC Proxy y control de acceso de clientes) y qué mejoras de seguridad trae Windows 11 24H2 y Windows Server 2025 alrededor de SMB.
Qué es SMB sobre QUIC y por qué es más seguro que SMB tradicional
SMB sobre QUIC es una variante de transporte para el protocolo SMB que sustituye TCP por QUIC como canal subyacente. En lugar de usar el puerto TCP 445 de toda la vida, encapsula todo el tráfico SMB dentro de un túnel QUIC cifrado que viaja por UDP 443, el mismo puerto que se usa para HTTPS moderno basado en HTTP/3.
El protocolo QUIC, estandarizado por el IETF, aporta varias ventajas clave frente a TCP clásico:
- Todo el tráfico va siempre cifrado y autenticado con TLS 1.3.
- Permite múltiples flujos en paralelo (fiables y no fiables).
- Reduce la latencia con 0-RTT.
- Mejora el control de congestión.
- Sobrevive a cambios de IP como los típicos de redes móviles o cambios de WiFi a datos.
Al combinar QUIC con SMB, Microsoft consigue una especie de “VPN SMB” integrada: el cliente establece un túnel TLS 1.3 con el servidor de archivos, todo por el puerto UDP 443, y dentro de ese túnel viaja el protocolo SMB estándar. Eso implica que la autenticación, la autorización y los datos SMB jamás se exponen en claro a la red subyacente.
Además, la experiencia de usuario es prácticamente idéntica a usar un recurso compartido de red interno: las características como multicanal, firma de SMB, compresión, alta disponibilidad, leasing de directorios y demás siguen funcionando como siempre, solo que dentro del túnel QUIC. El usuario final simplemente ve una unidad mapeada o una ruta UNC accesible, sin preocuparse por el transporte.
Es importante tener en cuenta que SMB sobre QUIC es opcional y debe habilitarse conscientemente por el administrador.
Requisitos previos para desplegar SMB sobre QUIC
Antes de pensar en exponer recursos compartidos vía QUIC, necesitas cumplir una serie de requisitos tanto en el servidor como en el cliente, así como a nivel de certificados y red.
- En el lado del servidor: debes contar con un servidor SMB que ejecute un sistema operativo compatible, como Windows Server 2022 Datacenter: Azure Edition (con características de SMB sobre QUIC) o Windows Server 2025, donde esta funcionalidad está ya disponible en todas las ediciones.
- Por el lado del cliente: necesitas Windows 11 (ediciones empresariales o profesionales con soporte de QUIC) o versiones equivalentes capaces de hablar SMB sobre QUIC.
En cuanto a identidad, lo recomendable es que tanto servidor como cliente estén unidos a un dominio de Active Directory, de forma que la autenticación pueda hacerse vía Kerberos. Aun así, también es posible usar SMB sobre QUIC con equipos en grupo de trabajo utilizando cuentas locales y NTLM, o con servidores unidos a Microsoft Entra siempre que se usen credenciales de dominio o locales para acceder al recurso compartido.
A nivel de red, el servidor debe ser accesible desde Internet en su interfaz pública y tener abierto el puerto UDP 443 entrante. La recomendación es clara: no exponer nunca el puerto TCP 445 al exterior.
Por último, necesitas una infraestructura de clave pública (PKI) capaz de emitir certificados de servidor TLS válidos. Puede ser una CA corporativa basada en Active Directory Certificate Services o un emisor público de confianza como DigiCert, GlobalSign o similares. También son imprescindibles privilegios administrativos en el servidor SMB para poder instalar funciones, configurar certificados y modificar reglas de firewall.
Instalación y requisitos del certificado de servidor para QUIC
El corazón de SMB sobre QUIC es el certificado de servidor que se usa para establecer el túnel TLS 1.3. Sin un certificado con las propiedades adecuadas, la conexión simplemente no funcionará.
Ese certificado debe cumplir varias condiciones técnicas:
- Usar la clave para firma digital.
- Tener el propósito de autenticación de servidor (EKU 1.3.6.1.5.5.7.3.1).
- Emplear algoritmos modernos como SHA256RSA o superiores y una clave pública basada en ECDSA P-256 o, alternativamente, RSA de al menos 2048 bits.
Igual de importante es la identidad del servidor. En el campo de nombre alternativo del sujeto (SAN) debes incluir todas las entradas DNS completas (FQDN) con las que los clientes vayan a acceder al servidor, por ejemplo fsedge1.contoso.com o nombres similares. El emisor del certificado (CN) puede ser cualquiera siempre que pertenezca a una CA confiable y, por supuesto, el certificado debe incluir la clave privada para que el servidor pueda completar el protocolo de enlace TLS.
Si tu organización utiliza una CA corporativa de Microsoft, lo más cómodo es crear una plantilla específica de certificado para SMB sobre QUIC y permitir que el administrador del servidor rellene los nombres DNS al solicitarlo. Esa plantilla puede forzar el EKU de autenticación de servidor, los algoritmos permitidos y otros parámetros de seguridad.
El proceso típico con una Enterprise CA consiste en abrir MMC.exe en el servidor de archivos, añadir el complemento de Certificados para la cuenta de equipo, ir al almacén Personal, hacer clic derecho y seleccionar “Solicitar un nuevo certificado”. A partir de ahí, se elige la directiva de inscripción de Active Directory, se selecciona la plantilla creada para QUIC y se rellenan los campos de asunto y SAN con los nombres DNS que usarán los usuarios. Tras inscribirlo, el certificado aparecerá en el almacén y podrá asignarse al servicio SMB sobre QUIC.
Configurar SMB sobre QUIC en el servidor
Una vez que el certificado está listo, llega el momento de habilitar y configurar SMB sobre QUIC en el servidor. Puedes hacerlo con Windows Admin Center o con PowerShell. Todo depende de tus preferencias y del tipo de entorno.
Con Windows Admin Center (WAC), el asistente de configuración de SMB sobre QUIC guía paso a paso: selección del certificado, configuración del puerto UDP, habilitación del servicio y comprobación de la conectividad básica. Eso sí, en servidores que no estén unidos a dominio (grupo de trabajo) WAC no permite configurar esta característica, y en ese caso tendrás que recurrir a PowerShell y cmdlets como New-SmbServerCertificateMapping para enlazar el certificado al servicio.
En entornos gestionados de forma más automatizada, PowerShell ofrece un control milimétrico. Puedes, por ejemplo, listar los certificados disponibles, crear el mapeo entre el certificado y el servidor SMB, cambiar puertos alternativos de QUIC o forzar requisitos de autenticación adicionales. Cmdlets como Set-SmbServerCertificateMapping permiten actualizar fácilmente la huella digital asociada cuando el certificado se renueva.
Además, si quieres ir un paso más allá, puedes combinar SMB sobre QUIC con nuevas funciones de seguridad de Windows Server 2025 como el bloqueo de NTLM, la obligación de cifrado SMB en el cliente o la restricción de dialectos SMB a 3.1.1 para evitar conexiones de dispositivos antiguos menos seguros.
En cualquier caso, no olvides revisar las reglas de firewall tras habilitar QUIC: debe estar permitido el tráfico UDP entrante en el puerto que hayas definido (por defecto 443) y, si configuras características adicionales como el proxy de KDC, tendrás que abrir también TCP 443 para ese servicio en particular.
Conectar clientes a recursos compartidos SMB sobre QUIC
Con el servidor listo, toca probar el acceso desde un cliente Windows 11. El primer paso es asegurarte de que el equipo está unido al dominio correspondiente o, en su defecto, que dispone de credenciales válidas en el servidor de archivos (cuenta local o de dominio según el escenario).
Es fundamental que los nombres DNS que vas a usar para conectar coincidan exactamente con los SAN del certificado del servidor. Esos nombres deben estar publicados en DNS público o, si no es posible, puedes incluirlos manualmente en el archivo HOSTS del cliente. Esto último solo es recomendable para pruebas o entornos muy controlados.
Para simular un escenario de teletrabajo real, conecta el dispositivo cliente a una red externa donde no tenga acceso directo a las IP internas del servidor ni a los controladores de dominio. Así comprobarás que toda la comunicación pasa realmente por QUIC y no por rutas internas de LAN.
La conexión puede hacerse de varias formas. En el Explorador de archivos, basta con escribir la ruta UNC al recurso compartido, por ejemplo \\fsedge1.contoso.com\ventas, y Windows intentará primero TCP y, si falla, pasará a QUIC de manera transparente. Si quieres forzar QUIC desde el principio, puedes usar los comandos:
NET USE * \\fsedge1.contoso.com\ventas /TRANSPORT:QUIC
o bien
New-SmbMapping -LocalPath 'Z:' -RemotePath '\\fsedge1.contoso.com\ventas' -TransportType QUIC
Estos comandos indican al cliente que solo debe usar QUIC como transporte. Si la conexión no se establece, tendrás pistas claras para revisar certificados, puertos, DNS o requisitos de acceso adicionales como el control de acceso de clientes.
Cómo mejorar la autenticación: uso opcional de KDC Proxy
En un escenario típico de SMB sobre QUIC, el cliente remoto no tiene conectividad directa con los controladores de dominio de Active Directory. En ese caso, la autenticación suele recaer en NTLMv2, donde el servidor de archivos actúa en nombre del cliente para validar las credenciales dentro del túnel cifrado.
Aunque NTLMv2 viaja protegido por TLS 1.3 dentro de QUIC, la recomendación de seguridad actual es depender lo mínimo posible de NTLM y favorecer Kerberos. Para conseguirlo en entornos remotos, puedes desplegar el servicio de proxy de KDC (KDC Proxy). Este permite reenviar peticiones de tickets Kerberos a los controladores de dominio internos usando un canal HTTPS cifrado.
La configuración en el servidor de archivos implica varios pasos con PowerShell y netsh:
- Reservar una URL para el proxy de KDC en HTTPS 443.
- Ajustar claves de registro del servicio KPSSVC para permitir la autenticación adecuada.
- Vincular el certificado TLS correcto a la dirección y puerto mediante
Add-NetIPHttpsCertBinding. Para ello, necesitarás la huella digital del certificado que ya utilizas para SMB sobre QUIC.
En el lado del cliente, la manera más limpia de indicar qué dominios deben usar KDC Proxy es mediante Directiva de Grupo. Existe una política específica en “Configuración del equipo\Plantillas administrativas\Sistema\Kerberos\Especificar servidores proxy KDC para clientes Kerberos”, donde se define un par nombre/valor: el nombre es el FQDN del dominio de AD y el valor es la URL HTTPS del proxy (por ejemplo https fsedge1.contoso.com:443:kdcproxy /).
Con esto, cuando un usuario del dominio intenta acceder a un servidor SMB publicado por QUIC, el cliente sabe que debe pedir los tickets Kerberos a través del proxy en lugar de intentar llegar directamente al controlador de dominio. Toda esa comunicación va cifrada por HTTPS 443. Sin exponer credenciales en la red intermedia y manteniendo las ventajas de Kerberos como autenticación principal.
Auditoría y supervisión de SMB sobre QUIC
Para tener el entorno bajo control, es clave poder auditar qué clientes se conectan por SMB sobre QUIC y qué ocurre durante esas conexiones. Windows introduce eventos específicos para este tipo de tráfico. Tanto en el cliente como en el servidor.
- En el lado del cliente SMB (desde Windows 11 24H2), puedes revisar el Visor de eventos en “Registros de aplicaciones y servicios\Microsoft\Windows\SMBClient\Conectividad”, donde se registran eventos como el ID 30832 relacionados con conexiones QUIC. Esto te ayuda a verificar si la conexión realmente se está estableciendo sobre QUIC, si hay problemas de certificado o si el servidor rechaza el acceso.
- En el servidor, tienes la opción de habilitar auditoría específica de certificados de cliente mediante el comando
Set-SmbServerConfiguration -AuditClientCertificateAccess $true. A partir de ahí, eventos como 3007, 3008 y 3009 en “Microsoft\Windows\SMBServer\Audit”, y 30831 en el registro de conectividad del cliente, recogen datos sobre los certificados que intentan conectarse: asunto, emisor, serie, hashes SHA1 y SHA256 y qué reglas de control de acceso se han aplicado.
Estos eventos incluyen un identificador de conexión que facilita correlacionar lo que ve el cliente con lo que registra el servidor, lo cual es especialmente útil en entornos grandes o cuando investigas incidencias de acceso denegado. Además, te sirven como base para auditorías de seguridad o para detectar comportamientos anómalos.
Control de acceso de clientes SMB sobre QUIC
Más allá del cifrado y la autenticación, Windows Server 2025 incorpora un nivel extra de control: el control de acceso de clientes SMB sobre QUIC. Esta función permite definir explícitamente qué dispositivos pueden o no pueden establecer un túnel QUIC con el servidor, independientemente de que confíen en la CA que emitió el certificado del servidor.
El mecanismo se basa en certificados de cliente. Cada dispositivo obtiene un certificado destinado a autenticación de cliente (EKU 1.3.6.1.5.5.7.3.2), emitido por una CA en la que el servidor confía. El servidor, por su parte, mantiene una lista de control de acceso basada en hashes de certificado o identificadores de emisor (CA) que determinan qué clientes están permitidos o bloqueados.
Para el lado servidor, necesitas Windows Server 2022 Datacenter: Azure Edition con la actualización adecuada o Windows Server 2025, SMB sobre QUIC ya configurado y la garantía de que confías en la CA que expide los certificados de cliente. En el lado cliente, hace falta un sistema compatible con SMB sobre QUIC, el certificado de cliente instalado en el almacén local y privilegios para crear la asignación SMB a ese certificado.
El primer paso en el servidor es forzar que los clientes presenten un certificado válido configurando Set-SmbServerCertificateMapping -RequireClientAuthentication $true. A partir de ese momento, el servidor no solo valida la cadena de certificados de cliente, sino que la usa para decidir si concede o no la conexión según las listas de permitidos y bloqueados.
En el cliente, obtienes el hash del certificado relevante usando PowerShell. Luego creas la asignación. A partir de ahí, cuando el cliente intente conectar a ese FQDN vía QUIC, usará ese certificado para autenticarse.
Listas de permitidos y bloqueados: cmdlets de control de acceso
Una vez que cliente y servidor usan certificados, puedes construir políticas muy finas de qué se permite y qué se bloquea. Windows introduce varios cmdlets para gestionar estas listas.
Para permitir a un cliente concreto, usas Grant-SmbClientAccessToServer -Name <servidor> -IdentifierType SHA256 -Identifier <hash>, donde el identificador es el hash SHA256 del certificado del cliente. Si en algún momento quieres revocar ese permiso, basta con ejecutar Revoke-SmbClientAccessToServer con los mismos datos.
Si necesitas crear una lista de bloqueados explícita, puedes hacerlo con Block-SmbClientAccessToServer y revertirlo con Unblock-SmbClientAccessToServer. Esta lista de denegación tiene prioridad sobre las entradas de permiso. Así, si cualquier certificado de la cadena del cliente coincide con una entrada de bloqueo, la conexión se rechaza.
Además de trabajar con certificados hoja (dispositivos concretos), puedes gestionar grupos de certificados emisor añadiendo entradas de tipo ISSUER. Por ejemplo, permitir todo lo que emita una CA intermedia concreta o bloquear una CA comprometida entera. Esto reduce muchísimo el número de entradas que hay que mantener cuando se trabaja con cientos o miles de equipos.
La lógica de evaluación es clara: si no se bloquea ninguno de los certificados de la cadena y al menos uno está permitido, el acceso se concede. Si cualquier elemento de la cadena está explícitamente bloqueado, la conexión se rechaza. Incluso aunque haya una entrada de permiso para un certificado hoja concreto. Esto permite escenarios como confiar en toda una CA raíz pero denegar de forma quirúrgica uno o varios certificados específicos.
Para comprobar el estado de las listas, puedes usar Get-SmbClientAccessToServer. Este comando muestra qué identificadores están permitidos o bloqueados, así como el tipo (SHA256, ISSUER, etc.) y el nombre del servidor al que aplican.
Seguridad de SMB clásico: por qué no es buena idea exponer SMB/CIFS en Internet
Antes de SMB sobre QUIC, la forma habitual de compartir archivos entre equipos era SMB/CIFS (en Windows) o SAMBA (en Linux/Unix) a través de la red local. Para conectarse desde fuera se solía abrir el puerto 445 (y, en ocasiones, también el 139). O bien montar una VPN general para entrar en la LAN.
El problema es que SMB/CIFS tradicional es muy simple, pero también peligroso cuando se expone más allá de una red interna controlada. En muchas implementaciones antiguas, el tráfico no va cifrado. Eso significa que cualquier atacante que pueda situarse entre cliente y servidor (ataques Man in the Middle) podría interceptar y leer los ficheros transmitidos.
Si encima el servidor permite recursos compartidos sin contraseña o con credenciales débiles, el riesgo se dispara. Incluso cuando hay contraseña, si el protocolo no cifra correctamente la autenticación, las credenciales pueden viajar en texto plano o ser vulnerables a ataques de replay o relay. Muchas redes domésticas y pequeñas empresas siguen usando versiones de SMB 2.0 sin cifrado. Una práctica no exenta de riesgos.
A esto se suman las vulnerabilidades históricas de SMB. Por ejemplo, la famosa EternalBlue, explotada por el ransomware WannaCry. Ese ataque se propagó a través de SMB solo en redes locales, pero sirve como ejemplo de lo que podría ocurrir si se abre SMB directo a Internet sin protección adicional. Otros protocolos clásicos como FTP o Telnet sufren problemas muy similares.
SMB sobre QUIC y las nuevas funciones de seguridad de SMB en Windows 11 y Windows Server 2025 ofrecen una forma mucho más razonable y robusta de exponer recursos compartidos a usuarios remotos: todo viaja cifrado por TLS 1.3 sobre QUIC, puedes apoyarte en Kerberos incluso sin acceso directo a DC mediante KDC Proxy, controlar exactamente qué clientes pueden conectarse con certificados y listas de permitidos/bloqueados y dejar atrás la peligrosa costumbre de abrir el puerto 445 a Internet o depender de VPN generales para algo tan básico como acceder a archivos.
