Aislamiento de dominio y de servidor con IPsec

Las reglas de firewall basadas en direcciones IP responden a la pregunta «¿de dónde viene este paquete?». Los atacantes saben llegar desde el lugar correcto: un puesto de trabajo comprometido en la subred adecuada o un portátil conectado a la toma de una sala de reuniones. Las reglas de seguridad de conexión IPsec añaden una pregunta más sólida: «¿qué equipo, o qué usuario, autenticado está al otro lado?»

Con el aislamiento de dominio, los miembros del dominio solo aceptan tráfico entrante de otros miembros del dominio autenticados. Con el aislamiento de servidor, un servidor sensible solo acepta tráfico de equipos o usuarios concretos, identificados por Kerberos, sea cual sea su dirección IP. Ambos se construyen con los mismos componentes del Firewall de Windows que ya gestiona mediante directiva de grupo a escala, y se apoyan en los principios de ámbito del pilar de endurecimiento del Firewall de Windows.

Es un control avanzado. Cambia la forma en que se establece cada conexión, así que el despliegue importa tanto como la configuración.

Los componentes

Las reglas de seguridad de conexión no permiten tráfico por sí solas. Garantizan que el tráfico esté autenticado; después, las reglas de firewall deciden si se permite el tráfico autenticado de ese par.

Paso 1: definir los valores predeterminados de IPsec

Ruta de GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security, propiedades, pestaña IPsec Settings, Customize:

En PowerShell, los conjuntos criptográficos son objetos independientes a los que hacen referencia las reglas:

$mm = New-NetIPsecMainModeCryptoProposal -Encryption AES256 -Hash SHA256 -KeyExchange DH19
New-NetIPsecMainModeCryptoSet -Name 'MM-Strong' -DisplayName 'MM-Strong' -Proposal $mm -PolicyStore 'corp.example.com\FW-IPsec'

$qm = New-NetIPsecQuickModeCryptoProposal -Encapsulation ESP -ESPHash SHA256
New-NetIPsecQuickModeCryptoSet -Name 'QM-Integrity' -DisplayName 'QM-Integrity' -Proposal $qm -PolicyStore 'corp.example.com\FW-IPsec'

$auth = New-NetIPsecAuthProposal -Machine -Kerberos
New-NetIPsecPhase1AuthSet -Name 'P1-ComputerKerberos' -DisplayName 'P1-ComputerKerberos' -Proposal $auth -PolicyStore 'corp.example.com\FW-IPsec'

Las reglas hacen referencia a estos conjuntos por su Name, no por su nombre para mostrar; por eso cada conjunto recibe un -Name explícito. Sin él, Windows genera un GUID y la regla siguiente no encuentra el conjunto.

Paso 2: aislamiento de dominio en modo de solicitud

Cree una regla de seguridad de conexión de tipo Isolation en una GPO nueva vinculada a una OU piloto:

• Requisitos: Request authentication for inbound and outbound connections.
• Método de autenticación: equipo (Kerberos V5).
• Perfil: dominio.

New-NetIPsecRule -DisplayName 'Domain isolation' -InboundSecurity Request -OutboundSecurity Request `
  -Phase1AuthSet 'P1-ComputerKerberos' -Profile Domain -PolicyStore 'corp.example.com\FW-IPsec'

El modo de solicitud nunca bloquea nada. Los miembros del dominio que tienen ambos la regla negocian asociaciones de seguridad; todo lo demás recurre al tráfico en claro. Esta fase le muestra qué pares pueden autenticarse y cuáles no, sin interrupción del servicio.

Añada exenciones de autenticación para la infraestructura que no puede o no debe negociar IPsec:

• Controladores de dominio, para que los clientes puedan obtener los tickets Kerberos que el propio IPsec necesita. Deje los DC en modo de solicitud en lugar de exigencia.
• Servidores DHCP y DNS si no son DC.
• Dispositivos de red, impresoras, IoT y sistemas no Windows que hablan con miembros del dominio.

Mantenga la lista de exenciones corta, documentada y basada en direcciones que controla; cada exención es un agujero en el modelo.

Paso 3: exigir la autenticación entrante

Cuando la supervisión muestre que casi todo el tráfico del dominio está protegido (vea la sección de supervisión más abajo), cambie primero los servidores y después los puestos de trabajo a Require inbound and request outbound. Los dispositivos sin identidad de dominio ya no pueden abrirles conexiones. La salida se queda en request para que los miembros del dominio sigan pudiendo llegar a los sistemas exentos y no Windows.

Evite Require inbound and outbound salvo en grupos de servidores muy controlados: rompe todas las conexiones salientes hacia pares que no pueden negociar IPsec.

Paso 4: aislamiento de servidor para los sistemas sensibles

Para un servidor sensible, como una base de datos financiera o un servidor de administración Tier 0, cree reglas de firewall entrantes que solo acepten tráfico autenticado de equipos autorizados:

1. Cree un grupo de seguridad de equipos, por ejemplo IPsec-FinanceDB-Clients, que contenga los servidores de aplicaciones que pueden conectarse.
2. En el servidor, cree una regla de permiso entrante para el puerto del servicio con Allow the connection if it is secure y, en la pestaña Remote Computers, autorice solo a ese grupo. Opcionalmente, añada Remote Users para una autorización a nivel de usuario (requiere segunda autenticación con Kerberos de usuario).
3. Elimine cualquier otra regla de permiso para ese puerto.

$sid = (Get-ADGroup 'IPsec-FinanceDB-Clients').SID.Value
New-NetFirewallRule -DisplayName 'SQL 1433 - authorised computers only' -Direction Inbound `
  -Protocol TCP -LocalPort 1433 -Action Allow -Authentication Required `
  -RemoteMachine "D:(A;;CC;;;$sid)" -Profile Domain -PolicyStore 'corp.example.com\FW-FinanceDB'

Añada -Encryption Required cuando el protocolo no cifre ya. La pertenencia a grupos del equipo viaja en el ticket Kerberos, así que añadir un equipo al grupo solo surte efecto cuando se renueva el ticket de ese equipo (un reinicio o klist purge -li 0x3e7).

El mismo patrón le da un acceso de administración basado en identidad: RDP y WinRM en los servidores Tier 0 aceptados solo desde equipos de un grupo Tier0-PAW, en línea con la administración por niveles y el modelo por niveles.

Qué detiene IPsec y qué no

El aislamiento IPsec hace que un dispositivo no gestionado en la red sea prácticamente inútil para llegar a los miembros del dominio, y vuelve ineficaces la suplantación de IP y los reenvíos de red simples contra los servidores aislados. Complementa, y no sustituye, el endurecimiento de protocolos como la firma SMB y las restricciones de NTLM de la guía de protocolos heredados: un atacante que controla un equipo unido al dominio se autentica como ese equipo. El aislamiento de servidor limita qué equipos del dominio cumplen los requisitos; las protecciones contra NTLM relay siguen siendo importantes.

Qué se rompe

• Equilibradores de carga y NAT entre clientes y servidores: el modo de transporte IPsec se negocia de extremo a extremo, así que un equilibrador de carga que termina o reescribe las conexiones rompe la autenticación. Exima la VIP o proteja el tráfico solo detrás del equilibrador.
• La supervisión de red y los IDS pierden visibilidad del contenido cuando exige cifrado. ESP solo con integridad mantiene legibles los paquetes.
• Los sistemas fuera del dominio y de otros bosques necesitan certificados o exenciones.
• Los problemas de Kerberos se convierten en problemas de conectividad: el desfase de reloj, los SPN rotos o los DC inaccesibles aparecen ahora como conexiones fallidas.
• Rendimiento: la sobrecarga de CPU es pequeña en hardware moderno con descarga en la NIC, pero pruebe los servidores de alto rendimiento.
• La resolución de problemas es más difícil para equipos no acostumbrados a IPsec. Forme a los equipos de red y de servidores antes de imponerlo.

Supervisar las asociaciones de seguridad

Habilite la auditoría de IPsec en Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff: Audit IPsec Main Mode y Audit IPsec Quick Mode (como mínimo los errores), más System > Audit IPsec Driver. Eventos útiles del registro de seguridad:

Un aumento de 4653 tras pasar al modo de exigencia señala pares sin una identidad válida: exactamente los dispositivos que debe eximir o corregir. Los eventos de acierto son muy voluminosos; recopile los errores de forma centralizada y tome muestras de los aciertos.

Comprobarlo

En un servidor del ámbito:

Get-NetIPsecRule -PolicyStore ActiveStore | Select-Object DisplayName, InboundSecurity, OutboundSecurity, Enabled
Get-NetIPsecMainModeSA | Select-Object RemoteEndpoint, LocalFirstId, RemoteFirstId
Get-NetIPsecQuickModeSA | Select-Object RemoteEndpoint, RemotePort, LocalPort

RemoteFirstId muestra la identidad de equipo autenticada de cada par. En wf.msc > Monitoring > Security Associations verá los mismos datos de forma gráfica. Después haga una prueba negativa: desde un portátil fuera del dominio en la misma subred, Test-NetConnection <server> -Port 445 debería fallar en cuanto el servidor exija la autenticación entrante, mientras que un miembro del dominio del grupo autorizado sigue conectándose.

Lista de comprobación

• Valores predeterminados de IPsec definidos: sin SHA-1 ni grupo DH 2, ICMP exento
• Regla de aislamiento de dominio desplegada en modo de solicitud en un piloto y después de forma amplia
• DC, DHCP, DNS e infraestructura no Windows exentos y documentados
• Servidores pasados a exigir la entrada y solicitar la salida, tras medir la cobertura de las SA
• Servidores sensibles restringidos a grupos de equipos autorizados con «permitir si es segura»
• Cifrado exigido solo donde el protocolo no se protege por sí mismo
• Errores de modo principal y modo rápido de IPsec auditados y reenviados

Consulte el tema Firewall de Windows para ver la serie completa, incluidos el registro y la gestión de directivas.