Configurar y probar Sophos Firewall IPS

Intrusion Prevention System (IPS) examina el tráfico en busca de patrones de ataque conocidos, exploits y características de protocolo sospechosas. Para que IPS proteja realmente, debe estar activo de forma global y la regla de firewall que procesa el tráfico debe tener asignada una IPS policy adecuada.

No conviene aplicar indiscriminadamente la policy más estricta a todas las reglas. Una policy adaptada a la ruta del tráfico, una fase piloto y logs fiables evitan interrupciones innecesarias sin reducir la protección a la ligera.

Activar IPS y asignarlo a una regla de firewall

Requisitos

Antes de configurarlo deben cumplirse estos requisitos:

• una suscripción activa de Network Protection o una licencia Trial
• firmas IPS disponibles y actualizaciones de patrones operativas
• una regla de firewall conocida que procese realmente el tráfico que se quiere examinar
• logging de la regla activado y un proceso para gestionar falsos positivos

IPS Protection está desactivado de forma predeterminada. En un firewall conectado a Internet, las firmas IPS solo se actualizan con una licencia válida e IPS activado. Los firewalls air-gap con licencia son la excepción documentada: pueden recibir firmas IPS mediante el proceso de actualización previsto incluso con IPS desactivado. Los detalles se explican en Licencias air-gap y actualizaciones de patrones.

Si Network Protection caduca, el interruptor de IPS puede seguir pareciendo activo aunque el firewall ya no aplique protección IPS. Cuando IPS se desactiva manualmente, las firmas online dejan de actualizarse y ya no se pueden configurar policies ni firmas propias. Después de 30 días, el firewall elimina las firmas y las reglas IPS.

Cuando caduca una licencia Trial, IPS se desactiva automáticamente. Durante los 30 días siguientes no aplica protección, no descarga firmas ni permite configurar policies; después elimina las firmas y las reglas. Para conservar la configuración, hay que exportarla o crear una copia de seguridad antes.

Activar IPS globalmente

1. Abrir Protect > Intrusion prevention > IPS policies. Según la vista, la ruta abreviada es Intrusion prevention > IPS policies.
2. Activar IPS Protection.
3. Comprobar el estado de la licencia y las actualizaciones de patrones.
4. Esperar hasta que las firmas estén disponibles.
5. Revisar las policies predeterminadas existentes.
6. Si hace falta una policy propia, usar Add para clonar una policy predeterminada adecuada.

Después de activarlo, no basta con comprobar el interruptor. Una versión de patrones actual y una primera coincidencia en el log demuestran mucho mejor que toda la cadena de protección funciona.

Activar o desactivar Firewall Acceleration o PKI Acceleration reinicia IPS o el motor DPI. Estos cambios deben hacerse en una ventana de mantenimiento, no durante un análisis de errores en curso.

Activar IPS en la regla de firewall

1. Abrir Rules and policies > Firewall rules.
2. Editar la regla que realmente coincide con el tráfico.
3. En Other security features, activar Detect and prevent exploits (IPS).
4. Seleccionar una IPS policy adecuada para el tráfico.
5. Activar el logging de la regla, guardar y probar con tráfico real.

La activación global por sí sola no basta. Si el tráfico coincide primero con otra regla sin IPS policy, una regla posterior no lo protegerá. En ese caso, consultar La regla de Sophos Firewall no coincide: revisar las causas.

Para servidores publicados, esto significa que DNAT, una regla de firewall bien delimitada, IPS policy, logging y gestión de parches deben funcionar conjuntamente. En segmentos internos también hay que comprobar si el tráfico atraviesa realmente el firewall y la regla esperada.

Elegir la IPS policy adecuada

La policy se elige según el origen, el destino y la aplicación:

• Clientes hacia Internet: Usar una policy de cliente o LAN-to-WAN y coordinarla con Web Protection, Application Control y, cuando corresponda, TLS Inspection. Incluir navegadores, servicios de actualización y aplicaciones empresariales en la fase piloto; para descargas sospechosas, Zero-Day Protection complementa la inspección mediante firmas.
• Internet hacia un servidor mediante DNAT: Delimitar una policy de servidor o web server al sistema de destino y a los puertos publicados. La protección se aplica a los servicios que realmente se ofrecen, no de forma general a todas las tecnologías de servidor. Publicar un servidor mediante DNAT explica el contexto de NAT y reglas; además, las IP, los dominios y las URL maliciosas conocidas pueden bloquearse mediante Threat Feeds.
• VPN site-to-site o remote access: Elegir la policy según los sistemas de origen y destino. Probar aplicaciones productivas, MTU/MSS, latencia y rendimiento a través de la ruta VPN real.
• VoIP: Probar SIP/RTP con una policy específica y un plan de reversión. Una policy agresiva de cliente o servidor puede interrumpir la señalización o el flujo multimedia.
• Redes de gestión, backup e infraestructura: Protegerlas de forma restrictiva sin interrumpir conexiones necesarias de administración, supervisión o backup. Aquí, las reglas bien delimitadas suelen aportar más que una selección especialmente amplia de firmas.

En límites de segmentos, por ejemplo de cliente a servidor o de VPN a servidor, IPS también dificulta el movimiento lateral tras una intrusión. Sin embargo, solo complementa unas reglas de firewall bien diseñadas. Los ajustes independientes de Spoof y DoS se encargan de patrones básicos de suplantación y flooding.

Crear una policy propia a partir de una plantilla

Con Add se puede clonar una policy predeterminada y adaptarla de forma específica. Es más comprensible que una colección arbitraria de firmas y conserva una protección básica sensata. El nombre debe indicar la finalidad y la ruta del tráfico, por ejemplo IPS-Pilot-LAN o IPS-DNAT-Webserver.

Las reglas de una policy se evalúan de arriba abajo. Por eso, una regla amplia para todas las firmas de servidor puede ocultar una regla especial situada debajo para una sola SID. Los ajustes específicos deben colocarse por encima de las reglas más generales; después, una coincidencia adecuada en el log debe confirmar que se aplica la acción esperada.

Filtrar y evaluar firmas

Las firmas se pueden filtrar por Category, Severity, Platform y Target. También se pueden crear firmas IPS propias, pero deben utilizarse solo para un caso de detección claramente documentado y revisarse más adelante. Estos datos son esenciales para logs, tickets y excepciones:

• SID: ID único de la firma
• Category: área técnica, por ejemplo DNS, navegador o malware
• Severity: nivel de gravedad
• Platform: plataforma afectada, por ejemplo Windows o Linux
• Target: firma de cliente o servidor
• Recommended action: acción recomendada por Sophos

Sophos asigna Critical a CVSS de 9 a 10, Major de 7 a menos de 9, Moderate de 4 a menos de 7 y Minor de 1 a menos de 4 o a firmas padre. Warning marca tráfico sospechoso como alerta. Sin embargo, la Severity por sí sola no decide: una firma Major en un servidor expuesto debe evaluarse de forma distinta a una coincidencia Warning en una red de prueba. Siempre hay que considerar el sistema de destino, la accesibilidad, el nivel de parches y la acción realmente aplicada.

Entender las acciones de IPS

Una regla de policy puede sobrescribir la acción recomendada por Sophos:

• Recommended: punto de partida razonable para reglas productivas; aplica la recomendación de Sophos correspondiente
• Allow packet: registra la coincidencia, pero permite el paquete; sirve para una fase piloto, aunque no impide el ataque detectado
• Drop packet: descarta solo el paquete afectado; la aplicación puede continuar o responder con errores
• Drop session: finaliza toda la sesión tras una coincidencia; intervención más fuerte ante un riesgo de ataque confirmado
• Reset: reinicia activamente la sesión TCP; el usuario o la aplicación ven una interrupción abrupta
• Disable: desactiva la firma; se pierde la protección para esa detección concreta
• Bypass session: deja de inspeccionar el resto de la sesión; el tráfico puede pasar a FastPath u offload y eludir así más inspecciones de las previstas

Las acciones de paquete se aplican a cada paquete. Las acciones de sesión inspeccionan hasta la primera coincidencia y después afectan a toda la conexión. Por eso, cualquier desviación de Recommended necesita una nota con firma, policy, regla de firewall, motivo, responsable y fecha de revisión.

Patrones PQC desde SFOS 22.0 MR2

SFOS 22.0 MR2 detecta negociaciones ML-KEM puras e híbridas, incluidas ML-KEM-512, -768 y -1024, y X25519 con ML-KEM-768. Los nuevos patrones PQC tienen Disabled como acción predeterminada porque PQC no es automáticamente sospechoso. Para evaluarlos, conviene probar primero una policy piloto propia con Allow packet y logging, y utilizar Drop session o Reset solo después del análisis. Sophos Firewall v22 MR2: control de PQC ofrece más contexto.

Desplegar y probar de forma controlada

1. Elegir una regla piloto: Empezar con una red de prueba de clientes conocida o una única regla DNAT. El tráfico esperado y la persona responsable deben estar claros antes de la prueba.
2. Probar aplicaciones reales: Comprobar el inicio de sesión, la transferencia de archivos, las actualizaciones, las API y las sesiones prolongadas. Un ping breve no demuestra que la aplicación funcione de forma estable con IPS.
3. Evaluar coincidencias: En Log viewer, revisar origen, destino, servicio, regla de firewall, firma, SID, Severity, acción y hora. Las herramientas siguientes aportan el contexto técnico.
4. Ampliar gradualmente: Añadir más reglas solo después de pruebas estables. VoIP, ERP, protocolos industriales, VPN y aplicaciones antiguas requieren una ventana de pruebas y un plan de reversión.

Para el análisis ayudan Servicios y logs, el uso conjunto de Log Viewer y Packet Capture y la revisión de paquetes descartados.

Las herramientas responden a preguntas diferentes:

• ips.log: información detallada sobre decisiones de IPS, DPI y Application Control
• Packet Capture: flujo de paquetes, dirección, Firewall Rule ID, NAT ID e IPS Policy ID
• Prueba de reglas: qué regla de firewall procesa realmente el tráfico
• Syslog o Central Reporting: conservación más prolongada y correlación

Cuando hay varios módulos de protección activos, hay que comparar la hora en los logs de firewall, IPS, web, Application Control y SSL/TLS Inspection. Una regla de firewall puede permitir tráfico que después bloquea un módulo posterior.

Comparar el rendimiento

El consumo de recursos de IPS varía según el modelo, el tráfico, las firmas, TLS Inspection, Application Control, VPN y el tamaño de los paquetes. Antes y después de activar IPS deben registrarse estos valores con una carga comparable:

• carga de CPU y memoria
• rendimiento en las interfaces afectadas
• latencia y retransmisiones de aplicaciones críticas
• volumen de IPS/DPI y Syslog
• mensajes de usuarios y aplicaciones

Desactivar IPS brevemente no demuestra que sea la causa. Para obtener comparaciones reproducibles hacen falta datos de rendimiento del firewall correctamente interpretados y una prueba iPerf controlada.

Gestionar falsos positivos y excepciones

Si se bloquea tráfico legítimo, no debe desactivarse IPS globalmente como reacción inmediata. Una coincidencia puede ser un falso positivo, una aplicación inesperada o un intento real de exploit. Primero hay que recopilar:

• ID y nombre de la firma
• origen, destino, servicio y regla de firewall coincidente
• hora, frecuencia y aplicación afectada
• nivel de parches del sistema de destino
• extracto de log o Packet Capture relevante

Conviene plantear preguntas concretas: ¿El error solo aparece en un host o puerto? ¿Es reproducible? ¿Desaparece después de aplicar un parche? ¿La misma SID apunta repetidamente al mismo destino? Solo estos hechos justifican cambiar la policy.

Después hay que delimitar el cambio al máximo:

• ajustar una sola firma en vez de una categoría completa
• usar una IPS policy propia solo en la regla de firewall afectada
• comprobar el orden de las reglas de policy
• delimitar mejor origen, destino y servicio en la regla de firewall
• documentar motivo, responsable y fecha de revisión
• comprobar después del cambio que solo se ve afectado el tráfico previsto

Una excepción temporal suele ser mejor que una desactivación permanente. Debe revisarse después de actualizar una aplicación, el firmware o un sistema. Si varias firmas interfieren con la misma aplicación, una policy propia o una mejor segmentación es más limpia que una gran excepción global.

Troubleshooting y operación

IPS no actúa

Comprobar en este orden:

1. ¿Es válida Network Protection o la licencia Trial?
2. ¿Está IPS Protection activado globalmente?
3. ¿Están actualizados los patrones IPS? En un clúster HA se actualizan en el Primary y se sincronizan automáticamente con el Auxiliary.
4. ¿Coincide el tráfico con la regla de firewall esperada que tiene IPS policy y logging?
5. ¿Una regla de policy amplia oculta una regla específica?
6. ¿Contiene la policy acciones injustificadas como Allow packet, Disable o Bypass session?
7. ¿Es adecuada la policy para tráfico de cliente, servidor, VPN o VoIP?
8. ¿Se ha comprobado con tráfico real que Log Viewer y ips.log muestran eventos correspondientes?

Las excepciones sin responsable o fecha de revisión se consideran abiertas y deben incluirse en la siguiente revisión operativa.

El servicio IPS está en DEAD

En SFOS 22.0 GA y versiones posteriores, en casos poco frecuentes pueden faltar datos de configuración necesarios de Web Policy. En ese caso, el servicio Web Policy no se inicia, IPS no puede inicializar su policy y permanece en DEAD; las actualizaciones de patrones también fallan. En un clúster HA, cada nodo puede verse afectado de forma independiente.

En la CLI, 5 Device Management > 3 Advanced Shell abre la shell necesaria. Este comando de solo lectura muestra todas las líneas de servicio que contienen ips en el nombre:

service -S | grep -i ips

Solo es relevante la línea cuyo primer nombre de servicio sea exactamente ips; no se refiere a ipsec-monitor. En un clúster HA hay que comprobar por separado cada nodo afectado.

Si el servicio está en DEAD, hay que guardar la versión de SFOS, la hora, el nodo, la salida de estado completa, ips.log y sig_upgrade.log, y contactar con Sophos Support indicando NC-181971. El comando por sí solo no demuestra que este problema esté presente. Sophos sigue sin publicar una versión corregida y solo proporciona el workaround a través de Support. Los intentos de reinicio repetidos o los comandos de reparación no documentados no son una solución adecuada.

Preguntas frecuentes