Reglas de salida del firewall de Windows: piloto acotado

¿Qué son las reglas de salida del firewall de Windows?

Las reglas de salida del firewall de Windows controlan las conexiones que salen de un equipo Windows. La acción de salida predeterminada de un perfil determina qué ocurre cuando ninguna regla aplicable permite o bloquea ese tráfico. Un piloto de bloqueo predeterminado parte de una población definida y un conjunto documentado de conexiones necesarias, y después prueba si esas conexiones siguen funcionando con la directiva prevista.

Esta opción de endurecimiento tiene costes operativos. Microsoft recomienda permitir el tráfico de salida de forma predeterminada en la mayoría de los despliegues y contempla el bloqueo predeterminado para determinados entornos de alta seguridad. Por tanto, un hallazgo sobre la acción predeterminada recopilada abre una revisión; no establece un requisito universal de bloquear el tráfico de salida en todo el dominio. Consulte las recomendaciones de Microsoft sobre las reglas de Windows Firewall.

La cuestión práctica es si su organización puede mantener una lista de permitidos útil para los equipos elegidos. Defina quién se responsabiliza de los cambios, qué aplicaciones necesitan comunicarse y cómo se recuperarán las dependencias que fallen antes de cambiar la acción predeterminada. Una directiva que interrumpe las actualizaciones o la administración remota sin una vía de recuperación puede perjudicar el objetivo del ejercicio.

Funcionamiento: la acción predeterminada de un perfil difiere de una regla de bloqueo

Los perfiles Domain, Private y Public tienen configuraciones independientes. Elija deliberadamente el perfil del piloto y verifique el perfil utilizado en la red de destino. Una configuración del perfil Domain no demuestra qué ocurre cuando el mismo equipo utiliza una red Private o Public.

Hay que distinguir dos diseños. Con una acción de salida predeterminada de Block, una regla explícita de permiso aplicable puede permitir el tráfico necesario. Con una regla explícita de bloqueo amplio, una regla ordinaria de permiso en conflicto no restablece ese tráfico: las reglas explícitas de bloqueo tienen prioridad. Un permiso más específico no permite eludir un bloqueo explícito que se superpone. Estos comportamientos de precedencia también se aplican a las reglas de salida.

Los almacenes de directivas también importan. Una regla guardada en una GPO de administración describe la configuración prevista. El ActiveStore del destino representa la directiva actualmente activa, ensamblada a partir de los almacenes aplicables. La combinación de reglas locales puede afectar a las excepciones que participan; revise la configuración real de combinación y las fuentes de las reglas en lugar de suponer que se utilizará una excepción creada localmente. La guía de administración por línea de comandos de Microsoft documenta las operaciones locales y mediante GPO.

Separe las restricciones de autenticación de las restricciones de conectividad. Nuestra guía para bloquear el NTLM saliente de sistemas Tier 0 trata la restricción de un mecanismo de autenticación implicado en la coerción y el relay. Esa decisión no define una lista de permitidos del firewall por aplicación y destino, y una acción de salida predeterminada del firewall no establece que la autenticación NTLM esté deshabilitada.

Detección: comparar los datos GPO recopilados con el destino

Registre el equipo, el contexto de red, el alcance previsto de la directiva y la hora de recopilación. Ejecute por separado los siguientes comandos de lectura en PowerShell en un destino Windows representativo. Son ejemplos basados en la documentación, no mediciones realizadas para este artículo.

Paso 1: leer la configuración de los perfiles activos

Microsoft documenta Get-NetFirewallProfile con ActiveStore:

Get-NetFirewallProfile -PolicyStore ActiveStore

Inspeccione Name, Enabled y DefaultOutboundAction en cada perfil, junto con la combinación de reglas locales y la configuración de registro. Conserve la salida devuelta. Confirme qué perfil de red utiliza realmente el piloto; un valor Block en un perfil inactivo no basta para demostrar que el flujo probado se filtró.

Compare el resultado de Domain con el valor WindowsFirewall/DomainProfile/DefaultOutboundAction de la GPO recopilado desde Registry.pol. En la representación del detector, 0 significa Allow y 1 significa Block. Cuando el valor de la GPO falta o difiere del destino, investigue la aplicación de la directiva y las fuentes de configuración competidoras. No sustituya el resultado activo del equipo por el valor elegido por el recopilador.

Paso 2: inspeccionar las reglas de salida y sus fuentes

Utilice la referencia de Get-NetFirewallRule para recuperar las reglas de salida de la directiva activa y rastrear sus almacenes de origen:

Get-NetFirewallRule -Direction Outbound -PolicyStore ActiveStore -TracePolicyStore

Revise el estado de habilitación, la acción, el perfil, la fuente y los filtros asociados de aplicación, servicio, dirección y puerto. Los objetos de regla por sí solos no muestran todos los filtros asociados de forma completa; inspeccione esos detalles en Windows Firewall with Advanced Security o mediante los cmdlets de filtro NetSecurity correspondientes. Identifique los bloqueos superpuestos y los permisos excesivamente amplios antes de interpretar una prueba de conectividad.

Nuestra guía de cuatro comprobaciones de seguridad GPO utiliza el mismo método de verificación: comparar la intención de la directiva, los equipos que la reciben y la protección realmente utilizada. Sus comprobaciones LLMNR, WSUS, LSA y UNC no establecen la cobertura del firewall de salida. Aplique aquí el método con pruebas específicas del firewall en el destino.

Paso 3: observar el tráfico necesario y rechazado

Lea el LogFileName configurado del perfil en lugar de suponer que todos los equipos utilizan la misma ruta. La guía de línea de comandos muestra %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log. La referencia de Set-NetFirewallProfile documenta el registro de paquetes aceptados y descartados. Correlacione las entradas conservadas con la operación de la aplicación, la marca de tiempo, el protocolo y los extremos que está probando.

Para un piloto de laboratorio aislado y administrado localmente, este comando habilita ambas opciones de registro para Domain:

Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True

En los equipos administrados, configure el registro en la directiva que los gobierna y verifíquelo en ActiveStore. Los cambios de registro son independientes de la acción de salida predeterminada. Registre la configuración anterior y planifique la retención para que las pruebas de diagnóstico sigan disponibles. Un paquete descartado es un punto de partida para investigar, no una prueba de malware; el silencio de un registro no demuestra que todas las rutas de las aplicaciones estén permitidas.

Remediación: diseñar un piloto acotado de bloqueo predeterminado (Remediation)

Paso 1: decidir si el bloqueo predeterminado encaja con la población

Documente la razón empresarial y de seguridad del piloto, los equipos elegidos y el límite del perfil Domain. Seleccione una población manejable cuyos responsables de aplicaciones estén disponibles para probarla. Identifique las ventanas de mantenimiento, las responsabilidades de supervisión y una vía independiente de recuperación. Decida qué pruebas permitirán ampliar el piloto y qué fallo exigirá revertirlo.

Si el inventario de dependencias está incompleto o nadie puede mantenerlo, registre esa limitación y resuélvala antes de aplicar las restricciones. El objetivo es una directiva de conectividad sostenible. Cerrar un hallazgo de configuración cambiando una acción predeterminada en todo el dominio sin comprender su efecto no es un criterio útil de éxito.

Paso 2: inventariar las aplicaciones y sus dependencias

Para cada aplicación y servicio, registre su ejecutable o identidad de servicio, los destinos previstos, el protocolo, los puertos de destino, el horario de funcionamiento y el responsable. Incluya explícitamente en la revisión la resolución DNS, la descarga de actualizaciones, los agentes de administración, la administración remota y las herramientas de recuperación. Inventaríe tanto las operaciones habituales como las tareas de mantenimiento poco frecuentes; una sesión interactiva satisfactoria no prueba una actualización o una copia de seguridad programada.

Utilice los requisitos de los proveedores y las operaciones legítimas observadas para construir la lista. Distinga los destinos que la aplicación necesita directamente de la infraestructura de apoyo, como un proxy o un resolvedor. Cuando los extremos cambien con el tiempo, registre cómo se mantendrá la lista de permitidos. No deduzca un mapa completo de dependencias de una captura breve de paquetes ni apruebe automáticamente cada conexión observada.

Paso 3: preparar reglas de permiso documentadas

Cree las excepciones necesarias antes de habilitar el bloqueo predeterminado. Asocie a cada regla un responsable, una finalidad, un perfil y una decisión de revisión. Compruebe que las reglas llegan al piloto mediante el almacén de directivas previsto y resuelva los conflictos con bloqueos explícitos. Inspeccione la combinación de reglas locales para tratar deliberadamente las reglas instaladas por aplicaciones y las excepciones creadas por administradores.

La siguiente regla ilustrativa utiliza los parámetros documentados por New-NetFirewallRule. La ruta, la dirección, el puerto, el dominio y la GPO son ejemplos que deben sustituirse por valores de inventario verificados; no es una regla que deba desplegarse sin cambios:

New-NetFirewallRule -DisplayName "Pilot application to approved service" -Direction Outbound -Action Allow -Profile Domain -Program "C:\Program Files\Example\client.exe" -Protocol TCP -RemoteAddress 192.0.2.10 -RemotePort 443 -PolicyStore "corp.contoso.com\Outbound Pilot"

Una excepción de ejemplo no constituye un inventario de dependencias de la aplicación. Añada únicamente las reglas justificadas por la carga de trabajo real, incluidos sus servicios de apoyo. Revise también los permisos amplios existentes: el bloqueo predeterminado aporta poco valor si una excepción general sigue permitiendo las conexiones que pretendía restringir.

Paso 4: cambiar únicamente el alcance elegido del perfil Domain

Para la GPO del piloto de ejemplo, los parámetros documentados de Set-NetFirewallProfile permiten expresar la acción predeterminada seleccionada:

Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Block -PolicyStore "corp.contoso.com\Outbound Pilot"

Confirme que esta GPO se aplica solo a la población seleccionada antes de cambiarla. Conserve la configuración anterior y mantenga el firewall habilitado. Después de aplicar la directiva, repita las consultas de perfiles y reglas de ActiveStore en los equipos de destino. Un comando de administración correcto escribe la configuración; no demuestra que todos los destinos previstos la hayan aplicado.

Paso 5: medir los flujos y ensayar la reversión

Pruebe cada operación registrada bajo el perfil Domain activo. Verifique el comportamiento de la aplicación, la resolución de nombres, las comprobaciones de actualizaciones, el acceso de administración y el acceso de recuperación. Compare los fallos con el tráfico descartado y los detalles de las reglas. Cuando una conexión sea necesaria, documente su finalidad antes de añadir o corregir la excepción adecuada; después, vuelva a probar la operación original.

Defina una prueba controlada para el tráfico que la directiva debe rechazar, utilizando un destino y una carga de trabajo de prueba aprobados. Registre el resultado esperado y las pruebas reales del destino. Evite interpretar un rechazo satisfactorio como prueba de que toda salida no deseada está bloqueada. Mantenga juntos los registros de operaciones permitidas y rechazadas para que los revisores puedan evaluar la intención de seguridad y la compatibilidad.

Si la acción predeterminada anterior registrada para la GPO de ejemplo era Allow, su comando de reversión es:

Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Allow -PolicyStore "corp.contoso.com\Outbound Pilot"

Restaure el estado real anterior de la directiva cuando fuera distinto, incluida una configuración no definida cuando corresponda. Revise por separado las reglas del piloto y los cambios de registro. Un bloqueo explícito que permanezca puede seguir impidiendo la conectividad después de devolver la acción predeterminada a Allow. Vuelva a comprobar ActiveStore y repita la operación empresarial fallida antes de declarar la recuperación completa. Amplíe el piloto solo cuando el inventario, las responsabilidades, las pruebas y el registro de reversión respalden la siguiente población.

Cómo detecta EtcSec esta configuración

La implementación Detect() de etc-collector revisada expone una comprobación pertinente aquí: FIREWALL_OUTBOUND_NOT_BLOCKED. Inicializa un hallazgo de gravedad Low con Count = 0 y después busca el entero recopilado FirewallOutboundAction. Si la búsqueda devuelve nil o cualquier valor distinto de 1, establece Count = 1. Un valor devuelto de 1 deja Count = 0.

El analizador de Registry.pol rellena ese campo solo desde una clave que coincide con WindowsFirewall y DomainProfile, con el nombre de valor DefaultOutboundAction. Los valores de los perfiles Private y Public quedan fuera de esta comprobación. La función auxiliar de enteros busca primero un valor no nil en Default Domain Controllers Policy, después en Default Domain Policy y, por último, en otra GPO disponible. Su alternativa recorre un mapa de Go; no determina la precedencia de las directivas de Windows.

Estos límites importan al revisar un hallazgo. La ausencia de un valor GPO recopilado activa la comprobación sin medir la acción predeterminada efectiva ni la aplicación real en un equipo. Count = 1 no cuenta los extremos expuestos ni demuestra tráfico de mando y control. Count = 0 no valida que el firewall esté habilitado, las reglas de permiso necesarias, los conflictos de bloqueo explícito, las excepciones locales ni el funcionamiento satisfactorio del piloto.

Utilice esta señal para iniciar la investigación acotada descrita antes. Adjunte a la revisión el perfil activo del destino, las reglas efectivas, las pruebas de aplicaciones y las pruebas de reversión. Decida si el bloqueo predeterminado es adecuado para esa población y resuelva la cuestión de configuración mediante las pruebas obtenidas, en lugar de basarse únicamente en la búsqueda agregada de GPO.