RDP funciona, el recurso compartido no: corrige las reglas del firewall correctamente

Qué demuestra RDP (y qué no)

Cuando RDP funciona y el uso compartido de archivos no, la causa raíz suele ser una de estas:

• Desajuste de alcance del firewall: RDP permitido desde “Cualquiera”, SMB permitido solo desde “Subred local”, o solo en el perfil “Dominio” mientras el servidor está en “Público”.
• Desajuste de puertos: Abriste 139, pero SMB está usando 445 (o viceversa en alguna situación heredada), o el cliente insiste en SMB sobre 445 y solo permitiste endpoints RPC para otra cosa.
• Desajuste en resolución de nombres: RDP usa una IP guardada o un registro DNS; SMB intenta NetBIOS, LLMNR, o el sufijo DNS equivocado; te conectas a un host distinto del que crees.
• Desajuste en la ruta de autenticación: RDP funciona con credenciales en caché o cuentas locales; SMB requiere Kerberos/LDAP a un DC al que no se puede acceder desde esa red, de modo que la autenticación falla después del handshake TCP.
• Desajuste en firma/encriptación/políticas de SMB: La conexión está permitida pero la negociación falla porque las políticas no coinciden.
• Problemas de filtrado con estado: Algunos firewalls “inteligentes” o IDS hacen cosas desagradables a las sesiones SMB, especialmente a través de VPN/NAT.

RDP y SMB son animales diferentes. RDP suele ser un único flujo TCP a un único puerto. SMB es una negociación habladora con expectativas estrictas sobre la continuidad de la sesión, y a menudo incorpora servicios de directorio en la mezcla. Tus reglas de firewall deben reflejar esa realidad.

Broma #1 (corta, relevante): Los firewalls son como porteros: recuerdan al VIP que dejaste entrar (RDP) y luego se sorprenden cuando llega toda la banda (SMB).

Mapa de tráfico SMB: puertos, protocolos y por qué “445” no es toda la historia

Los puertos mínimos que importan

Si usas SMB moderno (era Windows 7+ / Server 2008+ y posteriores), el núcleo es:

• TCP/445 — alojamiento directo SMB. Este es el que casi siempre necesitas.

La realidad heredada y “empresarial” añade más:

• TCP/139 — SMB sobre NetBIOS session service (antiguo; a veces aún usado en entornos mixtos).
• UDP/137, UDP/138 — servicio de nombres NetBIOS y servicio de datagramas (descubrimiento/resolución de nombres heredada).
• TCP/135 y un rango de puertos RPC dinámicos — no son necesarios para el uso básico de archivos, pero sí para muchas acciones de gestión (MMC, algunas impresoras compartidas, administración remota, DFS, etc.).
• Kerberos/LDAP/DNS hacia controladores de dominio — no son “puertos SMB”, pero a menudo son necesarios para autenticación y resolución de membresía de grupo:
  • TCP/88 (Kerberos), TCP/389 (LDAP), TCP/636 (LDAPS), TCP/53 y UDP/53 (DNS)

Por qué abrir 445 puede no bastar

Porque la falla del recurso compartido puede ocurrir después del connect TCP. Capas típicas:

1. Enrutamiento/ACLs: ¿Puede el cliente alcanzar el servidor en absoluto (a 445) desde la IP de origen correcta?
2. Firewall con estado: ¿Se completa SYN/SYN-ACK/ACK y se permite el tráfico de retorno?
3. Negociación SMB: ¿Acuerdan cliente y servidor dialectos (SMB2/SMB3), firma, cifrado?
4. Autenticación: ¿Puede el servidor validar credenciales (SAM local vs AD), y puede alcanzar un DC si es necesario?
5. Autorización: Permisos de recurso compartido y permisos NTFS.
6. Estabilidad: Problemas de MTU, dispositivos intermedios que resetean sesiones de larga duración, casos límite de bloqueo oportunista, o timeouts de sesión SMB.

Guion de diagnóstico rápido: encuentra el cuello de botella antes de editar reglas

Esta es la manera más rápida de dejar de andar a tientas en la oscuridad.

Primero: demuestra que estás alcanzando el host correcto

1. Resuelve el nombre de la misma forma en que lo hace SMB. Prueba el nombre que realmente tecleas en el Explorador o en tu comando de montaje.
2. Compara la respuesta DNS con el objetivo de RDP. La gente hace RDP a una IP y navega por un nombre. Así terminas depurando la máquina equivocada.

Segundo: prueba TCP/445 desde el cliente

1. Ejecuta una prueba de puerto (Windows: Test-NetConnection; Linux: nc).
2. Si está bloqueado, para. Arregla enrutamiento/ACLs/firewall antes de tocar configuraciones SMB.

Tercero: prueba la negociación y autenticación SMB explícitamente

1. Windows: intenta net use o Get-SmbConnection; Linux: smbclient.
2. Diferencia: “no puede conectar” vs “usuario/contraseña incorrectos” vs “acceso denegado”. Esos son equipos distintos y arreglos distintos.

Cuarto: inspecciona perfiles del firewall y alcance de reglas

1. Servidor Windows: confirma el perfil de red activo (Dominio/Privado/Público).
2. Confirma que la regla “File and Printer Sharing (SMB-In)” esté activada para el perfil correcto y restringida a las IP remotas adecuadas.

Quinto: captura paquetes en ambos extremos (solo si es necesario)

1. Captura en cliente: ¿ves SYNs salir? ¿Llegan SYN-ACKs de vuelta?
2. Captura en servidor: ¿ves SYNs llegar? ¿Ves RSTs salir? Eso te dice si el firewall del servidor es el que está golpeando el martillo.

Datos interesantes y contexto histórico (lo que explica las rarezas actuales)

• Dato 1: SMB nació en los años 80 en IBM y luego fue ampliamente extendido por Microsoft; el protocolo “simple” tiene décadas de carga histórica.
• Dato 2: TCP/445 se volvió el predeterminado para el alojamiento directo SMB a medida que Windows se alejó de la dependencia de NetBIOS; por eso 139 se siente como un puerto fantasma que aún persigue auditorías.
• Dato 3: Los infames gusanos de principios de los 2000 (los que abusaron de servicios de red de Windows) son parte de la razón por la que los equipos de seguridad tratan 445 como radioactivo fuera de redes de confianza.
• Dato 4: La firma SMB existe para prevenir ataques man-in-the-middle; mejora la integridad pero puede generar sorpresas de rendimiento y compatibilidad si se alterna inconsistente.
• Dato 5: SMB3 introdujo cifrado a nivel de protocolo (no solo “usar IPsec”), lo que cambió cómo se comportan algunas herramientas de monitorización y dispositivos intermedios.
• Dato 6: Los perfiles del Firewall de Windows (Dominio/Privado/Público) fueron diseñados para la movilidad de laptops, no para servidores con múltiples NIC; los servidores aún se clasifican mal con sorprendente frecuencia.
• Dato 7: La resolución de nombres NetBIOS y el descubrimiento por broadcast fueron convenientes en LANs planas; son frágiles a través de redes enrutadas y con frecuencia están bloqueados por diseño.
• Dato 8: “File and Printer Sharing” es un conjunto de reglas, no un interruptor único; habilitar el subconjunto equivocado es una solución a medias común.
• Dato 9: Muchas organizaciones bloquean intencionadamente SMB a través de WAN/VPN y, en su lugar, proporcionan acceso a archivos mediante gateways (DFS, SFTP, portales HTTPS). Tu “debería funcionar” puede ser política, no un error.

Una cita, porque sigue siendo pertinente: Paráfrasis de la idea: “La esperanza no es una estrategia.” — atribuida a menudo en círculos de operaciones; trátala como un lema SRE, no como escritura sagrada.

Tareas prácticas: comandos, salida y la decisión que tomas

Estas son comprobaciones reales que puedes ejecutar. Cada una incluye qué significa la salida y qué hacer después. Elige la ruta que coincida con tu entorno.

Task 1: Confirma que usas el mismo objetivo para RDP y SMB (cliente Windows)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName filesrv01.corp.example -Type A | Select-Object -ExpandProperty IPAddress"
10.20.30.40

Significado: El nombre SMB resuelve a 10.20.30.40. Si hiciste RDP a 10.20.30.41, estarás depurando dos equipos distintos.

Decisión: Si hay desacuerdo, corrige DNS/archivo hosts, o usa el nombre/IP correcto de forma consistente. Detente aquí hasta que los objetivos coincidan.

Task 2: Verifica la ruta del cliente al servidor SMB (cliente Linux)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 10.20.1.1 dev eth0 src 10.20.1.55 uid 1000

Significado: Tus paquetes van vía 10.20.1.1 desde la fuente 10.20.1.55. Los firewalls evaluarán esa IP de origen, no tus sentimientos.

Decisión: Si la ruta es inesperada (interfaz equivocada, origen equivocado), corrige enrutamiento/políticas de split-tunnel VPN antes de tocar el firewall.

Task 3: Prueba el puerto 445 desde Windows (el suero de la verdad más rápido)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.30.40 -Port 445 | Select-Object ComputerName,RemoteAddress,RemotePort,TcpTestSucceeded"
filesrv01
10.20.30.40
445
False

Significado: La conexión TCP a 445 falló. Esto no es un problema de permisos SMB; es un problema de ruta de red.

Decisión: Trabaja hacia afuera: ¿firewall del cliente? ¿ACL de red? ¿firewall del servidor? ¿grupo de seguridad? No pierdas tiempo en permisos de compartición todavía.

Task 4: Prueba el puerto 445 desde Linux (misma idea, menos palabras)

cr0x@server:~$ nc -vz 10.20.30.40 445
nc: connect to 10.20.30.40 port 445 (tcp) failed: Connection timed out

Significado: Timeout implica drop (firewall/ACL) más a menudo que reject. Un reject suele regresar rápido con “refused”.

Decisión: Si hay timeout, revisa dispositivos de seguridad intermedios. Si “refused”, confirma que el servicio SMB está escuchando.

Task 5: Confirma que el servidor escucha en 445 (servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object -First 3 LocalAddress,LocalPort,OwningProcess"
0.0.0.0
445
4

Significado: El puerto 445 está escuchando en todas las interfaces. PID 4 es el proceso System en Windows, normal para SMB.

Decisión: Si nadie escucha, asegúrate de que el servicio “Server” esté en ejecución y que las funciones del servidor SMB estén instaladas. Los cambios en el firewall no ayudarán a un puerto cerrado.

Task 6: Confirma que el servicio “Server” está en ejecución (servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service LanmanServer | Select-Object Status,Name,DisplayName"
Running
LanmanServer
Server

Significado: El servicio servidor SMB está en ejecución.

Decisión: Si está detenido/deshabilitado, arréglalo primero. Si está en ejecución, procede a perfil del firewall y alcance de reglas.

Task 7: Comprueba el perfil activo del Firewall de Windows (servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias,NetworkCategory,IPv4Connectivity"
Ethernet0
Public
Internet

Significado: El servidor piensa que está en una red Pública. Muchos reglas de “File and Printer Sharing” están deshabilitadas en Público por defecto.

Decisión: Corrige el perfil de red (a menudo asegurando la conectividad al dominio y el binding correcto de NIC) o habilita explícitamente reglas SMB para Público con un alcance remoto estricto.

Task 8: Inspecciona reglas relacionadas con SMB en el firewall (servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Select-Object DisplayName,Enabled,Profile,Direction | Format-Table -AutoSize"
File and Printer Sharing (SMB-In)                 True  Domain,Private  Inbound
File and Printer Sharing (NB-Session-In)          False Domain,Private  Inbound
File and Printer Sharing (NB-Name-In)             False Domain,Private  Inbound
File and Printer Sharing (NB-Datagram-In)         False Domain,Private  Inbound

Significado: SMB-In está habilitado, pero solo para Domain/Private. Si el servidor está en Public, no coincidirá.

Decisión: O corrige el perfil a Domain/Private, o habilita SMB-In en Public con un alcance remoto estrecho.

Task 9: Confirma el alcance remoto de la regla del firewall (servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
Any

Significado: Permite desde cualquier IP remota (dentro de los perfiles habilitados). Eso puede ser inaceptable, o puede estar bien dentro de una VLAN de confianza.

Decisión: En producción, delimítalo a subredes conocidas. “Any” es como terminas en una reunión de revisión de seguridad sin snacks.

Task 10: Prueba SMB a nivel de protocolo (cliente Linux)

cr0x@server:~$ smbclient -L //10.20.30.40 -U 'CORP\alice'
Password for [CORP\alice]:
Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       Remote IPC
Shares          Disk
SMB1 disabled -- no workgroup available

Significado: La conectividad y la autenticación tuvieron éxito. “SMB1 disabled” es buena noticia, no un problema.

Decisión: Si el listado funciona pero el montaje falla, concéntrate en permisos, políticas de firma/cifrado SMB, o en opciones de montaje del cliente.

Task 11: Prueba el mapeo SMB desde cliente Windows (claridad de autenticación)

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use * \\10.20.30.40\Shares /user:CORP\alice'"
The command completed successfully.

Significado: Puedes autenticarte y mapear el recurso. Si el Explorador aún falla por nombre, es resolución de nombres o matices SPN/Kerberos.

Decisión: Si IP funciona y nombre falla, corrige DNS, SPNs, y evita depender de NetBIOS/LLMNR.

Task 12: Comprueba conexiones SMB actuales (cliente Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,Encrypted,SigningRequired | Format-Table -AutoSize"
10.20.30.40 Shares 3.1.1  2 False True

Significado: Negociaste SMB 3.1.1; la firma es requerida; el cifrado está desactivado.

Decisión: Si ves un dialecto antiguo o una negociación fallida, revisa desajustes de políticas (configuración cliente/servidor SMB) antes de culpar al firewall.

Task 13: Confirma la configuración del servidor SMB en Windows (servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess,RequireSecuritySignature"
False
True
True
True

Significado: SMB1 deshabilitado; SMB2 habilitado; acceso no encriptado rechazado; firma requerida.

Decisión: Si clientes antiguos no pueden conectarse, no vuelvas a habilitar SMB1 a la ligera. Arregla el cliente. Si debes hacerlo, aísla lo heredado en un servidor de archivos separado y con firewall estricto.

Task 14: Identifica si el firewall del servidor está descartando el tráfico (captura de paquetes en servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "pktmon filter remove; pktmon filter add -p 445; pktmon start --etw -m real-time"
PktMon started.

Significado: Estás capturando tráfico del puerto 445 en tiempo real (basado en ETW). Reproduce ahora el intento desde el cliente.

Decisión: Si llegan SYNs pero no sale SYN-ACK, o si se emiten RSTs, estás en territorio del firewall/servicio local. Si no llega nada, el bloqueo está río arriba.

Task 15: Comprueba reglas de firewall en Linux (ejemplo nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
  }
}

Significado: Drop por defecto, permitir solo SSH. SMB fallará a menos que añadas TCP/445 (y quizá 139) desde fuentes aprobadas.

Decisión: Añade una regla accept acotada para SMB desde las subredes correctas, no un allow global.

Task 16: Confirma que SELinux no es el villano sorpresa (servidor Samba en Linux)

cr0x@server:~$ getenforce
Enforcing

Significado: SELinux está en modo enforcing. Está bien, pero etiquetas mal asignadas pueden parecer “problemas de red” cuando el demonio no puede acceder al sistema de archivos.

Decisión: Si las conexiones funcionan pero el acceso a recursos falla en Samba en Linux, revisa los logs de audit y los contexts en lugar de tocar el firewall.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición errónea

El ticket decía: “Servidor de archivos caído.” El ingeniero de guardia hizo lo clásico: RDP al servidor, vio un escritorio sano, CPU tranquila, disco bien. Respondió: “El servidor está arriba; debe ser un problema de permisos.” Esa respuesta compró exactamente quince minutos de paz.

Luego el helpdesk empezó a pegar capturas de pantalla: todos los usuarios, todos los recursos compartidos, todos los sitios. “Ruta de red no encontrada.” Si has visto esa frase a escala, casi puedes oler el problema: no son ACLs NTFS, no es una GPO, no es un perfil corrupto. Es transporte.

Resultó que alguien había endurecido las reglas entrantes en el firewall del host durante una tanda de hardening. Habilitaron la regla RDP para todos los perfiles porque “siempre necesitamos RDP”, pero dejaron “File and Printer Sharing (SMB-In)” habilitada solo para Domain y Private. El perfil NIC del servidor se había cambiado a Public después de un problema transitorio de conectividad al dominio durante el arranque.

La suposición errónea fue sutil: “Si RDP funciona, el firewall está bien.” No. El firewall estaba haciendo su trabajo para un puerto. Hizo lo correcto. La solución fue corregir la causa del perfil de red (detección de dominio) y acotar explícitamente SMB-In a las subredes esperadas para todos los perfiles relevantes, de modo que un cambio de perfil no dejara el acceso a archivos inaccesible globalmente.

Microhistoria 2: La optimización que salió mal

Un equipo de red quiso reducir el riesgo de movimiento lateral. Buen objetivo. Introdujeron un nuevo conjunto de políticas de firewall: “solo permitir los puertos requeridos por capa.” También bien. Luego se pusieron ingeniosos y trataron de minimizar reglas permitiendo SMB solo desde un pequeño conjunto de “jump hosts”, asumiendo que los usuarios accederían a las comparticiones a través de sesiones de escritorio remoto.

Durante una semana pareció exitoso. Menos puertos abiertos. Diagramas más limpios. Luego finanzas cerró el mes y empezaron a fallar trabajos por lotes. Esos trabajos no eran usuarios interactivos que pudieran RDP a un jump box. Eran servidores de aplicación que tiraban informes desde una compartición SMB usando cuentas de servicio. La optimización rompió silenciosamente workflows máquina-a-máquina legítimos que existían desde hace años.

Peor aún, los síntomas eran ruidosos y engañosos: algunos trabajos fallaban rápido, otros colgaban. Algunos servidores tenían conexiones en caché y continuaban con golpes. El monitoring mostraba el servidor de archivos “arriba”, y todos discutían si era un problema de rendimiento de almacenamiento.

La solución no fue “abrir SMB por todos lados”. La solución fue identificar las subredes clientes legítimas (capa de app, VDI, segmento admin) y permitir TCP/445 solo desde esas fuentes, con logging. Luego documentaron la dependencia en el proceso de cambios. La optimización no falló porque la seguridad sea mala; falló porque el equipo optimizó por número de puertos en lugar de por flujos de tráfico conocidos.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Otra compañía tenía un hábito que deseo que todos copiáramos: cada cambio de firewall que pudiera impactar tráfico este-oeste requería una “lista de comprobación de pruebas de puerto” desde al menos dos redes cliente representativas. No una reunión. Una lista de comandos con salidas guardadas.

Un viernes desplegaron una nueva política baseline de Windows. Tocó reglas de Windows Defender Firewall, incluido el grupo “File and Printer Sharing”. En papel era seguro: solo se ajustó el alcance de “RemoteAddress” y se deshabilitaron reglas NetBIOS heredadas. Sensato en 2026.

Antes de aprobar, el ingeniero ejecutó su checklist: Test-NetConnection a 445 desde la subred VDI, desde la subred de app y desde la subred admin. Una subred falló. La razón no era la regla: el alcance de la regla usó el CIDR equivocado para un rango VDI recién ampliado.

No hubo caída. No porque fueran brillantes. Porque fueron aburridos y consistentes, y probaron desde los lugares que importan en vez del lugar conveniente.

Broma #2 (corta, relevante): La regla de firewall más fiable es la que probaste desde la subred donde viven realmente tus usuarios, no desde la subred donde tu laptop de vacaciones se conecta.

Arréglalo correctamente: reglas de Windows Firewall que sobreviven auditorías

Comienza con la mentalidad correcta: “habilitar y acotar”, no “desactivar”

Desactivar Windows Defender Firewall para “ver si funciona” es el equivalente operacional a quitar los frenos de un coche para diagnosticar un chirrido. Claro, algo cambia. Y ahora creaste otro incidente.

Haz esto en su lugar:

1. Asegúrate de que el servidor está escuchando en 445 y que el servicio Server está en ejecución.
2. Confirma qué perfil de firewall está activo.
3. Habilita la(s) regla(s) entrante(s) correcta(s) para ese perfil.
4. Restringe la regla por rangos IP remotos que representen clientes legítimos.
5. Activa el registro de descartes temporalmente si necesitas pruebas.

Habilitar SMB-In con alcance remoto (PowerShell)

Ejemplo: permitir SMB solo desde tu subred VDI y la subred de apps.

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -Enabled True"

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -Profile Domain,Private,Public"

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -RemoteAddress 10.20.0.0/16,10.50.10.0/24"

Qué hace: Asegura que la regla está habilitada, se aplica en todos los perfiles (importante cuando los perfiles mienten) y restringe SMB entrante a redes conocidas.

Decisión operacional: Aplicar en Público es aceptable solo con un alcance remoto estricto. Si no puedes acotar, corrige el problema de perfil en su lugar.

Verifica que los cambios de regla se aplicaron realmente

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Select-Object Enabled,Profile"
True
Domain, Private, Public

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
10.20.0.0/16, 10.50.10.0/24

Decisión: Si RemoteAddress aún muestra Any, modificaste la regla equivocada (común con nombres localizados) o una GPO está reimplementando la configuración.

Cuando interviene Group Policy (y suele intervenir)

Si GPO controla reglas de firewall, las ediciones locales son teatro temporal. Necesitas:

• Identificar la política ganadora.
• Arreglar la regla a nivel de GPO.
• Confirmar con gpresult y las reglas efectivas.

cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Applied Group Policy Objects'"
Applied Group Policy Objects
-----------------------------
Default Domain Policy
Server Firewall Baseline

Significado: “Server Firewall Baseline” probablemente está aplicando la configuración del firewall.

Decisión: Edita la GPO base. Si aplicas un hotfix local, documéntalo como excepción temporal y programa la corrección en la GPO, o se revertirá.

Activa el registro del firewall (quirúrgico y temporal)

Cuando necesitas evidencia, el registro ayuda. No lo dejes activo a alto volumen para siempre, especialmente en servidores de archivos con mucha carga.

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallProfile -Profile Domain,Private,Public -LogAllowed True -LogBlocked True -LogFileName '%systemroot%\system32\LogFiles\Firewall\pfirewall.log' -LogMaxSizeKilobytes 16384"

cr0x@server:~$ powershell -NoProfile -Command "Get-Content $env:systemroot\system32\LogFiles\Firewall\pfirewall.log -Tail 5"
2026-02-05 10:14:33 DROP TCP 10.20.1.55 10.20.30.40 51834 445 ...

Significado: Los drops confirman implicación del firewall; la IP de origen te indica qué subred debe estar en alcance.

Decisión: Si ves drops desde fuentes legítimas, actualiza RemoteAddress o ACLs río arriba. Si los drops son de direcciones inexistentes, tu firewall hace su trabajo; déjalo.

No “arregles” SMB habilitando NetBIOS heredado por accidente

Si habilitas UDP/137-138 y TCP/139 para que el browsing funcione, podrías estar parcheando un problema de DNS. Además, amplías la superficie de ataque y comportamientos basados en broadcast en redes que no deberían tenerlos.

Preferible: DNS fiable, SMB en alojamiento directo sobre 445 y rutas UNC explícitas.

Arréglalo correctamente: reglas de firewall en Linux (nftables/iptables/ufw/firewalld)

Los servidores SMB en Linux suelen ser Samba. Los clientes SMB en Linux suelen usar cifs-utils, smbclient o librerías de aplicaciones. Los principios de firewall son los mismos: permitir TCP/445 desde las fuentes correctas, mantener reglas stateful correctas y no abrir el mundo porque alguien gritó en Slack.

nftables: permitir SMB desde subredes específicas

El ejemplo asume una tabla inet filter con una cadena input y policy drop.

cr0x@server:~$ sudo nft add rule inet filter input ip saddr 10.20.0.0/16 tcp dport 445 ct state new accept

cr0x@server:~$ sudo nft add rule inet filter input ip saddr 10.50.10.0/24 tcp dport 445 ct state new accept

cr0x@server:~$ sudo nft list chain inet filter input
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    ip saddr 10.20.0.0/16 tcp dport 445 ct state new accept
    ip saddr 10.50.10.0/24 tcp dport 445 ct state new accept
  }
}

Significado: Las conexiones SMB nuevas son aceptadas solo desde las redes fuente permitidas. El tráfico establecido se permite por la primera regla.

Decisión: Si los clientes aún hacen timeout, el bloqueo está río arriba. Si los clientes conectan pero la auth falla, pasa a la configuración de Samba y servicios de directorio.

iptables (legacy): mismo principio, sintaxis menos amigable

cr0x@server:~$ sudo iptables -A INPUT -p tcp -s 10.20.0.0/16 --dport 445 -m conntrack --ctstate NEW -j ACCEPT

cr0x@server:~$ sudo iptables -S INPUT | sed -n '1,40p'
-P INPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -s 10.20.0.0/16 -m tcp --dport 445 -m conntrack --ctstate NEW -j ACCEPT

Significado: Drop por defecto con allows explícitos. Esto está bien si también aseguras que el tráfico de retorno esté permitido (la regla RELATED,ESTABLISHED).

Decisión: Si olvidaste RELATED,ESTABLISHED, obtendrás comportamientos raros de un solo sentido que parecen “SMB es inestable.” Arregla eso primero.

ufw: rápido y legible (cuando puedes usarlo)

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 445 proto tcp
Rule added

cr0x@server:~$ sudo ufw status verbose
Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)
To                         Action      From
445/tcp                    ALLOW IN    10.20.0.0/16
22/tcp                     ALLOW IN    Anywhere

Significado: SMB permitido solo desde esa subred.

Decisión: Si necesitas múltiples subredes, añádelas explícitamente. No hagas “ufw allow 445/tcp” a menos que quieras “desde cualquier lugar”.

firewalld (estilo RHEL): usa servicios cuando tenga sentido, puertos cuando necesites precisión

cr0x@server:~$ sudo firewall-cmd --get-active-zones
public
  interfaces: eth0

cr0x@server:~$ sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="10.20.0.0/16" port protocol="tcp" port="445" accept' --permanent
success

cr0x@server:~$ sudo firewall-cmd --reload
success

cr0x@server:~$ sudo firewall-cmd --zone=public --list-rich-rules
rule family="ipv4" source address="10.20.0.0/16" port port="445" protocol="tcp" accept

Significado: Allow acotado en la zona activa.

Decisión: Si añades reglas en la zona equivocada, nada cambia. Siempre verifica las zonas/interfaces activas primero.

La red que olvidaste: NAT, VPN, proxies, IDS y dispositivos “útiles” intermedios

Por qué SMB es sensible a rarezas en el camino

SMB es stateful y espera sesiones estables. Mete una VPN, un IDS agresivo o un firewall que haga normalización TCP, y obtendrás fallos que parecen aleatorios: desconexiones intermitentes, “El nombre de red especificado ya no está disponible” o montajes que cuelgan bajo carga.

NAT y SMB: posible, pero a menudo mala idea

SMB sobre NAT puede funcionar a nivel TCP, pero normalmente está bloqueado por política. El problema mayor es operacional: cuando múltiples clientes parecen venir de una sola IP NAT, tu acotado y auditoría del firewall del servidor pierden sentido. La autenticación todavía puede funcionar, pero la respuesta a incidentes se vuelve una danza interpretativa.

Split tunneling VPN: la rotura silenciosa

Un patrón frecuente:

• RDP funciona porque se fuerza por la VPN (o se permite en internet vía un gateway).
• SMB falla porque el split tunneling enruta 445 directamente a internet, donde está bloqueado (como debería), o a un egress distinto que no tiene las ACL correctas.

Corrige políticas de split tunneling o publica acceso a archivos mediante un método aprobado. No te pelees con tu equipo de red abriendo 445 externamente. Ese camino acaba en un informe de incidente.

IDS/IPS e inspección SMB

Algunos aparatos de seguridad inspeccionan SMB y pueden terminar sesiones si ven violaciones de política o anomalías. Eso puede presentarse como:

• Conexión establecida y luego reset inmediato durante la negociación.
• Copias grandes de archivos que fallan a tamaños consistentes (límites de buffer de inspección).
• El cifrado SMB3 rompe supuestos de visibilidad y desencadena bloqueos extraños.

Si sospechas esto, captura paquetes en ambos lados del aparato y compara. No adivines.

MTU y fragmentación: el “funciona para archivos pequeños” especial

Si puedes navegar directorios pero copiar archivos grandes falla, sospecha problemas de MTU/PMTUD sobre VPN o túneles. Esto no es estrictamente “reglas de firewall”, pero es un problema de política de red que aparece a menudo justo después de un cambio de firewall porque las rutas cambiaron.

cr0x@server:~$ ping -c 3 -M do -s 1372 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1372(1400) bytes of data.
1372 bytes from 10.20.30.40: icmp_seq=1 ttl=125 time=12.3 ms
1372 bytes from 10.20.30.40: icmp_seq=2 ttl=125 time=12.1 ms
1372 bytes from 10.20.30.40: icmp_seq=3 ttl=125 time=12.2 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Significado: El camino soporta paquetes de 1400 bytes sin fragmentación. Si esto falla, ajusta MTU en túneles/interfaces o permite ICMP necesario para PMTUD.

Decisión: Si PMTUD está roto, seguirás persiguiendo la “inestabilidad SMB” para siempre. Arregla el camino.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: RDP funciona, SMB hace timeout (sin prompt, solo girando)

Causa raíz: TCP/445 es descartado por un firewall/ACL/grupo de seguridad, a menudo porque solo RDP (3389) se permitió.

Solución: Permite inbound TCP/445 al servidor de archivos desde subredes aprobadas. Verifica con Test-NetConnection -Port 445 o nc. Mantén el alcance.

2) Síntoma: SMB falla solo usando nombre; funciona vía IP

Causa raíz: Desajuste de sufijo/orden de búsqueda DNS, registro DNS obsoleto, o resolución de nombre usando NetBIOS/LLMNR que no atraviesa routers/VPN.

Solución: Arregla registros DNS y la configuración DNS del cliente. Prefiere FQDNs. Deshabilita la dependencia de descubrimiento por broadcast entre segmentos.

3) Síntoma: “Acceso denegado” instantáneo

Causa raíz: Permisos de recurso compartido/NTFS o usuario alcanzando un servidor distinto vía DFS/alias; a veces credenciales en caché que mapean a la cuenta equivocada.

Solución: Confirma que estás en el servidor previsto, luego revisa permisos de compartición + ACLs NTFS; limpia sesiones SMB en caché (net use * /delete).

4) Síntoma: “El nombre de red especificado ya no está disponible” durante copia de archivos

Causa raíz: Reset por un dispositivo intermedio, timeout por inactividad, problemas MTU/PMTUD, o desajuste de firma/cifrado SMB en ciertas operaciones.

Solución: Captura paquetes; revisa políticas VPN/IDS; valida MTU; confirma políticas SMB consistentes cliente/servidor.

5) Síntoma: Funciona desde una subred, falla desde otra

Causa raíz: Alcance remoto del firewall demasiado estrecho, rutas faltantes o enrutamiento asimétrico provocando que dispositivos stateful descarten tráfico de retorno.

Solución: Compara IP de origen y ruta. Amplía el alcance de la regla a las subredes correctas. Corrige la simetría de enrutamiento o la colocación de dispositivos stateful.

6) Síntoma: Servidor Windows muestra perfil Público inesperadamente

Causa raíz: Detección de dominio fallando (conectividad DNS/DC), orden/union de NICs extraño, o múltiples NICs con categorías de red diferentes.

Solución: Restaura la alcanzabilidad a DC/DNS; asegúrate de que la NIC correcta se use para dominio; aplica reglas de firewall que no dependan solo del perfil (con alcance remoto estricto).

7) Síntoma: Montaje CIFS en Linux cuelga, pero ping funciona

Causa raíz: Puerto 445 bloqueado o negociación/auth SMB fallando; ping es ICMP y te dice casi nada sobre la alcanzabilidad SMB.

Solución: Prueba con nc -vz host 445 y smbclient. Luego ajusta reglas de firewall u opciones de autenticación.

8) Síntoma: Abriste 445, pero aún falla para usuarios de dominio

Causa raíz: Ruta de autenticación bloqueada: el servidor no puede alcanzar controladores de dominio para Kerberos/LDAP/DNS desde esa interfaz/subred.

Solución: Asegura que el servidor de archivos pueda alcanzar DCs en los puertos requeridos desde esa interfaz/subred, o usa diseño de sitio/subred apropiado para que la autenticación permanezca local.

Listas de verificación / plan paso a paso

Paso a paso: cuando RDP funciona pero el recurso compartido no

1. Confirma identidad: Asegura que el nombre al que navegas resuelva a la misma IP a la que hiciste RDP.
2. Prueba transporte: Desde la red cliente, prueba TCP/445 al IP del servidor.
3. Confirma servicio: En el servidor, confirma que el puerto 445 está escuchando y que el servicio SMB está en ejecución.
4. Confirma perfil y coincidencia de regla: En Windows, revisa el perfil activo del firewall y asegura que la regla SMB-In esté habilitada para él.
5. Acota el allow: Establece RemoteAddress a subredes cliente aprobadas. Evita “Any” a menos que el servidor ya esté detrás de una frontera de red confiable y sea una decisión consciente.
6. Vuelve a probar el puerto 445: Si ahora es alcanzable, prueba listados/mapeos SMB.
7. Prueba la auth SMB explícitamente: Usa net use o smbclient -L para separar errores de autenticación de errores de conectividad.
8. Comprueba la alcanzabilidad de DCs (entornos de dominio): Si falla auth, prueba DNS/Kerberos/LDAP desde el servidor hacia los DCs.
9. Solo entonces: Corrige permisos de compartición y ACLs NTFS, porque ahora estás en la capa correcta.
10. Captura paquetes si el comportamiento es inconsistente: Especialmente si ocurren resets/timeouts a mitad de transferencia.

Lista: calidad de reglas de firewall (la lista “para no avergonzarte después”)

• La regla tiene un nombre y propósito claros (“Permitir SMB desde subredes VDI”).
• El allow entrante está acotado por RemoteAddress (o equivalente CIDR de origen).
• Solo se abren los puertos necesarios (normalmente TCP/445; añade 139/137/138 solo con justificación).
• El logging se habilita temporalmente durante despliegues o troubleshooting, luego se reduce.
• Las reglas se aplican mediante tu sistema real de configuración (GPO, Ansible, DSC), no por “clics de conocimiento tribal”.
• Los casos de prueba cubren al menos dos redes cliente reales (VDI + subred app, o oficina + VPN).
• Existe un plan de rollback (restaurar políticas/reglas previas) y se prueba en no-prod.

Lista: cuando debes abrir SMB entre segmentos

• Confirma que el segmento es confiable y está monitorizado.
• Usa mínimo privilegio: solo los servidores de archivos, solo TCP/445, solo desde fuentes específicas.
• Prefiere SMB3 con firma (y cifrado cuando sea requerido).
• Tener detección: logs de conexiones denegadas y alertas por comportamiento de escaneo.
• Documenta la dependencia (qué apps, qué subredes, qué responsables).

Preguntas frecuentes

1) Si RDP funciona, ¿no significa que el firewall permite tráfico?

Significa que el firewall permite una cosa: TCP/3389 (o el puerto que use tu gateway RDP). SMB es TCP/445 y a menudo forma parte de grupos, perfiles y alcances distintos.

2) ¿Qué puerto único necesito para compartir archivos en Windows?

Normalmente TCP/445. Si tratas con SMB NetBIOS heredado, también podrías ver TCP/139 y UDP/137-138, pero trátalos como excepciones que justificar, no como valores por defecto que habilitas.

3) ¿Por qué funciona por IP pero no por hostname?

Resolución de nombres. SMB puede usar una ruta de resolución distinta a la de tu cliente RDP. Arregla DNS, usa FQDNs y deja de revivir NetBIOS para lidiar con problemas.

4) ¿Debo habilitar “File and Printer Sharing” en el perfil Público?

Solo si además restringes las direcciones remotas de la regla a subredes conocidas y confiables. “Público + Any” es un hallazgo de auditoría esperando suceder.

5) Abrí 445 en el servidor, pero los clientes aún no se conectan. ¿Ahora qué?

Demuestra dónde está el bloqueo. Si el servidor nunca ve el SYN, está río arriba (ACL de red, grupo de seguridad, enrutamiento). Si el servidor ve el SYN pero no responde, es firewall local o binding del servicio.

6) ¿Un antivirus o seguridad endpoint puede bloquear SMB aunque el firewall lo permita?

Sí. Algunos productos de endpoint incluyen inspección de red o reglas de “reducción de superficie de ataque” que pueden bloquear o interferir con SMB. Prueba con capturas de paquetes y revisa logs del producto.

7) ¿Por qué veo “SMB1 disabled” y debería preocuparme?

Debes estar aliviado. SMB1 es legado y poco seguro. El mensaje suele ser informativo de las herramientas. Si un dispositivo antiguo requiere SMB1, aísla y firewalléalo fuerte en lugar de degradar todo tu entorno.

8) ¿Necesito abrir puertos a controladores de dominio para que SMB funcione?

No siempre, pero a menudo sí. El acceso SMB autenticado por dominio depende de Kerberos/LDAP/DNS. Si el servidor de archivos no puede alcanzar DCs desde esa red, puedes obtener fallos de autenticación incluso cuando TCP/445 está abierto.

9) ¿Cuál es la forma más segura de permitir SMB para usuarios remotos?

No expongas SMB directamente a Internet. Usa VPN con enrutamiento y ACLs correctas, o un gateway de acceso a archivos diseñado para remoto. Luego acota SMB a la subred de clientes VPN y a los servidores de archivos.

10) Mi montaje CIFS en Linux falla, pero clientes Windows funcionan. ¿Es tema de firewall?

A veces. A menudo son opciones de dialecto/firma/cifrado SMB o formato de credenciales. Primero verifica conectividad TCP/445 desde el host Linux, luego prueba con smbclient, y ajusta opciones de montaje.

Próximos pasos que puedes hacer hoy

Deja de tratar “RDP funciona” como luz verde para todo lo demás. Es un único punto de datos y frecuentemente el más engañoso porque te hace confiar demasiado.

Haz esto a continuación:

1. Desde una red cliente afectada, prueba TCP/445 al IP del servidor. Sin pase, no hay SMB.
2. En el servidor, confirma que el puerto 445 está escuchando y que el servicio SMB está en ejecución.
3. Revisa el perfil del firewall de Windows y la regla efectiva “File and Printer Sharing (SMB-In)”. Habilítala donde haga falta y acota RemoteAddress a subredes cliente reales.
4. Si la conexión funciona por IP pero no por nombre, arregla DNS. No revivas NetBIOS como medida temporal.
5. Si el transporte funciona pero la autenticación falla, confirma que el servidor puede alcanzar controladores de dominio (DNS/Kerberos/LDAP) desde esa interfaz.
6. Escribe el cambio final en tu sistema de configuración (GPO/DSC/Ansible) y añade una prueba de puerto simple a tu checklist de cambios.

Así es como lo arreglas correctamente: no abriendo puertos al azar, sino demostrando la capa que falla y ajustando la regla mínima que restaura el flujo previsto.