Använd Sophos Firewall FQDN hosts och wildcard FQDNs korrekt

FQDN-värdar är användbara när en destination inte kan beskrivas tillförlitligt med en fast IP-adress. Typiska exempel är molntjänster, uppdateringsservrar, autentiseringsslutpunkter eller leverantörstjänster vars IP-adresser kan ändras.

En FQDN-värd är inte en ersättning för en webbpolicy, inte fullständig URL-kontroll och inte en garanti för att varje applikation kommer att matcha rent. Den viktiga frågan är hur Sophos Firewall löser namnet eller, för jokertecken, lär sig det från DNS-trafik.

När FQDN-värdar är vettiga

FQDN-värdar passar regler där en teknisk destination beskrivs bättre med ett DNS-namn än med individuella IP-adresser. Detta är särskilt användbart för utgående trafik.

Användbara exempel:

En intern server får bara ansluta till updates.vendor.example .
En applikation behöver tillgång till ett fåtal kända FQDN:er från leverantörer.
En specifik molnändpunkt måste användas i en brandväggsregel, NAT-regel, SD-WAN-rutt eller VPN-konfiguration.
Ett felsökningsfall måste visa om en regel matchar det förväntade namnet eller en oväntad IP-adress.

FQDN-värdar är mindre lämpliga för bred webbåtkomst som “allt under en SaaS-tjänst” när applikationen använder många domäner, CDN:er, API:er, telemetri och inloggningsslutpunkter. För webbtrafik är webbpolicyer, URL-grupper, DNS-skydd, Application Control eller TLS Inspection ofta det bättre kontrollskiktet.

Sophos Firewall kan använda FQDN-värdar inte bara i firewallregler, utan även i inställningar som SD-WAN policy routes, VPN settings och tekniska värdobjekt för mail-, proxy-, DNS-, autentiserings-, remote access-, webb- eller syslogservrar. Ändå bör man per användning kontrollera om ett DNS-namn verkligen är stabilare än ett IP-objekt eller ett dedikerat policylager.

För själva brandväggsregeln, börja med att förstå och konfigurera Sophos Firewall-regler säkert. Om en regel inte matchar, använd Sophos Firewall-regel matchar inte: kontrollera orsakerna.

Normal FQDN-värd eller jokertecken FQDN

Sophos Firewall hanterar normala FQDN-värdar och jokertecken FQDN:er på olika sätt. Detta är den viktigaste operativa detaljen.

Normal FQDN-värd

För en normal FQDN-värd, som updates.vendor.example , löser brandväggen namnet via DNS. De returnerade IP-adresserna används för objektet. Om DNS-posten har en TTL, uppdaterar brandväggen upplösningen efter att TTL löper ut.

För SFOS 22 gäller en viktig IPv6-begränsning: FQDN-värdobjekt löser inte IPv6-adresser. Det hindrar inte DNS Lookup eller vanliga klienter från att få AAAA-svar, men objektet självt underhåller inte dessa IPv6-mål. IPv6-stöd och begränsningar i Sophos Firewall med SFOS 22 skiljer detta från övriga funktioner som stöds eller inte stöds.

Detta fungerar bra när:

FQDN pekar direkt till de nödvändiga IP-adresserna,
applikationen använder exakt det namnet,
DNS-svaren växlar inte konstant mellan många CDN-mål,
testet använder samma namnupplösning som brandväggen ser.

Jokertecken FQDN

För ett jokertecken FQDN, som *.example.com , löser brandväggen inte bara “alla möjliga underdomäner”. DNS tillhandahåller inte en fullständig lista över alla underdomäner.

Brandväggen lär sig istället matchande IP-adresser från DNS-svar. För detta måste den se de matchande svaren; vid transit-DNS måste dessutom learn-subdomains vara aktiverat. Synlig DNS-trafik i sig garanterar inte att inlärningen lyckas. De dokumenterade inlärningsvägarna är:

Sophos Firewall är DNS-servern för klienterna.
Eller så går DNS-trafik genom brandväggen och detekteras av DPI.
Enligt Sophos gäller denna inlärning UDP DNS-trafik på port 53 till externa DNS-servrar.

Om klienter använder DNS-over-HTTPS, DNS-over-TLS, en annan DNS-sökväg eller en lokal resolver, kanske brandväggen inte ser de relevanta DNS-svaren. Ett jokertecken FQDN kan då förbli tomt eller ofullständigt trots att domänen fungerar i webbläsaren.

Skapa en FQDN-värd

Menysökvägen är:

Hosts and services > FQDN host > Add

Endast ett fåtal fält har betydelse för ett rent objekt:

Name: beskrivande och tekniskt stabil, till exempel fqdn_vendor_updates eller wfqdn_example_subdomains .
FQDN: det fullständiga namnet, till exempel updates.vendor.example eller *.example.com .
FQDN host group: välj eventuellt en befintlig grupp eller skapa en ny grupp. En FQDN-värd kan tillhöra flera FQDN host groups.
Stavning: skriv FQDNs med gemener. Sophos uppger att versaler i FQDN-värdar inte stöds.

När fälten är ifyllda sparas objektet med Save.

Efter att du har sparat, placera inte objektet blint omedelbart i produktionsreglerna. Kör ett kort test först: löser brandväggen namnet, visar Log Viewer senare den förväntade destinations-IP:n och matchar denna IP-adress klientens DNS-svar?

Samla flera FQDN-värdar i en grupp

En FQDN host group samlar flera befintliga FQDN-värdar i ett återanvändbart objekt. Grupper kan bland annat väljas i brandväggsregler och SD-WAN policy routes.

Gå till Hosts and services > FQDN host group > Add. Ange ett unikt namn under Name, välj de värdar som behövs och klicka på Save. För en applikation med separata ändpunkter kan gruppen grp_vendor_service exempelvis innehålla login.vendor.example, api.vendor.example och updates.vendor.example. En värd kan tillhöra flera grupper. Ta bara med de namn som behövs, eftersom varje extra värd utökar alla regler som använder gruppen.

I listorna FQDN host och FQDN host group kan du söka på alla attribut som visas. Innan du ändrar eller tar bort ett objekt ska du separat kontrollera vilka brandväggsregler, SD-WAN policy routes eller andra konfigurationer som använder det. En ändring i en delad grupp påverkar alla dessa användningar.

Använd i brandväggsregler

I de flesta konstruktioner hör en FQDN-värd till i utgående regler under Destination networks . Regeln beskriver sedan vilka interna källor som kan ansluta till vilken dynamisk destination.

Typiskt flöde:

Skapa FQDN-objektet under Hosts and services > FQDN host .
Öppna eller skapa matchningsregeln under Rules and policies > Firewall rules .
Definiera Source zones och Source networks and devices snävt.
Välj Destination zones medvetet, vanligtvis WAN .
Välj FQDN-objektet under Destination networks .
Tillåt endast de portar som krävs under Services , till exempel HTTPS .
Aktivera loggning.
Kör ett riktigt test och kontrollera Rule ID, destinations-IP, NAT Rule ID och tjänst i Log Viewer.

En FQDN-värd gör inte en regel säker av sig själv. Om Källa är Any, Service är Any och Destination är ett brett jokerteckenobjekt, kan resultatet snabbt bli väldigt öppet. En liten regel med tydlig källa, tydlig service, aktiv loggning och dokumenterat syfte är bättre.

Specialfall: förkonfigurerade grupper för Web Proxy-regler

De förkonfigurerade grupperna SafeSearch enforcement, YouTube restrictions enforcement och Google app enforcement är endast avsedda för regler som upprätthåller SafeSearch, YouTube-begränsningar eller Google Workspace-inloggningar via Web Proxy. De ersätter inte en egen lista med allmänna SaaS-destinationer.

Innan du aktiverar en sådan regel ska du se till att enheterna i pilotgruppen litar på CA-certifikatet, konfigurera lämpliga dekrypteringsundantag och förbereda konkreta acceptanstester för HTTP och HTTPS. Processen beskrivs i inför TLS Inspection stegvis på Sophos Firewall.

Ställ i den separata brandväggsregeln in Action på Allow och Destination zones på WAN. Välj de förkonfigurerade grupper som behövs under Destination networks och HTTP och HTTPS under Services. Aktivera även Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine och Decrypt HTTPS during web proxy filtering. Placera regeln ovanför regler som behandlar samma trafik med DPI-motorn.

Kontrollera efter testet i Log Viewer och en webbläsare att endast den avsedda pilotgruppen använder regeln och att den önskade begränsningen fungerar. För återställning inaktiverar du den nya proxyregeln och verifierar att trafiken åter behandlas av DPI-regeln under den. Ta bort proxyregeln först när detta tillstånd har bekräftats.

Gränser och fallgropar

Många FQDN-problem kommer inte från regellistan, utan från DNS-beteendet hos klienter eller applikationer.

Brandväggen ser olika DNS-svar

Om klient och brandvägg använder olika DNS-upplösare kan de ta emot olika IP-adresser för samma namn. Detta är normalt med CDN. En regel kan sedan matcha en IP medan klienten använder en annan.

Vid felsökning, jämför:

Vilken IP returnerar nslookup eller dig på klienten?
Vilken destinations-IP visas i Log Viewer?
Vilka DNS-servrar använder klienten och brandväggen?
Använder DNS port 53 , DNS-over-HTTPS eller DNS-over-TLS?

Wildcard FQDN lär sig ingenting

Ett jokertecken FQDN fungerar bara om brandväggen ser de matchande DNS-svaren. Om en klient använder DoH i webbläsaren eller en DNS-sökväg som inte går genom brandväggen, kan brandväggen inte lära sig underdomänerna. För DNS-trafik som bara passerar genom brandväggen ska du dessutom kontrollera om learn-subdomains är aktiverat. Det är ytterligare en förutsättning, inte en garanti för att inlärningen lyckas.

I dessa fall är det inte lösningen att flytta brandväggsregeln. Bestäm istället för DNS-designen: använd brandväggen som DNS-sändare, dirigera DNS-trafik genom brandväggen på ett kontrollerat sätt, eller använd ett annat kontrolllager för webbtrafik.

FQDN är för brett

Ett jokertecken som *.example.com kan innehålla mycket mer än avsett. Moderna SaaS-tjänster använder inloggningsdomäner, API-domäner, media-CDN, telemetri, supporttjänster och tredje part. Ibland är ett enskilt jokerteckenobjekt för grovt.

Om åtkomsten måste vara bred till sin design är en webbpolicy, URL-grupp eller Application Control ofta lättare att förstå och granska än en mycket stor FQDN-brandväggsregel.

Flera domäner pekar på samma IP

Sophos dokumenterar uttryckligen att FQDN-värdar inte stöder flera domäner som slås upp till samma IP-adress. Ett FQDN-objekt arbetar med de IP-adresser som namnuppslagningen ger och kan inte skilja sådana domäner åt på IP-nivå. Därför får man inte förvänta sig en tillförlitlig separation av domänerna med ett sådant objekt.

För domänbaserade webbbeslut är webbskiktet därför mer lämpligt än en ren IP-baserad brandväggsregel med ett FQDN-objekt.

Felsökning

Om en FQDN-regel inte fungerar som förväntat, kontrollera först den verkliga anslutningen. Namnet i objektet är inte avgörande; IP-adressen som används vid testtillfället är.

Regeln stämmer inte överens

Kontrollera:

Matchar källzonen?
Matchar käll-IP eller källnätverk?
Matchar tjänsten, till exempel TCP 443 istället för endast HTTP?
Visar Log Viewer ett annat Rule ID?
Visar Log Viewer en destinations-IP som inte matchar det aktuella DNS-svaret?
Är en mer allmän regel aktiv utöver FQDN-regeln?

Om Log Viewer visar en annan regel är regelordningen viktigare än FQDN-objektet. Om Log Viewer inte visar något är utebliven trafik till brandväggen eller inaktiv loggning möjliga orsaker, men inte de enda. Kontrollera även den valda modulen samt tids-, fält- och sökfilter. Brandväggsregelsessioner loggas först när anslutningen stängs med en mottagen Destroy-händelse; om anslutningen stängs utan denna händelse kan sessionsloggen saknas. Därför måste även en fortfarande öppen anslutning beaktas. Kontrollera med en riktad Packet Capture om testpaketen når brandväggen; en tom Log Viewer är i sig inget bevis för motsatsen.

Wildcard FQDN förblir tomt

Kontrollera:

Använder klienten brandväggen som DNS-server?
Är DNS synligt genom brandväggen?
Använder kunden DoH eller DoT?
Används UDP 53?
Är learn-subdomains aktiverat vid transit-DNS? Synliga DNS-svar i sig garanterar inte att en bindning har lärts in.
Finns det en DNS-begäranväg eller intern resolver som döljer svaret innan brandväggen ser det?

Om DNS avsiktligt dirigeras internt, hjälper konfigurera DNS request routes på Sophos Firewall till med DNS-designen.

DNS ändras, regeln reagerar senare

FQDN-objekt fungerar med DNS-svar och cachar. Om en leverantörs destination ändras kan det bli en fördröjning tills brandväggen använder det nya tillståndet. För normala FQDN-värdar är TTL för DNS-posten avgörande.

I Device Console tillhandahåller Sophos den systemomfattande kommandofamiljen set fqdn-host; den ändrar inte bara ett valt värdobjekt. cache-ttl använder som standard dns-reply-ttl eller kan ställas in från 60 till 86400 sekunder. idle-timeout tar bort oanvända bindings efter ett konfigurerbart intervall på 60 till 86400 sekunder; standardvärdet är 3600 sekunder. eviction styr om och efter vilket intervall inlärda IP-adresser för wildcard-underdomäner tas bort; intervallet är 60 till 86400 sekunder. learn-subdomains aktiverar eller inaktiverar inlärningen av dessa adresser från transittrafik som passerar brandväggen men varken kommer från eller är avsedd för den. Om cache-ttl ändras gäller det nya värdet bara för poster som löses efter ändringen; redan cachade poster behåller sitt tidigare värde tills de löper ut.

Ändra inte dessa värden som första åtgärd. Kontrollera först att DNS-designen, resolvervägen och regelbasen är korrekta. Dokumentera alla aktuella värden före en ändring, ändra endast en parameter i taget och testa effekten med nyupplösta poster. Återställ det dokumenterade ursprungsvärdet vid rollback; för standard-TTL är detta dns-reply-ttl. Tuning hör hemma i en dokumenterad drift- eller supportprocedur.

Driftsrekommendation

FQDN-värdar förblir hanterbara när de behandlas som tekniska beroenden, inte spontana undantag.

God praxis:

Dokumentera ett tydligt syfte för varje FQDN-objekt.
Använd jokertecken sparsamt.
Kombinera FQDN-objekt med smala käll- och tjänstdefinitioner.
Aktivera loggning för nya eller kritiska regler.
Testa ändringar med Log Viewer och DNS-uppslag.
Göm inte bred webbåtkomst i en stor FQDN-regel.
För SaaS eller molntjänster, kontrollera regelbundet om leverantören kräver ytterligare domäner.

CLI-dokumentationen anger upp till 16 000 FQDN-värdar. För SFOS 22 dokumenterar Sophos dock en gemensam övre gräns på 16 000 värdar för alla värdtyper tillsammans; detta får inte tolkas som ytterligare, oberoende FQDN-kapacitet eller ledig reservkapacitet. Denna övre gräns är ingen inbjudan till okontrollerad tillväxt. Många gamla FQDN-undantag gör review, troubleshooting och regelunderhåll svårare. En mindre, dokumenterad objektlista med ägare, syfte och granskningsdatum är bättre.

Om ett objekt skapades bara för att “en applikation annars inte fungerar”, granska det senare. Dessa nödobjekt blir ofta permanenta undantag som är svåra att förklara.

Vanliga frågor

Vad är skillnaden mellan en FQDN-värd och en IP-värd?

En IP-värd beskriver en fast adress eller nätverk. En FQDN-värd beskriver ett DNS-namn vars nuvarande IP-adresser brandväggen kan använda. Detta hjälper till med dynamiska destinationer, men beror på DNS-upplösning och cachebeteende.

Fungerar `*.example.com` automatiskt för alla underdomäner?

Inte som en komplett domänlista. Brandväggen måste se matchande DNS-svar och lära sig IP-adresser från dem. Om DNS inte är synligt genom brandväggen kan ett jokertecken FQDN förbli ofullständigt.

Varför stämmer inte min FQDN-regel?

Vanligtvis stämmer inte regelkontexten, ordningen eller faktiskt använda destinations-IP. I Log Viewer, kontrollera vilket regel-ID, destinations-IP, destinationsport och NAT-regel-ID som visas under det riktiga testet.

Fungerar FQDN-värdar med DNS-over-HTTPS eller DNS-over-TLS?

Jokertecken FQDN är problematiska när klienter använder DoH eller DoT och brandväggen inte kan se DNS-svaren. Brandväggen kan då inte på ett tillförlitligt sätt lära sig de nödvändiga underdomänerna.

Bör FQDN-värdar användas för webbfiltrering?

Endast selektivt. För riktig webbkontroll är webbpolicyer, URL-grupper, DNS-skydd, Application Control eller TLS Inspection vanligtvis mer lämpliga. FQDN-värdar är användbara för tekniska destinationer i nätverksregler, men de är inte en fullständig URL-policy.