Inspeccionar puertos no estándar con Sophos Firewall

Sophos Firewall inspecciona HTTP, HTTPS, FTP, SMTP/S, POP e IMAP en sus puertos estándar. Si una aplicación utiliza uno de estos protocolos en otro puerto, service-param puede asignar adicionalmente ese puerto al servicio de inspección clásico.

El comando no abre puertos de forma general. No crea un objeto de servicio ni una regla de firewall y tampoco activa una policy web, TLS o de correo. Para que el tráfico sea inspeccionado deben coincidir la regla, el puerto de destino permitido y la ruta de inspección responsable. En las reglas web nuevas se debe aclarar primero si el flujo lo procesa DPI Engine o Web Proxy.

⚠️ service-param es una asignación global. Un puerto adicional no afecta solo a un host o una regla de firewall. Antes del cambio se documentan los usos existentes del puerto, las policies afectadas y un rollback ejecutable.

Cuándo es apropiado service-param

El comando es apropiado cuando una aplicación conocida utiliza realmente HTTP, HTTPS, FTP, SMTP, SMTPS, POP o IMAP en un puerto TCP no estándar y el servicio clásico correspondiente debe inspeccionar ese tráfico. Ejemplos típicos son un portal HTTPS interno en el puerto 8443 o una configuración explícita de correo en un puerto adicional.

Un puerto TCP abierto no demuestra que se utilice el protocolo esperado. Si en 8443 circula tráfico binario propietario, asignarlo a HTTPS puede interrumpir conexiones en vez de aportar protección. Para el tráfico web también se comprueba si DPI Engine ya reconoce el protocolo o si realmente hay que añadir un puerto de servicio al proxy. Para correo se distingue SMTP con STARTTLS de SMTPS con TLS desde el inicio de la conexión. Mail Protection en modo MTA explica la ruta de correo.

service-param no es apropiado si una regla de firewall solo debe permitir otro puerto de destino. En Hosts and services > Services se crea un objeto de servicio TCP adecuado y se utiliza en la regla. La asignación de inspección solo se añade cuando el proxy o servicio de correo responsable también debe procesar el puerto no estándar.

Registrar el estado inicial en Device Console

El comando se ejecuta desde 4. Device Console. Antes de cualquier cambio, el siguiente comando muestra los puertos de servicio existentes y otros valores globales:

show service-param

Se registra la salida completa junto con el build de SFOS, la hora y la referencia del cambio. Es especialmente importante comprobar si el puerto previsto ya está asignado a otro servicio. El mismo puerto no se asigna por sospecha simultáneamente a HTTP, HTTPS, SMTP y SMTPS.

Sophos documenta estos nombres de servicio para SFOS 22:

FTP
HTTP
HTTPS
IMAP
POP
SMTP
SMTPS
IM_MSN
IM_YAHOO

IM_MSN e IM_YAHOO son etiquetas heredadas de la CLI. No son el punto de partida para un nuevo diseño de mensajería instantánea. Las aplicaciones nuevas se protegen mediante reglas de firewall, Application Control, TLS Inspection y la detección de protocolos realmente compatible.

Añadir un puerto adicional

La sintaxis básica documentada para los servicios compatibles es:

set service-param <service> add port <portID>
set service-param <service> delete port <portID>

Para un portal HTTPS confirmado en TCP 8443, un piloto controlado tiene este aspecto:

show service-param
set service-param HTTPS add port 8443
show service-param

La regla de firewall necesita además un servicio que permita TCP 8443 como puerto de destino. Para HTTPS se determina qué ruta de inspección descifra, qué certificado se espera y si la aplicación utiliza Certificate Pinning. Una página web visible no demuestra ni el descifrado ni el escaneo de malware.

El marcador portID de la sintaxis de Sophos se utiliza en Device Console con el valor concreto del puerto. El puerto solo se añade después de que un Packet Capture o la documentación de la aplicación confirmen el protocolo y el puerto de destino.

No mezclar opciones globales con la prueba del puerto

Para HTTPS, Sophos enumera además deny_unknown_proto on|off e invalid-certificate allow|block. SMTPS también dispone de invalid-certificate allow|block. SMTP ofrece otras opciones globales para Failure Notifications, Fast ISP Mode, Notification Port y Strict Protocol Check.

Estos valores resuelven otro problema distinto de add port y no se modifican en el mismo piloto. En particular, invalid-certificate allow puede tolerar globalmente errores de certificado, mientras que deny_unknown_proto y strict-protocol-check cambian el tratamiento de conexiones que no cumplen el protocolo esperado. Una conexión correcta después de varios cambios simultáneos sería difícil de atribuir y podría reducir la protección sin que se advierta.

La sintaxis oficial también incluye:

set service-param HTTPS deny_unknown_proto <on|off>
set service-param HTTPS invalid-certificate <allow|block>
set service-param SMTPS invalid-certificate <allow|block>
set service-param SMTP failure_notification <on|off>
set service-param SMTP fast-isp-mode <on|off>
set service-param SMTP notification-port add port <portID>
set service-param SMTP strict-protocol-check <on|off>

Antes de uno de estos cambios globales se evalúan por separado la salida actual exacta, los remitentes o aplicaciones web afectados, el efecto de seguridad y las instrucciones del soporte. Por eso, el artículo no presenta estos comandos como valores predeterminados recomendados.

Validar el efecto con un flujo real

La prueba comienza con una sola fuente piloto y una regla de firewall con logging. Antes y después del cambio se utilizan el mismo destino, el mismo puerto y una conexión nueva. En Log Viewer, Firewall Rule ID, la acción web o de correo y la hora deben coincidir con el piloto.

Para HTTPS también se comprueban el emisor del certificado, el handshake TLS y la acción Block o Allow esperada. Si el diseño incluye escaneo de malware, se realiza un test EICAR controlado exactamente a través de ese puerto. EICAR solo confirma la ruta antivirus normal, no todas las funciones TLS, de policy o ML. Para SMTP, SMTPS, POP e IMAP se utiliza un mensaje de prueba inequívoco y se sigue en Mail Logs, Quarantine y, si procede, Mail Spool.

Un Packet Capture confirma que el cliente utiliza realmente el puerto de destino previsto. Si solo el Firewall Log muestra Allow, todavía no hay prueba de que el proxy o servicio de correo posterior haya inspeccionado el contenido. Probar de forma controlada las reglas de Sophos Firewall combina la coincidencia de reglas, Log Viewer y Packet Capture.

Revertir la asignación del puerto

El rollback elimina únicamente del servicio correcto el puerto añadido durante el cambio:

set service-param HTTPS delete port 8443
show service-param

Después se crea de nuevo el mismo flujo de prueba. La conectividad debe volver al estado inicial documentado. Las autorizaciones temporales del servicio de firewall, reglas piloto y excepciones se eliminan por separado; delete port no elimina esos objetos.

Si ya falla la adición, se registran el error y show service-param. A menudo el puerto ya se trata como puerto estándar o está asignado a otro servicio. La entrada existente no se elimina a ciegas porque otra ruta de inspección puede depender de ella.

Lista de comprobación operativa

• La aplicación, el protocolo y el puerto de destino real están confirmados.
• show service-param y el build de SFOS están registrados antes del cambio.
• El servicio de firewall, la coincidencia de reglas y la asignación de inspección se tratan por separado.
• El puerto no está asignado ya a un servicio incompatible.
• En el piloto solo cambia add port, no una opción global de certificado o protocolo.
• Están preparados el test positivo, el test negativo, el log de inspección y el Packet Capture.
• Están disponibles el comando delete port correspondiente y la ruta de retorno sin cambios.

FAQ