Firewall de Windows contra el movimiento lateral

Todos los equipos Windows compatibles incluyen un firewall de host con estado muy capaz. En muchos entornos está desactivado («ya se encarga el firewall de red») o se deja en su estado por defecto, en el que los instaladores y los administradores locales pueden añadir reglas de entrada libremente. Bien usado, es uno de los controles más baratos y eficaces contra el movimiento lateral: la técnica que convierte un portátil comprometido en una red comprometida.

Esta guía construye una directiva para puestos de trabajo y servidores con directiva de grupo (las mismas opciones existen en Intune, en Endpoint security > Firewall).

Principios

1. Los tres perfiles activados (dominio, privado, público), impuestos por directiva.
2. Entrada por defecto: bloquear. Solo entra el tráfico permitido explícitamente.
3. Solo cuentan las reglas centrales. La combinación de reglas locales está desactivada.
4. Los protocolos de administración solo llegan desde redes de administración. RDP, WinRM, SMB, RPC y WMI son accesibles desde los servidores de salto y las PAW, no desde cualquier otro cliente.
5. Registrar los descartes, dimensionar el registro y recopilarlo.

Paso 1: configuración de los perfiles

Ruta de GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Abra las propiedades y configure, para cada uno de los perfiles Domain, Private y Public:

El equivalente en PowerShell, útil para probar en un solo equipo:

Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True `
  -DefaultInboundAction Block -DefaultOutboundAction Allow `
  -NotifyOnListen False -AllowLocalFirewallRules False `
  -LogBlocked True -LogMaxSizeKilobytes 16384 `
  -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log"

Compruebe el estado efectivo (el resultado combinado de la configuración local y de directiva de grupo):

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction, AllowLocalFirewallRules, LogBlocked

Con AllowLocalFirewallRules en False, se ignoran las reglas que los instaladores de software crearon localmente. Es intencionado, y es la razón para inventariar qué reglas de entrada necesitan realmente sus aplicaciones (paso 3) antes del despliegue.

Paso 2: reglas para puestos de trabajo

Los puestos de trabajo necesitan muy poco tráfico entrante. Una lista de permisos realista:

Todo lo demás, en particular SMB, RPC y WinRM desde otros puestos de trabajo, sigue bloqueado. Esa única decisión detiene la mayor parte del «salto de portátil en portátil» que usan los afiliados de ransomware.

Las reglas con ámbito tienen este aspecto (en la GPO son iguales, con la pestaña Scope):

New-NetFirewallRule -DisplayName "RDP from Tier2 admin subnet" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress 10.20.50.0/24 -Action Allow -Profile Domain

New-NetFirewallRule -DisplayName "SMB from management servers" -Direction Inbound `
  -Protocol TCP -LocalPort 445 -RemoteAddress 10.20.10.11,10.20.10.12 -Action Allow -Profile Domain

Cuidado con los grupos de reglas predefinidos como Remote Desktop, File and Printer Sharing o Windows Remote Management: al habilitar el grupo se habilitan reglas con un ámbito remoto Any. Modifique su ámbito en la GPO o cree en su lugar sus propias reglas con ámbito.

Paso 3: reglas para servidores

Los servidores necesitan reglas de entrada para el servicio que prestan, más una administración con ámbito limitado:

• Puertos de aplicación (HTTPS 443 en un servidor web, 1433 en SQL Server) limitados a los clientes o equilibradores de carga que los usan, no «Any» si puede evitarse.
• Puertos de administración limitados a los servidores de salto Tier 1 o a las PAW.
• En los controladores de dominio, el conjunto completo de puertos de AD (Kerberos 88, LDAP 389/636, GC 3268/3269, DNS 53, SMB 445, RPC 135 y el intervalo dinámico) debe seguir accesible para todos los miembros del dominio; restrinja los protocolos de administración (RDP, WinRM) a los equipos de administración Tier 0.

Antes de imponer nada, inventaríe qué escucha realmente y quién se conecta:

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
  Sort-Object LocalPort -Unique

Combínelo con unos días de pfirewall.log con el registro de conexiones correctas activado, para que las reglas reflejen la realidad y no la documentación.

Salida en los servidores. La mayoría de los servidores solo necesitan hablar con un conjunto conocido de destinos: DNS, controladores de dominio, servidores de actualizaciones, su base de datos. Denegar la salida por defecto, en particular en los servidores Tier 0, dificulta mucho el comando y control y la exfiltración de datos. Empiece con log successful connections para construir la lista y después cambie la acción de salida por defecto a Block con reglas de permiso.

Paso 4: bloquear los abusos habituales

Algunas reglas adicionales que conviene considerar:

• Bloquear por completo la entrada en el perfil Public en los portátiles (el bloqueo por defecto ya lo hace si no añade reglas de permiso en Public).
• Bloquear a nivel de host el SMB saliente (TCP 445) hacia Internet; no hay ningún motivo legítimo para ello y evita fugas de credenciales mediante autenticación forzada hacia hosts externos.
• Impedir que mshta.exe, wscript.exe, cscript.exe y hosts de script similares abran conexiones salientes donde no se usan. El control de aplicaciones es la solución más sólida, pero esto es barato.

New-NetFirewallRule -DisplayName "Block outbound SMB to Internet" -Direction Outbound `
  -Protocol TCP -RemotePort 445 -RemoteAddress Internet -Action Block

Internet es una palabra clave integrada que excluye la subred local y los intervalos privados definidos como intranet; compruebe que encaja con su direccionamiento o enumere explícitamente sus intervalos internos con una regla de permiso.

Paso 5: registro y supervisión

pfirewall.log es un registro de texto plano en cada host. Es útil durante las investigaciones, pero rara vez se recopila. Opciones:

• Recopilarlo con su agente de registros.
• O habilitar la auditoría de Plataforma de filtrado de Windows (Advanced Audit Policy > Object Access > Filtering Platform Connection, solo errores), que genera eventos de seguridad 5157 para las conexiones bloqueadas. Con la auditoría de aciertos es muy ruidosa, así que empiece por los errores y filtre en el recopilador.
• Supervise siempre los cambios de configuración del firewall: eventos de seguridad 4946-4948 (regla añadida, modificada, eliminada) y 4950 (configuración cambiada), de Audit MPSSVC Rule-Level Policy Change.

Un atacante que desactiva el firewall o añade una regla de permiso para su herramienta deja exactamente estos eventos.

Lista de comprobación

• Firewall activado en todos los perfiles, impuesto por GPO o Intune
• Entrada bloqueada por defecto; combinación de reglas locales desactivada
• Los puestos de trabajo solo aceptan RDP/WinRM/SMB/RPC desde equipos de administración y gestión
• Grupos de reglas predefinidos sustituidos o con el ámbito redefinido
• Reglas de servidor construidas a partir de los puertos en escucha y las conexiones observadas
• Salida denegada por defecto en los servidores Tier 0
• Paquetes descartados registrados; alertas sobre los eventos de cambio de reglas 4946-4950

Los firewalls de host complementan el modelo de administración por niveles: los niveles impiden que las credenciales privilegiadas lleguen a los puestos de trabajo, y el firewall impide que los puestos sirvan de trampolín incluso cuando se filtra alguna credencial.