Verificar serviços e portas de saída da Sophos Firewall

A Sophos Firewall estabelece por si própria ligações à Sophos e a alguns serviços externos de plataforma. Utiliza-as para descarregar firmware e patterns, sincronizar licenças, ligar dispositivos RED, enviar relatórios para Sophos Fusion (anteriormente Sophos Central) ou abrir Support Access. Se existir outro router, proxy ou filtro egress à frente da firewall, determinadas funções podem falhar mesmo que o tráfego normal dos clientes continue a funcionar.

A distinção principal é que se trata de tráfego de sistema gerado pela própria firewall. Uma regra LAN-to-WAN ampla adicional na Sophos Firewall não corrige um filtro upstream. É necessária uma regra de saída direcionada no sistema upstream que está realmente a bloquear a ligação.

⚠️ Base de trabalho controlada pela Avanet: O resumo seguinte é o snapshot interno de 4 de setembro de 2026 para o SFOS 22. É a base para planeamento e aceitação; os nomes de destino podem mudar posteriormente. IP fixos obtidos numa única consulta DNS não substituem FQDN e wildcards. O responsável pela firewall segue a reconciliação descrita abaixo antes de alterar o snapshot.

Verificação rápida quando um serviço Sophos não funciona

1. Registar a função afetada, a hora do erro e a build atual do SFOS.
2. Verificar se a firewall resolve por DNS o nome de destino do snapshot e se a hora do sistema e a sincronização NTP estão corretas.
3. No router ou filtro egress upstream, procurar um bloqueio relativo ao endereço WAN da firewall, ao FQDN de destino e à porta necessária.
4. Permitir apenas o grupo funcional em falta, não *.sophos.com, Any e todas as portas de forma geral.
5. Iniciar exatamente um novo teste e comparar por hora Packet Capture, o log upstream e o log de serviço SFOS correspondente.

Uma resolução DNS bem-sucedida apenas prova que o nome pode ser resolvido. Um handshake TCP bem-sucedido ainda não prova que licenciamento, atualização, upload ou aprovisionamento RED funcionam integralmente. Depois de alterar a regra de rede, deve testar-se novamente a função real.

Destinos e portas necessários para o SFOS 22

A tabela é o snapshot aprovado para o planeamento inicial. Selecionam-se apenas grupos funcionais ativos na firewall concreta ou previstos para uma implementação agendada. Para serviços regionais do Sophos Fusion, permite-se apenas a região realmente utilizada. Uma organização na região de Frankfurt, por exemplo, não precisa automaticamente de destinos S3 em Oregon, Mumbai, Sydney e Tóquio.

utm.cloud.sophos.com/api/utm é um URL com um caminho, não um FQDN. Se o produto upstream apenas aceitar um FQDN como destino, introduz-se somente o host utm.cloud.sophos.com; /api/utm não deve ser inserido num objeto FQDN. O snapshot contém hosts upe.p.hmr.sophos.com específicos para Heartbeat e Sophos Fusion, não uma autorização para todo o domínio wildcard. Estes nomes podem mudar com a operação da plataforma e são atualizados apenas pela reconciliação controlada. Da mesma forma, pool.ntp.org só se aplica quando é utilizado o destino NTP predefinido; se estiver configurado outro servidor NTP, deve permitir-se esse destino.

Escolher destinos regionais para relatórios e backups

Primeiro confirma-se a região realmente utilizada por cada serviço no ambiente Sophos Fusion. A localização da organização, por si só, não a determina. Se a correspondência não for clara, identifica-se o destino do envio de relatórios ou do backup com Packet Capture e o log upstream, e esclarece-se antes de permitir o acesso. Esta lista é um catálogo, não uma allowlist conjunta: selecionam-se apenas os destinos necessários para a região e a função utilizadas. O CFR envia relatórios e logs; o backup permite guardar e restaurar a configuração da firewall.

• Estados Unidos (Oregon) — 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
• Leste dos 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
• Ásia-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
• Ásia-Pacífico (Tóquio) — 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
• Ásia-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
• Emirados Árabes Unidos (Dubai) — 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 — a exceção documentada, não uma base para inventar um único host de backup.

Para as primeiras oito regiões, TCP 443 é a porta destes grupos de serviços. Limitação da fonte para Dubai: Ambas as tabelas de serviços congeladas contêm nove linhas regionais, mas as células comuns de porta e finalidade abrangem apenas oito (rowspan=8); as células de Dubai estão vazias. O resumo acima associa TCP 443 ao grupo de serviços, não a um valor de porta explicitamente preenchido para UAE. Os destinos de Dubai estão documentados, mas a porta regional continua ambígua nestas tabelas. Esclarece-se através da reconciliação controlada antes de permitir o acesso a UAE; aqui não se preenche nenhum valor ausente nem se afirma ter testado o comportamento do produto.

Criar a allowlist egress em segurança

A regra é criada no dispositivo que filtra realmente o tráfego de sistema de saída. Pode ser uma firewall upstream, um router do fornecedor ou uma cloud network firewall. Como origem, usa-se apenas o endereço WAN da Sophos Firewall tal como o dispositivo de filtragem o vê, antes ou depois de uma eventual tradução. Como destinos usam-se os FQDN necessários e como serviços apenas as portas TCP ou UDP documentadas.

Tratar corretamente wildcards e endereços IP dinâmicos

Muitos serviços Sophos usam CDN, plataformas cloud ou hosts distribuídos regionalmente. Os endereços IP por trás de um FQDN podem mudar. Um único nslookup, seguido por IP fixos e uma allowlist inalterada durante anos, não é fiável.

Se o filtro upstream suportar regras baseadas em FQDN ou URL, mantêm-se aí os nomes do snapshot aprovado. Se o dispositivo apenas filtrar endereços IP, é necessário um processo documentado de resolução e atualização regular. Permitir amplamente todas as redes AWS ou Sophos não é um substituto equivalente e aumenta desnecessariamente a superfície permitida.

É preciso especial cuidado com *.sophos.com: no snapshot, este wildcard amplo pertence apenas a Central Firewall Management. Não deve ser estendido a outras funções ou portas. RED, atualizações, sandbox, licenciamento e Support Access têm padrões de destino mais restritos.

Não criar uma regra WAN de entrada

Estas ligações começam na firewall e seguem para o exterior. Não se cria uma regra DNAT ou WAN-to-Local de entrada. Também não se deve adicionar por suspeita uma exceção ampla de TLS Inspection, IPS ou Web Filtering. Primeiro verificam-se DNS, rota, bloqueio upstream e serviço concreto.

Support Access é particularmente fácil de interpretar de forma errada: a firewall liga-se para o exterior através de TCP 22 a *.apu.sophos.com. O procedimento seguro para o ativar e limitar no tempo está em Configurar Sophos Firewall Support Access.

Delimitar erros sistematicamente

Verificar DNS, rota e porta separadamente

Em Diagnostics > Tools > Name lookup pode começar-se por resolver um destino do snapshot sem alterar a configuração. Lookup using all configured servers mostra se os resolvers configurados respondem de forma diferente ou demoram demasiado tempo. Em alternativa, pode usar-se a consulta habitual da Device Console:

dnslookup host xg-up2date-firmwares.sophosupd.com

Depois, Diagnostics > Packet capture mostra se a firewall inicia uma ligação ao endereço resolvido, que interface WAN utiliza e se chegam respostas. O Display filter é limitado ao IP de destino e à porta concretos. O estado Generated identifica os pacotes criados pela própria firewall. Em paralelo, procura-se no sistema upstream a mesma janela temporal, origem e destino. O capture deve ser desativado após o teste; o buffer é limitado e não substitui logging permanente.

O resultado é interpretado por camadas:

• Sem resposta DNS: verificar servidor DNS, rota para o resolver e hora do sistema.
• O SYN sai da firewall, mas não regressa resposta: verificar regra upstream, caminho do fornecedor, NAT e caminho de retorno.
• TCP ou UDP funciona, mas a função continua com erro: verificar o log de serviço adequado e o estado do produto; a conectividade por si só não é uma prova funcional completa.
• Apenas um nó HA mostra o erro: verificar logs e capture no nó que processou a ligação no momento do erro.

Utilizar o log de serviço SFOS adequado

Para atualizações, u2d.log e up2date_av.log são bons pontos de partida; para licenciamento licensing.log, para RED red.log, para sandbox sandboxd.log e para Sophos Fusion, entre outros, centralmanagement.log, sophos-central.log e os ficheiros fwcm-*.log. Para NTP corresponde ntpclient.log. A atribuição completa e a exportação segura estão em Encontrar e interpretar logs de serviço da Sophos Firewall.

Em HA, os logs de serviço ficam no nó que processou a ligação. Um teste bem-sucedido no Primary atual não prova retrospetivamente que o outro nó tinha a mesma ligação no momento do erro. Devem registar-se em conjunto hora, nó, nome de destino, IP resolvido e porta.

Validar e operar a alteração

Depois de adicionar uma regra egress, não se repete apenas o teste da porta. A função real deve mostrar um sucesso visível: um pattern muda de estado, a licença sincroniza, RED liga-se, Sophos Fusion recebe a tarefa, aparece um relatório ou Support Access mostra uma sessão ativa.

O logging da regra upstream deve permanecer ativo e ser revisto após alguns dias. Removem-se regiões não utilizadas e regras de teste temporariamente amplas.

O responsável pela firewall revê o snapshot pelo menos trimestralmente e antes de upgrades de firmware, ao ativar uma nova função Sophos, após uma mudança de região, após um aviso relevante do fabricante e durante incidentes de conectividade não resolvidos. Nesse passo concreto de reconciliação, abre a página variável Default services e regista data, build SFOS, revisor e diff face ao snapshot interno.

Cada entrada adicionada, alterada ou removida é associada a uma função ativa, região e porta. As adições são aplicadas por grupo funcional numa janela de manutenção e validadas com DNS, Packet Capture, log upstream e teste funcional. Um destino não é eliminado apenas por desaparecer do diff: primeiro verifica-se a utilização no log da regra, depois desativa-se o objeto antigo e observa-se durante um período definido. Se a validação falhar, reverte-se a alteração e mantém-se aprovado o snapshot anterior. Só um teste bem-sucedido produz um novo snapshot datado.

Reverter efeitos inesperados

Antes da alteração, deve exportar-se ou guardar-se de outra forma a base de regras upstream existente. Se surgirem depois ligações inesperadas ou outros efeitos, desativa-se apenas a nova regra ou restaura-se o último âmbito documentado de destinos e portas. Em seguida, testam-se novamente tanto a função originalmente afetada como uma ligação normal e independente à Internet. Assim é possível determinar se a allowlist causou o efeito sem alterar simultaneamente regras não relacionadas.

Critério de sucesso: resolução DNS, estabelecimento da ligação de saída, allowlist upstream adequada e teste funcional têm sucesso em conjunto. Se faltar uma camada, o problema ainda não está corretamente resolvido.

Perguntas frequentes