Sophos Firewall som NTP-relä via NAT

När interna enheter måste använda gatewayens IP-adress som NTP-mål kan Sophos Firewall vidarebefordra deras förfrågningar till en tidsserver via NAT. Inställningen under Administration > Time synkroniserar däremot bara brandväggens egen klocka; den tillhandahåller ingen NTP-servertjänst för klienterna.

Sophos dokumenterade lösning är ett NTP-relä via NAT. Enheter skickar NTP till brandväggens IP-adress, och Sophos Firewall översätter destination och källa och vidarebefordrar paketen till en riktig extern eller intern tidsserver. Brandväggen blir inte tidskällan. Separat fungerar den som NTP-klient för sin egen klocka.

Detta är särskilt användbart om enheter är permanent konfigurerade till gatewayens IP-adress, om en tidigare UTM-miljö har ersatts eller när man vill styra NTP-mål centralt. Vid ny DHCP-planering är det ofta tydligare att distribuera rätt tidsserver direkt via en DHCP-option. Grunderna finns i Konfigurera DHCP-optioner på Sophos Firewall.

⚠️ Viktigt: Sophos Firewall bör inte tillhandahålla en öppen NTP-tjänst till Internet. Källzoner, källnätverk, målservrar och brandväggsregler måste begränsas medvetet. WAN som Source Zone är vanligtvis felaktigt för detta mönster.

Vilken variant är lämplig?

NTP via NAT är ett pragmatiskt mönster, men inte alltid den bästa arkitekturen.

Två varianter är viktiga för den här artikeln:

• Variant A: Interna enheter använder brandväggens IP-adress som NTP-server, brandväggen vidarebefordrar till en extern NTP-server.
• Variant B: Interna enheter använder brandväggens IP-adress som NTP-server, brandväggen vidarebefordrar till en intern NTP-server. Dessutom måste den interna NTP-servern tillåtas att synkronisera externt.

Den andra varianten har därför två separata trafikflöden. Om den interna tidsserverns externa synkronisering redan tillåts och översätts på lämpligt sätt kontrollerar och återanvänder man det befintliga regelparet; ytterligare identiska regler behövs inte.

Förutsättningar

Före konfigurering bör dessa punkter vara tydliga:

• Vilka interna nätverk får använda NTP?
• Vilken IP-adress använder klienter som NTP-destination, till exempel gatewayens IP-adress?
• Vilken riktig NTP-server ska användas?
• Ska en intern tidsserver eller en extern tjänst som time.google.com eller pool.ntp.org användas?
• Kan brandväggen på ett tillförlitligt sätt lösa DNS för FQDN-mål?
• Är brandväggens egen systemtid korrekt synkroniserad?

Ett genomgående IPv4-exempel visar hur värdena hör ihop:

• net_Internet-LAN: 10.10.11.0/24, klienternas inkommande gränssnitt Port2 i zonen för det interna klientnätverket.
• host_internal-firewall-ip: värden 10.10.11.1, den brandväggsadress som dessa klienter använder.
• host_Google-NTP: FQDN time.google.com för variant A och vid behov som extern tidskälla för den interna servern.
• NTP_Server_Internal: värden 192.168.20.10, nåbar via Port3 i zonen DMZ, för variant B.

Dessa privata adresser, objektnamn och gränssnitt är exempel och ersätts med de faktiska värdena. Man väljer bara de nätverk som behöver reläet och deras faktiska inkommande gränssnitt; vid behov läggs en separat, lika snävt avgränsad regel till för IOT_NET. Nätverks- och värdobjekten skapas under Hosts and services > IP host. För flera gatewayadresser måste de tillhörande källnätverken, inkommande gränssnitten och destinationsadresserna stämma överens. Före ändringar dokumenterar man befintliga NAT- och brandväggsregler, deras ordning och klienternas tidskälla. Den riktiga tidsservern måste vara nåbar och acceptera förfrågningar från den brandväggsadress som MASQ använder.

Korrekt tid är viktigt för tidskritiska funktioner som MFA, WAF-autentisering, certifikat, loggar, VPN och SIEM-korrelation. Om själva brandväggen har felaktig tid, bör systemtiden kontrolleras först innan klienternas NTP-trafik omdirigeras.

Följande steg gäller Sophos Firewall 22.0. Brandväggens NTP-inställningar kan inte synkroniseras från Sophos Fusion (tidigare Sophos Central); de hanteras i WebAdmin, via CLI eller API. NAT- och brandväggsstegen nedan använder WebAdmin.

Exemplen använder avsiktligt en IPv4-konfiguration, med IP version: IPv4 valt när värden skapas. I IPv6- eller dual-stack-miljöer bör detta mönster inte bara kopieras. Först måste det klargöras om klienter verkligen behöver NTP över IPv6, vilka brandväggs- och NAT-funktioner som gäller i den använda SFOS-versionen och om DHCPv6, Router Advertisements eller en direkt intern tidsserver är den renare lösningen.

Snabbreferens

För erfarna administratörer är kortlogiken enkel: klienter skickar UDP 123 till brandväggens eller gatewayns IP. En DNAT-regel skriver om destinationen till den verkliga NTP-servern, en brandväggsregel tillåter exakt denna trafik och Log Viewer bekräftar sedan Firewall Rule ID och NAT Rule ID.

Extern NTP-server: en DNAT-regel vidarebefordrar NTP från brandväggens IP till FQDN- eller värdobjektet för den externa NTP-servern. En brandväggsregel tillåter NTP från de berörda interna källorna mot WAN. I sitt allmänna reläexempel lämnar Sophos Original destination som Any. För reläet via gatewayens IP-adress som beskrivs här begränsas fältet till exakt den brandväggs-IP som klienterna använder. Då styrs inte direkta NTP-förfrågningar till andra servrar om i tysthet.

Intern NTP-server: två flöden krävs. Först måste den interna NTP-servern kunna synkronisera externt via SNAT/MASQ. Sedan vidarebefordrar en DNAT-regel klientförfrågningar från brandväggens IP till den interna NTP-servern. Båda regelparen bör kontrolleras separat i Log Viewer.

Vid första implementeringen bör regelpositionen medvetet vara hög, vanligtvis Top eller ovanför breda LAN-to-WAN- och allmänna NAT-regler. Därefter kan positionen placeras in i det befintliga regelkonceptet, så länge Log Viewer och Packet Capture fortfarande visar att den förväntade regeln matchar först.

host_internal-firewall-ip innehåller Sophos Firewalls interna LAN-IP-adress, här 10.10.11.1. Klienterna använder den adressen som NTP-server. Ersätt exemplet med brandväggens interna LAN-IP i ditt eget klientnätverk och anpassa net_Internet-LAN (10.10.11.0/24), ingångsgränssnittet och källzonen. I den här konfigurationen är klientingången Port2; den interna NTP-servern i variant B nås däremot via Port3 i zonen DMZ. Båda reglerna använder den fördefinierade tjänsten NTP; ingen extra tjänst för enbart UDP krävs. Välj den zon som klientnätverket tillhör i din miljö; ”intern LAN-zon” är en beskrivning, inte ett obligatoriskt zonnamn.

Skapa följande två IPv4-objekt under Hosts and services > IP host > Add och spara varje objekt med Save. Återanvänd lämpliga befintliga objekt om de finns.

Variant A: Använd extern NTP-server

Denna variant är lämplig om klienter ska använda brandväggens IP-adress som NTP-server och det inte finns någon egen intern tidsserver. Brandväggen översätter NTP-förfrågan till en extern tidsserver, till exempel time.google.com eller en avsiktligt vald leverantörstidsserver.

Google Public NTP (time.google.com) använder leap smear. Blanda inte med tidskällor utan leap smear.

Skapa FQDN-värd för extern NTP-server

Menysökvägen är:

Hosts and services > FQDN host

Gör så här:

1. Välj Add.
2. Ange Name, till exempel host_Google-NTP.
3. Ange den externa NTP-servern under FQDN, till exempel time.google.com.
4. Spara.

Om en intern eller extern tidsserver med fast IP-adress används i stället för FQDN kan ett vanligt värdobjekt vara lämpligare. Det är viktigt att målet tydligt kan identifieras senare i NAT- och brandväggsregeln.

Skapa NAT-regel för den externa NTP-servern

NAT-regeln säkerställer att NTP-förfrågningar till brandväggens IP-adress skrivs om till den externa tidsservern. Menysökvägen är:

Rules and policies > NAT rules

Gör så här:

1. Välj Add NAT rule > New NAT rule.
2. Ställ in Rule name, till exempel DNAT_Client_NTP_to_External.
3. Ställ in Rule position på Top eller placera regeln ovanför breda NAT-regler.
4. Ställ in Original source på det berörda interna nätverket, i exemplet net_Internet-LAN (10.10.11.0/24).
5. Ställ in Original destination på host_internal-firewall-ip, i exemplet 10.10.11.1.
6. För Original service, ta bort Any och välj NTP.
7. För Translated source (SNAT) välj MASQ.
8. För Translated destination (DNAT), välj den externa NTP-serverns FQDN-värd eller värdobjekt.
9. Ta bort Any under Inbound interface och välj klienternas faktiska inkommande gränssnitt, i exemplet Port2. Sophos tillåter även Any, men ett uttryckligt val förhindrar matchning på oavsiktliga inkommande gränssnitt.
10. Låt Translated service (PAT) vara Original så att UDP 123 förblir oförändrat. Outbound interface förblir Any för denna DNAT-regel; routningen till den översatta destinationen avgör vilket utgående gränssnitt som används.
11. Spara.

⚠️ Lämna inte Original destination öppen: om Original destination inte begränsas till brandväggens eller gatewayns IP kan regeln få en mycket bredare effekt beroende på den övriga NAT-designen. Då kan inte bara trafik till brandväggens IP vidarebefordras, utan NTP-trafik från nätet kan också styras om transparent. För ett kontrollerat relä ska regeln bara matcha när klienter verkligen använder brandväggens eller gatewayns IP som NTP-destination.

I detaljvyn bör man särskilt kontrollera fyra punkter: Den ursprungliga destinationen måste verkligen vara brandväggens eller gatewayens IP-adress, tjänsten måste förbli begränsad till NTP eller UDP 123, den översatta destinationen måste peka på den planerade tidsservern och SNAT bör passa returvägen.

Om NAT-grunderna eller DNAT-fälten är oklara hjälper Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT. Där förklaras också varför NAT inte ersätter en brandväggsregel.

Tillåt externt NTP med en brandväggsregel

Efter NAT-regeln krävs en lämplig brandväggsregel. Detta tillåter NTP-trafik från de interna nätverken till målservern. Menysökvägen är:

Rules and policies > Firewall rules

Gör så här:

1. Välj Add firewall rule > New firewall rule.
2. Ställ in Rule name, till exempel NTP_LAN_to_Google.
3. Ställ in Rule position på Top eller placera regeln ovanför allmänna LAN-to-WAN-regler om dessa annars skulle matcha först.
4. Aktivera Log firewall traffic.
5. Ställ in Source zones på de interna zonerna, till exempel den interna LAN-zonen, DMZ eller en IoT-zon. WAN och Any är fel för detta mönster.
6. Ställ in Source networks and devices på de berörda nätverken eller enheterna. Inte generellt Any om bara vissa nätverk ska använda NTP.
7. Ställ in Destination zones på WAN.
8. Ställ in Destination networks på ett IPv4-värdobjekt för den IP-adress till brandväggen eller gatewayen som klienterna använder som NTP-destination, till exempel host_internal-firewall-ip. Skapa det vid behov under Hosts and services > IP host > Add, med Type: IP och exakt den IP-adressen. Det måste motsvara Original destination i klienternas DNAT-regel, inte den externa NTP-värden.
9. Ställ in Services på NTP.
10. Ställ in Action på Accept.
11. Spara.

I officiella eller förenklade exempel visas Source networks and devices ibland som Any. Det är bekvämt i labb, men sällan det bästa valet i produktion. Ett konkret nätverksobjekt som net_Internet-LAN, IOT_NET eller en liten värdgrupp gör det senare tydligt vilka enheter som får använda denna NTP-vidarebefordran.

Vid inkommande DNAT fastställer Sophos först den översatta destinationen. Destination zones använder dess zon, här WAN; Destination networks använder däremot den ursprungliga destinationen, här brandväggens eller gatewayens IP-adress. Den riktiga tidsservern anges endast i Translated destination (DNAT). Sophos allmänna NTP-exempel anger inte Destination networks; denna åtskillnad följer de uttryckliga DNAT- och loopback-exemplen. Starta en ny NTP-session från klienten efter en ändring: befintliga sessioner utvärderas inte på nytt mot ändrade NAT-regler. Man kontrollerar Firewall Rule ID, NAT Rule ID och vägen för inkommande och vidarebefordrade paket enligt testavsnittet innan konfigurationen godkänns; konfigurationen i sig bevisar inte att synkroniseringen lyckas.

När det kommer till regeln bör man inte bara vara uppmärksam på funktion, utan också på läsbarhet. Ett namn som NTP_LAN_to_Google eller IOT_to_NTP_internal är senare lättare att förstå än en generisk regel med Any.

Att logga trafiken för den här regeln är användbart vid driftsättningen. Efter testet bör man kunna se i Log Viewer vilket klientnätverk begäran kom från, vilken Firewall Rule ID som användes och om den förväntade NAT Rule ID också är synlig. Om inget regel-ID eller fel regel visas är ordningen eller matchningen av regeln viktigare än själva NTP-konfigurationen.

För regelstruktur, ordningsföljd, Services och loggning passar även Förstå och konfigurera Sophos Firewall-regler korrekt.

Variant B: Använd intern NTP-server

Denna variant är lämplig om en intern domänkontrollant, Linux-tidsserver eller annat internt system ska vara tidskälla för klienter, men klienterna fortsätter att använda brandväggens IP-adress som NTP-server.

Här kontrolleras två trafikflöden med tillhörande regelpar; befintliga regler kan återanvändas om de passar:

Skapa värd för intern NTP-server

Menysökvägen är:

Hosts and services > IP host

Gör så här:

1. Välj Add.
2. Ange Name, till exempel NTP_Server_Internal.
3. Ställ in IP version på IPv4 om IPv4 används.
4. Ställ in Type på IP.
5. Ange IP address för den interna NTP-servern, i exemplet 192.168.20.10.
6. Spara.

Regelpar 1: Intern NTP-server synkroniseras externt

Först måste den interna NTP-servern själv kunna nå en extern tidsserver, om den inte redan synkroniseras på annat sätt. Dess konfigurerade överordnade tidskälla måste vara den riktiga tidsservern, inte den gatewayadress som används som relä. Trafiken kan bara skickas tillbaka till servern själv om den också matchar en relä-DNAT-regel som har denna server som översatt destination. I exemplet ovan förhindrar källnätverket och det inkommande gränssnittet denna matchning mot klienternas DNAT-regel; den felaktigt valda gatewayadressen kan då sakna användbar tidsinformation.

NAT-regel:

1. Öppna Rules and policies > NAT rules.
2. Välj Add NAT rule > New NAT rule.
3. Ställ in Rule name, till exempel SNAT_Internal_NTP_to_WAN.
4. Ställ in Rule position på Top eller placera regeln lämpligt ovanför breda NAT-regler.
5. Ställ in Original source på värden NTP_Server_Internal.
6. Ställ in Original destination på den avsedda externa tidskällan, i exemplet host_Google-NTP.
7. Ta bort Any under Original service och välj NTP.
8. Välj MASQ under Translated source (SNAT); Translated destination (DNAT) och Translated service (PAT) förblir Original.
9. Ställ in Inbound interface på den interna serverns inkommande gränssnitt, i exemplet Port3; begränsa Outbound interface till det WAN-gränssnitt som faktiskt används. Vid flera WAN-anslutningar måste alla avsedda utgående gränssnitt tas med.
10. Spara.

Brandväggsregel:

1. Öppna Rules and policies > Firewall rules.
2. Välj Add firewall rule > New firewall rule.
3. Ställ in Rule name, till exempel Internal_NTP_to_WAN.
4. Aktivera Log firewall traffic.
5. Ställ in Source zones på den interna NTP-serverns zon, i exemplet DMZ.
6. Ställ in Source networks and devices på NTP_Server_Internal.
7. Ställ in Destination zones på WAN.
8. Ställ in Destination networks på samma externa tidskälla som i SNAT-regeln, i exemplet host_Google-NTP. Här används inte DNAT; den ursprungliga och den faktiska destinationen är identiska.
9. Ställ in Services på NTP och Action på Accept.
10. Placera regeln ovanför allmänna regler som annars skulle matcha först och spara.

Regelpar 2: Led klienter till den interna NTP-servern via brandväggens IP-adress

Själva vidarebefordran byggs sedan: klienter skickar NTP till brandväggens IP-adress, brandväggen vidarebefordrar till den interna NTP-servern.

NAT-regel:

1. Öppna Rules and policies > NAT rules.
2. Välj Add NAT rule > New NAT rule.
3. Ställ in Rule name, till exempel DNAT_Client_NTP_to_Internal.
4. Ställ in Rule position på Top eller placera regeln ovanför allmänna NAT-regler.
5. Ställ in Original source på de berörda interna klientnätverken, i exemplet net_Internet-LAN.
6. Ställ in Original destination på den brandväggs- eller gatewayadress som klienterna använder som NTP-mål, i exemplet host_internal-firewall-ip.
7. För Original service, ta bort Any och välj NTP.
8. För Translated source (SNAT), välj MASQ.
9. För Translated destination (DNAT) välj NTP_Server_Internal.
10. Välj de berörda interna klientgränssnitten under Inbound interface, i exemplet Port2.
11. Låt Translated service (PAT) vara Original; Outbound interface förblir Any för denna DNAT-regel.
12. Spara.

Även här är Original destination avgörande: regeln ska bara översätta NTP-förfrågningar som är adresserade till brandväggens eller gatewayns IP. Om detta fält förblir för brett kan brandväggen också fånga NTP-förfrågningar som klienter egentligen ville skicka direkt till en annan tidsserver.

Brandväggsregel:

1. Öppna Rules and policies > Firewall rules.
2. Välj Add firewall rule > New firewall rule.
3. Ställ in Rule name, till exempel LAN_to_Internal_NTP.
4. Aktivera Log firewall traffic.
5. Ställ in Source zones på de interna klientzonerna. Undvik WAN och Any.
6. Ställ in Source networks and devices på de berörda klientnätverken.
7. Ställ in Destination zones på zonen för den interna NTP-servern, till exempel den interna LAN-zonen eller DMZ.
8. Ställ in Destination networks på IPv4-värdobjektet för den ursprungligen adresserade IP-adressen till brandväggen eller gatewayen, till exempel host_internal-firewall-ip, som i Original destination i klienternas DNAT-regel. Välj inte NTP_Server_Internal; den värden anges fortfarande i Translated destination (DNAT).
9. Ställ in Services på NTP.
10. Ställ in Action på Accept. Placera regeln ovanför allmänna regler som annars skulle matcha först och spara.

Även här kommer Destination zones från den översatta interna destinationen, medan Destination networks innehåller brandväggens eller gatewayens ursprungliga IP-adress. Kontrollera en ny klientsession, regel-ID:n och paketvägen separat för detta regelpar. MASQ ser till att svaren går tillbaka genom brandväggen, men döljer klientens ursprungliga IP-adress för den interna NTP-servern. Om tidsservern behöver klientadresser för loggning eller åtkomstkontroll bör man använda direkt åtkomst med en lämplig returväg i stället för detta relämönster.

Om den interna NTP-servern själv är en domänkontrollant bör reglerna avgränsas särskilt noggrant. Alla klientnätverk behöver inte nå varje domänkontrollant direkt. NTP kan tillåtas utan att samtidigt öppna för bred åtkomst till domänkontrollanter.

Drift, säkerhet och testning

Bedöm IPS och säkerhetsfunktioner

NTP är tekniskt sett en liten UDP-tjänst, men UDP 123 blir också relevant i praktiken för missbruk, felkonfiguration eller oönskade externa mål. Om en Network-Protection-licens är tillgänglig kan en lämplig IPS-policy för brandväggsregeln vara vettig.

För NTP är en snävt avgränsad konfiguration viktigare än att aktivera så många säkerhetsfunktioner som möjligt:

• Endast interna källzoner: förhindrar brandväggen från att fungera som ett offentligt NTP-relä.
• Konkreta källnätverk: begränsar NTP till klienter, servrar eller enheter som verkligen behöver denna vidarebefordran.
• Ange destinationsserver: begränsar den trafik som matchar denna reläregel till den angivna tidsservern och gör loggarna lättare att tolka.
• Endast service NTP: undviker en för bred UDP-regel.
• Aktivera loggning: visar i Log Viewer om Firewall Rule ID och NAT Rule ID fungerar som förväntat.

IPS bör därför ses som ytterligare kontroll, inte som en ersättning för en ren regel. Om NTP-regeln bara tillåter ett fåtal interna nätverk till en definierad tidsserver, uppnås redan den viktigaste säkerhetsvinsten genom omfattning och spårbarhet. När ett stort antal nätverk, oklara enheter eller IoT/OT-områden är inblandade blir en riktad IPS-policy mer intressant.

Om IPS används för denna NTP-regel bör den tilldelade IPS-policyn uttryckligen innehålla NTP-relaterade signaturer (IPS patterns). Då riktas det extra skyddet mot angrepp på NTP-tjänster; att beskriva en policy som allmänt lämplig ersätter inte valet av dessa signaturer.

⚠️ IPS kräver en lämplig Network-Protection-licens. Om IPS är aktiverat på en regel som ofta används, bör loggar och prestanda övervakas. För enkel NTP-vidarebefordran är tydlig avgränsning viktigare än en onödigt bred säkerhetsfunktionskombination.

Om en dedikerad IPS-policy används för detta ändamål bör den inte kopieras över hela linjen till alla interna nätverk. Det är mer meningsfullt att ha en liten regel med en tydlig källa, ett definierat NTP-mål, aktiv loggning och efterföljande kontroll i Log Viewer.

Andra säkerhetsfunktioner bör medvetet behandlas försiktigt med NTP. För denna enkla UDP-tjänst hjälper Web Filtering, TLS Inspection, Application Control eller Malware Scan vanligtvis inte med den faktiska NTP-funktionen. Om sådana profiler är aktiva på en kollektiv regel bör det kontrolleras om NTP skulle vara bättre placerad i en egen, liten regel.

Distribuera NTP-inställningar via DHCP

Om klienterna får sin nätverkskonfiguration via DHCP bör man kontrollera om en NAT-vidarebefordran ens är nödvändig. För många miljöer är det renare att distribuera önskad NTP-server direkt via DHCP.

Om det finns en domänkontrollant eller central tidsserver kan DHCP-option 42 peka direkt på denna server, förutsatt att klienten faktiskt stöder och använder optionen. Domänmedlemmar kan i stället följa domänens tidshierarki; därför kontrolleras den aktiva tidskällan på klienten. NAT är särskilt användbart när enheter redan är fast inställda på gatewayens IP-adress eller är svåra att konfigurera om. För särskilda DHCP-alternativ är Konfigurera DHCP-optioner på Sophos Firewall en bättre startpunkt.

Konfigurera brandväggen separat som NTP-klient

NTP-vidarebefordran för klienter är inte samma sak som Sophos Firewalls systemtid. Under Administration > Time finns tre alternativ i SFOS 22.0:

Följande vy visar inställningarna för brandväggens klocka med en fördefinierad NTP-server och tidszonen Europe/Zurich. Den konfigurerar inte klientreläet; lyckad synkronisering kontrolleras separat.

• Use predefined NTP server är standardalternativet. Brandväggen använder NTPv3 och 0.sophos.pool.ntp.org.
• Use custom NTP server accepterar IPv4-, IPv6- eller DNS-adresser; upp till tio servrar kontrolleras i den visade ordningen.
• Do not use NTP server ställer in datum och tid manuellt och rekommenderas inte för löpande drift.

Efter servervalet kan man välja Sync now och därefter Apply. Efter Sync now uppdateras Current time först när WebAdmin laddas om. På samma sida ställs tidszonen in efter platsen.

⚠️ Påverkan på VPN: Enligt Sophos återupprättas alla IPsec-anslutningar när NTP-tidsservrarna ändras. Ändringen bör därför genomföras under ett lämpligt underhållsfönster.

Kontrollera de två trafikflödena separat:

• Brandväggssystemtid: relevant för Log Viewer, certifikat, MFA, VPN, WAF-autentisering, rapporter, Syslog och supportanalys.
• Klient-NTP via NAT: Enheter i det interna nätverket får tid via gatewayens IP-adress eller en omdirigerad NTP-adress.

Om själva brandväggen har en felaktig tid eller tidszon kan loggposter vara svåra att korrelera, certifikatkontroller kan misslyckas eller tidsbaserad autentisering som TOTP/MFA kan orsaka problem. Då bör brandväggens systemtid och brandväggens NTP-åtkomst korrigeras först. Först då är det meningsfullt att validera klient-NTP via NAT.

För SIEM- eller Syslog-miljöer är denna punkt särskilt viktig: brandväggen kan dirigera NTP-trafik korrekt och fortfarande skicka felaktiga tidsstämplar till en SIEM om dess egen tid eller tidszon är felaktig.

För loggvidarebefordran passar skicka Sophos Firewall Syslog till SIEM. Vid MFA-problem bör även aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access tas med.

Testa NTP och isolera fel

Efter att reglerna har sparats bör man inte bara kontrollera att de finns. Avgörande är om en klient verkligen kan synkronisera tiden via NTP och om de förväntade NAT- och brandväggsreglerna matchar.

Testet börjar på samma sätt för båda varianterna: En klient från det berörda nätverket använder brandväggens eller gatewayens IP-adress som NTP-server. Därefter startar man en tidssynkronisering eller väntar en kort stund tills klienten skickar NTP.

Man öppnar Log viewer uppe till höger i WebAdmin. I modulen Firewall kan man filtrera efter regel, IP-adress eller port med Add filter; fritextsökningen kan också hitta 123, klientens IP-adress eller regelnamnet. Sessionsloggar visas inte alltid direkt: brandväggen loggar sessionen vid den interna Destroy-händelsen. För UDP kan man behöva vänta tills sessionen löper ut; UDP har ingen TCP-anslutning som avslutas.

Med variant A ska det synas:

• Klienten kommer från det förväntade interna nätverket.
• Brandväggsregeln för externt NTP matchar.
• Regeln DNAT matchar den externa tidskällan.
• Målet är den planerade externa NTP-servern.

Två saker bör kontrolleras för variant B:

• Den interna NTP-servern får skicka NTP externt.
• Klienterna dirigeras via DNAT från brandväggens IP-adress till den interna NTP-servern.

Om Log Viewer inte tydligt visar vilken regel som matchar används Diagnostics > Packet capture. Under Configure begränsar BPF-uttrycket port 123 inspelningen till NTP. När Packet capture har aktiverats ska det inkommande paketet visa klientens IP-adress, brandväggens IP-adress och UDP 123; det vidarebefordrade paketet visar den översatta destinationen. NAT ID och Rule ID måste motsvara de skapade reglerna. Incoming och Forwarded bekräftar vägen, medan Consumed skulle visa ett paket avsett för själva brandväggen; Violation och Reason förklarar varför ett paket avvisas.

En lyckad vidarebefordran bekräftar inte i sig att tiden synkroniseras. Klientens NTP-status måste dessutom visa ett giltigt svar och ett synkroniserat tillstånd; för variant B kontrolleras även den interna tidsserverns synkroniseringsstatus. I paketfångsten förväntas ett svar från den riktiga tidsservern och, på returvägen till klienten, den adresserade gatewayens IP-adress som avsändare igen. Om svaret saknas kontrolleras först nåbarheten, returvägen och tidsserverns åtkomstkontroll för MASQ-adressen.

Som negativt test skickar en klient från ett internt nätverk som inte är tillåtet en ny NTP-förfrågan till gatewayens IP-adress. Den skapade klient-DNAT-regeln och den tillhörande tillåtande brandväggsregeln får inte matcha denna trafik. Om förfrågan ändå vidarebefordras söker man efter en tidigare eller bredare NAT- eller brandväggsregel. En förfrågan från en tillåten klient direkt till en annan NTP-adress får inte heller styras om av denna DNAT-regel för gatewayadressen. Övriga brandväggspolicyer avgör om direkt NTP tillåts eller blockeras; detta relä tvingar inte i sig all trafik att använda en central tidskälla.

Om inga loggar är synliga kan förfrågan saknas från klienten, brandväggsregeln kanske inte loggar, eller trafiken tar en annan väg. För den systematiska kontrollen passar testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Vid brandväggens egna NTP-problem är även NTP-klientloggen relevant. Loggöversikten finns i Sophos Firewall felsökning: Services och loggar.

Kort slutkontroll

Före avslut i produktionsmiljön bör fem punkter vara uppfyllda:

1. Klienter använder verkligen brandväggens eller gatewayens IP-adress som NTP-server.
2. NTP-reglerna tillåter endast de avsedda interna källnätverken.
3. De förväntade Firewall Rule ID och NAT Rule ID är synliga i Log Viewer.
4. Brandväggssystemets tid är korrekt separat.
5. Efter ändringar av DHCP, VLAN, NAT eller regler testas NTP på nytt.

Vanliga fel

• WAN tillåtet som Source Zone: Brandväggen kan oavsiktligt agera som ett öppet NTP-relä. Begränsa källzoner till interna zoner.
• Any för källa och destination: Regeln är svår att kontrollera. Definiera källnätverk och målservrar specifikt.
• NAT-regeln finns, men ingen brandväggsregel: Trafiken är översatt men inte tillåten. Kontrollera Log Viewer för regel-ID och NAT ID.
• Brandväggsregel utan loggning: Felanalys blir onödigt svårt. Aktivera Log firewall traffic åtminstone under testet.
• FQDN-målet kan inte namnuppslås: DNAT-målet nås inte. Kontrollera brandväggens DNS-upplösning.
• Klienten använder en annan NTP-server: Regeln matchar aldrig. Kontrollera klientkonfigurationen eller DHCP-alternativet.
• Tidsservern svarar inte: Klienten förblir osynkroniserad. Kontrollera destinationsservern, routing och UDP 123.

Återställning

Om reläet orsakar problem, inaktivera först den nya DNAT-regeln för klienterna och starta ett nytt NTP-test; inaktivera sedan den tillhörande brandväggsregeln. I variant B tas den interna serverns SNAT- och WAN-brandväggsregler bort endast om de inte längre behövs för dess egen synkronisering. Radera regler och värdobjekt som skapats enbart för detta relä först när det är bekräftat att inga träffar eller beroenden återstår. Ge därefter klienterna en direkt nåbar NTP-server, till exempel via DHCP-alternativ 42; annars förlorar de sin tidskälla.

Vanliga frågor