Crear y probar firmas IPS personalizadas en Sophos Firewall

Una firma IPS propia resulta útil cuando Sophos no proporciona una firma adecuada para un patrón de red o de aplicación claramente definido. Puede detectar, por ejemplo, una cadena conocida en texto plano, una característica inusual de un protocolo o una combinación precisa de puerto, dirección y carga útil.

La firma por sí sola no protege nada. Debe utilizarse en una política IPS, esa política debe estar asignada a la regla de firewall que realmente coincide con el tráfico y el flujo de datos debe ser visible para IPS. Un patrón demasiado amplio puede bloquear tráfico legítimo; uno demasiado restrictivo puede no generar ninguna coincidencia.

Probar primero una firma nueva en una regla IPS piloto con Action: Allow packet. Aunque Recommended action ya indique Allow packet, la acción de la regla de la política IPS es la que determina el comportamiento. Drop packet, Drop session, Reset o Bypass session modifican el tráfico de producción y solo deben ponerse en servicio después de una prueba positiva y una negativa reproducibles.

Seis pasos para una prueba piloto controlada

1. Describir el caso de detección con el protocolo, la dirección, el puerto y un patrón inequívoco.
2. Crear una firma en Intrusion prevention > Custom IPS signatures con una regla de alcance limitado y Recommended action: Allow packet.
3. Añadir la firma a una regla propia dentro de una política IPS que se pueda eliminar y seleccionar allí Action: Allow packet.
4. Asignar esta política IPS únicamente a la regla de firewall prevista para la prueba piloto y activar allí Log firewall traffic.
5. Generar una prueba que cumpla las condiciones y otra que deliberadamente no las cumpla, y comparar Log Viewer, ips.log y la coincidencia con la regla.
6. Cambiar la acción de la regla de la política IPS solo después de una validación estable; si aparecen coincidencias inesperadas, restaurar la asignación anterior de la política.

Una entrada guardada o una comprobación de sintaxis satisfactoria todavía no demuestran el funcionamiento. El éxito implica que la prueba positiva coincida exactamente con la firma personalizada y la regla de firewall esperadas, que la prueba negativa no genere coincidencias y que la aplicación de producción siga comportándose igual.

Cuándo conviene una firma propia

Las firmas personalizadas son adecuadas para una característica estable y visible a nivel de paquete o de flujo. Puede tratarse de un valor de un protocolo propietario, un indicador claro de explotación o una protección temporal para una vulnerabilidad conocida internamente. La ruta de datos esperada y la respuesta deseada deben estar definidas antes de escribir la firma.

Para direcciones IP o dominios cambiantes, suelen ser más adecuados los hosts, servicios y grupos, los Threat Feeds o las reglas de firewall de alcance limitado. Además, una firma personalizada no sustituye ni la gestión de parches ni una regla bien definida del fabricante. Para una única coincidencia en el registro, mantener un desarrollo propio permanente rara vez resulta proporcionado.

Los datos cifrados constituyen una limitación importante. IPS solo puede detectar un patrón content en la carga útil HTTPS si el contenido se descifra realmente en la ruta de procesamiento elegida y es visible para el motor. Sin una inspección TLS adecuada, normalmente solo quedan disponibles las características sin cifrar o visibles por otros medios.

Comprobar previamente la licencia y el ciclo de vida

Para activar IPS se necesita una suscripción Network Protection activa o una licencia de prueba válida, además de acceso de administrador para la firma, la política y la regla de firewall. Antes de la prueba piloto, se documentan la asignación actual de la política y el ID de la regla, y se conserva una copia de seguridad para la reversión. Los 30 días mencionados a continuación empiezan a contar cuando caduca la licencia o se desactiva IPS manualmente, no cuando se realiza el siguiente intento de configuración.

No se pueden configurar firmas propias si ha caducado la licencia de prueba de IPS o si IPS Protection está desactivado en Intrusion prevention > IPS policies. Sophos recomienda volver a activar IPS en un plazo de 30 días si se quieren conservar las firmas personalizadas existentes. Por tanto, una copia de seguridad o una exportación debe formar parte del plan de reversión antes de cambiar la licencia, IPS o realizar cambios importantes en las políticas.

A continuación, IPS debe estar activo globalmente y la regla de firewall que procesa el tráfico necesita una política IPS. La configuración básica completa se explica en Configurar Sophos Firewall IPS y probarlo de forma segura. Una firma personalizada complementa esta ruta de datos; no es un mecanismo de protección paralelo.

Delimitar claramente la sintaxis de las reglas

Limitaciones de la documentación para SFOS 22/23: La ayuda de sintaxis contiene ejemplos con un formato contradictorio: distance: 4.within:4; no es una plantilla fiable para copiar; en el caso de byte_jump, el texto explicativo menciona operandos de comparación que no aparecen en el esquema de sintaxis. Las etiquetas de los bits TCP reservados tampoco son claras. Estos puntos no se interpretan como capacidades adicionales del motor. Los fragmentos explicados a continuación siguen siendo ejemplos de documentación, no reglas probadas en un firewall. Si una regla se rechaza o su comportamiento no está claro, conservar la compilación exacta, la regla y el mensaje de error y solicitar una aclaración al soporte de Sophos; hasta entonces, no autorizar ninguna acción de bloqueo en producción.

El formulario de entrada separa Protocol y Custom rule. En la regla se combinan palabras clave individuales con sus valores y un punto y coma. Cuantas más características independientes deban coincidir, menor suele ser el riesgo de coincidencias fortuitas. Al mismo tiempo, la firma no debe ser tan específica que un cambio inocuo en el protocolo la vuelva ineficaz.

Para una prueba en texto plano exclusivamente controlada, se puede utilizar TCP como protocolo y, por ejemplo, lo siguiente como patrón de carga útil de alcance limitado:

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT es un valor de documentación deliberadamente llamativo. La regla de firewall de la prueba piloto asociada se limita además al servicio de prueba, por ejemplo, al puerto TCP 8080. El token, la dirección y el puerto se sustituyen por valores que aparezcan en el flujo de datos real y visible para IPS. Este ejemplo no es una firma de ataque universal y no debe aplicarse sin cambios a reglas de producción de amplio alcance.

Carga útil y ventana de búsqueda

content busca una secuencia de caracteres o de bytes; los valores binarios se escriben entre barras verticales. nocase ignora las diferencias entre mayúsculas y minúsculas en una coincidencia de contenido, y rawbytes trabaja sobre los datos sin procesar. depth y offset limitan la búsqueda mediante posiciones absolutas dentro de la carga útil, mientras que distance y within trabajan de forma relativa a la coincidencia anterior. uricontent, isdataat y pcre cubren casos más específicos relacionados con URI, posiciones y expresiones regulares.

Un intervalo de búsqueda limitado reduce las coincidencias fortuitas y el coste de procesamiento. En particular, pcre, las ventanas grandes o varios patrones de contenido amplios solo deben introducirse con paquetes realistas y supervisando la carga. Si depth es menor que el patrón de contenido buscado, la firma nunca podrá generar una coincidencia.

Los modificadores nocase, rawbytes, depth, offset, distance y within pertenecen a content; no son reglas de detección independientes. Sin depth, la búsqueda se extiende desde offset hasta el final de la carga útil. Sin within, la búsqueda de un segundo patrón de contenido también queda abierta desde distance hasta el final. Por tanto, un punto de inicio por sí solo no basta para mantener acotada la ventana de búsqueda. uricontent busca en la URI normalizada de la solicitud, no en datos arbitrarios de la carga útil. isdataat comprueba si hay datos en una posición especificada; con relative, esta posición se refiere al final de la coincidencia de contenido anterior.

Cabecera, flujo y valores estructurados

El origen, el destino y el puerto se pueden delimitar con srcaddr, dstaddr, srcport y dstport. Para las cabeceras IP están disponibles, entre otros, ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto y samip. Las características TCP se describen con flags, flow, seq, ack y window; itype, icode, icmp_id y icmp_seq se aplican a ICMP. rpc, byte_test y byte_jump están pensados para protocolos estructurados o binarios.

flow solo se aplica a TCP. En este contexto, to_server y from_client son equivalentes, al igual que to_client y from_server. bi_direction amplía la detección a ambas direcciones; por tanto, si se establece una condición de puerto, la prueba negativa también debe tener en cuenta el tráfico de retorno. La elección entre no_stream y only_stream no debe confundirse con una comprobación del tamaño de paquete: dsize comprueba el tamaño de la carga útil de un paquete y no genera coincidencias en paquetes reensamblados a partir de un flujo. Por ello, no es adecuado combinarlo con only_stream. Cuando falta una coincidencia, primero se decide si la característica debe buscarse en el paquete individual o en el flujo reensamblado, en lugar de cambiar únicamente el tamaño o el patrón de contenido.

Para las reglas complejas se aplica la sintaxis de IPS personalizado descrita anteriormente y compatible con SFOS 22. No se deben incorporar sin comprobación palabras clave de Snort no documentadas ni reglas copiadas de otros motores.

Operandos: dirección, puerto, URI y posición de los datos

Los siguientes fragmentos se introducen en Custom rule, no en la shell. Son una referencia para SFOS 22/23, no firmas de ataque ya probadas. Solo se combinan las condiciones adecuadas para el caso de detección; Protocol, la política piloto y Allow packet siguen formando parte de la prueba descrita anteriormente. Los corchetes de los patrones de sintaxis indican partes opcionales y no se introducen.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; compara las IP de origen y destino con direcciones individuales. Las direcciones de documentación se sustituyen por las direcciones de prueba observadas; de ello no se puede deducir compatibilidad con subredes o listas de direcciones.

• srcport:40000; dstport:8080; compara los puertos de origen y destino con números. Aquí, el puerto de destino corresponde al servicio de prueba. Solo se debe fijar un puerto de origen del cliente variable si realmente forma parte del caso de detección; de lo contrario, las conexiones nuevas no cumplirán esta condición.

• uricontent:"/ips-pilot"; busca la ruta sustituible en la URI normalizada de la solicitud. También son posibles los patrones mixtos de texto y datos binarios. La comparación debe corresponder al valor de la URI normalizada, no simplemente a lo que se escribe en la barra de direcciones del navegador.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; exige además que haya datos en la posición 50 relativa al final de esta coincidencia de contenido. Sin relative, la posición es absoluta dentro de la carga útil. El número se elige según la estructura real del protocolo; comprueba la disponibilidad de datos, no su contenido.

• content:"ABC"; content:"DEF"; distance:1; within:10; utiliza dos patrones sustituibles con una ventana de búsqueda relativa. distance establece la distancia desde el final de la primera coincidencia y within limita la búsqueda siguiente. Para las ventanas absolutas, offset y depth también reciben valores numéricos, por ejemplo, offset:4; depth:20; en el content correspondiente. Estos números se eligen a partir de la posición y la longitud reales del patrón; no son valores predeterminados del protocolo.

Expresiones regulares con pcre

Las formas básicas son pcre:"/REGEX/"; y pcre:"m/REGEX/";. Un ! antes de las comillas de apertura niega la expresión, por ejemplo, pcre:!"/AVANET-IPS-PILOT/i";. Se trata de una condición de ausencia de coincidencia y puede tener un alcance muy amplio sin restricciones adicionales. REGEX o el token de la prueba piloto se sustituyen por el patrón necesario. Las opciones se sitúan después del / de cierre, por ejemplo, pcre:"/AVANET-IPS-PILOT/i";.

• i ignora las diferencias entre mayúsculas y minúsculas; s permite que . también abarque saltos de línea.
• m permite que ^ y $ también actúen al principio y al final de las líneas del búfer. x ignora los caracteres de espacio en blanco no escapados en el patrón, excepto dentro de las clases de caracteres.
• A ancla la coincidencia al principio del búfer. E vincula $ únicamente al final real, no a la posición anterior a un salto de línea final.
• G invierte la voracidad predeterminada de los cuantificadores; un ? posterior vuelve a invertirla.
• R comienza de forma relativa al final de la última coincidencia de patrón. U utiliza búferes de URI decodificadas; B no utiliza búferes decodificados.

Por ello, antes de la prueba piloto se define en qué búfer y a partir de qué posición debe aplicarse el patrón. Una expresión regular correcta para datos sin procesar no tiene por qué coincidir con una URI decodificada.

Leer campos binarios: byte_test y byte_jump

byte_test lee un campo y comprueba su valor numérico. El esquema es byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT es el número de bytes leídos y OFFSET el inicio dentro de la carga útil; con relative, el inicio es relativo a la última coincidencia de patrón. VALUE es el valor de comparación. Están documentados <, >, =, ! y &: menor que, mayor que, igual, distinto y AND bit a bit, respectivamente. Un ! delante de un operador de comparación niega su resultado. big o little establece el orden de los bytes. Con string se leen dígitos de texto en lugar de un campo numérico binario; hex, dec y oct solo se aplican a este modo de texto.

Ejemplo de un campo binario: byte_test:2,=,16,0,big; lee dos bytes desde la posición 0 de la carga útil en formato big endian y los compara con 16. La cantidad, la posición, el orden de los bytes y el valor de comparación deben proceder del protocolo, no de este ejemplo. Un valor numérico fortuito no demuestra un ataque.

byte_jump, en cambio, lee una longitud y desplaza la posición para las comprobaciones siguientes. El esquema es byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. Los dos primeros operandos determinan el ancho del campo y la posición de lectura; relative hace que el desplazamiento sea relativo a la última coincidencia de patrón. multiplier multiplica el valor leído para calcular la distancia del salto. align redondea esta distancia hacia arriba hasta el siguiente límite de 32 bits. Con from_beginning, la distancia del salto se aplica desde el principio de la carga útil en lugar de desde la posición actual. string y las bases numéricas tienen la misma finalidad que en byte_test.

byte_jump:2,0,big; es, por tanto, un fragmento para un campo de longitud de dos bytes al principio de la carga útil, con el orden de bytes elegido explícitamente. No es una comparación de tamaño; el operador de comparación y el valor de comparación no son operandos de byte_jump. Para ambas palabras clave de bytes, se elige explícitamente big o little en los campos binarios de varios bytes: no se debe confiar en un orden de bytes predeterminado deducido de la documentación. Primero se comprueban el campo y el destino del salto en la carga útil real de prueba; después se comprueban un caso positivo y uno negativo para la condición siguiente. Una longitud incorrecta puede desplazar la posición de búsqueda más allá del patrón deseado.

Campos IP, opciones y fragmentos

• ttl:64;, ttl:>64; y ttl:<64; comparan el valor IP Time to Live mediante igualdad, mayor que o menor que. tos:16; compara el campo TOS y id:1234; el campo IP-ID. Estos números de ejemplo no son valores de detección recomendados; se eligen a partir de la característica de cabecera que realmente se busca.
• ipopts:rr; comprueba una opción IP presente. Los valores permitidos son rr (Record Route), eol (End of List), nop (No Operation), ts (Timestamp), sec (Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier) y any (cualquier opción IP). Por tanto, any exige una opción, no simplemente cualquier paquete IP.
• fragoffset:0; compara el desplazamiento de fragmento de la cabecera IP con un número decimal. Este campo no es el desplazamiento de búsqueda de contenido dentro de la carga útil.
• fragbits comprueba M (More Fragments), D (Don’t Fragment) y R (Reserved). Un + antepuesto permite otros bits además de los indicados, * exige al menos uno de los bits indicados y ! exige que los bits indicados no estén activados. Así, fragbits:+M; comprueba que More Fragments esté activado sin excluir otros bits.
• dsize:300;, dsize:>300;, dsize:<300; y dsize:300<>400; describen un tamaño exacto de carga útil, una comparación de mayor o menor que, o un intervalo. Los números se refieren a los datos de la carga útil del paquete, no a toda la conexión. Siguen siendo aplicables las limitaciones explicadas anteriormente respecto a los flujos reconstruidos.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; y ip_proto:<6; comparan el identificador numérico del protocolo en la cabecera IP, no el puerto TCP/UDP. samip; no tiene valor y exige que las IP de origen y destino sean iguales.

Campos TCP y selección del flujo

flags comprueba los indicadores TCP: S para SYN, A para ACK, F para FIN, R para RST, U para URG y P para PSH. Sin modificador, por ejemplo, flags:S; comprueba que esté activado exactamente SYN. Un +, * o ! antepuesto tiene el significado explicado anteriormente para fragbits. Por tanto, flags:+S; permite indicadores adicionales. La ayuda muestra un segundo grupo opcional de indicadores después de una coma, pero no explica su semántica de comparación. Por ello, no tratar flags:S,A; como una instrucción confirmada para ignorar ACK; solicitar una aclaración de este comportamiento para la compilación instalada antes de utilizarlo. Los casos especiales de bits TCP reservados y «ningún indicador activado» no se proporcionan aquí deliberadamente como sintaxis lista para copiar; requieren una regla confirmada para la versión específica y no deben deducirse de una etiqueta ambigua.

Para flow están disponibles las direcciones ya explicadas, así como established, no_stream y only_stream. flow:established; exige una conexión TCP establecida. flow:no_stream; excluye los paquetes de flujo reconstruidos y flow:only_stream; limita la detección a estos. Estos fragmentos explican cada selección por separado y no son una indicación de utilizar ambas opciones de flujo conjuntamente. bi_direction sigue siendo la ampliación al tráfico de ida y vuelta descrita anteriormente.

seq:1234;, ack:1234; y window:4096; comparan el número de secuencia TCP, el número de confirmación y el tamaño de ventana, respectivamente, con un número. Los valores exactos de secuencia o ACK cambian entre conexiones y solo tienen sentido si ese valor concreto forma parte del caso de detección. La ventana TCP no es una ventana de búsqueda en la carga útil.

ICMP y RPC

itype:8; e icode:0; comparan el tipo y el código ICMP. Ambos también admiten <, > e intervalos como itype:3<>5;; el tipo y el código son campos distintos. icmp_id:1234; e icmp_seq:1; comparan de forma exacta el identificador ICMP y el valor de secuencia. Los valores se eligen según el caso ICMP deseado y no se equiparan a los números de secuencia TCP.

rpc:100000,2,*; comprueba en las solicitudes SUNRPC-CALL el número de aplicación 100000, la versión 2 y cualquier procedimiento. El esquema es rpc:APPLICATION,VERSION,PROCEDURE;; * se permite para la versión y el procedimiento, pero no para el número de aplicación. Los números se sustituyen por la aplicación, la versión y el procedimiento buscados. Un comodín no evita tener que analizar el protocolo: deja deliberadamente sin restringir la parte correspondiente y amplía así la detección.

Crear una firma y asignarla a una política

En Intrusion prevention > Custom IPS signatures > Add se definen Name, Protocol, Custom rule, Severity y Recommended action. Un nombre como PILOT-TCP-8080-AVANET-TOKEN permite identificar la finalidad y los límites de la prueba. Severity describe la evaluación propia del riesgo; no demuestra que el patrón sea malicioso.

Para la primera ejecución, Recommended action se mantiene en Allow packet. Importante: la acción de la regla de la política IPS prevalece sobre esta recomendación. Por eso, la regla piloto también debe utilizar Allow packet. Las demás acciones tienen consecuencias considerablemente más importantes:

• Drop packet descarta únicamente el paquete que coincide.
• Drop session finaliza la sesión tras la coincidencia.
• Reset finaliza una sesión TCP y envía un restablecimiento al origen.
• Bypass session permite el tráfico y deja de inspeccionar el resto de la sesión.

Con las acciones basadas en sesión, SFOS solo inspecciona hasta el primer paquete que coincida. Por tanto, antes de cambiar de Allow packet a una de estas acciones, debe confirmarse que esa primera coincidencia corresponde exactamente a la sesión prevista.

Al guardar, SFOS reconfigura el motor IPS. Si hay suficiente RAM libre, esto ocurre sin interrupciones. Si hay poca RAM libre, el motor puede reiniciarse y provocar una interrupción breve. Por tanto, incluso los cambios de una firma aparentemente pequeña deben realizarse dentro de una ventana supervisada. Después de guardar, se comprueban el estado de IPS e ips.log para detectar reinicios o errores antes de continuar con la prueba piloto.

Después de esta comprobación previa, guardar la firma con Save y volver a abrir su entrada: Protocol, Custom rule, Severity y Recommended action deben corresponder a los valores previstos. Mantener Firewall Acceleration y PKI Acceleration sin cambios durante la prueba piloto; cada activación o desactivación reinicia IPS y distorsiona la comparación. La comprobación de zonas, Trusted MAC, los pares IP-MAC y las excepciones de DoS son mecanismos independientes descritos en Protección contra DoS y suplantación, no propiedades de una firma personalizada.

A continuación viene la segunda parte, que a menudo se pasa por alto: en Intrusion prevention > IPS policies, abrir una política que se pueda eliminar y esté destinada a la prueba piloto, añadir una regla, elegir Custom signature, seleccionar la firma y colocar la regla específica por encima de las reglas más amplias. SFOS evalúa las reglas de las políticas IPS de arriba abajo. Guardar la regla de la política con Save y después guardar también la política IPS que la contiene con Save. Volver a abrir la política y comprobar la selección de firma y la acción guardadas. A continuación, esta política se asigna en Rules and policies > Firewall rules > [regla piloto] > Detect and prevent exploits (IPS) a la regla piloto que realmente coincide con el tráfico; guardar también la regla de firewall y comprobarla con una sesión nueva.

Administrar el mismo objeto de firma mediante la API XML

Quien automatice la prueba piloto trabaja con el objeto XML IPSCustomSignature, no con una regla de política IPS. La referencia de SFOS 22/23 denomina las operaciones Add Custom Signature, Update custom signature y Delete Custom Signature. El acceso, la operación de escritura explícita, la copia de seguridad, la evaluación de la respuesta y la detención cuando el contenido de la solicitud no esté aclarado se explican de forma centralizada en Utilizar la API XML de forma segura. Antes de escribir, deben confirmarse la definición del objeto y la operación en API help de la compilación instalada; aquí no se proporciona ninguna solicitud de escritura ejecutable adicional.

En el ejemplo de objeto, Name, Protocol, CustomRule, Severity y RecommendedAction aparecen dentro de IPSCustomSignature. Name identifica la firma, no la política ni la regla de firewall. La tabla de parámetros exige para este campo una cadena escalar de un máximo de 15 caracteres; Delete también exige ese nombre exacto. Por tanto, para la automatización mediante API se debe elegir un nombre corto e inequívoco como IPS-PILOT-8080. El nombre de ejemplo más largo de WebAdmin indicado anteriormente no es una plantilla para copiar en la API. Antes de Update o Delete, consultar la identidad realmente guardada y todos los usos en políticas, en lugar de deducir el destino a partir de un SID o de una entrada con un nombre parecido.

La tabla identifica los cinco datos como obligatorios y escalares para Add/Update. Protocol admite TCP, UDP, ICMP o ALL; Severity admite Critical, Major, Moderate, Minor o Warning. CustomRule contiene la definición de la firma como cadena. La etiqueta de la tabla Custom Rule, con un espacio, no es la forma XML CustomRule. Su indicación adicional de separar las letras con un punto no explica ni una conversión general de reglas ni el escape XML. Por tanto, no modificar mecánicamente con puntos la sintaxis descrita anteriormente, sino comprobar el contenido de la regla y la codificación XML correcta para la compilación. El ejemplo del fabricante solo utiliza SignatureDefinition como marcador de posición; eso no genera una firma lista para usar ni una firma que haya demostrado detectar tráfico malicioso.

No confundir recomendación y acción: El ejemplo XML utiliza RecommendedAction, mientras que la tabla de parámetros denomina ese mismo ámbito Action. Como valores de texto enumera Allow Packet, Drop Packet, Drop Session, Reset y Bypass Session, además de 3. Esto no constituye una autorización confirmada para sustituir RecommendedAction por una etiqueta XML Action. No se explica ningún significado de 3 ni su correspondencia con una acción de texto; no adivinar este valor ni utilizarlo como abreviatura de una acción concreta. Consultar la recomendación realmente guardada y seguir comprobando por separado la acción de la regla de la política IPS. Un objeto creado mediante la API no sustituye ni la asignación de la política ni las pruebas positiva y negativa.

Contrastar las respuestas de la API con la operación y el estado guardado

Las siguientes líneas están documentadas en las referencias de objetos de SFOS 22/23. Los nombres Message.* siguen siendo símbolos de documentación sin resolver: no son mensajes de ejecución garantizados, ni textos de error traducidos, ni causas confirmadas de forma concluyente. Los números también son códigos de estado XML, no códigos de estado HTTP. Conservar conjuntamente la operación, el código y la respuesta real; no sustituir las líneas específicas del objeto por una interpretación general de códigos del artículo central sobre la API.

Para Add Custom Signature, la referencia indica:

• 200 — Message.CustomSigAddSuccess
• 500 — Message.CustomSigAddFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigInvalidSignatureRule
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Para Update custom signature, indica:

• 200 — Message.CustomSigUpdateSuccess
• 500 — Message.CustomSigUpdateFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigCustomSignatureCheck1
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Precisamente 504 distingue Add de Update mediante el símbolo; Message.CustomSigCustomSignatureCheck1 no se reinterpreta como un supuesto mensaje inequívoco de error de sintaxis. Antes de repetir Add/Update, volver a abrir la entrada en WebAdmin o comprobarla mediante una consulta de lectura confirmada para la compilación: ¿coinciden Name, Protocol, Custom rule, Severity y Recommended action con el estado deseado? Ante 502, comparar la identidad existente con la deseada, sin sobrescribir automáticamente ni crear una entrada con un segundo nombre. Ante 504, contrastar además la regla exacta y la documentación de la compilación. Ante 505, comprobar conjuntamente el estado guardado, el estado de IPS e ips.log; el símbolo no implica ni una reversión segura ni permiso para reiniciar el motor. Ante 506, comprobar el estado de IPS y de la licencia según el apartado del ciclo de vida, pero no cambiar el estado de IPS por mera sospecha. Incluso después de 200, siguen siendo necesarias las comprobaciones de los valores guardados, la vinculación de la política y la ruta de datos; 500 no demuestra que no se haya producido ningún cambio parcial.

Para Delete Custom Signature están documentadas estas líneas específicas:

• 200 — Message.CustomSigDeleteSuccess
• 500 — Message.CustomSigDeleteFailed
• 503 — Message.CustomSignatureInUse
• 506 — Message.CustomSignatureIpsOff

Autorizar Delete solo después de la reversión descrita más adelante y de una comprobación completa de los usos. Ante 503, examinar las referencias de las políticas al objeto real, en lugar de eliminar indiscriminadamente una política de producción. Ante 506, aclarar el estado de IPS y de la licencia, en lugar de desactivar IPS globalmente para intentar la eliminación. Después de la respuesta, comprobar que el nombre exacto ya no esté presente y que las políticas dependientes tengan el estado esperado; ante 500 o una respuesta poco clara, no repetir la eliminación a ciegas. Si el estado guardado, la respuesta o la responsabilidad siguen sin estar claros, detener la automatización y aclarar con el soporte de Sophos la respuesta depurada, la versión de la regla, la compilación y los registros. Aquí no se afirma que ningún comportamiento en tiempo de ejecución se haya probado en un firewall.

Realizar las pruebas positiva y negativa

La prueba positiva envía el patrón acordado por el puerto previsto y en la dirección esperada. En Log Viewer, situado en la parte superior derecha de WebAdmin, se selecciona el módulo IPS y se filtra por la hora de la prueba, Source y Destination. La firma o el SID, la acción y la hora deben corresponder a la prueba. ips.log proporciona detalles adicionales del motor. Packet Capture, en Diagnostics > Packet capture, muestra además Firewall Rule ID e IPS Policy ID. La relación entre la regla, Packet Capture y el módulo de seguridad se explica en Probar sistemáticamente una regla de firewall.

Después de la fase piloto, también se puede evaluar el efecto en Reports > Network & threats > Intrusion attacks. El informe es útil para comparar periodos, pero no sustituye las pruebas positiva y negativa realizadas oportunamente en Log Viewer. XGS 87/87w y XGS 88/88w no admiten informes locales en el dispositivo; en estos modelos, realizar las comprobaciones inmediatas descritas en Log Viewer.

Después se realiza al menos una prueba negativa: el mismo servicio sin token, otro puerto o una dirección distinta. La firma no debe generar una coincidencia. En el caso de un patrón de contenido, también son importantes las solicitudes normales de la aplicación, ya que las cadenas cortas o genéricas pueden aparecer en cargas útiles completamente legítimas.

Solo cuando ambas pruebas sean estables se establece la acción de bloqueo prevista y se vuelve a comprobar. Una firma de bloqueo solo se considera validada si se detiene exactamente el caso positivo, el caso negativo sigue funcionando y ninguna otra regla de firewall o IPS causa el efecto.

Comprobar el número de firmas

El número se puede obtener en WebAdmin sin utilizar la shell. En Intrusion prevention > IPS policies, se abre una política que se pueda eliminar y se crea una regla de política nueva. Con Select all, SFOS muestra el número total encima de Action. La lista solo es visible al añadir una regla a una política que se pueda eliminar; después se puede cerrar el cuadro de diálogo sin guardar.

Sophos documenta además dos consultas de lectura en 5. Device management > 3. Advanced shell:

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

El primer comando cuenta las firmas estándar y el segundo las firmas personalizadas. Estas consultas de base de datos no modifican nada, pero deben realizarse dentro de una sesión de soporte o diagnóstico documentada. El número no demuestra la calidad ni el funcionamiento y puede cambiar con las actualizaciones de patrones.

Para cada consulta se espera una única fila de resultado bajo count, seguida de (1 row). Los valores de ejemplo de Sophos 28623 y 1 proceden de un ejemplo de SFOS 19.0.1 y no son valores esperados para SFOS 22/23. Ante errores de base de datos, conexión o permisos, no modificar tablas ni servicios: utilizar la comprobación de WebAdmin y conservar la salida exacta y la compilación para el soporte.

Si la firma no funciona como se espera

No hay ninguna coincidencia

Primero se comprueba si IPS está activo, si el tráfico coincide con la regla de firewall esperada que tiene la política IPS correcta y si la firma personalizada está realmente incluida en una regla de política que se evalúa. Después se revisan el protocolo, la dirección, el puerto, el cifrado y la carga útil real. Una cadena mostrada en el navegador no tiene por qué aparecer sin cambios en el paquete de red.

Resulta útil una captura de paquetes con filtros muy específicos que muestre la dirección, el puerto y el contenido visible en ese punto de captura. Sin embargo, la ausencia de un patrón en texto plano en una captura cifrada no demuestra que falte en el búfer IPS descifrado. Por ello, comprobar conjuntamente el punto de captura, el descifrado y la reconstrucción del flujo. En una prueba controlada en texto plano, debe poder verificarse el patrón realmente transmitido; después se comprueban offset, depth, distance, within, el estado del flujo y el orden de las reglas de la política.

Demasiadas conexiones generan coincidencias

La firma se mantiene en Allow packet hasta que se restrinjan más Source, Destination, el puerto, la dirección o la ventana de búsqueda. Las palabras genéricas, las secuencias binarias cortas y las expresiones regulares sin límites son causas habituales. Una regla de firewall de amplio alcance hace que el efecto sea aún más difícil de controlar.

Si el firewall muestra un aumento del uso de recursos o un reinicio de IPS después de guardar, se conservan la hora, el modelo, el firmware, los recursos libres e ips.log. Guardar repetidamente distintas variantes no constituye entonces una prueba rigurosa; primero se aclaran la causa y la ventana de mantenimiento.

Revertir de forma segura

Si aparecen coincidencias inesperadas, primero se elimina la regla personalizada de la política piloto o se restaura la política IPS anterior en la regla de firewall. Después se comprueban sesiones nuevas mediante una prueba positiva y una negativa. La firma personalizada solo se elimina cuando no existe ningún otro uso.

Antes de eliminarla, debe quedar documentado qué política, regla de firewall y aplicación la han utilizado. Los registros, la versión de la regla probada y el motivo de la reversión deben incluirse en la documentación del cambio. Desactivar IPS globalmente o eliminar toda la política de producción no es una reversión adecuada para una única firma defectuosa.

Preguntas frecuentes