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
| Módulo | Función según SFOS 22 | Límite importante |
|---|---|---|
dns | Aprende subdominios del tráfico DNS no local. | No sustituye un resolver, una política DNS ni las pruebas de resolución. |
h323 | Admite comunicaciones de audio, vídeo y datos basadas en H.323. | Un cambio puede afectar a todas las conexiones H.323, no solo a una PBX o regla. |
irc | Admite tráfico IRC en el modelo cliente-servidor. | Sophos advierte de riesgos de DoS y rendimiento en redes IRC abiertas. |
pptp | Admite la ruta de datos de conexiones PPTP. | Cargar el helper no crea un túnel VPN ni determina si PPTP encaja en el modelo de seguridad actual. |
sip | Reconoce la señalización SIP y puede admitir conexiones multimedia dinámicas. | SIP ALG puede ayudar o interferir según la PBX, el SBC, NAT, TLS y el proveedor. |
tftp | Admite TFTP sobre UDP. | TFTP no tiene funciones de seguridad; el helper no aporta confidencialidad ni autenticación. |
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. Antes de cambiar algo se lee el estado global:
system system_modules show
Debe conservarse toda la salida aunque solo se investigue un módulo. Así se detecta si un sistema migrado o modificado difiere del valor predeterminado. loaded solo demuestra el estado del módulo, no que el helper procese un flujo concreto o cause el error.
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 para ejecutar por completo.
| Módulo | Descargar | Cargar |
|---|---|---|
| DNS | system system_modules dns unload | system system_modules dns load |
| H.323 | system system_modules h323 unload | system system_modules h323 load |
| IRC | system system_modules irc unload | system system_modules irc load |
| PPTP | system system_modules pptp unload | system system_modules pptp load |
| SIP | system system_modules sip unload | system system_modules sip load |
| TFTP | system system_modules tftp unload | system system_modules tftp load |
Antes de ejecutar se verifica la sintaxis del build instalado con ?. 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.
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. Después se repiten system system_modules show y el mismo flujo. 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.
FAQ
¿Deben descargarse por defecto los System Modules no utilizados?
¿Es el módulo SIP lo mismo que SIP ALG?
¿Un módulo PPTP o TFTP cargado crea acceso?
loaded solo describe el estado global del helper.¿Cómo se revierte una prueba de System Modules?
system system_modules show. Después se restaura solo el módulo probado a su valor anterior con load o unload y se repite el mismo flujo de aplicación.