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 ampliar la inspección del protocolo a ese puerto.

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.

Elegir primero la ruta de inspección

Un puerto de destino adicional y la inspección de ese flujo son dos decisiones distintas. En Hosts and services > Services, un objeto de servicio TCP define qué puerto de destino coincide con una regla de firewall. Al crearlo en Hosts and services > Services > Add, normalmente se deja Source port en 1:65535, ya que las aplicaciones eligen dinámicamente su puerto de origen. El objeto por sí solo no activa la inspección de contenido.

Para tráfico web, service-param no suele ser el primer paso en SFOS 22:

• DPI Engine detecta HTTP y SSL/TLS en todos los puertos. Por tanto, un portal HTTPS en TCP 8443 necesita un servicio coincidente en la regla de firewall, la web policy prevista y los ajustes de escaneo adecuados. Si hay que descifrar, también debe coincidir una regla en Rules and policies > SSL/TLS inspection rules. Estas reglas detectan TLS en cualquier puerto TCP y evalúan conjuntamente origen, destino, usuario, servicio y criterios de sitios web.
• Con Use web proxy instead of DPI engine, Transparent Web Proxy solo procesa HTTP en el puerto 80 y HTTPS en el 443. El tráfico HTTP y TLS en otros puertos permanece en DPI Engine. Por tanto, service-param no sirve para ampliar el proxy transparente a otros puertos de forma general.
• Con Direct Web Proxy, el cliente se conecta al listener configurado en Web > General settings > Web proxy configuration. Esta ruta de proxy explícito funciona independientemente de que se seleccione Use web proxy instead of DPI engine en una regla de firewall.

IPS también es una ruta independiente. Intrusion prevention > IPS policies debe estar activado globalmente, debe haber una suscripción Network Protection activa o una licencia de prueba y la policy IPS prevista debe estar configurada en la regla de firewall coincidente. service-param no activa IPS ni demuestra que una firma haya reconocido el flujo. Para comprobarlo, se correlacionan Firewall Rule ID y el evento IPS en Log Viewer.

Así, service-param es principalmente candidato cuando el servicio específico de protocolo documentado por Sophos debe procesar un puerto adicional, por ejemplo FTP o un protocolo de correo. Para una inspección web o TLS mediante DPI, se configura correctamente la ruta de reglas.

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, la revisión de la ruta de inspección no ha llevado ya a la solución DPI y el servicio específico del protocolo debe procesar ese tráfico. Ejemplos típicos son FTP en TCP 2121 o una configuración SMTP acordada en TCP 2525.

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. Si se utiliza Mail Protection en modo MTA, el tráfico sigue una ruta diferente a través del MTA.

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 una conexión SMTP confirmada en TCP 2525, un piloto controlado tiene este aspecto:

show service-param
set service-param SMTP add port 2525
show service-param

Este ejemplo se aplica a la inspección del proxy de correo transparente en Legacy mode. La regla de firewall necesita además un servicio que permita TCP 2525 como puerto de destino; se debe seleccionar SMTP en Scan email content y configurar una policy de correo adecuada. Antes del cambio se confirma que el puerto transporta SMTP y si utiliza STARTTLS. Una conexión TCP o una entrega de correo correcta no demuestra por sí sola la inspección del contenido. En MTA mode no se debe modificar para este piloto la regla de firewall MTA creada automáticamente.

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 SMTP delete port 2525
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 falla la adición, se registran el error y show service-param. Con estos datos se determina si el puerto ya se trata como puerto estándar o está asignado a otro servicio. Una 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