Sophos Firewall come server NTP: inoltrare NTP tramite NAT

In molte reti, client, server, switch, punti di accesso o dispositivi speciali dovrebbero semplicemente utilizzare il Gateway-IP come server temporale. In questo scenario, tuttavia, non esiste un server NTP interno completo in esecuzione su Sophos Firewall, che a sua volta fornisce l’ora ai client.

La soluzione pratica è un inoltro NTP tramite NAT. I dispositivi inviano NTP al firewall IP e Sophos Firewall inoltra queste richieste a un server temporale reale esterno o interno.

Ciò è particolarmente utile se i dispositivi sono configurati in modo permanente su Gateway-IP, 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 Sophos Firewall Configura opzioni DHCP.

⚠️ 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 il firewall IP come server NTP, il firewall inoltra a un server NTP esterno.
• Variante B: I dispositivi interni utilizzano il firewall IP come server NTP, il firewall inoltra a un server NTP interno. Inoltre, è necessario consentire la sincronizzazione esterna del server NTP interno.

La seconda variante necessita quindi di due regole NAT e due regole firewall. Questo è il punto che manca in molte brevi note su questo argomento.

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 Gateway-IP?
• 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? L’ora corretta è importante per le funzioni critiche in termini di tempo come l’autenticazione MFA, WAF, i certificati, i registri, la correlazione VPN e SIEM. Se il firewall stesso ha un orario errato, è necessario controllare l’orario del sistema prima di reindirizzare Client-NTP.

I passaggi di questo articolo si basano su Sophos Firewall 22.0. I percorsi di menu e i nomi dei campi possono differire leggermente nelle versioni SFOS più vecchie o più recenti. La configurazione va eseguita nell’interfaccia WebAdmin di Sophos Firewall o in un’automazione API/CLI controllata con attenzione. In Sophos Central, questo set di regole NAT e firewall normalmente non viene gestito come configurazione NTP relay autonoma.

Gli esempi sono descritti volutamente come configurazione IPv4, perché anche Sophos mostra la creazione dell’host nella guida ufficiale con IP version: IPv4. 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. Il campo critico è Original destination: deve puntare all’IP del firewall o gateway.

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.

Variante A: utilizzare un server NTP esterno

Questa variante è adatta se i client devono utilizzare il firewall IP come server NTP e non esiste un proprio time server interno. Il firewall traduce la richiesta NTP in un server temporale esterno, ad esempio 1.sophos.pool.ntp.org, time.google.com o in un server temporale del provider scelto deliberatamente.

Crea host FQDN per il server NTP esterno

Il percorso del menu è:

Hosts and services > FQDN host

Procedura:

1. Selezionare Add.
2. Assegnare Nome, ad esempio NTP_1_sophos_pool.
3. Immettere il server NTP esterno in FQDN, ad esempio 1.sophos.pool.ntp.org.
4. Salva.

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.

Crea la regola NAT per il server NTP esterno

La regola NAT garantisce che le richieste NTP al firewall IP vengano riscritte sul 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. Imposta Rule position su Top o posizionalo sopra le regole generali di NAT.
4. Impostare Original source sulla rete interna interessata, ad esempio LAN_NET o IOT_NET.
5. Impostare Original destination sul firewall o Gateway-IP che i client utilizzano come server NTP.
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, selezionare l’interfaccia interna o le interfacce interne interessate.
10. Salva.

    

⚠️ 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 Gateway-IP, 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 una versione del firewall.

Consenti regola firewall per NTP esterno

Secondo 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 LAN_to_External_NTP.
3. Impostare Rule position su Top o posizionarla sopra le regole generali LAN-to-WAN se altrimenti verrebbero applicate prima.
4. Attiva Log firewall traffic.
5. Impostare Source zones sulle zone interne, ad esempio LAN, 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 un Any generale se solo alcune reti dovessero utilizzare NTP.
7. Impostare Destination zones su WAN.
8. Impostare Services su NTP.
9. Impostare Action su Accept.
10. Salva.

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 LAN_NET, IOT_NET o un piccolo gruppo di host, così resta chiaro quali dispositivi possono usare questo inoltro NTP.

La regola è limitata principalmente tramite Source Zone, Source Network, servizio, posizione della regola e target NAT. Se si deve utilizzare anche Destination networks, è necessario verificare l’effetto in Log Viewer, poiché le regole DNAT possono modificare l’indirizzo di destinazione visibile nell’analisi.

L’accesso a questa regola è utile per l’introduzione. Dopo il test dovresti essere in grado di 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 il firewall IP come server NTP.

Qui sono necessarie due coppie di regole:

Crea host per il server NTP interno

Il percorso del menu è:

Hosts and services

Procedura:

1. Selezionare Add.
2. Impostare Nome, 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.
6. Salva.

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.

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. Impostare Original source per ospitare NTP_Server_Internal.
6. Per Original service, rimuovere Any e selezionare NTP.
7. Per Translated source (SNAT) selezionare MASQ.
8. Salva.

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. Attiva Log firewall traffic.
5. Impostare Source zones sulla zona del server NTP interno, ad esempio LAN.
6. Impostare Source networks and devices su NTP_Server_Internal.
7. Impostare Destination zones su WAN.
8. Impostare Services su NTP.
9. Salva.

Coppia di regole 2: guida i client al server NTP interno tramite firewall-IP

Viene quindi creato l’inoltro vero e proprio: i client inviano NTP al firewall-IP, 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. Posiziona Rule position sopra le regole generali NAT.
5. Impostare Original source sulle reti client interne interessate.
6. Impostare Original destination sul firewall o Gateway-IP che i client utilizzano come destinazione NTP.
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. Salva.

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. Attiva Log firewall traffic.
5. Impostare Source zones sulle zone client interne. Evita 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 LAN o DMZ.
8. Impostare Services su NTP.
9. Salva. Se è impostata anche una Rete di destinazione, è necessario verificare in modo specifico se la regola firewall continua a corrispondere secondo DNAT. Per l’accettazione iniziale, la rete di origine, la zona di destinazione, il servizio, la regola NAT e Log Viewer sono solitamente i punti di controllo più chiari.

Se il server NTP interno stesso è un controller di dominio, è necessario eseguire l’ambito 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

Classificare 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 interno: impedisce al firewall di agire come un relè pubblico NTP.
• Reti di origine in particolare: limita NTP a client, server o dispositivi che necessitano realmente di questo inoltro.
• Imposta Destination Server: impedisce qualsiasi server temporale esterno e rende i registri valutabili.
• Solo servizio NTP: evita una regola UDP troppo ampia.
• Attiva 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 coinvolte un gran numero di reti, dispositivi poco chiari o aree IoT/OT, una politica IPS mirata diventa più interessante.

⚠️ 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.

Distribuisci NTP in modo pulito con 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. NAT è particolarmente utile se i dispositivi utilizzano già Gateway-IP o sono difficili da riconfigurare. Per le opzioni speciali DHCP, Sophos Firewall Configura opzioni DHCP è un inizio migliore.

Controllare separatamente l’ora del sistema firewall

Il reindirizzamento del client NTP non è uguale all’ora di sistema Sophos Firewall. Entrambi dovrebbero essere controllati separatamente:

• 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 Gateway-IP 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 del sistema firewall e l’accesso NTP al firewall. 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 Invia Sophos Firewall Syslog a SIEM. Per i problemi MFA, dovrebbe essere incluso anche MFA per Sophos Firewall WebAdmin, VPN Abilita portale e accesso remoto.

Testare NTP e isolare gli errori

Dopo il salvataggio, non dovresti 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 Gateway-IP come server NTP. Successivamente viene avviata una sincronizzazione dell’ora oppure viene eseguita una breve attesa finché il client non invia NTP.

In Log Viewer si filtra per servizio NTP o UDP 123.

Con la variante A dovrebbe essere visibile:

• Il client proviene dalla rete interna prevista.
• La regola firewall NTP per gli hit NTP esterni.
• 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 dal firewall-IP al server NTP interno. Se Log Viewer non mostra chiaramente quale regola si applica, Diagnostics > Cattura pacchetti sarà di aiuto. Lì dovresti verificare se i pacchetti dal client a UDP 123 arrivano sul firewall e se i pacchetti continuano poi al server temporale esterno o interno previsto.

Se non sono visibili registri, la richiesta non può essere inviata al client, 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 Sophos Firewall Risoluzione dei problemi: Services e registri.

Accettazione breve

Prima del completamento produttivo, cinque punti dovrebbero essere corretti:

1. I client utilizzano effettivamente il firewall o Gateway-IP 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 relè NTP aperto. Limita 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 è stata raggiunta. Controlla 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.

Domande frequenti