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.

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. Detta fungerar tillförlitligt när brandväggen kan se DNS-trafiken:

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?

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.

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.

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 påpekar att FQDN-värdar inte är avsedda att rent särskilja flera domäner när de löser sig till samma IP-adress. På IP-lagret kan brandväggen inte alltid veta vilken domän en applikation senare använder.

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, når inte trafiken brandväggen eller så är loggningen inte aktiv.

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?
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.

Sophos erbjuder CLI-alternativ för FQDN-värdar, till exempel cache-ttl, idle-timeout, eviction och learn-subdomains. cache-ttl kan använda TTL från DNS-svaret eller ett värde mellan 60 och 86400 sekunder. idle-timeout tar som standard bort oanvända bindings efter 3600 sekunder. eviction styr när inlärda IP-adresser från wildcard-underdomäner tas bort. Om cache-ttl ändras gäller det nya värdet bara för nyupplösta poster; redan cachade poster behåller sitt tidigare värde tills de löper ut.

Dessa värden bör inte ändras som första reaktion. Kontrollera först om DNS-designen, resolvervägen och regelbasen är korrekta. 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.

Sophos anger upp till 16 000 FQDN-värdar, men det ä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.