Nada sube más la presión arterial que “el servidor está arriba pero nadie puede conectarse”. El equipo de aplicaciones jura que es la red. El equipo de red jura que es la aplicación. El administrador de Windows guarda silencio porque acaba de “limpiar las reglas del firewall” y ahora todos esperan que ese silencio sea tu problema.
Windows Defender Firewall no es complicado como lo es BGP. Es complicado como una gran cocina de oficina: todo el mundo dejó algo, la mitad está mal etiquetada y un recipiente definitivamente está goteando. La buena noticia es que puedes llegar a un conjunto de reglas estable, mínimo y auditable. La mejor noticia: muchos valores predeterminados de Windows merecen confianza, si entiendes qué hacen realmente.
Las reglas que realmente importan (90% de los resultados)
La mayoría de los conjuntos de reglas del Firewall de Windows son ruidosos por la misma razón por la que la mayoría de los armarios son desordenados: nadie quiere tirar algo que podría ser necesario. Así terminas con 700 reglas entrantes, 600 deshabilitadas y unas cuantas entradas “TEMP – NO BORRAR” de 2019 que todo el mundo teme tocar.
Si gestionas sistemas de producción, hay un pequeño número de categorías de reglas que deciden si tienes un día normal o una avalancha de tickets:
1) Acceso de gestión remota (RDP, WinRM, WMI)
Esto es existencial. Si bloqueas tu propio plano de administración, tu “endurecimiento” de seguridad se convierte en generador de outages. Decide qué gestión remota usas y permítela explícitamente desde fuentes conocidas. Luego pruébalo desde esas fuentes.
- RDP TCP/3389 (o tu puerto personalizado, si insistes)
- WinRM TCP/5985 (HTTP) y TCP/5986 (HTTPS)
- WMI/DCOM RPC endpoint mapper TCP/135 más puertos RPC dinámicos (más sobre esto más adelante)
2) Puertos reales de escucha de la aplicación
Si la aplicación escucha en TCP/443, te importa TCP/443 entrante. Todo lo demás es reparto de apoyo. No “abras un rango por si acaso”. Abre el puerto al que se enlaza el servicio, con alcance a las redes de origen que lo necesitan.
3) Resolución de nombres y sincronización horaria (DNS, NTP)
DNS rompe todo mientras parece no hacer nada. La deriva horaria rompe la autenticación mientras parece “aleatorio”. DNS saliente (UDP/TCP 53) y NTP saliente (UDP 123) son las reglas aburridas con las que no debes volverte creativo.
4) Dependencias de servicios de directorio (para servidores unidos al dominio)
Kerberos, LDAP/LDAPS y la ocasional llamada RPC son los pilares ocultos bajo “el inicio de sesión funciona” y “la GPO se aplica”. Muchas organizaciones se apañan con “permitir cualquier salida” en servidores, lo cual es desordenado pero funcional. Si cierras la salida, las dependencias del dominio deben planificarse, no descubrirse a las 2 a.m.
5) Compartición de archivos (SMB) y recursos administrativos
SMB es potente y frecuentemente abusado. Para servidores que no necesitan SMB entrante, bloquéalo. Para servidores que sí, limita el alcance y registra las conexiones.
- SMB TCP/445
- Los puertos legados NetBIOS (UDP/137, UDP/138, TCP/139) deberían considerarse como “¿por qué sigue esto aquí?”
6) Controles de salida que evitan que un “incidente pequeño se vuelva grande”
Las reglas entrantes evitan accesos no solicitados. Las reglas salientes evitan que tu servidor se convierta en un entusiasta participante en el negocio de otra persona. En un entorno maduro, la política de salida importa—especialmente para servidores que solo deberían hablar con unas pocas dependencias internas.
Una verdad seca: si no estás preparado para inventariar dependencias, no empieces con un bloqueo saliente agresivo. Solo crearás un nuevo deporte llamado “adivina la salida faltante”.
Broma #1: Una regla de firewall llamada “TEMP” tiene una semivida más larga que el plutonio en la mayoría de las empresas.
Valores predeterminados en los que puedes confiar (y cuándo no)
Los valores predeterminados de Windows Defender Firewall no son aleatorios. Están diseñados para mantener el sistema operativo usable en una gama ridícula de entornos: portátiles en Wi‑Fi de cafetería, servidores en un dominio, equipos de desarrollo con toolchains cuestionables y quioscos que nunca deberían haber estado online.
Qué puedes confiar en general
- Comportamiento predeterminado entrante: bloquear tráfico entrante no solicitado a menos que una regla lo permita. Esta es la base correcta para hosts Windows.
- Comportamiento stateful: las conexiones establecidas funcionan como se espera. Si tu servidor inicia una conexión TCP saliente, el tráfico de retorno está permitido sin necesitar reglas entrantes para puertos efímeros.
- Reglas de red básicas: existen muchas reglas integradas para que Windows pueda hacer cosas de Windows (DHCP, comportamiento del cliente DNS, ICMP básico, etc.). No necesitas “simplificar” borrándolas. Deshabilita o limita intencionalmente si es necesario, pero no vayas a lo extremo.
- Diferentes perfiles: la separación Dominio/Privado/Público es realmente útil—cuando la máquina está correctamente clasificada.
Dónde los predeterminados pueden traicionarte
Los predeterminados solo son tan buenos como las suposiciones detrás de ellos. Aquí es donde te puedes ver perjudicado:
- Mala clasificación de perfil: un servidor que piensa que está en una red Pública aplicará el perfil Público. Ese perfil suele ser más restrictivo. Resultado: “funcionaba ayer, nada cambió”, excepto que sí cambió.
- Reglas “Permitir si es seguro”: algunas reglas integradas dependen de IPsec o contexto de autenticación. Si no usas eso, esas reglas pueden no comportarse como “permitir”.
- Herramientas de seguridad de terceros: las suites de protección de endpoints a veces añaden callouts, filtros WFP o reglas locales. Terminarás resolviendo “Windows Firewall” cuando el bloqueo esté en otra capa de la pila.
- Reglas locales vs reglas de GPO: en entornos de dominio las políticas se fusionan. Tu “arreglo” local puede ser anulado o puede no aplicarse, y diagnosticarás mal si no compruebas la política efectiva.
La postura práctica: confía en el comportamiento base (stateful, denegar entrante por defecto), confía en las reglas de plomería integradas del OS salvo que tengas una razón, y desconfía de todo lo que dependa de que el perfil de red esté “correcto” hasta que lo verifiques.
Perfiles: Dominio vs Privado vs Público (y por qué la mala clasificación arruina días)
Windows Defender Firewall aplica reglas por perfil. Los perfiles no son cosméticos. Son, en efecto, diferentes conjuntos de políticas. Si el perfil está mal, jurarás que el firewall es “aleatorio”. No lo es. Obedece—solo que al perfil equivocado.
Perfil de Dominio
Se aplica cuando Windows cree que está conectado a su dominio y puede alcanzar un controlador de dominio. En entornos de servidor, aquí es donde normalmente pones tu política real: permitir gestión desde bastiones, permitir puertos de aplicaciones desde balanceadores de carga, permitir monitoreo desde subredes de monitoreo, bloquear el resto.
Perfil Privado
Típicamente para redes no dominadas pero de confianza. En empresas, a menudo termina como “perfil de laboratorio de desarrollo” o “perfil de servidor en grupo de trabajo”. Trátalo como semi-confiable. No lo conviertas en un comodín de “permitir todo”.
Perfil Público
Para redes no confiables. A los portátiles les encanta este perfil. Los servidores casi nunca deberían estar en él—salvo cuando lo están, porque alguien colocó un servidor en una DMZ sin accesibilidad al dominio y olvidó que Windows clasifica según la detección de la red.
Diagnósticamente: cuando algo falla después de un reinicio, después de mover subredes, tras cambios en VPN o después de una ventana de mantenimiento del controlador de dominio, verifica el perfil activo antes de hacer cualquier cosa ingeniosa.
Evaluación de reglas y precedencia: cómo Windows decide “permitir” vs “nope”
Windows Defender Firewall puede parecer una hoja de cálculo hasta que te das cuenta de que se implementa mediante la Windows Filtering Platform (WFP). No necesitas convertirte en un ingeniero de WFP, pero sí necesitas algunos modelos mentales:
Filtrado stateful: el tráfico de retorno no es “entrante permitido”
Si un servidor realiza una conexión saliente a TCP/443, la respuesta está permitida. A veces la gente crea reglas entrantes para puertos efímeros para “arreglar” esto, y así terminas con políticas tipo queso suizo.
Las reglas de bloqueo ganan a las de permitir
Si el tráfico coincide con una regla de bloqueo explícita, se bloquea incluso si otra regla lo permitiría. Esto es bueno. Te permite diseñar excepciones “permitir amplio, bloquear específico” (o al revés) según tu estilo de política. Pero también significa que una única regla de bloqueo demasiado amplia puede matar el acceso silenciosamente.
Las reglas más específicas no siempre tienen “mayor prioridad” como esperas
Windows evalúa según el conjunto de reglas aplicables. No puedes confiar en “hice la regla después” como mecanismo de prioridad. Debes asegurarte de que no exista una regla de bloqueo en conflicto y validar la política efectiva.
GPO vs política local: la realidad fusionada
En entornos de dominio, las reglas pueden venir de:
- Política de firewall local en el host
- Reglas de firewall de Group Policy
- Callouts de terceros al WFP (no son “reglas” pero se comportan como filtros)
Cuando alguien dice “lo permití en el firewall”, tu siguiente pregunta debería ser “¿en qué capa, y es efectivo?”
Servicios básicos de Windows: los puertos que debes considerar, no memorizar
Las listas de puertos son útiles hasta que se vuelven un culto cargo. Piensa en dependencias y roles:
Dependencias de identidad y dominio
- Kerberos: TCP/UDP 88 (autenticación)
- LDAP: TCP/UDP 389; LDAPS: TCP/636
- Catálogo global: TCP 3268/3269
- DNS: TCP/UDP 53 (porque AD está pegado a DNS)
- Hora: UDP 123 (a Kerberos le importa mucho)
Plano de gestión
- RDP: TCP 3389
- WinRM: TCP 5985/5986
- Registro remoto de eventos / herramientas MMC: pueden requerir RPC/SMB dependiendo de cómo las uses
Compartir archivos e impresión (SMB)
SMB (TCP/445) es lo que importa. Si todavía ves puertos NetBIOS en 2026, pregunta “¿qué dependencia legada nos tiene secuestrados?” y planifica su retirada.
Puertos dinámicos RPC: la parte que la gente rompe a propósito
RPC no es “abre 135 y ya”. TCP/135 es el endpoint mapper. El servicio real suele usar puertos dinámicos. Si necesitas permitir gestión basada en RPC a través de firewalls, normalmente restringes el rango de puertos dinámicos y permites ese rango explícitamente. Si no, acabarás con (a) cosas fallando al azar, o (b) un rango enorme de puertos abiertos “temporalmente”.
Tareas prácticas: 12+ comandos, salidas y decisiones
Estos son los comandos que realmente ejecuto cuando estoy en una máquina Windows (o en una sesión remota) intentando responder a una pregunta: “¿Es el firewall la razón por la que este tráfico muere?” Cada tarea incluye qué significa la salida y la decisión que tomas después.
Task 1: Check which firewall profiles are active
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction"
Name Enabled DefaultInboundAction DefaultOutboundAction
---- ------- -------------------- ---------------------
Domain True Block Allow
Private False Block Allow
Public False Block AllowQué significa: El perfil Dominio está activo y aplica “Bloquear entrante, Permitir saliente.” Esa es una base sensata.
Decisión: Si está habilitado el perfil equivocado (Público en un servidor de dominio), corrige la clasificación de la red antes de tocar las reglas.
Task 2: Confirm the network category (Private/Public) and domain connectivity signal
cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory, IPv4Connectivity, DomainAuthenticationKind"
InterfaceAlias NetworkCategory IPv4Connectivity DomainAuthenticationKind
-------------- -------------- --------------- ------------------------
Ethernet0 DomainAuthenticated Internet KerberosQué significa: Windows cree que está autenticado en el dominio. Bien. Si esto dice Público, espera una política más restrictiva.
Decisión: Si la categoría es incorrecta tras un movimiento, verifica problemas de NLA, DNS y alcance al DC; no “soluciones” con excepciones amplias del firewall.
Task 3: Verify the service is actually listening
cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -in 443,3389,5985 } | Select-Object LocalAddress, LocalPort, OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- ------------
0.0.0.0 443 4120
0.0.0.0 3389 1096Qué significa: Algo está escuchando en 443 y 3389. Si el puerto no está escuchando, el firewall no es tu principal sospechoso.
Decisión: Si no está escuchando, ve a la configuración del servicio/enlace de la app primero. No abras puertos para servicios que no existen.
Task 4: Map the listening port to a process and service
cr0x@server:~$ powershell -NoProfile -Command "$p=Get-Process -Id 4120; $p.Name"
w3wpQué significa: El proceso worker de IIS posee 443. Ahora sabes qué estás protegiendo y qué podrías romper.
Decisión: Si el proceso propietario es inesperado, puede que tengas el servicio equivocado enlazado al puerto o un servicio sombra que lo esté secuestrando.
Task 5: Check effective inbound rules that match a port (example: 443)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 443 } | Select-Object InstanceID, LocalPort, Protocol"
InstanceID LocalPort Protocol
---------- --------- --------
{A1B2C3D4-1111-2222-3333-444455556666} 443 TCPQué significa: Hay al menos una regla allow habilitada para TCP/443 entrante.
Decisión: Si no existe una regla allow, crea una limitada a las fuentes requeridas. Si existe, busca una regla de bloqueo en conflicto o una discrepancia de perfil.
Task 6: Hunt for explicit block rules that could override your allow
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Block | Select-Object DisplayName, Profile, PolicyStoreSource | Format-Table -AutoSize"
DisplayName Profile PolicyStoreSource
----------- ------- -----------------
Block inbound from guest VLAN Domain GroupPolicy
Block all inbound (temporary) Domain,Public LocalQué significa: Un “Block all inbound” local puede arruinar tu día, y ganará a muchas reglas allow.
Decisión: Si existe un bloqueo demasiado amplio, deshabilítalo o níñelo, y luego vuelve a probar. También: averigua quién lo creó y por qué.
Task 7: Validate the rule scope (remote addresses) for the allow rule
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Where-Object DisplayName -Match 'HTTPS' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
RemoteAddress
-------------
10.20.30.0/24Qué significa: La regla solo permite una subred específica. Genial para la seguridad; terrible si tu balanceador de carga vive en otro sitio.
Decisión: Si clientes legítimos están fuera de ese alcance, expande el alcance con cuidado (añade las subredes correctas), no a “Any”.
Task 8: Turn on firewall logging (temporarily) for the active profile
cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallProfile -Name Domain -LogAllowed True -LogBlocked True -LogFileName 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' -LogMaxSizeKilobytes 32768"
Qué significa: El registro queda habilitado. Esto te ayuda a dejar de adivinar.
Decisión: Usa el registro durante un incidente y luego ajusta: mantén el registro de bloqueos activado para servidores clave, pero no llenes discos en equipos ruidosos.
Task 9: Read recent blocked traffic from the firewall log
cr0x@server:~$ powershell -NoProfile -Command "Get-Content 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' -Tail 10"
2026-02-05 12:01:21 DROP TCP 10.20.40.15 10.20.30.10 51512 443 60 S 1234567890 0 65535 - - - RECEIVE
2026-02-05 12:01:22 DROP TCP 10.20.40.15 10.20.30.10 51513 443 60 S 1234567891 0 65535 - - - RECEIVEQué significa: El cliente 10.20.40.15 está siendo descartado al conectar con 10.20.30.10:443. Ese es tu indicio claro.
Decisión: Añade/ajusta una regla allow para esa fuente (o corrige el enrutamiento/NAT si la IP de origen no es la esperada).
Task 10: Test connectivity to a remote service from the Windows host
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.50.20 -Port 1433"
ComputerName : 10.20.50.20
RemoteAddress : 10.20.50.20
RemotePort : 1433
InterfaceAlias : Ethernet0
SourceAddress : 10.20.30.10
TcpTestSucceeded : TrueQué significa: La salida a SQL Server funciona desde este host (al menos el handshake TCP).
Decisión: Si esto falla, investiga reglas salientes, perfil y cualquier firewall upstream. Si funciona pero la app falla, estás ante problemas de autenticación, TLS o capa de aplicación.
Task 11: List outbound rules that might be blocking critical egress
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block' | Select-Object DisplayName, Profile, PolicyStoreSource | Format-Table -AutoSize"
DisplayName Profile PolicyStoreSource
----------- ------- -----------------
Block outbound to Internet Domain GroupPolicy
Block outbound except allowlist Domain GroupPolicyQué significa: Estás en un entorno con restricción de salida (bueno), y ahora debes asegurar que las dependencias estén explícitamente permitidas (también bueno, pero trabajo).
Decisión: Si falta la dependencia, añade una regla allow para las IP/puertos de destino y documenta por qué existe.
Task 12: Check which rules are coming from GPO vs local
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True | Select-Object -First 5 DisplayName, PolicyStoreSource, PolicyStoreSourceType | Format-Table -AutoSize"
DisplayName PolicyStoreSource PolicyStoreSourceType
----------- --------------- ---------------------
Core Networking - DNS (UDP-Out) Local Local
Allow HTTPS inbound to web tier GroupPolicy GroupPolicy
Block all inbound (temporary) Local Local
Allow WinRM from bastion GroupPolicy GroupPolicy
Core Networking - DHCP (UDP-Out) Local LocalQué significa: Puedes ver la procedencia. Esto termina discusiones.
Decisión: Si una regla local entra en conflicto con GPO, decide si las reglas locales están permitidas; a menudo la solución correcta está en GPO para que sea consistente.
Task 13: Confirm whether local rules are even allowed (GPO setting can disable them)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile -Name Domain | Select-Object Name, AllowLocalRules, AllowLocalIPsecRules"
Name AllowLocalRules AllowLocalIPsecRules
---- -------------- --------------------
Domain True TrueQué significa: Las reglas locales pueden aplicarse. Si esto fuera False, los “arreglos” locales no ayudarán.
Decisión: Si las reglas locales están deshabilitadas, deja de editarlas y ve a la fuente de la política (GPO) o al equipo que la gestiona.
Task 14: Quick snapshot of firewall status (legacy netsh still useful)
cr0x@server:~$ netsh advfirewall show allprofiles
Domain Profile Settings:
----------------------------------------------------------------------
State ON
Firewall Policy BlockInbound,AllowOutbound
LocalFirewallRules N/A (GPO-store only)
LocalConSecRules N/A (GPO-store only)
Logging:
LogAllowedConnections Enable
LogDroppedConnections Enable
FileName C:\Windows\System32\LogFiles\Firewall\pfirewall.log
MaxFileSize 32768
Private Profile Settings:
----------------------------------------------------------------------
State OFF
Public Profile Settings:
----------------------------------------------------------------------
State OFFQué significa: Dominio está ON; las reglas locales no son aplicables porque la política está solo en GPO (este estilo de salida varía por versión/política).
Decisión: Si ves “GPO-store only”, debes arreglar las reglas en el nivel de GPO, no mediante cambios locales.
Task 15: Capture a targeted firewall trace when logs aren’t enough
cr0x@server:~$ netsh wfp capture start file=C:\Temp\wfptrace.cab
WFP capture started.cr0x@server:~$ netsh wfp capture stop
WFP capture stopped.Qué significa: Capturaste eventos WFP. Esto es más pesado que pfirewall.log y útil cuando un callout de terceros está bloqueando tráfico.
Decisión: Usa esto cuando sospeches fuertemente “no son las reglas del firewall, es algo en WFP” y necesites evidencia para el propietario de la herramienta de seguridad.
Task 16: Add a safe, scoped inbound allow rule (example: allow HTTPS from load balancers)
cr0x@server:~$ powershell -NoProfile -Command "New-NetFirewallRule -DisplayName 'Allow HTTPS from LB subnets' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 443 -RemoteAddress 10.20.40.0/24,10.20.41.0/24 -Profile Domain"
Qué significa: Añadiste una regla allow estrechamente definida en el perfil Domain únicamente.
Decisión: Vuelve a probar inmediatamente desde esas subredes. Si funciona, incorpora el cambio en tu proceso de policy-as-code o en GPO para que sobreviva auditorías y reconstrucciones.
Task 17: Temporarily disable a suspicious rule (with a paper trail)
cr0x@server:~$ powershell -NoProfile -Command "Disable-NetFirewallRule -DisplayName 'Block all inbound (temporary)'"
Qué significa: Esa regla ya no se aplica.
Decisión: Si el servicio se recupera, encontraste al culpable. Entonces reemplázala por una regla de bloqueo precisa o elimínala de la fuente de la verdad. No dejes reglas “temporales” deshabilitadas como artefactos permanentes.
Guía rápida de diagnóstico (primero/segundo/tercero)
Cuando una conexión falla, usualmente persigues una de cuatro cosas: el servicio no está escuchando, la ruta es incorrecta, un firewall está bloqueando o TLS/autenticación está fallando. El truco es identificar en qué categoría estás en minutos, no en reuniones.
Primero: demuestra que el servicio existe en el destino
- Comprueba que el puerto esté escuchando (
Get-NetTCPConnection -State Listen). - Confirma el proceso/servicio que lo posee (mapea PID a proceso).
- Si no está escuchando, para. Arregla el servicio. Las reglas del firewall no resucitarán un listener.
Segundo: demuestra que los paquetes están llegando (o no)
- Activa el registro del firewall (a corto plazo) y busca DROPs al puerto de destino.
- Si ves DROPs, es firewall local o WFP. Si no ves nada, el tráfico puede no estar llegando al host (ACL upstream, enrutamiento, VIP equivocado, IP equivocada).
- Valida que la IP de origen que aparece en los registros coincide con la esperada (a los balanceadores y al NAT les encantan las sorpresas).
Tercero: valida la política efectiva y conflictos
- Revisa el perfil activo. Los hosts mal perfilados son el asesino silencioso.
- Busca reglas de bloqueo que puedan anular allows.
- Verifica el alcance de la regla (direcciones remotas, tipos de interfaz, perfiles).
- Confirma la fuente de la regla (GPO vs local). No “arregles localmente” lo que se aplica centralmente.
Cuarto (cuando sigue raro): sospecha de callouts WFP y seguridad endpoint
- Si los logs muestran permitido pero el tráfico aún falla, o no aparece nada, captura un trace de WFP.
- Correlaciona con cambios en seguridad endpoint. El “firewall” puede no ser el componente que está bloqueando.
Tres mini-historias corporativas desde las trincheras del firewall
Mini-historia 1: El incidente causado por una suposición equivocada (perfil ≠ dominio)
El entorno estaba ordenado en papel: servidores web Windows en un dominio, reglas de firewall gestionadas por GPO, entrantes solo desde balanceadores, gestión solo desde un bastion. El tipo de configuración que hace asentir a los auditores y dormir a los operadores.
Entonces una ventana de mantenimiento dejó fuera de servicio un par de controladores de dominio en un sitio remoto. Ese sitio también hospedaba un puñado de servidores web detrás de un balanceador local. Los servidores siguieron funcionando, pero en una hora las comprobaciones de salud empezaron a fallar. La mitad del pool pasó a “no saludable”, luego la mayor parte.
Todos inicialmente persiguieron al balanceador. El VIP estaba estable. La configuración de health check no había cambiado. El equipo de red mostró flujos limpios en el switch. El equipo de aplicación insistía en que el servicio estaba arriba. Estaba—localmente.
El problema real: los servidores cambiaron silenciosamente de DomainAuthenticated a Público porque no podían alcanzar un controlador de dominio. El perfil Público no tenía regla allow entrante para la fuente del health check, porque nadie esperaba que un servidor de dominio alguna vez fuera “Público”. El firewall hizo exactamente lo que le indicaron, en el perfil que creía activo.
La solución no fue “abrir más puertos”. La solución fue hacer el entorno resistente a fallos de alcance al DC: asegurar conectividad redundante a controladores de dominio, y para roles específicos tipo DMZ, definir explícitamente qué debe pasar si el perfil Domain deja de estar activo. Además, hacer que el monitoreo alerte sobre cambios de perfil. El outage no lo causó el firewall; lo causó una suposición.
Mini-historia 2: La optimización que salió mal (deny saliente sin inventario)
Un programa de seguridad decidió “reducir la superficie de ataque” implementando deny por defecto de salida en servidores Windows. Filosóficamente, tiene sentido. Prácticamente, es un proyecto de descubrimiento de dependencias con gabardina.
Lo desplegaron por fases. Al principio los resultados parecían buenos: menos tráfico saliente, menos conexiones extrañas a internet, muchos dashboards mostrando tendencias favorables. Entonces llegó la noche de parches.
Windows Update fue bloqueado. También las comprobaciones CRL/OCSP para certificados TLS en algunas aplicaciones. El agente de monitoreo no pudo alcanzar su colector porque alguien olvidó que usaba TCP/443 hacia un endpoint SaaS. Mientras tanto el equipo de operaciones, intentando estabilizar, añadió reglas allow ad-hoc a nivel local—solo para descubrir que las reglas locales estaban deshabilitadas por GPO.
El fallo no fue que el control saliente sea malo. El fallo fue tratarlo como una “optimización” puntual en lugar de una capacidad operativa. El allowlisting saliente requiere un catálogo mantenido de dependencias, un proceso de excepciones rápido y observabilidad (logs) para ver qué estás bloqueando.
Finalmente lo consiguieron, pero solo después de crear una canalización de listas de permitidos ligada a manifiestos de aplicaciones y etiquetas de entorno. Lección: los controles de seguridad que no son operables se vuelven outages. Los outages se convierten en excepciones. Las excepciones se convierten en la política real.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día (reglas con alcance + registro)
Un sistema financiero tenía una regla simple: cada servidor Windows de producción debía tener el registro de paquetes descartados habilitado en el perfil Domain, con logs enviados a un colector central. No eternamente verbose; lo suficiente para responder “¿qué fue bloqueado?” sin hacer RDP a todo.
Una mañana, un job por lotes empezó a fallar al alcanzar un servidor de archivos. El job se ejecutaba desde una cuenta de servicio en un servidor de aplicaciones, y había funcionado durante años. El equipo de archivos dijo que “no cambiaron nada”. El equipo de aplicaciones dijo que “no cambiaron nada”. Todos tenían razón técnica, que es la peor clase de razón.
Los logs de DROP contaron la historia en cinco minutos: la IP de origen había cambiado. El servidor de aplicaciones se había reconstruido en una nueva subred como parte de una limpieza de virtualización. La regla SMB en el servidor de archivos permitía SMB solo desde la subred antigua. Eso fue todo. Sin misterio.
La solución igual de aburrida: actualiza la regla SMB para incluir la nueva subred, valida el acceso y actualiza la automatización de build para que las reconstrucciones registren sus nuevas direcciones en la fuente de verdad del alcance de reglas. Nadie tuvo que adivinar. Nadie tuvo que “abrir 445 a Any temporalmente”. La práctica aburrida—reglas con alcance más logs centralizados de drops—salvó el día.
Broma #2: La forma más rápida de aprender de qué depende tu aplicación es bloquear el tráfico saliente y esperar a que alguien grite.
Errores comunes: síntoma → causa raíz → solución
1) “Funciona desde una subred pero no desde otra”
Síntoma: Algunos clientes se conectan bien; otros hacen time out o reciben rechazo.
Causa raíz: La regla Allow tiene un alcance RemoteAddress estrecho que no incluye la subred fallida, o el tráfico está NATeado de modo que la IP origen difiere.
Solución: Revisa los logs de drop para la IP de origen real. Amplía el alcance de la regla para incluir los rangos correctos. Si hay NAT, coordina con el equipo de red para permitir la IP traducida.
2) “Después del reinicio, nada puede conectar”
Síntoma: El servidor arranca, los servicios están corriendo, pero el acceso entrante muere.
Causa raíz: Cambió el perfil (Dominio → Público) por problemas de NLA/alcance al DC. O se reaplicó la GPO y se eliminó una excepción local.
Solución: Verifica el perfil y el estado de autenticación de dominio. Arregla DNS/alcance al DC. No metas una regla allow amplia en Público a menos que intentes soportar intencionalmente un escenario sin dominio.
3) “RDP está bloqueado pero la regla está habilitada”
Síntoma: RDP hace timeout; ves una regla allow para 3389.
Causa raíz: La regla aplica al perfil equivocado, tipo de interfaz incorrecto, o está anulada por una regla de bloqueo más amplia. También es posible: RDP se movió a otro puerto y la regla no se actualizó.
Solución: Confirma el puerto de escucha, el perfil activo y busca reglas de bloqueo entrantes. Limita la regla allow a la red del bastión únicamente. Verifica que la configuración del servicio coincida con la regla.
4) “WinRM funciona en algunos servidores pero no en otros”
Síntoma: La automatización falla contra un subconjunto de hosts Windows.
Causa raíz: Aplicación inconsistente de GPO, reglas locales deshabilitadas en algunos hosts, o WinRM enlazado a HTTPS sin una cadena de certificados alcanzable (parece “red”).
Solución: Revisa la fuente de la política. Valida la configuración del listener y los puertos de WinRM. Si usas 5986, asegúrate de la cadena de confianza del certificado y de la accesibilidad CRL/OCSP (las reglas salientes importan).
5) “DNS está roto pero solo en este servidor”
Síntoma: La resolución de nombres falla; la conectividad IP está bien.
Causa raíz: UDP/53 saliente bloqueado por una política de restricción saliente, o el fallback a TCP de DNS bloqueado, o configuración de servidor DNS incorrecta combinada con limitaciones salientes.
Solución: Prueba UDP y TCP hacia el servidor DNS. Añade allows salientes explícitos a los servidores DNS. Verifica la configuración DNS del servidor y cualquier reenviador condicional del entorno.
6) “La app del vendor necesita ‘un montón de puertos’, así que abrimos 1–65535”
Síntoma: El vendor insistió. Se aprobó el cambio. Nadie recuerda para qué fue.
Causa raíz: Falta de mapeo de dependencias y gestión de cambios basada en el miedo.
Solución: Revierte al principio de menor privilegio: identifica listeners reales, restringe rangos dinámicos RPC si es necesario, permite solo las fuentes requeridas. Usa logs para verificar qué se bloquea al endurecer.
7) “Creamos la regla pero aún no funciona”
Síntoma: La regla del firewall existe; el tráfico sigue fallando.
Causa raíz: La regla está en la tienda local pero las reglas locales están deshabilitadas por GPO. O la regla está habilitada pero no es aplicable por perfil/tipo de interfaz equivocado.
Solución: Revisa AllowLocalRules y la fuente de la regla. Pon la regla en la tienda de política correcta (típicamente GPO) y asegúrate de que coincida con el perfil activo.
Listas de verificación / plan paso a paso
Checklist A: Postura mínima viable de firewall para servidores Windows
- Mantén el bloqueo entrante predeterminado en todos los perfiles. No “permitas todo entrante temporalmente.” Haz que eso sea socialmente inaceptable.
- Permite la gestión (RDP/WinRM) solo desde subredes bastión/jump. Si lo permites desde “Any”, te has creado un blanco.
- Permite puertos de aplicación solo desde las redes cliente reales (balanceadores, capas app, subredes de usuarios según sea necesario).
- Permite salida a DNS y NTP internos explícitamente si aplicas restricciones salientes.
- Bloquea SMB entrante en servidores que no lo necesiten. Si lo necesitan, permite solo desde redes de administración.
- Habilita el registro de paquetes descartados al menos en capas críticas, y centraliza los logs.
- Documenta excepciones con propietario + fecha de expiración. Luego haz cumplir la expiración.
Checklist B: Cuando te piden “abrir puertos para una app”
- Identifica los puertos de escucha de la app en el host (no confíes en el PDF del vendor).
- Identifica las redes de origen que necesitan acceso (clientes, balanceadores, monitoreo, jobs batch).
- Crea reglas allow entrantes con alcance por: perfil, protocolo, puerto local, dirección remota y (si es posible) programa/servicio.
- Si RPC está implicado, restringe el rango de puertos dinámicos y permite ese rango—no abras “todos los puertos altos”.
- Habilita logging durante el despliegue. Verifica que los clientes esperados sean permitidos y que escaneos inesperados sean bloqueados.
- Captura el conjunto de reglas en el sistema de registro (plantilla GPO, gestión de configuración, policy-as-code). Los cambios locales son deuda técnica.
Checklist C: Endurecimiento sin autoboicotearse
- Comienza con privilegio mínimo entrante antes de la salida. Es más simple y reduce riesgo real.
- Si persigues controles salientes, hazlo por rol (web, app, BD, gestión) con catálogos de dependencias.
- Prueba dependencias de dominio explícitamente para hosts unidos al dominio (Kerberos, LDAP, DNS, hora).
- Monitorea los cambios de perfil y cambios de política de firewall como señales de primera clase.
- No borres reglas integradas solo para sentirte productivo. Deshabilita con intención y registra por qué.
Hechos y contexto interesantes (porque la historia explica los predeterminados)
- Hecho 1: El Firewall de Windows comenzó a estar “activado por defecto” de forma significativa para muchos usuarios alrededor de Windows XP SP2, después de que los gusanos hicieran obvia la cuenta del coste de tener puertos abiertos.
- Hecho 2: El motor de aplicación moderno debajo es la Windows Filtering Platform (WFP), que permite que múltiples componentes (incluyendo productos de seguridad) participen en decisiones de tráfico.
- Hecho 3: Los perfiles (Dominio/Privado/Público) están ligados a Network Location Awareness de Windows. No son “etiquetas” manuales; cambian según lo que Windows detecta sobre la red.
- Hecho 4: Muchas reglas de “Core Networking” existen porque Windows necesita hacer cosas básicas de host (DHCP, descubrimiento de vecinos, comportamiento DNS). Eliminarlas suele causar fallos que parecen “Windows es inestable”.
- Hecho 5: El comportamiento dinámico de puertos de RPC es históricamente flexible para evitar colisiones y soportar múltiples servicios; también es una razón frecuente por la que los proyectos de endurecimiento de firewall se vuelven caóticos.
- Hecho 6: Group Policy no solo añade reglas de firewall—también puede decidir si las reglas locales están permitidas, por eso “añadí una regla local” a veces no hace nada.
- Hecho 7: El filtrado stateful significa que no necesitas abrir puertos efímeros entrantes para tráfico de retorno, pero la gente aún lo hace porque aprendió firewalls en modelos stateless más antiguos.
- Hecho 8: Las reglas del Firewall de Windows pueden limitarse a programas/servicios, no solo a puertos, lo cual es más robusto en hosts que ejecutan múltiples apps.
- Hecho 9: El formato del log del firewall (pfirewall.log) es intencionalmente plano. Está diseñado para ser parseable y enviable, no bonito.
Una idea operacional parafraseada que sigue siendo cierta en toda época: idea parafraseada
“La fiabilidad viene de gestionar fallos previsibles, no de esperar que no ocurran.” — John Allspaw (idea parafraseada)
Preguntas frecuentes
Q1: ¿Debo confiar en los valores predeterminados del Firewall de Windows en servidores?
Confía en el modelo base: bloqueo entrante por defecto, tráfico de retorno stateful y reglas integradas de red. No confíes ciegamente en que los perfiles siempre serán correctos ni en que herramientas de terceros no añadirán filtros.
Q2: ¿Por qué mi servidor de dominio a veces muestra el perfil Público?
Normalmente porque no puede alcanzar un controlador de dominio o DNS está mal configurado, por lo que Network Location Awareness no puede confirmar la autenticación de dominio. Arregla la conectividad y la resolución de nombres; no lo tapes con reglas “allow all” del perfil Público.
Q3: ¿Necesito reglas entrantes para puertos efímeros?
No para el tráfico de retorno de conexiones iniciadas por tu host. Debes pensar en puertos dinámicos cuando permites gestión basada en RPC u otros servicios que negocian puertos dinámicos.
Q4: ¿Cuál es el enfoque más sencillo y seguro para permitir RDP?
Permite TCP/3389 entrante solo desde una subred bastión/jump (o estaciones de admin específicas vía VPN), en el perfil Domain. Registra los drops. No permitas RDP desde “Any” a menos que te guste la respuesta a incidentes como hobby.
Q5: Si mi app usa HTTPS, ¿puedo permitir 443 desde cualquier lugar?
Puedes, pero no deberías por defecto. Limita por redes de origen (balanceadores, reverse proxies, subredes de usuarios) y considera usar scoping por programa/servicio para que otro proceso no pueda enlazar 443 y heredar tu confianza.
Q6: ¿Por qué veo una regla allow pero el tráfico aún está bloqueado?
Razones comunes: una regla de bloqueo la anula, la regla aplica a otro perfil, las reglas locales están deshabilitadas por GPO o un callout WFP de terceros está bloqueando. Revisa logs y la procedencia de la regla.
Q7: ¿Vale la pena bloquear salidas?
Sí, pero solo si puedes operarlo: mantén inventarios de dependencias, un proceso de excepciones rápido y monitoriza los bloqueos. Si no, se convierte en fábrica de outages y acaba siendo eludido.
Q8: ¿Cómo sé rápido si el firewall es el cuello de botella?
Confirma que el puerto está escuchando, activa/revisa logs de drop para ese puerto de destino y valida perfil más conflictos de reglas. Si los drops muestran el flujo exacto, es política local. Si no hay rastro, lo más probable es que el tráfico no llegue al host.
Q9: ¿Debo eliminar reglas integradas para reducir desorden?
No. Deshabilita con intención si es necesario, pero eliminar reglas integradas rara vez mejora la seguridad y con frecuencia afecta la estabilidad. El desorden se maneja mejor con disciplina de políticas y convenciones de nombres.
Conclusión: pasos prácticos siguientes
Si quieres que el Firewall de Windows deje de ser una casa encantada, no necesitas cientos de reglas. Necesitas un pequeño conjunto de reglas que estén con alcance, sean atribuibles y testeadas—más la disciplina de no “arreglar temporalmente” producción con un mazo.
- Audita el perfil activo y las acciones por defecto en tu flota de servidores. Los hosts mal perfilados son una clase recurrente de outage.
- Define una política estándar de gestión (RDP/WinRM) con alcance por origen y logging.
- Para cada rol de servidor, documenta los puertos de escucha y crea reglas entrantes con alcance a los clientes reales.
- Decide si la salida será Allow-by-default o Allowlist, y si es allowlist, construye primero el inventario de dependencias y el logging.
- Activa el registro de paquetes descartados para capas críticas y centralízalo. Adivinar sale caro.
- Mueve las reglas a tu sistema de registro (GPO/gestión de configuración). Los cambios locales no escalan ni sobreviven reconstrucciones.
El objetivo no es “ajustes máximos de seguridad.” El objetivo es una política de firewall que puedas explicar durante un incidente sin mentir y que puedas cambiar sin rezar.