Verificare servizi e porte in uscita di Sophos Firewall
Sophos Firewall stabilisce autonomamente connessioni verso Sophos e alcuni servizi di piattaforma esterni. Le utilizza per scaricare firmware e pattern, sincronizzare le licenze, collegare dispositivi RED, inviare report a Sophos Central o aprire Support Access. Se davanti al firewall si trova un altro router, proxy o filtro egress, singole funzioni possono non riuscire anche se il normale traffico client continua a funzionare.
La distinzione fondamentale è che si tratta di traffico di sistema generato dal firewall stesso. Una regola LAN-to-WAN ampia aggiuntiva su Sophos Firewall non risolve un filtro upstream. Serve una regola in uscita mirata sul sistema upstream che blocca realmente la connessione.
⚠️ I nomi di destinazione sono un elenco dinamico del produttore. La panoramica seguente riflette la documentazione pubblica SFOS 22 del 21 agosto 2026. Prima di creare una allowlist di produzione, verificare nuovamente la pagina Sophos attuale Default services. Gli indirizzi IP fissi ottenuti con una singola risoluzione DNS non sostituiscono in modo permanente FQDN e wildcard documentati.
Controllo rapido quando un servizio Sophos non funziona
- Annotare la funzione interessata, l’ora dell’errore e la build SFOS attuale.
- Verificare che il firewall risolva via DNS il nome di destinazione documentato e che ora di sistema e sincronizzazione NTP siano corrette.
- Sul router o filtro egress upstream cercare un blocco relativo all’indirizzo WAN del firewall, al FQDN di destinazione e alla porta richiesta.
- Consentire solo il gruppo funzionale mancante, non
*.sophos.com,Anye tutte le porte in modo generalizzato. - Avviare esattamente un nuovo test e confrontare per orario Packet Capture, log upstream e log di servizio SFOS corrispondente.
Una risoluzione DNS riuscita dimostra solo che il nome può essere risolto. Un handshake TCP riuscito non dimostra ancora che licenza, aggiornamento, upload o provisioning RED funzionino interamente. Dopo la modifica della regola di rete occorre testare nuovamente la funzione effettiva.
Destinazioni e porte richieste da SFOS 22
La tabella riassume i gruppi più importanti. Per i servizi regionali Sophos Central si consente solo la regione realmente utilizzata. Un’organizzazione nella regione di Francoforte, ad esempio, non necessita automaticamente di tutte le destinazioni S3 in Oregon, Mumbai, Sydney e Tokyo.
| Funzione | Destinazioni documentate | Porte | Sintomo tipico |
|---|---|---|---|
| Categorizzazione web e reputazione IP | 4.sophosxl.net | TCP 443 | Categorie o reputazione non vengono valutate con dati aggiornati. |
| Aggiornamenti firmware, pattern e client | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware o pattern restano bloccati durante verifica o download. |
| Scanner antivirus aggiuntivo per appliance piccole | oem.avdl.ctmail.com | TCP 80 | Gli aggiornamenti antivirus aggiuntivi non riescono. |
| Licenze | *.soa.sophos.com | TCP 443 | Attivazione o sincronizzazione della licenza non riesce. |
| Provisioning RED | *.astaro.com | TCP 3400, UDP 3410 | Il dispositivo RED non si registra o non crea il tunnel. |
| Security Heartbeat e Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, gli host regionali *.upe.p.hmr.sophos.com documentati da Sophos e *.sophos.com per Central Firewall Management | TCP 80, 443; Central Firewall Management usa anche TCP 22 | Registrazione, Heartbeat, Synchronized Application Control o gestione Central resta offline. |
| Central Firewall Reporting | host regionale tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com | TCP 443 | Log e report non compaiono in Central. |
| Central Firewall Backup | host regionale <region>-firewall-backup.s3.<region>.amazonaws.com; per UAE Sophos documenta *.s3.me-central-1.amazonaws.com | TCP 443 | Backup o restore Central non raggiunge lo storage. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | I file non vengono inviati alla sandbox o mancano i risultati. |
| Support Access | *.apu.sophos.com | TCP 22 | Il tunnel di supporto in uscita non può essere stabilito. |
| NTP | pool.ntp.org | UDP 123 | L’ora deriva; certificati, MFA, Kerberos o log appaiono incoerenti. |
| SAR, telemetria e controllo DDNS | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443; il controllo DDNS usa TCP 80 | Security Audit Report, telemetria o rilevamento dell’IP pubblico non funziona. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | Il percorso dati ZTNA o la connessione a Sophos Central non funziona. |
Sophos elenca anche singoli host concreti per Heartbeat e Central. Questi valori possono cambiare in base a regione, gestione della piattaforma o modifiche del produttore. Perciò la tabella non viene trasformata in un elenco IP statico.
Creare in sicurezza la allowlist egress
La regola va creata sul dispositivo che filtra realmente il traffico di sistema in uscita. Può essere un firewall upstream, un router del provider o un cloud network firewall. Su quel sistema si usa come origine solo l’indirizzo pubblico o tradotto di Sophos Firewall. Le destinazioni sono i FQDN necessari e i servizi soltanto le porte TCP o UDP documentate.
Gestire correttamente wildcard e indirizzi IP dinamici
Molti servizi Sophos usano CDN, piattaforme cloud o host distribuiti regionalmente. Gli indirizzi IP dietro un FQDN possono cambiare. Un singolo nslookup, seguito da IP fissi e da una allowlist invariata per anni, non è quindi affidabile.
Se il filtro upstream supporta regole basate su FQDN o URL, vi si mantengono i nomi documentati da Sophos. Se il dispositivo filtra solo indirizzi IP, serve un processo documentato di risoluzione e aggiornamento periodico. Consentire indiscriminatamente tutte le reti AWS o Sophos non è un’alternativa equivalente e aumenta inutilmente la superficie autorizzata.
Prestare particolare attenzione a *.sophos.com: Sophos indica espressamente questa wildcard ampia per Central Firewall Management. Non estenderla automaticamente ad altre funzioni o porte. RED, aggiornamenti, sandbox, licenze e Support Access dispongono di pattern di destinazione più ristretti.
Non creare una regola WAN in ingresso
Queste connessioni partono dal firewall e vanno verso l’esterno. Non creare una regola DNAT o WAN-to-Local in ingresso. Allo stesso modo, non aggiungere per supposizione un’esenzione ampia da TLS Inspection, IPS o Web Filtering. Verificare prima DNS, route, blocco upstream e servizio specifico.
Support Access è particolarmente facile da interpretare male: il firewall si connette in uscita tramite TCP 22 a *.apu.sophos.com. La procedura sicura per attivarlo e limitarlo nel tempo è descritta in Configurare Sophos Firewall Support Access.
Delimitare sistematicamente gli errori
Controllare separatamente DNS, route e porta
Nella Device Console si può iniziare con un controllo in sola lettura di una destinazione documentata:
dnslookup host xg-up2date-firmwares.sophosupd.com
Un Packet Capture ristretto mostra poi se il firewall avvia una connessione verso l’indirizzo risolto, quale interfaccia WAN usa e se tornano risposte. Limitare il capture all’IP di destinazione e alla porta specifici. Cercare in parallelo nel sistema upstream la stessa finestra temporale, origine e destinazione.
Interpretare il risultato per livelli:
- Nessuna risposta DNS: verificare server DNS, route verso il resolver e ora di sistema.
- Il SYN lascia il firewall, ma non torna risposta: verificare regola upstream, percorso del provider, NAT e ritorno.
- TCP o UDP funziona, ma la funzione resta guasta: verificare il log di servizio corrispondente e lo stato del prodotto; la sola connettività non è una prova funzionale completa.
- Solo un nodo HA mostra l’errore: verificare log e capture sul nodo che ha elaborato la connessione al momento dell’errore.
Usare il log di servizio SFOS corretto
Per gli aggiornamenti, u2d.log e up2date_av.log sono buoni punti di partenza; per le licenze licensing.log, per RED red.log, per la sandbox sandboxd.log e per Sophos Central, tra gli altri, centralmanagement.log, sophos-central.log e i file fwcm-*.log. Per NTP è adatto ntpclient.log. L’associazione completa e l’esportazione sicura sono descritte in Trovare e interpretare i log di servizio Sophos Firewall.
In HA, i log di servizio si trovano sul nodo che ha elaborato la connessione. Un test riuscito sul Primary attuale non dimostra retrospettivamente che l’altro nodo avesse la stessa connessione al momento dell’errore. Registrare insieme ora, nodo, nome di destinazione, IP risolto e porta.
Collaudare e gestire la modifica
Dopo aver aggiunto una regola egress, non basta ripetere il test della porta. La funzione effettiva deve mostrare un successo visibile: un pattern cambia stato, la licenza si sincronizza, RED si collega, Central riceve il task, compare un report oppure Support Access mostra una sessione attiva.
Mantenere attivo il logging sulla regola upstream e riesaminarla dopo alcuni giorni. Rimuovere regioni non utilizzate, vecchi nomi di destinazione e regole di test temporaneamente ampie. Prima di upgrade firmware o dell’attivazione di nuove funzioni Sophos, confrontare nuovamente l’elenco Default services attuale per non scoprire la dipendenza durante la finestra di manutenzione.
Criterio di successo: risoluzione DNS, creazione della connessione in uscita, allowlist upstream corrispondente e test funzionale riescono insieme. Se manca un livello, il problema non è ancora risolto in modo pulito.