Crear y probar firmas IPS personalizadas en Sophos Firewall

Una firma IPS personalizada resulta útil cuando Sophos no ofrece una firma adecuada para un patrón de red o de aplicación claramente definido. Puede detectar una cadena de texto sin cifrar conocida, una característica inusual de un protocolo o una combinación precisa de puerto, dirección y payload.

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

Una firma nueva se prueba primero con Allow packet y logging en una ruta piloto pequeña. Drop packet, Drop session, Reset y Bypass session modifican el tráfico productivo y solo deben utilizarse después de una prueba positiva y otra negativa reproducibles.

Un piloto controlado en seis pasos

1. Describir el caso de detección con protocolo, dirección, puerto y un patrón inequívoco.
2. En Intrusion prevention > Custom IPS signatures, crear una firma limitada con Allow packet.
3. Añadir la firma a una regla propia de una IPS policy que se pueda eliminar.
4. Asignar esa IPS policy solo a la regla de firewall piloto prevista y activar el logging.
5. Generar una prueba coincidente y otra deliberadamente no coincidente; comparar Log Viewer, ips.log y la coincidencia de la regla.
6. Establecer la acción deseada únicamente tras una validación estable; retirar la asignación de policy o la firma si aparecen coincidencias inesperadas.

Una entrada guardada o una comprobación de sintaxis correcta aún no demuestran el funcionamiento. El éxito significa que la prueba positiva coincide exactamente con la firma personalizada y la regla de firewall esperadas, la prueba negativa no coincide y la aplicación productiva se comporta como antes.

Cuándo conviene una firma propia

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

Para direcciones IP o dominios cambiantes suelen ser más apropiados los hosts, servicios y grupos, los threat feeds o unas reglas de firewall limitadas. Una firma propia tampoco sustituye la gestión de parches ni una regla mantenida por el fabricante. Desarrollar una firma permanente para un único evento de log rara vez es proporcional.

El payload cifrado es un límite importante. IPS solo puede detectar un patrón content en un payload HTTPS si el contenido se descifra realmente y es visible para el motor en la ruta de procesamiento elegida. Sin una TLS Inspection adecuada, normalmente solo están disponibles características sin cifrar o visibles de otro modo.

Comprobar primero la licencia y el ciclo de vida

Las firmas propias no se pueden configurar si ha caducado la 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 Custom Signatures existentes. Por tanto, un backup o una exportación forma parte del plan de rollback antes de modificar la licencia, IPS o policies importantes.

Después, IPS debe estar activo globalmente y la regla de firewall que procesa el tráfico necesita una IPS policy. La configuración básica completa se explica en Configurar y probar IPS de Sophos Firewall de forma segura. Una firma personalizada amplía esta ruta de datos; no es un mecanismo de protección paralelo.

Limitar de forma consciente la sintaxis de la regla

El formulario separa Protocol y Custom rule. La regla combina palabras clave individuales, sus valores y puntos y coma. Exigir que coincidan varias características independientes suele reducir las coincidencias accidentales. A la vez, la firma no debe ser tan específica que un cambio inocuo del protocolo la deje sin efecto.

Para una prueba de texto sin cifrar exclusivamente controlada, se puede seleccionar TCP como protocolo y utilizar un patrón de payload limitado como este:

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

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

Payload y ventana de búsqueda

content busca una secuencia de caracteres o bytes; los valores binarios se escriben entre barras verticales. nocase ignora mayúsculas y minúsculas en una coincidencia de content, mientras que rawbytes trabaja con los datos sin procesar. depth y offset limitan la búsqueda de forma absoluta en el payload; distance y within lo hacen de forma relativa a la coincidencia anterior. uricontent, isdataat y pcre cubren casos más específicos de URI, posición y expresiones regulares.

Una ventana de búsqueda limitada reduce las coincidencias accidentales y la carga de procesamiento. En particular, pcre, las ventanas grandes y varios patrones content amplios solo deben introducirse con paquetes realistas y bajo una carga observada. Si depth es menor que el patrón content buscado, la firma nunca puede coincidir.

Cabeceras, streams y valores estructurados

La fuente, el destino y el puerto se pueden limitar con srcaddr, dstaddr, srcport y dstport. Para la cabecera 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.

La referencia completa de la sintaxis IPS personalizada de SFOS 22 sigue siendo vinculante para reglas complejas. No se deben adoptar sin comprobar palabras clave de Snort no documentadas ni reglas copiadas de otros motores.

Crear la firma y asignarla a una policy

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 hace visibles la finalidad y el límite de la prueba. Severity representa la evaluación propia del riesgo; no demuestra que el patrón sea malicioso.

Para la primera ejecución, Recommended action permanece en Allow packet. Las demás acciones tienen consecuencias mucho mayores:

• Drop packet descarta solo el paquete coincidente.
• Drop session termina la sesión después de la coincidencia.
• Reset termina una sesión TCP y envía un reset al origen.
• Bypass session permite el tráfico y deja de analizar el resto de la sesión.

Al guardar, SFOS reconfigura el motor IPS. Según Sophos, esto ocurre sin interrupciones cuando hay suficiente RAM libre. Con poca RAM libre, el motor puede reiniciarse y provocar una breve interrupción. Incluso una modificación aparentemente pequeña debe realizarse en una ventana observada.

Después viene la segunda parte, que se omite a menudo: en Intrusion prevention > IPS policies, abrir una policy eliminable destinada al piloto, añadir una regla, seleccionar la Custom Signature y colocar la regla específica por encima de las reglas más amplias. A continuación, asignar esa policy en Rules and policies > Firewall rules a la regla piloto que realmente coincide.

Realizar una prueba positiva y otra negativa

La prueba positiva envía el patrón acordado por el puerto previsto y en la dirección esperada. Al mismo tiempo se registran en Log Viewer Firewall Rule ID, IPS policy, nombre de la firma, fuente, destino, acción y hora. ips.log aporta detalles adicionales del motor; Probar sistemáticamente una regla de firewall explica la relación entre regla, Packet Capture y módulo de seguridad.

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

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

Comprobar el número de firmas

El número se puede consultar en WebAdmin sin utilizar la shell. En Intrusion prevention > IPS policies, se abre una policy eliminable y se añade una nueva regla de policy. Con Select all, SFOS muestra el total encima de Action. La lista solo aparece al añadir una regla a una policy eliminable; después se puede cerrar el diálogo sin guardar.

Sophos también documenta dos consultas de solo lectura en 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 predeterminadas y el segundo las firmas personalizadas. Estas consultas de base de datos no modifican datos, pero deben formar parte de una sesión de soporte o diagnóstico documentada. El número no demuestra calidad ni funcionamiento y puede cambiar con las actualizaciones de patterns.

Cuando la firma no funciona como se esperaba

No hay ninguna coincidencia

Primero se comprueba que IPS esté activo, que el tráfico coincida con la regla de firewall esperada con la IPS policy correcta y que la Custom Signature figure realmente en una regla de policy evaluada. A continuación se revisan protocolo, dirección, puerto, cifrado y payload real. Una cadena que aparece en el navegador no tiene por qué estar sin cambios en el paquete de red.

Un Packet Capture con un filtro limitado ayuda a confirmar el contenido visible y la dirección. Si el patrón no está allí, modificar la regla IPS no puede crearlo. Si los paquetes son visibles, se revisan offset, depth, distance, within, el estado del stream y el orden de las reglas de policy.

Coinciden demasiadas conexiones

La firma se mantiene en Allow packet hasta limitar mejor la fuente, el destino, 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 amplia dificulta aún más controlar el efecto.

Si la firewall muestra un aumento de recursos o un reinicio de IPS después de guardar, se conservan la hora, el modelo, el firmware, los recursos libres y ips.log. Guardar repetidamente variantes distintas deja de ser una prueba limpia; primero hay que aclarar la causa y una ventana de mantenimiento.

Revertir de forma segura

Si hay coincidencias inesperadas, primero se elimina la regla personalizada de la policy piloto o se restablece la IPS policy anterior en la regla de firewall. Después se comprueban sesiones nuevas con las pruebas positiva y negativa. La Custom Signature se elimina únicamente cuando no tiene ningún otro uso.

Antes de eliminarla se documenta qué policy, regla de firewall y aplicación la utilizaban. Los logs, la versión de la regla probada y el motivo del rollback forman parte del registro del cambio. Desactivar IPS globalmente o retirar toda la policy productiva no es un rollback adecuado para una sola firma defectuosa.

FAQ