Comprobar servicios y puertos salientes de Sophos Firewall

Sophos Firewall establece conexiones propias con Sophos y algunos servicios externos de plataforma. Las utiliza para descargar firmware y patterns, sincronizar licencias, conectar dispositivos RED, enviar informes a Sophos Fusion (antes Sophos Central) o abrir Support Access. Si delante del firewall hay otro router, proxy o filtro de egreso, pueden fallar funciones concretas aunque el tráfico normal de los clientes siga funcionando.

La distinción principal es que se trata de tráfico de sistema generado por el propio firewall. Una regla amplia LAN-to-WAN adicional en Sophos Firewall no corrige un filtro previo. Se necesita una regla saliente específica en el sistema upstream que realmente bloquea la conexión.

⚠️ Base de trabajo controlada por Avanet: El siguiente resumen es el snapshot interno del 4 de septiembre de 2026 para SFOS 22. Es la base para la planificación y aceptación; los nombres de destino pueden cambiar después. Las IP fijas obtenidas con una única consulta DNS no sustituyen a los FQDN y wildcards. El responsable del firewall sigue el proceso de reconciliación descrito abajo antes de modificar el snapshot.

Comprobación rápida cuando falla un servicio de Sophos

1. Registrar la función afectada, la hora del error y la build actual de SFOS.
2. Comprobar si el firewall resuelve por DNS el destino del snapshot y si la hora del sistema y la sincronización NTP son correctas.
3. Buscar en el router o filtro de egreso upstream un bloqueo de la dirección WAN del firewall, el FQDN de destino y el puerto requerido.
4. Permitir solo el grupo funcional que falta, no *.sophos.com, Any y todos los puertos de forma general.
5. Iniciar exactamente una nueva prueba y comparar por hora Packet Capture, el log upstream y el log de servicio SFOS correspondiente.

Una resolución DNS correcta solo demuestra que el nombre puede resolverse. Un handshake TCP correcto todavía no demuestra que la licencia, la actualización, el upload o el aprovisionamiento RED funcionen completamente. Después de cambiar la regla de red hay que probar de nuevo la función real.

Destinos y puertos necesarios para SFOS 22

La tabla es el snapshot aprobado para la planificación inicial. Se seleccionan únicamente grupos funcionales activos en el firewall concreto o previstos para un despliegue programado. Para servicios regionales de Sophos Fusion se permite solo la región utilizada. Una empresa en Frankfurt, por ejemplo, no necesita automáticamente destinos S3 de Oregon, Mumbai, Sydney y Tokio.

utm.cloud.sophos.com/api/utm es una URL con una ruta, no un FQDN. Si el producto upstream solo admite un FQDN como destino, se introduce únicamente el host utm.cloud.sophos.com; /api/utm no corresponde a un objeto FQDN. El snapshot contiene hosts upe.p.hmr.sophos.com concretos para Heartbeat y Sophos Fusion, no una autorización para todo el dominio wildcard. Estos nombres pueden cambiar con la operación de la plataforma y solo se actualizan mediante la reconciliación controlada. Del mismo modo, pool.ntp.org solo se aplica cuando se utiliza el destino NTP predeterminado; si se ha configurado otro servidor NTP, se permite ese destino.

Elegir destinos regionales para informes y copias de seguridad

Primero se confirma la región que utiliza cada servicio en el entorno de Sophos Fusion. La ubicación física de la empresa no basta para determinarla. Si la correspondencia no está clara, se identifica el destino de la carga de informes o de la copia de seguridad con Packet Capture y el log upstream, y se aclara antes de permitir el acceso. Esta lista es un catálogo, no una allowlist conjunta: se seleccionan únicamente los destinos necesarios de la región y función utilizadas. CFR envía informes y logs; la copia de seguridad permite guardar y restaurar la configuración del firewall.

• Estados Unidos (Oregón) — us-west-2
  • CFR: tf-presigned-url-us-west-2-prod-firewall-bucket.s3.us-west-2.amazonaws.com
  • Backup: us-west-2-firewall-backup.s3.us-west-2.amazonaws.com
• Europa (Frankfurt) — eu-central-1
  • CFR: tf-presigned-url-eu-central-1-prod-firewall-bucket.s3.eu-central-1.amazonaws.com
  • Backup: eu-central-1-firewall-backup.s3.eu-central-1.amazonaws.com
• Europa (Irlanda) — eu-west-1
  • CFR: tf-presigned-url-eu-west-1-prod-firewall-bucket.s3.eu-west-1.amazonaws.com
  • Backup: eu-west-1-firewall-backup.s3.eu-west-1.amazonaws.com
• Este de Estados Unidos (Ohio) — us-east-2
  • CFR: tf-presigned-url-us-east-2-prod-firewall-bucket.s3.us-east-2.amazonaws.com
  • Backup: us-east-2-firewall-backup.s3.us-east-2.amazonaws.com
• Asia-Pacífico (Mumbai) — ap-south-1
  • CFR: tf-presigned-url-ap-south-1-prod-firewall-bucket.s3.ap-south-1.amazonaws.com
  • Backup: ap-south-1-firewall-backup.s3.ap-south-1.amazonaws.com
• Asia-Pacífico (Tokio) — ap-northeast-1
  • CFR: tf-presigned-url-ap-northeast-1-prod-firewall-bucket.s3.ap-northeast-1.amazonaws.com
  • Backup: ap-northeast-1-firewall-backup.s3.ap-northeast-1.amazonaws.com
• Canadá (Central) — ca-central-1
  • CFR: tf-presigned-url-ca-central-1-prod-firewall-bucket.s3.ca-central-1.amazonaws.com
  • Backup: ca-central-1-firewall-backup.s3.ca-central-1.amazonaws.com
• Asia-Pacífico (Sydney) — ap-southeast-2
  • CFR: tf-presigned-url-ap-southeast-2-prod-firewall-bucket.s3.ap-southeast-2.amazonaws.com
  • Backup: ap-southeast-2-firewall-backup.s3.ap-southeast-2.amazonaws.com
• Emiratos Árabes Unidos (Dubái) — me-central-1
  • CFR: tf-presigned-url-me-central-1-prod-firewall-bucket.s3.me-central-1.amazonaws.com
  • Backup: *.s3.me-central-1.amazonaws.com — la excepción documentada, no una base para inventar un host de backup concreto.

Para las primeras ocho regiones, TCP 443 es el puerto de estos grupos de servicios. Limitación de la fuente para Dubái: Ambas tablas de servicios congeladas tienen nueve filas regionales, pero las celdas compartidas de puerto y finalidad abarcan solo ocho (rowspan=8); las celdas de Dubái están vacías. El resumen anterior asigna TCP 443 al grupo de servicios, no como un valor expresamente indicado para UAE. Los destinos de Dubái están documentados, pero el puerto regional sigue siendo ambiguo en estas tablas. Se aclara mediante la reconciliación controlada antes de permitir el acceso a UAE; aquí no se rellena ningún valor ausente ni se afirma haber probado el comportamiento del producto.

Crear la allowlist de egreso de forma segura

La regla se crea en el dispositivo que realmente filtra el tráfico de sistema saliente. Puede ser un firewall previo, un router del proveedor o un firewall de red cloud. Como origen se utiliza únicamente la dirección WAN de Sophos Firewall tal como la ve el dispositivo de filtrado, antes o después de una posible traducción. Como destinos se usan los FQDN necesarios y como servicios solo los puertos TCP o UDP documentados.

Tratar correctamente wildcards y direcciones IP dinámicas

Muchos servicios Sophos utilizan CDN, plataformas cloud o hosts distribuidos regionalmente. Las IP detrás de un FQDN pueden cambiar. Por tanto, un único nslookup, seguido de IP fijas y una allowlist sin cambios durante años no es fiable.

Si el filtro upstream admite reglas por FQDN o URL, se mantienen allí los nombres del snapshot aprobado. Si el dispositivo solo filtra IP, hace falta un proceso documentado de resolución y actualización periódica. Permitir ampliamente todas las redes de AWS o Sophos no es un sustituto equivalente y aumenta innecesariamente la superficie autorizada.

Con *.sophos.com hay que ser especialmente cuidadoso: en el snapshot, este wildcard amplio pertenece solo a Central Firewall Management. No se extiende a otras funciones o puertos adicionales. RED, updates, sandbox, licencias y Support Access disponen de patrones de destino más estrechos.

No crear una regla WAN entrante

Estas conexiones se inician en el firewall y salen hacia internet. No se crea para ellas una regla DNAT o WAN-to-Local entrante. Tampoco debe añadirse por sospecha una excepción amplia de TLS Inspection, IPS o Web Filtering. Primero se comprueban DNS, ruta, bloqueo upstream y servicio concreto.

Support Access es especialmente fácil de interpretar mal: el firewall se conecta de forma saliente por TCP 22 a *.apu.sophos.com. El procedimiento seguro para activarlo y limitarlo en el tiempo se explica en Configurar Sophos Firewall Support Access.

Delimitar errores de forma sistemática

Comprobar DNS, ruta y puerto por separado

En Diagnostics > Tools > Name lookup se puede resolver primero un destino del snapshot sin modificar la configuración. Lookup using all configured servers muestra si los resolvers configurados responden de forma distinta o tardan demasiado. Como alternativa puede utilizarse la consulta habitual de Device Console:

dnslookup host xg-up2date-firmwares.sophosupd.com

Después, Diagnostics > Packet capture muestra si el firewall inicia una conexión hacia la IP resuelta, qué interfaz WAN utiliza y si regresan respuestas. El Display filter se limita a la IP de destino y al puerto concretos. El estado Generated identifica los paquetes creados por el propio firewall. En paralelo se busca en el sistema upstream el mismo intervalo de tiempo, origen y destino. El capture se desactiva después de la prueba; su buffer es limitado y no sustituye al logging permanente.

El resultado se interpreta por capas:

• Sin respuesta DNS: comprobar servidor DNS, ruta al resolver y hora del sistema.
• El SYN sale del firewall, pero no vuelve respuesta: comprobar regla upstream, ruta del proveedor, NAT y retorno.
• TCP o UDP funciona, pero la función sigue fallando: comprobar el log de servicio correspondiente y el estado del producto; la conectividad por sí sola no es una prueba funcional completa.
• Solo un nodo HA muestra el error: revisar logs y capture en el nodo que procesó la conexión en el momento del error.

Utilizar el log de servicio SFOS adecuado

Para updates, u2d.log y up2date_av.log son buenos puntos de partida; para licencias, licensing.log; para RED, red.log; para sandbox, sandboxd.log; y para Sophos Fusion, entre otros, centralmanagement.log, sophos-central.log y los archivos fwcm-*.log. Para NTP corresponde ntpclient.log. La asignación completa y la exportación segura se describen en Encontrar e interpretar logs de servicio de Sophos Firewall.

En HA, los logs de servicio se guardan en el nodo que procesó la conexión. Una prueba correcta en el Primary actual no demuestra retrospectivamente que el otro nodo tuviera la misma conexión en el momento del error. Por eso se registran juntos hora, nodo, nombre de destino, IP resuelta y puerto.

Validar y operar el cambio

Después de añadir una regla de egreso, no se repite solamente la prueba de puerto. La función real debe mostrar un éxito visible: un pattern cambia de estado, la licencia sincroniza, RED conecta, Sophos Fusion recibe la tarea, aparece un informe o Support Access muestra una sesión activa.

Se mantiene el logging de la regla upstream y se revisa después de unos días. Se eliminan regiones no utilizadas y reglas de prueba temporalmente amplias.

El responsable del firewall revisa el snapshot como mínimo trimestralmente y antes de upgrades de firmware, al activar una nueva función Sophos, después de cambiar de región, tras un aviso relevante del fabricante y durante incidentes de conectividad sin resolver. En ese paso concreto de reconciliación abre la página cambiante Default services y registra fecha, build SFOS, revisor y diff respecto al snapshot interno.

Cada entrada añadida, modificada o eliminada se asigna a una función activa, región y puerto. Las adiciones se aplican por grupo funcional en una ventana de mantenimiento y se validan con DNS, Packet Capture, log upstream y prueba funcional. Un destino no se borra solo porque desaparezca del diff: primero se comprueba su uso en el log, después se desactiva el objeto antiguo y se observa durante un periodo definido. Si falla la validación, se revierte el cambio y se mantiene aprobado el snapshot anterior. Solo una prueba correcta genera un nuevo snapshot fechado.

Revertir efectos inesperados

Antes del cambio se exporta o guarda de otro modo la base de reglas upstream existente. Si después aparecen conexiones inesperadas u otros efectos, se desactiva únicamente la nueva regla o se restaura su último alcance documentado de destinos y puertos. A continuación se prueban de nuevo tanto la función afectada originalmente como una conexión normal a Internet independiente. Así se aísla si la allowlist causó el efecto sin modificar al mismo tiempo reglas no relacionadas.

Criterio de éxito: resolución DNS, establecimiento de conexión saliente, allowlist upstream correspondiente y prueba funcional tienen éxito en conjunto. Si falta una capa, el problema aún no está resuelto de forma limpia.

Preguntas frecuentes