Configurar y probar de forma segura IPS en Sophos Firewall
Intrusion Prevention System (IPS) examina el tráfico de red en busca de patrones de ataque conocidos, exploits y características anómalas de los protocolos. Para que IPS proporcione una protección efectiva, debe estar activado globalmente. Además, la regla de firewall que procesa el flujo de datos debe utilizar una política IPS adecuada.
El procedimiento seguro y breve consiste en comprobar la licencia y los patrones, activar IPS, seleccionar una política en función del sistema que se quiere proteger, asignarla a la regla de firewall correcta y validar la ruta de datos con un grupo piloto reducido. Aplicar la política más estricta a todas las reglas no ofrece automáticamente la mejor protección. Una selección inadecuada genera detecciones, carga o interrupciones innecesarias y dificulta el análisis de los eventos relevantes.
Comprobar los requisitos y el estado de la licencia
Antes de configurar IPS se necesita:
- una suscripción Network Protection activa o una licencia de prueba;
- firmas IPS disponibles y actualizaciones de patrones operativas;
- el ID de la regla de firewall que realmente procesa el tráfico previsto;
- el registro de la regla activado para correlacionar la sesión, la regla de firewall y el evento IPS;
- una persona responsable, pruebas definidas y un procedimiento de reversión para los falsos positivos.
IPS Protection está desactivado de forma predeterminada. En un firewall conectado a Internet, las firmas IPS solo se actualizan si hay una licencia válida e IPS está activado. Los firewalls con licencia Air Gap constituyen la excepción documentada: pueden recibir firmas IPS mediante el proceso de actualización previsto aunque IPS esté desactivado. Licencias Air Gap y actualizaciones de patrones explica estas diferencias.
Tras vencer una suscripción de Network Protection, el interruptor de IPS puede seguir apareciendo como activo aunque el firewall ya no aplique la protección IPS. La licencia de prueba se comporta de otro modo: al vencer, IPS se desactiva automáticamente. Con IPS desactivado dejan de descargarse firmas en línea y ya no es posible configurar políticas ni firmas personalizadas. Después de 30 días en este estado, SFOS elimina las firmas y las reglas IPS. Si es necesario conservar la configuración, debe crearse previamente una exportación o una copia de seguridad.
Aunque IPS esté desactivado, las políticas IPS existentes pueden seguir asignándose a reglas de firewall. Esta asignación no demuestra que haya una inspección activa ni una protección efectiva. Si la suscripción de pago ha vencido e IPS está desactivado, o si una licencia de prueba vencida ha desactivado IPS automáticamente, primero debe activarse una suscripción de Network Protection para poder volver a activar IPS. Tras activar la suscripción, compruebe de nuevo el interruptor de IPS y las firmas.
Incluso una suscripción válida no protege indefinidamente sin contacto con el sistema de licencias. Por lo general, los firewalls conectados sincronizan sus licencias cada 24 horas. Si la sincronización no se produce durante 90 días consecutivos, SFOS desactiva las suscripciones de seguridad; con una licencia Air Gap, este plazo es de 180 días. Los inicios de sesión y el tráfico pueden seguir funcionando, pero sin la protección de las suscripciones desactivadas. Por tanto, cuando IPS parece estar configurado pero no actúa, el estado de la licencia debe formar parte del diagnóstico.
En Backup & firmware > Pattern updates, SFOS muestra, entre otros, los estados Ready to install, Downloading, Success y Failed. Update pattern now inicia una actualización de las definiciones de patrones normales. Una entrada correcta para Application Signatures no demuestra que también se hayan descargado las firmas IPS: en los sistemas conectados, estas siguen requiriendo una licencia e IPS activado.
Activar IPS y definir la ruta de datos
- Abra Intrusion prevention > IPS policies.
- Active IPS Protection.
- En Backup & firmware > Pattern updates, compruebe la fecha y hora y el estado de los patrones IPS.
- Documente el estado anterior de IPS Protection, el ID de la regla de firewall del flujo piloto, la política IPS anterior, Log firewall traffic y las excepciones existentes.
Activar o desactivar Firewall Acceleration o PKI Acceleration reinicia IPS o el motor DPI. Esos cambios no forman parte de este procedimiento de activación. Si un problema reproducible afecta a un ajuste global del motor, Comprobar de forma segura los ajustes globales de IPS explica qué cambios se aplican de inmediato, cuáles requieren pulsar Apply o reiniciar y cómo conservar el valor inicial.
El sistema que se desea proteger determina la política
Target designa el lado cuyo software vulnerable protege una firma. No equivale simplemente a Source Zone o Destination Zone. Por ejemplo, para un navegador que recibe una respuesta manipulada, el Target puede ser Client; para un servidor web publicado que recibe una solicitud maliciosa, puede ser Server.
La selección se resuelve con tres preguntas:
- ¿Qué sistema es el objetivo que se debe proteger en el flujo analizado: el cliente o el servidor?
- ¿Qué plataformas, protocolos y servicios se ejecutan realmente en él?
- ¿Cubre una política existente ese ámbito sin incluir grupos de firmas ajenos al entorno?
Para una ruta normal de clientes hacia Internet, el punto de partida es una política adecuada para clientes o LAN-to-WAN. En una publicación mediante DNAT, debe elegirse una política para servidores o servidores web que corresponda al sistema operativo y a los puertos realmente publicados. En un flujo VPN o de segmentación también decide la aplicación protegida, no solo el nombre de la zona de origen. MTU, MSS, latencia y rendimiento deben comprobarse a través de la ruta VPN real.
VoIP requiere una prueba funcional específica de la señalización SIP y los medios RTP, además de tener preparada la vuelta a la política anterior. Para redes de gestión, copias de seguridad e infraestructura, las reglas de alcance limitado suelen aportar más que una selección de firmas especialmente amplia. IPS también puede dificultar los ataques laterales en los límites entre segmentos internos; sin embargo, los umbrales contra la suplantación y las inundaciones siguen siendo una tarea independiente de los ajustes de protección contra spoofing y DoS.
Conviene crear una política propia cuando sea necesario delimitar mejor la ruta de datos, un SID concreto requiera una excepción documentada o se quiera usar deliberadamente una acción distinta de Recommended. Para ello, en Intrusion prevention > IPS policies > Add se asigna un nombre inequívoco, como IPS-Pilot-LAN o IPS-DNAT-Webserver, y se clona como punto de partida una política existente apropiada. Primero se guarda la política nueva o clonada con Save; este paso todavía no crea ninguna regla nueva de la política. Después se ajustan las reglas de la copia; las firmas incluidas por el fabricante no se pueden modificar.
Filtrar firmas y ordenar las reglas de la política
Al añadir una regla se pueden seleccionar firmas individuales, firmas personalizadas o Select all. El Smart Filter admite términos de búsqueda y criterios como Category, Severity, Platform y Target; tras introducirlos, el filtro se aplica con la tecla Enter.
El editor de reglas se abre por separado de la creación de la política: en Intrusion prevention > IPS policies, seleccione Edit en la política deseada, ya guardada, después Add e introduzca un nombre inequívoco para la regla. A continuación, seleccione las firmas necesarias: Select individual signature para firmas individuales o Custom signature para firmas personalizadas. Para realizar una búsqueda mediante Smart filter, seleccione primero Select all, introduzca el término de búsqueda y aplíquelo con la tecla Enter.
Las categorías ayudan a delimitar el ámbito técnico. La tabla completa siguiente explica las etiquetas visibles en SFOS. Category es una ayuda de consulta, no un veredicto de riesgo; combinada con Platform y Target, permite que el Smart Filter seleccione solo las firmas pertinentes.
| Category | Significado |
|---|---|
app-detect | Identifica y controla el tráfico de determinadas aplicaciones y distintos aspectos de su comportamiento. |
browser-chrome | Detecta y bloquea vulnerabilidades de Google Chrome. |
browser-firefox | Detecta y bloquea vulnerabilidades de Firefox y productos que usan el motor Gecko. |
browser-ie | Detecta y bloquea vulnerabilidades de Internet Explorer y productos que usan Trident o Tasman. |
browser-webkit | Detecta y bloquea vulnerabilidades de WebKit, incluido Safari; Chrome queda excluido porque tiene su propia categoría. |
browser-other | Detecta y bloquea vulnerabilidades de navegadores sin categoría propia, como Edge u Opera. |
browser-plugin | Detecta y bloquea vulnerabilidades de navegadores compatibles con plugins. |
exploit-kit | Detecta y bloquea vulnerabilidades orientadas a la actividad de kits de exploits. |
file-executable | Detecta y bloquea vulnerabilidades independientes del sistema presentes o distribuidas mediante ejecutables. |
file-flash | Detecta y bloquea vulnerabilidades presentes o distribuidas mediante archivos Flash. |
file-image | Detecta y bloquea vulnerabilidades incrustadas en imágenes, entre ellas JPG, PNG, GIF, BMP y PDF. |
file-identify | Identifica archivos por su extensión, contenido o cabeceras presentes en el tráfico. |
file-java | Detecta y bloquea vulnerabilidades de archivos Java (jar). |
file-multimedia | Detecta y bloquea vulnerabilidades incrustadas en archivos multimedia, entre ellos MP4, MOV y QT. |
file-office | Detecta y bloquea vulnerabilidades incrustadas en archivos de la familia Microsoft Office. |
file-pdf | Detecta y bloquea vulnerabilidades incrustadas en archivos PDF. |
file-other | Detecta y bloquea vulnerabilidades en archivos sin categoría propia. |
indicator-compromise | Detecta y bloquea dispositivos comprobadamente comprometidos; estas reglas pueden generar falsos positivos. |
indicator-obfuscation | Detecta y bloquea contenido ofuscado. |
indicator-shellcode | Detecta y bloquea indicadores simples de shellcode en el tráfico. |
malware-backdoor | Detecta y bloquea tráfico destinado a canales de mando de puertas traseras conocidos. |
malware-cnc | Detecta y bloquea actividad C&C maliciosa conocida de botnets: comunicaciones de retorno, descarga de archivos depositados y exfiltración. |
malware-other | Detecta y bloquea otro malware sin categoría específica. |
misc | Detecta y bloquea vulnerabilidades de aplicaciones no incluidas en otra categoría IPS. |
netbios | Detecta y bloquea vulnerabilidades del protocolo NetBIOS. |
os-linux | Detecta y bloquea vulnerabilidades de Linux. |
os-solaris | Detecta y bloquea vulnerabilidades de Solaris. |
os-windows | Detecta y bloquea vulnerabilidades de Windows. |
os-mobile | Detecta y bloquea vulnerabilidades de sistemas operativos móviles. |
os-other | Detecta y bloquea vulnerabilidades de sistemas operativos sin categoría propia. |
policy-other | Detecta y bloquea tráfico que puede infringir las políticas corporativas del operador. |
protocol-dns | Detecta y bloquea vulnerabilidades de DNS. |
protocol-ftp | Detecta y bloquea vulnerabilidades de FTP. |
protocol-icmp | Detecta y bloquea vulnerabilidades de ICMP. |
protocol-imap | Detecta y bloquea vulnerabilidades de IMAP. |
protocol-nntp | Detecta y bloquea vulnerabilidades de NNTP. |
protocol-pop | Detecta y bloquea vulnerabilidades de POP. |
protocol-rpc | Detecta y bloquea vulnerabilidades de RPC. |
protocol-scada | Detecta y bloquea vulnerabilidades de protocolos SCADA. |
protocol-services | Detecta y bloquea vulnerabilidades de los demás protocolos de servicio de la red. |
protocol-snmp | Detecta y bloquea vulnerabilidades de SNMP. |
protocol-telnet | Detecta y bloquea vulnerabilidades de Telnet. |
protocol-tftp | Detecta y bloquea vulnerabilidades de TFTP. |
protocol-VOIP | Detecta y bloquea vulnerabilidades de VoIP. |
protocol-other | Detecta y bloquea vulnerabilidades de protocolos sin categoría propia. |
pua-other | Detecta y bloquea vulnerabilidades que afectan a aplicaciones potencialmente no deseadas (PUA) usadas en la red. |
server-apache | Detecta y bloquea vulnerabilidades de servidores web Apache. |
server-iis | Detecta y bloquea vulnerabilidades de servidores web Microsoft IIS. |
server-mssql | Detecta y bloquea vulnerabilidades de servidores Microsoft SQL. |
server-mysql | Detecta y bloquea vulnerabilidades de servidores Oracle MySQL. |
server-oracle | Detecta y bloquea vulnerabilidades de servidores Oracle Database. |
server-samba | Detecta y bloquea vulnerabilidades de servidores Samba. |
server-webapp | Detecta y bloquea vulnerabilidades de aplicaciones web. |
server-mail | Detecta y bloquea vulnerabilidades del tráfico dirigido a servidores de correo. |
server-other | Detecta y bloquea vulnerabilidades de servidores sin categoría propia. |
sql | Detecta y bloquea vulnerabilidades y ataques de inyección SQL contra servidores que ejecutan SQL. |
scan | Detecta y bloquea herramientas de análisis de vulnerabilidades habituales, como Nmap y Nuclei. |
Las categorías amplias de indicadores deben probarse primero en un piloto de observación. En particular, indicator-compromise puede generar falsos positivos; la categoría por sí sola no justifica un bloqueo ni una excepción.
Después de seleccionar las firmas, establezca deliberadamente la Action; las diferencias se explican en la sección sobre gravedad y acción. Guarde la regla con Save en el editor de reglas. Este paso es distinto del guardado inicial de la política. En el procedimiento DDoS, después se guarda además la política que contiene la regla con Save.
Después de guardar, inicie una sesión de prueba nueva y compruebe ips_policy_id o idp_policy_id, además de fw_rule_id; si hay una detección, compare también signature_id, classification y log_subtype con la regla y la acción previstas. La ausencia de detecciones no demuestra por sí sola que se hayan aplicado el filtro o la política.
Las reglas de una política se evalúan de arriba abajo. Por ello, una regla amplia para todas las firmas de servidor puede ocultar una regla especial situada debajo para un solo SID. Las excepciones específicas o las acciones diferentes deben situarse por encima de la regla más general. Una detección posterior debe mostrar la política, el ID de regla y la acción esperados.
Las firmas IPS personalizadas están destinadas a casos de detección claramente descritos, no a sustituir una selección estándar inadecuada. El procedimiento con la sintaxis, una política piloto de alcance limitado y pruebas positivas y negativas se describe en Crear y probar firmas IPS personalizadas.
Evaluar por separado la gravedad y la acción
Para los registros, los tickets y las excepciones son importantes SID, Category, Severity, Platform, Target y Recommended action. 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 identifica y genera una alerta sobre un tipo determinado de tráfico. La gravedad por sí sola no determina el riesgo: también deben evaluarse la accesibilidad, el sistema de destino, el estado de los parches y la acción efectiva.
Esta correspondencia con CVSS tiene excepciones: Sophos describe casos cuya clasificación de gravedad no encaja en las fórmulas indicadas. De ello no puede deducirse ni una función documentada de WebAdmin para sobrescribir la gravedad ni un procedimiento para reclasificarla; compruebe la gravedad que realmente se muestra para la firma.
Una regla de política puede sobrescribir la acción recomendada:
- Recommended aplica la acción recomendada por Sophos para cada firma y es el punto de partida habitual para las reglas en producción.
- Allow packet registra la detección, pero permite el paquete. Es apropiado para un piloto, aunque no impide el ataque detectado.
- Drop packet descarta únicamente el paquete afectado. La aplicación puede seguir funcionando o responder con un error.
- Drop session finaliza la sesión completa después de una detección.
- Reset finaliza activamente una sesión TCP enviando un reset al iniciador.
- Disable desactiva solo esa firma; se pierde la detección correspondiente.
- Bypass session deja de inspeccionar el resto de la sesión. Como consecuencia, el tráfico puede pasar a FastPath u Offload y quedar excluido de la inspección en mayor medida de la prevista.
Las acciones de paquete se aplican a cada paquete. Las acciones de sesión inspeccionan hasta la primera detección y, a partir de ella, actúan sobre toda la conexión. Por eso, toda desviación de Recommended debe justificarse indicando la firma, la política, la regla de firewall, la persona responsable y la fecha de revisión.
Seleccionar la política IPS en la regla de firewall
- Abra Rules and policies > Firewall rules.
- Edite la regla cuyo ID se haya verificado en el flujo piloto.
- En Other security features, seleccione la política IPS en Detect and prevent exploits (IPS).
- Active Log firewall traffic, guarde los cambios y genere una sesión nueva para la prueba.
La activación global por sí sola no basta. Si el tráfico coincide primero con otra regla que no tiene una política IPS, una regla posterior no lo protegerá. La regla de Sophos Firewall no coincide: comprobar las causas ayuda a verificar la coincidencia de reglas.
Las reglas de firewall delimitan qué tráfico se permite. IPS detecta patrones de ataque en el flujo de datos visible. Web Protection controla contenidos y categorías web, Application Control clasifica aplicaciones, TLS Inspection hace visible el contenido cifrado cuando es necesario y Zero-Day Protection analiza archivos sospechosos. Los Threat Feeds, por ejemplo los mantenidos por Cybora, bloquean además direcciones IP, dominios o URL maliciosos conocidos. Estos módulos se complementan; ninguno sustituye una regla de firewall de alcance limitado, la gestión de parches ni la selección correcta de la política.
Validar un piloto controlado
Antes de empezar deben definirse la duración de la prueba, la persona responsable, la base de comparación y los criterios de cancelación. La línea base debe incluir la fecha y hora de los patrones, el ID de la regla de firewall, las políticas IPS anterior y nueva, las excepciones conocidas, el uso de CPU y memoria y al menos una conexión de control sin cambios. Para VoIP, ERP, protocolos industriales, VPN y aplicaciones antiguas, la prueba requiere una ventana de mantenimiento.
- Verificar la asignación de la política: genere una sesión nueva y compruebe en Packet Capture o en el registro del firewall el ID de la regla de firewall y el ID de la política IPS esperados. Esto demuestra la asignación, pero no una detección de firma. El procedimiento conjunto de Log Viewer y Packet Capture puede aplicarse directamente a la conexión de prueba.
- Probar los flujos de trabajo reales: ejecute el inicio de sesión, la transferencia de archivos, las actualizaciones, las API y las sesiones de larga duración. Un ping no los sustituye.
- Evaluar los eventos: si se produce una detección, registre el ID y el nombre de la firma, la política, la regla de firewall, el origen, el destino, los puertos y la acción efectiva. No se debe generar un ataque real expresamente para comprobar el funcionamiento. Para obtener una detección inocua y determinista, utilice el piloto de firmas personalizadas controlado.
- Comparar la conexión de control: una conexión permitida del mismo ámbito debe seguir mostrando la regla y la aplicación esperadas. Si desaparecen paquetes, el análisis independiente de los paquetes descartados ayuda a acotar la causa.
- Ampliar solo después: añada más hosts o reglas únicamente cuando no queden bloqueos sin explicar y se respeten los límites de carga, latencia y aplicación definidos previamente.
El éxito no implica necesariamente haber activado una firma de ataque. Lo decisivo es haber demostrado la asignación de la política, que los flujos de prueba y de control funcionen, que no haya bloqueos sin explicar y que los valores de recursos sean aceptables. En cuanto falle un proceso empresarial crítico, aparezca un bloqueo sin explicar o se supere un límite de rendimiento acordado, deben restaurarse los valores iniciales documentados de la asignación de la política y del registro de la regla. Una política piloto creada específicamente solo se elimina cuando ya no está asignada a ninguna regla y se han documentado sus excepciones. Si IPS estaba desactivado globalmente antes del piloto, este estado inicial solo debe restaurarse después de comprobar qué otras reglas de firewall perderían así su protección IPS.
Interpretar correctamente los registros, Packet Capture y los informes
Las herramientas responden a preguntas diferentes:
- Registro del firewall:
ips_policy_idmuestra qué política estaba asociada al flujo. Resulta útil incluso sin una detección de firma. - Evento IPS:
log_type=IDP,signature_id,signature_msg,idp_policy_id,fw_rule_id,classificationylog_subtyperelacionan la firma, la política, la regla y el resultado. El valordetection_severitydel registro no coincide necesariamente con la representación categórica de Severity en la política. - Packet Capture: muestra, entre otros datos, el ID de la regla de firewall, el ID de NAT y el ID de la política IPS en el flujo de paquetes.
ips.log: ofrece información más detallada sobre las decisiones de IPS, DPI, Application Control y Active Threat Response.sig_upgrade.logysigmigration.log: muestran la actualización o la migración de firmas.- Reports > Network & threats > Intrusion attacks: resulta adecuado para el análisis retrospectivo; Log Viewer sigue siendo más apropiado para eventos actuales concretos.
La correspondencia de otros archivos de registro y servicios se explica en Servicios y registros de Sophos Firewall. Cuando hay varios módulos de protección activos, debe compararse la misma marca temporal en los registros del firewall, IPS, web, Application Control e inspección SSL/TLS. Una regla de firewall puede permitir tráfico que posteriormente bloquee un módulo situado más adelante en el procesamiento.
Comprobar el rendimiento con una carga comparable
Según el modelo, el tráfico, las firmas, TLS Inspection, Application Control, la VPN y el tamaño de los paquetes, IPS consume cantidades de recursos diferentes. Antes y después de activarlo deben registrarse, con una carga comparable, la CPU, la memoria, el rendimiento, la latencia, las retransmisiones de aplicaciones críticas y el volumen de IPS/DPI y Syslog.
Desactivar IPS brevemente no demuestra por sí solo la causa. Para obtener comparaciones reproducibles hacen falta métricas de rendimiento del firewall correctamente interpretadas y una prueba controlada con iPerf.
Decidir sobre los falsos positivos en lugar de limitarse a permitirlos
Una detección IPS puede ser un falso positivo, una aplicación inesperada o un intento real de explotación. Primero deben registrarse el ID y el nombre de la firma, el origen, el destino, el servicio, la regla de firewall, la hora, la frecuencia, la aplicación afectada y el estado de los parches. A continuación se toma la decisión:
- Reproduzca el flujo legítimo y confirme que lo activa exactamente ese SID.
- Compruebe el estado de los parches, las indicaciones del fabricante y la accesibilidad del sistema protegido.
- Evalúe el riesgo de permitir el tráfico asociado a la detección. Si el resultado no está claro o no puede reproducirse, no debe crearse una excepción permanente.
- Elija la medida reversible de menor alcance: preferentemente, aplique el parche o delimite mejor la ruta de datos; en caso contrario, establezca temporalmente un único SID en Allow packet dentro de una política que solo se utilice allí. Disable o Bypass session eliminan más protección y requieren una justificación más sólida.
- Vuelva a probar el flujo positivo legítimo y un flujo negativo o de control.
- Documente la excepción, la persona responsable y la fecha de revisión, y vuelva a evaluarla después de actualizar la aplicación, los patrones, el firmware o el sistema.
Si muchas firmas interfieren con la misma aplicación, una política propia de alcance limitado o una mejor segmentación son soluciones más limpias que acumular excepciones globales permanentes. Desactivar IPS globalmente no es una reversión adecuada para un solo SID.
Solución de problemas según el síntoma
No se ven eventos IPS
Genere primero una sesión nueva y compruebe el ID de la regla de firewall y ips_policy_id en el registro del firewall o en Packet Capture. Si falta el ID de la política, el flujo coincide con otra regla o la regla seleccionada no tiene asignada una política IPS. Si puede demostrarse la política pero no hay ninguna detección de firma, puede ser el comportamiento correcto para tráfico inocuo. Para obtener una prueba reproducible debe usarse una Custom Signature de alcance limitado en un piloto aislado, no un exploit real.
Hay un evento, pero el tráfico no se bloquea
Compruebe signature_id, la política y log_subtype en el evento IPS. A continuación, revise la primera regla coincidente de la política y su acción efectiva. Allow packet, Disable o Bypass session pueden impedir el bloqueo esperado; una regla amplia situada más arriba puede ocultar la regla específica. Después de cada cambio debe probarse una sesión nueva.
Faltan firmas IPS o falla la actualización de patrones
Compruebe conjuntamente el estado de la licencia, el interruptor global de IPS y Backup & firmware > Pattern updates. El estado Failed o una versión reciente de Application Signatures no demuestran que IPS se haya actualizado correctamente. sig_upgrade.log muestra la ruta de actualización; si existen problemas de licencia, licensing.log aporta contexto. En un clúster HA, el nodo Primary actualiza los patrones IPS y los sincroniza automáticamente con el Auxiliary.
El servicio IPS aparece como DEAD
En System services > Services, compruebe y documente el estado del servicio IPS. Si Sophos Support solicita además una salida de shell específica del nodo, acceda mediante 5 Device Management > 3 Advanced Shell para ejecutar esta comprobación de solo lectura:
service -S | grep -i ips
La línea relevante es aquella cuyo primer nombre de servicio es exactamente ips; no se refiere a ipsec-monitor. Este comando de Advanced Shell no forma parte del procedimiento publicado para el problema conocido y solo debe utilizarse en un diagnóstico coordinado con el soporte. En un clúster HA, el estado solicitado debe registrarse por separado en cada nodo afectado.
En SFOS 22.0 GA y versiones posteriores, en raras ocasiones pueden faltar datos de configuración necesarios para las políticas web. En ese caso, el servicio de políticas web no se inicia, IPS no puede inicializar su política y permanece en DEAD; las actualizaciones de patrones también fallan. En un clúster HA, cada nodo puede verse afectado de forma independiente.
Registre la versión de SFOS, la hora, el nodo, el estado del servicio, ips.log y sig_upgrade.log, y póngase en contacto con Sophos Support haciendo referencia a NC-181971. El estado por sí solo no demuestra esta causa. Sophos sigue sin publicar una versión corregida en la lista actual de problemas conocidos y proporciona la solución alternativa a través del soporte. Los reinicios repetidos o los comandos de reparación no documentados no constituyen un procedimiento de diagnóstico adecuado.
Paquete completo de firmas solo para casos especiales demostrados
Durante una actualización de patrones, SFOS puede descargar el paquete completo de firmas IPS en lugar de un paquete parcial. Esta opción solo se aplica a appliances con al menos 32 GB de RAM y, según Sophos, puede afectar al rendimiento. No activa IPS ni asigna una política a ninguna regla de firewall.
Un motivo válido es una firma indicada expresamente por Sophos Support que no esté incluida en el paquete parcial. La opción no debe activarse de forma preventiva solo porque parezca preferible disponer de más firmas. Primero se consulta el estado actual en Device Console:
system ips full-signature-pack show
La ayuda de Device Console no especifica ningún valor predeterminado. Una vez confirmados el límite de RAM y la necesidad concreta, puede activarse la descarga completa:
system ips full-signature-pack enable
Después de la siguiente actualización de patrones, deben comprobarse la fecha y hora de los patrones, sig_upgrade.log, la firma esperada, el estado de IPS, la CPU, la RAM y el tráfico afectado. Si no se obtiene el beneficio esperado o empeora el funcionamiento, debe restaurarse el estado consultado anteriormente. Si antes de la prueba era disable, el comando de reversión es:
system ips full-signature-pack disable
Detección de PQC a partir de SFOS 22.0 MR2
SFOS 22.0 MR2 puede detectar y controlar métodos de intercambio de claves poscuánticos puros e híbridos basados en ML-KEM. Los nuevos patrones IPS están desactivados de forma predeterminada porque PQC no es sospechoso por sí mismo. Para analizar estas conexiones, debe utilizarse primero una política piloto propia con Allow packet y registro. Solo un caso de uso definido y una prueba positiva y una prueba de control estables justifican Drop session o Reset. Sophos Firewall v22 MR2: control de PQC ofrece más información.