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.
⚠️ Baseline di lavoro controllata da Avanet: La panoramica seguente è lo snapshot interno del 4 settembre 2026 per SFOS 22. È la base per pianificazione e collaudo; i nomi di destinazione possono cambiare in seguito. Gli IP fissi ottenuti con una singola risoluzione DNS non sostituiscono FQDN e wildcard. Il responsabile del firewall segue la riconciliazione descritta più avanti prima di modificare lo snapshot.
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 dello snapshot 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 è lo snapshot approvato per la pianificazione iniziale. Selezionare solo i gruppi funzionali attivi sul firewall specifico o previsti per un rollout pianificato. Per i servizi regionali Sophos Central si consente solo la regione realmente utilizzata. Un’organizzazione nella regione di Francoforte, ad esempio, non necessita automaticamente delle destinazioni S3 in Oregon, Mumbai, Sydney e Tokyo.
| Funzione | Destinazioni dello snapshot | 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 | utm.cloud.sophos.com, dzr-utm-amzn-eu-west-1-9af7.upe.p.hmr.sophos.com | TCP 80, 443 | Heartbeat o Synchronized Security resta offline. |
| Sophos Central e Synchronized Application Control | utm.cloud.sophos.com/api/utm, dzr-utm-amzn-us-west-2-fa88.upe.p.hmr.sophos.com | TCP 443 | La registrazione o Synchronized Application Control resta offline. |
| Central Firewall Management | *.sophos.com | TCP 22, 443 | La gestione Central resta offline o i task non raggiungono il firewall. |
| 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 lo snapshot contiene *.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. |
utm.cloud.sophos.com/api/utm è un URL con un percorso, non un FQDN. Se il prodotto upstream accetta come destinazione solo un FQDN, va inserito soltanto l’host utm.cloud.sophos.com; /api/utm non va inserito in un oggetto FQDN. Lo snapshot contiene host upe.p.hmr.sophos.com specifici per Heartbeat e Central, non un’autorizzazione per l’intero dominio wildcard. Questi nomi possono cambiare con la gestione della piattaforma e vengono aggiornati solo tramite la riconciliazione controllata. Analogamente, pool.ntp.org vale soltanto quando si usa la destinazione NTP predefinita; se è configurato un altro server NTP, va consentita la relativa destinazione.
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. Come origine si usa solo l’indirizzo WAN di Sophos Firewall così come viene visto dal dispositivo di filtro, prima o dopo un’eventuale traduzione. 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 dello snapshot approvato. 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: nello snapshot questa wildcard ampia appartiene solo a Central Firewall Management. Non estenderla 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
In Diagnostics > Tools > Name lookup si può prima risolvere una destinazione dello snapshot senza modificare la configurazione. Lookup using all configured servers mostra se i resolver configurati rispondono in modo diverso o impiegano un tempo anomalo. In alternativa si può usare la consueta query nella Device Console:
dnslookup host xg-up2date-firmwares.sophosupd.com
In Diagnostics > Packet capture, un capture ristretto mostra poi se il firewall avvia una connessione verso l’indirizzo risolto, quale interfaccia WAN usa e se tornano risposte. Limitare il Display filter all’IP di destinazione e alla porta specifici. Lo stato Generated identifica i pacchetti creati dal firewall stesso. Cercare in parallelo nel sistema upstream la stessa finestra temporale, origine e destinazione. Disattivare il capture dopo il test: il buffer è limitato e non sostituisce un logging permanente.
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 e regole di test temporaneamente ampie.
Il responsabile del firewall rivede lo snapshot almeno ogni trimestre e prima di upgrade firmware, quando attiva una nuova funzione Sophos, dopo un cambio di regione, dopo un avviso pertinente del produttore e durante incidenti di connettività irrisolti. In quella concreta fase di riconciliazione apre la pagina dinamica Default services e registra data, build SFOS, revisore e diff rispetto allo snapshot interno.
Ogni voce aggiunta, modificata o rimossa viene associata a una funzione attiva, una regione e una porta. Applicare le aggiunte un gruppo funzionale alla volta in una finestra di manutenzione, quindi validarle con DNS, Packet Capture, log upstream e test funzionale. Non eliminare una destinazione solo perché manca nel diff: verificarne prima l’uso nel log della regola, poi disattivare il vecchio oggetto e osservarlo per un periodo definito. Se la validazione fallisce, annullare la modifica e mantenere approvato lo snapshot precedente. Solo un test riuscito produce un nuovo snapshot datato.
Ripristino in caso di effetti imprevisti
Prima della modifica, esportare o salvare in altro modo la base di regole upstream esistente. Se compaiono connessioni inattese o altri effetti, disattivare soltanto la nuova regola oppure ripristinarne l’ultimo ambito documentato di destinazioni e porte. Quindi verificare nuovamente sia la funzione inizialmente interessata sia una normale connessione Internet indipendente. In questo modo si isola l’eventuale effetto della allowlist senza modificare contemporaneamente regole non correlate.
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.