Gestionar de forma segura los System Modules de Sophos Firewall

Sophos Firewall utiliza los System Modules como helpers de protocolo cuando el firewall necesita seguir información adicional o considerar conexiones dinámicas. SFOS 22 enumera dns, h323, irc, pptp, sip y tftp. Los módulos están cargados de forma predeterminada.

Un módulo cargado no es una regla de firewall ni una recomendación para utilizar el protocolo. No sustituye una regla NAT, una ruta o una política de seguridad. Descargar todos los helpers aparentemente innecesarios tampoco es una medida de hardening adecuada. El ajuste es global y puede afectar de forma inesperada a aplicaciones existentes.

⚠️ Regla operativa: Primero se documentan el estado y el flujo concreto con errores. Después se cambia como máximo un módulo, se repite el mismo flujo y se restaura el estado original si no hay mejora.

Clasificar correctamente los seis módulos

En sip y h323, el helper se señala con frecuencia demasiado pronto como causa o solución. El proceso completo con NAT, RTP, timeouts, puerto SIP personalizado, Packet Capture y llamadas de prueba está en Resolver problemas VoIP con SIP y RTP.

Guardar el estado inicial en Device Console

Los comandos se ejecutan en 4. Device Console, no en Advanced Shell. Se accede mediante SSH o desde admin > Console, en la esquina superior derecha de WebAdmin. Para SSH, debe permitirse SSH en la zona necesaria en Administration > Device access > Local service ACL; la consola web requiere HTTPS en esa misma sección. No se debe abrir el acceso más allá del origen de administración necesario.

Antes de cambiar algo se lee el estado global:

system system_modules show

Se guarda la salida completa, aunque solo se investigue un módulo. Así sigue siendo posible detectar si un sistema migrado o modificado anteriormente difiere de la configuración predeterminada. El estado loaded solo demuestra el estado del módulo, no que el helper procese un flujo concreto ni que cause sus errores. Tampoco demuestra que IRC, SIP o TFTP estén configurados sin puertos personalizados ni otros argumentos personalizados. Antes de cualquier cambio, se determina y documenta expresamente si el módulo afectado tiene una configuración predeterminada confirmada, sin puertos personalizados ni otros argumentos personalizados.

En el caso de IRC, SIP o TFTP con argumentos personalizados, antes de la prueba se guardan la baseline completa realmente configurada y un procedimiento admitido para restaurarla exactamente, confirmado para el build instalado. Para SIP, esto incluye el puerto de señalización personalizado exacto recogido en la documentación de configuración existente y fiable; para IRC y TFTP, incluye todos los valores de puertos y demás argumentos realmente configurados. La ayuda de sintaxis por sí sola no demuestra la configuración actual. Si la baseline no está clara, faltan valores o no se ha confirmado el procedimiento de vuelta atrás que conserva el estado, el helper correspondiente se deja sin cambios. No se adivinan ni los valores predeterminados ni los comandos de restauración.

También se documentan IP de origen y destino, puerto, protocolo, Rule ID, NAT ID, hora y prueba exacta de la aplicación. Sin un flujo reproducible no puede evaluarse un cambio global. Log Viewer, Policy Test y Packet Capture permiten la validación técnica.

Cargar o descargar exactamente un módulo

Los comandos básicos siguen el mismo patrón. La tabla es una referencia, no un bloque de comandos para ejecutar por completo. El cambio simple mediante estos comandos y la vuelta atrás mediante el comando inverso solo están previstos para una baseline predeterminada confirmada previamente, sin puertos personalizados ni otros argumentos personalizados. Para IRC, SIP o TFTP con una configuración personalizada, se utiliza exclusivamente el procedimiento de cambio y restauración guardado antes de la prueba y confirmado para el build instalado; sin ese procedimiento, no se inicia ninguna prueba.

Antes de ejecutar, se comprueba la sintaxis en el build instalado mediante la ayuda integrada: se escribe el comando previsto y se utiliza ? para mostrar los argumentos admitidos. No deben enviarse variantes incompletas a modo de prueba; Sophos advierte que un comando incompleto de Device Console puede bloquear el daemon access_server. Tras un único cambio se vuelve a ejecutar system system_modules show y se repite el flujo de aplicación documentado. Deben evitarse cambios paralelos en NAT, reglas, routing, timeouts o PBX porque impiden atribuir el resultado.

Sophos documenta expresamente que load y unload para SIP persisten tras un reinicio. La página de SFOS 22 no ofrece la misma precisión para los demás módulos. Su estado debe leerse de nuevo después de un reinicio planificado en lugar de asumir la persistencia.

No deducir puertos personalizados de una sintaxis abreviada incompleta

La página enumera para IRC, SIP y TFTP términos adicionales como port, portname, default o show, pero no explica por completo su forma exacta. Esos valores no deben adivinarse. Device Console muestra la sintaxis del build instalado con ?.

Para SIP, Sophos publica por separado el comando exacto system system_modules sip load ports <custom_port>. Esta decisión pertenece al análisis VoIP, no a una prueba general de helpers. El placeholder se sustituye por el puerto de señalización utilizado realmente por el proveedor o la PBX.

Conocer los límites de SIP antes de probar

De forma predeterminada, el helper SIP utiliza el puerto UDP 5060. Traduce las direcciones IP locales de la cabecera SIP a direcciones públicas y crea en el firewall una conexión de voz dinámica esperada. Por tanto, su efecto va más allá de reconocer la señalización.

Dos límites son esenciales para el diagnóstico:

• El helper solo admite puertos multimedia SIP en el intervalo 1024–65535. Si un puerto multimedia configurado queda fuera, el firewall descarta los paquetes y el Event Log muestra Invalid Traffic.
• El helper no admite mensajes SIP o SDP que ocupen más de un paquete. Esto puede ocurrir con SIP sobre TCP. Sophos indica como solución alternativa una conexión de control SIP mediante UDP; solo debe usarse si el proveedor, la PBX o el SBC la admiten.

Un puerto de señalización personalizado y el rango multimedia RTP son valores diferentes. <custom_port> en el comando de carga es el puerto de señalización SIP realmente utilizado; no se debe deducir de él un rango RTP.

Verificar el efecto y la vuelta atrás

Una prueba útil comprueba más que la salida de CLI. Después de cargar o descargar se verifican la conexión, el tráfico en ambas direcciones, Rule y NAT ID, drops y la aplicación afectada. Para SIP o H.323 se incluyen registro, conexiones entrantes y salientes y medios bidireccionales. Para DNS se comprueban consulta y respuesta con el nombre esperado. Para TFTP se verifica también la transferencia del archivo.

Si el síntoma no cambia o aparecen errores nuevos, solo el módulo modificado vuelve al estado registrado:

• Si estaba cargado y se ha confirmado la baseline predeterminada sin puertos personalizados ni otros argumentos personalizados, se vuelve a cargar con el comando ... load correspondiente.
• Si estaba descargado y se ha confirmado la baseline predeterminada sin puertos personalizados ni otros argumentos personalizados, se vuelve a descargar con el comando ... unload correspondiente. Tampoco en este caso basta el estado por sí solo para demostrar la ausencia de argumentos personalizados.
• Si SIP estaba cargado en un puerto de señalización personalizado, se restaura exactamente ese valor guardado con system system_modules sip load ports <previous_custom_port>. <previous_custom_port> se sustituye por el valor de la baseline, no por un nuevo valor de ejemplo. Este procedimiento de vuelta atrás también debe haberse confirmado para el build instalado antes de la prueba y debe restaurar toda la configuración guardada.
• Para IRC o TFTP con puertos personalizados u otros argumentos personalizados, la baseline completa guardada se restaura exclusivamente mediante el procedimiento de restauración admitido y confirmado previamente para el build instalado, no mediante un simple comando inverso de carga o descarga. Si no se dispone de ese procedimiento, el helper se deja sin cambios desde el principio.

Después se vuelven a ejecutar system system_modules show y el mismo flujo de prueba. La salida de CLI debe volver a coincidir con el estado inicial guardado, y la prueba no debe haber causado alteraciones adicionales en la ruta original de la aplicación. Para IRC, SIP o TFTP con una configuración personalizada, también se compara la baseline completa configurada, incluidos todos los valores de argumentos guardados, mediante el procedimiento de comprobación confirmado previamente; un estado del módulo coincidente no demuestra por sí solo que se haya restaurado esa configuración. Un reinicio no sustituye este rollback.

Si el comportamiento cambia pero la causa sigue sin estar clara, se conservan los estados anterior y posterior, el build de firmware, los logs y el Packet Capture. Un helper descargado globalmente no debe quedar como solución permanente solo porque una prueba breve parezca mejor.

En SIP, el síntoma orienta la siguiente comprobación: Invalid Traffic sin medios lleva primero al puerto multimedia configurado y al intervalo 1024–65535. Si falla el registro TCP o se interrumpen mensajes SIP/SDP largos, se comprueba el límite de un solo paquete. Si el estado mostrado del módulo es correcto pero el comportamiento no cambia, se confirman primero el puerto de señalización realmente utilizado y la ruta Rule/NAT afectada.

FAQ