Sophos Firewall come relay NTP tramite NAT

Quando i dispositivi interni devono usare l’IP del gateway come destinazione NTP, Sophos Firewall può inoltrare le loro richieste a un server temporale tramite NAT. L’impostazione in Administration > Time sincronizza invece solo l’orologio del firewall e non fornisce ai client un servizio server NTP.

La soluzione documentata da Sophos è un relay NTP tramite NAT. I dispositivi inviano NTP all’IP del firewall; Sophos Firewall traduce destinazione e sorgente e inoltra i pacchetti a un vero server temporale esterno o interno. Il firewall non diventa quindi la sorgente dell’ora. Separatamente, funziona come client NTP per sincronizzare il proprio orologio.

Ciò è particolarmente utile se i dispositivi sono configurati in modo permanente su IP del gateway, se un precedente ambiente UTM è stato sostituito o se si desidera controllare centralmente i target NTP. Per i nuovi progetti DHCP, spesso è più pulito distribuire il server temporale corretto direttamente tramite l’opzione DHCP. Le nozioni di base sono disponibili in Configurare le opzioni DHCP su Sophos Firewall.

⚠️ Importante: Il Sophos Firewall non deve fornire un servizio NTP aperto su Internet. Le zone di origine, le reti di origine, i server di destinazione e le regole del firewall devono essere deliberatamente limitate. WAN come Source Zone di solito non è corretto per questo modello.

Quale variante è adatta?

NTP tramite NAT è un modello pragmatico, ma non sempre l’architettura migliore.

Due varianti sono importanti per questo articolo:

• Variante A: I dispositivi interni utilizzano l’IP del firewall come server NTP, il firewall inoltra a un server NTP esterno.
• Variante B: I dispositivi interni utilizzano l’IP del firewall come server NTP, il firewall inoltra a un server NTP interno. Inoltre, è necessario consentire la sincronizzazione esterna del server NTP interno.

La seconda variante prevede quindi due percorsi di traffico distinti. Se la sincronizzazione esterna del server temporale interno è già consentita e tradotta correttamente, si verifica e si riutilizza la coppia di regole esistente; non servono ulteriori regole identiche.

Requisiti

Prima della configurazione, questi punti dovrebbero essere chiari:

• Quali reti interne possono utilizzare NTP?
• Quale indirizzo IP utilizzano i client come destinazione NTP, ad esempio IP del gateway?
• Quale vero server NTP utilizzare?
• È opportuno utilizzare un server temporale interno o un servizio esterno come time.google.com o pool.ntp.org?
• Il firewall è in grado di risolvere in modo affidabile il DNS per le destinazioni FQDN?
• L’ora di sistema del firewall è sincronizzata correttamente?

Un esempio IPv4 coerente chiarisce le associazioni:

• net_Internet-LAN: 10.10.11.0/24, ingresso dei client Port2 nella zona della rete client interna.
• host_internal-firewall-ip: host 10.10.11.1, l’IP del firewall usato da questi client.
• host_Google-NTP: FQDN time.google.com per la variante A e, se necessario, come sorgente temporale esterna del server interno.
• NTP_Server_Internal: host 192.168.20.10, raggiungibile tramite Port3 nella zona DMZ, per la variante B.

Questi indirizzi privati, nomi di oggetti e interfacce sono esempi e vanno sostituiti con i valori effettivi. Si selezionano solo le reti che richiedono il relay e le loro reali interfacce di ingresso; per IOT_NET si aggiunge, se necessario, una regola separata con limiti altrettanto precisi. Gli oggetti di rete e host si creano in Hosts and services > IP host. Se si usano più IP di gateway, le reti sorgente, gli ingressi e gli indirizzi di destinazione associati devono essere coerenti. Prima delle modifiche si annotano le regole NAT/firewall esistenti, il loro ordine e la sorgente temporale dei client; il vero server temporale deve essere raggiungibile e accettare richieste dall’indirizzo del firewall usato da MASQ.

L’ora corretta è importante per le funzioni critiche in termini di tempo come MFA, l’autenticazione WAF, i certificati, i log, le VPN e la correlazione SIEM. Se il firewall stesso ha un orario errato, è necessario controllare l’orario del sistema prima di reindirizzare Client-NTP.

I passaggi seguenti si basano sulla documentazione ufficiale di Sophos Firewall 22.0 (fonti verificate il 17.10.2026). Per questa guida non sono stati eseguiti test su un dispositivo. Le impostazioni NTP del firewall non possono essere sincronizzate da Sophos Fusion (in precedenza Sophos Central): vanno configurate in WebAdmin, tramite CLI o API. I passaggi NAT e firewall seguenti usano WebAdmin.

Gli esempi usano volutamente una configurazione IPv4, selezionando IP version: IPv4 durante la creazione dell’host. In ambienti IPv6 o dual-stack questo schema non dovrebbe essere copiato automaticamente. Prima bisogna chiarire se i client hanno davvero bisogno di NTP su IPv6, quali funzioni firewall e NAT valgono nella release SFOS usata e se DHCPv6, Router Advertisements o un server temporale interno diretto siano la soluzione più pulita.

Quick Reference

Per amministratori esperti, la logica breve è semplice: i client inviano UDP 123 all’IP del firewall o gateway. Una regola DNAT riscrive la destinazione verso il vero server NTP, una regola firewall consente esattamente questo traffico e Log Viewer conferma poi Firewall Rule ID e NAT Rule ID.

Server NTP esterno: una regola DNAT inoltra NTP dall’IP del firewall all’oggetto FQDN o host del server NTP esterno. Una regola firewall consente NTP dalle sorgenti interne interessate verso WAN. Nell’esempio generale di relay di Sophos, Original destination resta su Any; per il relay tramite IP del gateway descritto qui, il campo viene limitato all’esatto IP del firewall usato dai client. In questo modo le richieste NTP dirette ad altre destinazioni non vengono reindirizzate involontariamente.

Server NTP interno: servono due movimenti. Prima il server NTP interno deve potersi sincronizzare verso l’esterno tramite SNAT/MASQ. Poi una regola DNAT inoltra le richieste client dall’IP del firewall al server NTP interno. Entrambe le coppie di regole devono essere verificate separatamente in Log Viewer.

Per la prima implementazione, la posizione della regola dovrebbe essere volutamente alta, tipicamente Top o sopra regole LAN-to-WAN e NAT ampie. In seguito la posizione può essere inserita nel concetto di regole esistente, purché Log Viewer e Packet Capture continuino a mostrare che la regola attesa viene applicata per prima.

host_internal-firewall-ip contiene l’indirizzo IP LAN interno di Sophos Firewall, qui 10.10.11.1. I client usano questo indirizzo come server NTP. Sostituisci il valore con l’IP LAN interno del firewall della tua rete client e adatta net_Internet-LAN (10.10.11.0/24), l’interfaccia di ingresso e la zona sorgente. Qui l’ingresso è Port2 nella zona della rete client interna; Port1 appartiene alla DMZ e non viene usato. Entrambe le regole usano il servizio predefinito NTP; non serve un servizio aggiuntivo solo UDP. Questo esempio di configurazione non dimostra un test reale riuscito. Seleziona la zona assegnata alla rete client nel tuo ambiente; «zona LAN interna» è una descrizione, non un nome di zona obbligatorio.

In Hosts and services > IP host > Add, crea i due oggetti IPv4 seguenti e salva ciascuno con Save. Riutilizza eventuali oggetti esistenti adatti.

Variante A: utilizzare un server NTP esterno

Questa variante è adatta se i client devono utilizzare l’IP del firewall come server NTP e non esiste un proprio time server interno. Il firewall traduce la destinazione della richiesta NTP verso un server temporale esterno, ad esempio time.google.com o un server temporale del provider scelto deliberatamente.

Google Public NTP (time.google.com) usa il leap smear. Non combinarlo con sorgenti temporali senza leap smear.

Creare un host FQDN per il server NTP esterno

Il percorso del menu è:

Hosts and services > FQDN host

Procedura:

1. Selezionare Add.
2. Assegnare Name, ad esempio host_Google-NTP.
3. Immettere il server NTP esterno in FQDN, ad esempio time.google.com.
4. Salvare.

Se viene utilizzato un time server interno o esterno con un IP fisso anziché FQDN, un normale oggetto host potrebbe avere più senso. È importante che la destinazione possa essere chiaramente riconosciuta successivamente nella regola NAT e firewall.

Creare la regola NAT per il server NTP esterno

La regola NAT riscrive la destinazione delle richieste NTP all’IP del firewall verso il server temporale esterno. Il percorso del menu è:

Rules and policies > NAT rules

Procedura:

1. Selezionare Add NAT rule > New NAT rule.
2. Impostare Rule name, ad esempio DNAT_Client_NTP_to_External.
3. Impostare Rule position su Top o posizionare la regola sopra le regole NAT generali.
4. Impostare Original source sulla rete interna interessata, nell’esempio net_Internet-LAN (10.10.11.0/24).
5. Impostare Original destination su host_internal-firewall-ip, nell’esempio 10.10.11.1.
6. Per Original service, rimuovere Any e selezionare NTP.
7. Per Translated source (SNAT) selezionare MASQ.
8. Per Translated destination (DNAT), selezionare l’host FQDN o l’host del server NTP esterno.
9. Per Inbound interface, rimuovere Any e selezionare l’effettivo ingresso dei client, nell’esempio Port2. Sophos consente in alternativa Any, ma una selezione esplicita evita corrispondenze su ingressi indesiderati.
10. Lasciare Translated service (PAT) su Original, in modo che UDP 123 rimanga invariato. Per questa regola DNAT, Outbound interface resta su Any; l’uscita è determinata dal percorso verso la destinazione tradotta.
11. Salvare.

    

⚠️ Non lasciare aperta Original destination: se Original destination non è limitata all’IP del firewall o gateway, la regola può agire in modo molto più ampio a seconda del resto del design NAT. In alcuni casi non viene inoltrato solo il traffico verso l’IP del firewall, ma anche traffico NTP della rete viene reindirizzato in modo trasparente. Per un relay controllato, la regola deve corrispondere solo quando i client usano davvero l’IP del firewall o gateway come destinazione NTP. Nella visualizzazione dettagliata prestare particolare attenzione a quattro punti: la destinazione originale deve essere effettivamente il firewall o IP del gateway, il servizio deve rimanere limitato a NTP o UDP 123, la destinazione tradotta deve puntare al server temporale pianificato e SNAT deve corrispondere al percorso di ritorno.

Se le nozioni di base di NAT o i campi DNAT non sono chiari, Comprendere NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT aiuterà. Spiega anche perché NAT non sostituisce l’autorizzazione concessa da una regola del firewall.

Consentire NTP esterno con una regola firewall

Dopo la regola NAT è necessaria una regola firewall adeguata. Ciò consente il traffico NTP dalle reti interne al server di destinazione. Il percorso del menu è:

Rules and policies > Firewall rules

Procedura:

1. Selezionare Add firewall rule > New firewall rule.
2. Impostare Rule name, ad esempio NTP_LAN_to_Google.
3. Impostare Rule position su Top o posizionarla sopra le regole generali LAN-to-WAN se altrimenti verrebbero applicate prima.
4. Attivare Log firewall traffic.
5. Impostare Source zones sulle zone interne, ad esempio la zona LAN interna, DMZ o una zona IoT. WAN e Any non sono corretti per questo modello.
6. Impostare Source networks and devices sulle reti o sui dispositivi interessati. Non usare genericamente Any se solo alcune reti devono usare NTP.
7. Impostare Destination zones su WAN.
8. Impostare Destination networks su un oggetto host IPv4 per l’IP del firewall o del gateway usato dai client come destinazione NTP, per esempio host_internal-firewall-ip. Se non esiste, crearlo in Hosts and services > IP host > Add, con Type: IP e quell’esatto indirizzo IP. Deve corrispondere a Original destination della regola DNAT dei client, non all’host NTP esterno.
9. Impostare Services su NTP.
10. Impostare Action su Accept.
11. Salvare.

Negli esempi ufficiali o semplificati, Source networks and devices viene talvolta mostrato come Any. In laboratorio è comodo, ma in produzione raramente è la scelta migliore. È più pulito usare un oggetto di rete concreto come net_Internet-LAN, IOT_NET o un piccolo gruppo di host, così resta chiaro quali dispositivi possono usare questo inoltro NTP.

Per il DNAT in ingresso, Sophos determina prima la destinazione tradotta. Destination zones usa la sua zona, qui WAN; Destination networks usa invece la destinazione originale, qui l’IP del firewall o del gateway. Il vero server orario rimane solo in Translated destination (DNAT). L’esempio NTP generico di Sophos non specifica Destination networks; questa distinzione segue i suoi esempi espliciti di DNAT e loopback. Dopo una modifica, avviare una nuova sessione NTP dal client: le sessioni esistenti non vengono rivalutate con le regole NAT modificate. Prima di approvare la configurazione, controllare Firewall Rule ID, NAT Rule ID e il percorso dei pacchetti in ingresso e inoltrati come descritto nella sezione di test; la sola configurazione non dimostra che la sincronizzazione sia riuscita.

La registrazione del traffico di questa regola è utile durante la messa in servizio. Dopo il test si dovrebbe poter vedere nel Log Viewer da quale rete client proviene la richiesta, quale Firewall Rule ID è stato utilizzato e se è visibile anche il NAT Rule ID previsto. Se non viene visualizzato alcun ID regola o viene visualizzata la regola sbagliata, l’ordine o la corrispondenza della regola è più importante della configurazione NTP stessa.

Per la struttura delle regole, la sequenza, Services e la registrazione, è adatto anche Comprensione e configurazione corretta delle regole Sophos Firewall.

Variante B: utilizzare il server NTP interno

Questa variante è adatta se un controller di dominio interno, un server temporale Linux o un altro sistema interno deve essere la fonte dell’ora per i client, ma i client continuano a utilizzare l’IP del firewall come server NTP.

Qui si verificano due percorsi di traffico con le rispettive coppie di regole; le regole esistenti adeguate possono essere riutilizzate:

Creare un host per il server NTP interno

Il percorso del menu è:

Hosts and services > IP host

Procedura:

1. Selezionare Add.
2. Impostare Name, ad esempio NTP_Server_Internal.
3. Impostare IP version su IPv4 se si utilizza IPv4.
4. Impostare Type su IP.
5. Immettere IP address del server NTP interno, nell’esempio 192.168.20.10.
6. Salvare.

Coppia di regole 1: il server NTP interno si sincronizza esternamente

Innanzitutto, il server NTP interno deve essere in grado di raggiungere un server temporale esterno se non è già sincronizzato altrove. La sorgente temporale upstream configurata deve essere il vero server temporale, non l’IP del gateway usato come relay. Il traffico può essere reindirizzato al server stesso solo se corrisponde anche a una regola DNAT di relay che ha quel server come destinazione tradotta. Nell’esempio precedente, la rete sorgente e l’interfaccia di ingresso impediscono questa corrispondenza con la regola DNAT dei client; l’IP del gateway scelto erroneamente potrebbe quindi non fornire un’ora utilizzabile.

Regola NAT:

1. Aprire Rules and policies > NAT rules.
2. Selezionare Add NAT rule > New NAT rule.
3. Impostare Rule name, ad esempio SNAT_Internal_NTP_to_WAN.
4. Impostare Rule position su Top o posizionarla in modo appropriato sopra regole NAT ampie.
5. In Original source, selezionare l’oggetto host NTP_Server_Internal creato in precedenza.
6. Impostare Original destination sulla sorgente temporale esterna prevista, nell’esempio host_Google-NTP.
7. Per Original service, rimuovere Any e selezionare NTP.
8. Per Translated source (SNAT) selezionare MASQ; Translated destination (DNAT) e Translated service (PAT) restano su Original.
9. Impostare Inbound interface sull’ingresso del server interno, nell’esempio Port3; limitare Outbound interface all’interfaccia WAN effettivamente usata. In presenza di più connessioni WAN, considerare tutte le uscite previste.
10. Salvare.

Regola del firewall:

1. Aprire Rules and policies > Firewall rules.
2. Selezionare Add firewall rule > New firewall rule.
3. Impostare Rule name, ad esempio Internal_NTP_to_WAN.
4. Attivare Log firewall traffic.
5. Impostare Source zones sulla zona del server NTP interno, nell’esempio DMZ.
6. Impostare Source networks and devices su NTP_Server_Internal.
7. Impostare Destination zones su WAN.
8. Impostare Destination networks sulla stessa sorgente temporale esterna della regola SNAT, nell’esempio host_Google-NTP. Qui non viene applicato DNAT; la destinazione originale e quella effettiva coincidono.
9. Impostare Services su NTP e Action su Accept.
10. Posizionare la regola sopra le regole generali che altrimenti verrebbero applicate per prime e salvare.

Coppia di regole 2: indirizzare i client al server NTP interno tramite IP del firewall

Viene quindi creato l’inoltro vero e proprio: i client inviano NTP all’IP del firewall, il firewall inoltra al server interno NTP.

Regola NAT:

1. Aprire Rules and policies > NAT rules.
2. Selezionare Add NAT rule > New NAT rule.
3. Impostare Rule name, ad esempio DNAT_Client_NTP_to_Internal.
4. Impostare Rule position su Top o sopra le regole NAT generali.
5. Impostare Original source sulle reti client interne interessate, nell’esempio net_Internet-LAN.
6. Impostare Original destination sull’IP del firewall o gateway usato dai client come destinazione NTP, nell’esempio host_internal-firewall-ip.
7. Per Original service, rimuovere Any e selezionare NTP.
8. Per Translated source (SNAT), selezionare MASQ.
9. Per Translated destination (DNAT) selezionare NTP_Server_Internal.
10. Per Inbound interface, selezionare le interfacce interne dei client interessate, nell’esempio Port2.
11. Lasciare Translated service (PAT) su Original; per questa regola DNAT, Outbound interface resta su Any.
12. Salvare.

Anche qui Original destination è decisiva: la regola deve tradurre solo richieste NTP indirizzate all’IP del firewall o gateway. Se questo campo resta troppo ampio, il firewall può catturare anche richieste NTP che i client volevano inviare direttamente a un altro server temporale.

Regola del firewall:

1. Aprire Rules and policies > Firewall rules.
2. Selezionare Add firewall rule > New firewall rule.
3. Impostare Rule name, ad esempio LAN_to_Internal_NTP.
4. Attivare Log firewall traffic.
5. Impostare Source zones sulle zone client interne. Evitare WAN e Any.
6. Impostare Source networks and devices sulle reti client interessate.
7. Impostare Destination zones sulla zona del server NTP interno, ad esempio la zona LAN interna o DMZ.
8. Impostare Destination networks sull’oggetto host IPv4 dell’IP del firewall o del gateway contattato originariamente, per esempio host_internal-firewall-ip, come in Original destination della regola DNAT dei client. Non selezionare NTP_Server_Internal; quell’host rimane in Translated destination (DNAT).
9. Impostare Services su NTP.
10. Impostare Action su Accept. Posizionare la regola sopra le regole generali che altrimenti verrebbero applicate per prime e salvare. Anche qui Destination zones corrisponde alla destinazione interna tradotta, mentre Destination networks contiene l’IP originale del firewall o del gateway. Verificare separatamente una nuova sessione client, gli ID delle regole e il percorso dei pacchetti per questa coppia di regole. MASQ garantisce il ritorno attraverso il firewall, ma nasconde al server NTP l’IP originale del client. Se quell’indirizzo serve per log o controllo accessi, usare un accesso diretto con una rotta di ritorno adeguata.

Se il server NTP interno stesso è un controller di dominio, occorre limitarne l’accesso con particolare attenzione. Non tutte le reti client devono raggiungere direttamente tutti i controller di dominio. NTP può essere consentito senza aprire accessi al controller di dominio altrettanto ampi.

Operazioni, sicurezza e test

Valutare IPS e funzionalità di sicurezza

NTP è tecnicamente un piccolo servizio UDP, ma nella pratica UDP 123 diventa rilevante anche per abusi, configurazioni errate o target esterni indesiderati. Se è disponibile una licenza Network Protection, può essere sensata una policy IPS adeguata sulla regola del firewall.

Più importante del maggior numero possibile di funzionalità di sicurezza con il NTP è un design rigoroso:

• Source Zone solo interna: impedisce al firewall di agire come un relay NTP pubblico.
• Reti sorgente specifiche: limita NTP a client, server o dispositivi che necessitano realmente di questo inoltro.
• Definire il server di destinazione: limita il traffico che corrisponde a questa regola di relay al server temporale definito e facilita l’analisi dei registri.
• Solo servizio NTP: evita una regola UDP troppo ampia.
• Attivare la registrazione: mostra in Log Viewer se Firewall Rule ID e NAT Rule ID funzionano come previsto.

L’IPS dovrebbe quindi essere visto come un controllo aggiuntivo, non come un sostituto di una regola pulita. Se la regola NTP consente solo poche reti interne a un time server definito, il guadagno di sicurezza più importante si ottiene già attraverso l’ambito e la tracciabilità. Quando sono coinvolti molti segmenti di rete, dispositivi poco chiari o aree IoT/OT, una politica IPS mirata diventa più interessante.

Se si utilizza IPS su questa regola NTP, la policy IPS assegnata deve includere esplicitamente firme relative a NTP (IPS patterns). In questo modo, la protezione aggiuntiva si concentra sugli attacchi contro i servizi NTP; definire una policy genericamente adeguata non sostituisce la selezione di queste firme.

⚠️ IPS richiede una licenza di protezione della rete adeguata. Se IPS è abilitato su una regola molto utilizzata, i registri e le prestazioni dovrebbero essere monitorati. Per il semplice inoltro NTP, un ambito pulito è più importante di una combinazione inutilmente ampia di funzionalità di sicurezza.

Se a questo scopo viene utilizzata una policy IPS dedicata, non dovrebbe essere copiata in modo trasversale su tutte le reti interne. Ha più senso avere una piccola regola con una sorgente chiara, un target NTP definito, registrazione attiva e successivo controllo nel Log Viewer.

Altre funzionalità di sicurezza dovrebbero essere trattate deliberatamente con cautela con NTP. Per questo semplice servizio UDP, Web Filtering, TLS Inspection, Application Control o Malware Scan di solito non aiutano con la funzione NTP effettiva. Se tali profili sono attivi su una regola collettiva, dovrebbe essere verificato se NTP sarebbe meglio posizionato nella propria, piccola regola.

Distribuire NTP tramite DHCP

Se i client ricevono la configurazione di rete tramite DHCP, verificare se è necessario un inoltro NAT. Per molti ambienti è più pulito distribuire il server NTP desiderato direttamente tramite DHCP.

Se è presente un controller di dominio o un server temporale centrale, l’opzione DHCP 42 può puntare direttamente a questo server, purché il client supporti e usi effettivamente tale opzione. I membri di dominio possono invece seguire la gerarchia temporale del dominio; occorre quindi verificare sul client la sorgente temporale effettiva. NAT è particolarmente utile se i dispositivi utilizzano già IP del gateway o sono difficili da riconfigurare. Per le opzioni speciali DHCP, Configurare le opzioni DHCP su Sophos Firewall è un inizio migliore.

Configurare separatamente il firewall come client NTP

Il relay dei client non equivale alla configurazione dell’ora di sistema di Sophos Firewall. In SFOS 22.0, Administration > Time offre tre impostazioni:

Configurazione attuale invariata dell’orologio del firewall: Use pre-defined NTP server, Europe/Zurich. È separata dal relay client e non prova una sincronizzazione riuscita; Sync now e Apply non sono stati usati.

• Use predefined NTP server è l’impostazione predefinita. Il firewall usa NTPv3 e 0.sophos.pool.ntp.org.
• Use custom NTP server accetta indirizzi IPv4, IPv6 o DNS; fino a dieci server vengono verificati nell’ordine mostrato.
• Do not use NTP server imposta data e ora manualmente e non è consigliato per il normale esercizio.

Dopo aver selezionato i server, si può scegliere Sync now e poi Apply. Dopo Sync now, Current time si aggiorna solo quando si ricarica WebAdmin. Nella stessa pagina si imposta il fuso orario appropriato per la sede.

⚠️ Impatto VPN: secondo Sophos, la modifica dei server temporali NTP causa la riconnessione di tutte le connessioni IPsec. Pianificarla in una finestra di manutenzione.

Controllare separatamente i due flussi:

• Tempo del sistema firewall: rilevante per Log Viewer, certificati, MFA, VPN, autenticazione WAF, report, Syslog e analisi di supporto.
• Client-NTP tramite NAT: I dispositivi nella rete interna ricevono l’ora tramite IP del gateway o un indirizzo NTP reindirizzato.

Se il firewall stesso ha un orario o un fuso orario non corretti, le voci di registro potrebbero essere difficili da correlare, i controlli dei certificati potrebbero fallire o l’autenticazione basata sull’orario come TOTP/MFA potrebbe causare problemi. Quindi è necessario correggere prima l’ora di sistema del firewall e verificare che il firewall stesso possa raggiungere la propria sorgente temporale NTP. Solo allora ha senso convalidare il client NTP tramite NAT.

Per gli ambienti SIEM o Syslog, questo punto è particolarmente importante: il firewall può instradare correttamente il traffico NTP e inviare comunque timestamp errati a SIEM se la sua ora o fuso orario non è corretto.

Per l’inoltro dei registri, è adatto Inviare Syslog di Sophos Firewall a un SIEM. Per i problemi MFA, dovrebbe essere incluso anche Abilitare MFA per WebAdmin, VPN Portal e Remote Access di Sophos Firewall.

Testare NTP e isolare gli errori

Dopo il salvataggio, non si dovrebbe solo controllare se la regola esiste. Ciò che è fondamentale è se un client può realmente sincronizzare NTP e se vengono rispettate le regole NAT e firewall previste.

Il test inizia allo stesso modo per entrambe le varianti: un client della rete interessata utilizza il firewall o IP del gateway come server NTP. Successivamente viene avviata una sincronizzazione dell’ora oppure viene eseguita una breve attesa finché il client non invia NTP.

Aprire Log viewer nell’angolo in alto a destra di WebAdmin. Nel modulo Firewall, Add filter consente di filtrare per regola, IP o porta; in alternativa, la ricerca libera trova 123, l’IP del client o il nome della regola. I log di sessione non compaiono necessariamente subito: il firewall registra la sessione all’evento interno Destroy. Per UDP può essere necessario attendere la fine della sessione; UDP non prevede una chiusura della connessione come TCP.

Con la variante A dovrebbe essere visibile:

• Il client proviene dalla rete interna prevista.
• La regola firewall prevista per NTP esterno viene applicata.
• La regola DNAT corrisponde alla fonte temporale esterna.
• L’obiettivo è il server NTP esterno pianificato.

Due cose dovrebbero essere controllate per la variante B:

• Il server NTP interno può inviare NTP esternamente.
• I client vengono instradati tramite DNAT dall’IP del firewall al server NTP interno.

Se Log Viewer non indica chiaramente quale regola viene applicata, usare Diagnostics > Packet capture. In Configure, l’espressione BPF port 123 limita la cattura a NTP. Dopo aver attivato Packet capture, il pacchetto in ingresso deve mostrare l’IP del client, l’IP del firewall e UDP 123; quello inoltrato mostra la destinazione tradotta. NAT ID e Rule ID devono corrispondere alle regole create. Incoming e Forwarded confermano il percorso; Consumed indica invece un pacchetto destinato al firewall stesso, mentre Violation e Reason spiegano uno scarto.

Il solo inoltro riuscito non conferma ancora la sincronizzazione dell’ora. Anche lo stato NTP sul client deve mostrare una risposta valida e uno stato sincronizzato; nella variante B si verifica anche lo stato di sincronizzazione del server temporale interno. Nella cattura dei pacchetti ci si aspetta una risposta dal vero server temporale e, sul percorso di ritorno al client, l’IP del gateway contattato di nuovo come mittente. Se manca la risposta, verificare prima la raggiungibilità, il percorso di ritorno e il controllo accessi del server temporale per l’indirizzo MASQ.

Come test negativo, un client di una rete interna non autorizzata invia una nuova richiesta NTP all’IP del gateway. La regola DNAT dei client creata e la relativa autorizzazione non devono corrispondere a questa richiesta. Se la richiesta viene comunque inoltrata, cercare una regola NAT/firewall precedente o più ampia. Anche una richiesta di un client autorizzato diretta a un altro indirizzo NTP non deve essere reindirizzata da questa regola DNAT per l’IP del gateway. La restante policy del firewall determina se NTP diretto è consentito o bloccato; questo relay da solo non impone una sorgente temporale centrale per tutto il traffico.

Se non sono visibili registri, il client potrebbe non inviare affatto la richiesta, la regola del firewall non registra o il traffico prende un percorso diverso. Verifica regola firewall con Log Viewer, Policy Test e Packet Capture è adatto per il controllo sistematico.

Per problemi NTP specifici del firewall, è rilevante anche il registro del client NTP. La panoramica del registro si trova in Risoluzione dei problemi di Sophos Firewall: servizi e log.

Verifica finale

Prima della messa in produzione, verificare cinque punti:

1. I client utilizzano effettivamente il firewall o IP del gateway come server NTP.
2. Le regole NTP consentono solo le reti di origine interne previste.
3. I Firewall Rule ID e NAT Rule ID previsti sono visibili in Log Viewer.
4. L’ora del sistema firewall è corretta separatamente.
5. Dopo DHCP, VLAN, NAT o modifiche alle regole, NTP verrà nuovamente testato.

Errori tipici

• WAN consentito come Source Zone: il firewall può agire involontariamente come un relay NTP aperto. Limitare le zone di origine alle zone interne.
• Any per origine e destinazione: La regola è difficile da controllare. Definire in modo specifico le reti di origine e i server di destinazione.
• Regola NAT presente, ma nessuna regola firewall: Il traffico viene tradotto ma non consentito. Controllare Log Viewer per ID regola e ID NAT.
• Regola del firewall senza registrazione: L’analisi degli errori diventa inutilmente difficile. Attivare Log firewall traffic almeno durante il test.
• La destinazione FQDN non viene risolta: la destinazione DNAT non viene raggiunta. Controllare la risoluzione DNS del firewall.
• Il client utilizza un altro server NTP: La regola non viene mai soddisfatta. Controllare la configurazione del client o l’opzione DHCP.
• Il server temporale non risponde: il client rimane non sincronizzato. Controllare il server di destinazione, il routing e UDP 123.

Rollback

Se il relay causa problemi, disattivare prima la nuova regola DNAT dei client e avviare un nuovo test NTP, quindi disattivare la relativa regola firewall. Nella variante B, rimuovere le regole SNAT e firewall verso WAN del server interno solo se non servono più alla sua sincronizzazione. Eliminare le regole e gli oggetti host creati esclusivamente per questo relay solo dopo aver confermato che non vi sono più corrispondenze né dipendenze. Infine assegnare ai client un server NTP direttamente raggiungibile, per esempio tramite l’opzione DHCP 42; altrimenti perderanno la loro sorgente dell’ora.

Domande frequenti