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 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.
⚠️ Os nomes de destino são uma lista variável do fabricante. O resumo seguinte corresponde à documentação pública do SFOS 22 de 21 de agosto de 2026. Antes de criar uma allowlist produtiva, deve voltar a verificar-se a página atual da Sophos Default services. Endereços IP fixos obtidos numa única consulta DNS não substituem permanentemente os FQDN e wildcards documentados.
Verificação rápida quando um serviço Sophos não funciona
- Registar a função afetada, a hora do erro e a build atual do SFOS.
- Verificar se a firewall resolve por DNS o nome de destino documentado e se a hora do sistema e a sincronização NTP estão corretas.
- No router ou filtro egress upstream, procurar um bloqueio relativo ao endereço WAN da firewall, ao FQDN de destino e à porta necessária.
- Permitir apenas o grupo funcional em falta, não
*.sophos.com,Anye todas as portas de forma geral. - 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 resume os grupos mais importantes. Para serviços regionais da Sophos Central, permite-se apenas a região realmente utilizada. Uma organização na região de Frankfurt, por exemplo, não precisa automaticamente de todos os destinos S3 em Oregon, Mumbai, Sydney e Tóquio.
| Função | Destinos documentados | Portas | Sintoma típico |
|---|---|---|---|
| Categorização Web e reputação IP | 4.sophosxl.net | TCP 443 | Categorias ou reputação não são avaliadas com dados atuais. |
| Atualizações de firmware, patterns e clientes | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware ou patterns ficam parados durante a verificação ou o download. |
| Scanner antivírus adicional para appliances pequenos | oem.avdl.ctmail.com | TCP 80 | As atualizações antivírus adicionais falham. |
| Licenciamento | *.soa.sophos.com | TCP 443 | A ativação ou sincronização da licença falha. |
| Aprovisionamento RED | *.astaro.com | TCP 3400, UDP 3410 | O dispositivo RED não se regista ou não estabelece um túnel. |
| Security Heartbeat e Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, os hosts regionais *.upe.p.hmr.sophos.com documentados pela Sophos e *.sophos.com para Central Firewall Management | TCP 80, 443; Central Firewall Management usa adicionalmente TCP 22 | Registo, Heartbeat, Synchronized Application Control ou gestão Central permanece offline. |
| Central Firewall Reporting | host regional tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com | TCP 443 | Logs e relatórios não aparecem na Central. |
| Central Firewall Backup | host regional <region>-firewall-backup.s3.<region>.amazonaws.com; para UAE a Sophos documenta *.s3.me-central-1.amazonaws.com | TCP 443 | Backup ou restore da Central não alcança o armazenamento. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | Os ficheiros não são enviados para a sandbox ou faltam resultados. |
| Support Access | *.apu.sophos.com | TCP 22 | Não é possível estabelecer o túnel de suporte de saída. |
| NTP | pool.ntp.org | UDP 123 | A hora deriva; certificados, MFA, Kerberos ou logs parecem incoerentes. |
| SAR, telemetria e verificação DDNS | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443; a verificação DDNS usa TCP 80 | Security Audit Report, telemetria ou deteção do IP público não funciona. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | O caminho de dados ZTNA ou a ligação à Sophos Central falha. |
A Sophos também enumera hosts concretos de Heartbeat e Central. Estes valores podem mudar conforme região, operação da plataforma ou alterações do fabricante. Por isso, a tabela não é convertida numa lista IP estática.
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. Nesse sistema, deve usar-se como origem apenas o endereço público ou traduzido da Sophos Firewall. 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 documentados pela Sophos. 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: a Sophos indica expressamente este wildcard amplo para Central Firewall Management. Não deve ser estendido automaticamente 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
Na Device Console pode começar-se por uma verificação apenas de leitura de um destino documentado:
dnslookup host xg-up2date-firmwares.sophosupd.com
Depois, um Packet Capture restrito mostra se a firewall inicia uma ligação ao endereço resolvido, que interface WAN utiliza e se chegam respostas. O capture é limitado ao IP de destino e à porta concretos. Em paralelo, procura-se no sistema upstream a mesma janela temporal, origem e destino.
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 Central, 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, Central 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, nomes de destino antigos e regras de teste temporariamente amplas. Antes de upgrades de firmware ou de ativar novas funções Sophos, volta a comparar-se a lista atual Default services para não descobrir a dependência durante a janela de manutenção.
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.