Konfigurera Sophos DNS Protection med Sophos Firewall

Sophos DNS Protection kontrollerar DNS-frågor via en molntjänst och hanterar policies och rapporter i Sophos Central. Tjänsten kan blockera skadliga domäner, phishing, Command-and-Control-mål och oönskade kategorier innan en klient upprättar den egentliga anslutningen.

Med Sophos Firewall är den tydligaste standardlösningen oftast att klienterna använder brandväggen som DNS-resolver, brandväggen vidarebefordrar offentliga frågor till DNS Protection och interna domäner skickas via DNS Request Routes till interna DNS-servrar.

DNS Protection ersätter inte Web Protection, Threat Feeds eller NDR och Active Threat Response. Det kompletterar dessa kontroller på DNS-nivå.

Beslut och målarkitektur

DNS är en grundläggande funktion. Om resolvern är långsam, instabil eller för restriktiv upplever användarna snabbt problemet som ett allmänt nätverksavbrott. DNS Protection bör därför bara användas när mervärdet från Central-policies, kategorier, loggar eller skydd för roamingklienter motiverar den extra driften.

Ur Avanets perspektiv är snabba, redundanta resolvrar tillsammans med väl underhållna Threat Feeds den mest pragmatiska lösningen för många traditionella brandväggsinstallationer. DNS Protection passar särskilt när:

• DNS-frågor ska vara synliga i Sophos Central.
• olika platser behöver olika DNS-policies.
• kategorier ska blockeras redan vid namnuppslagningen.
• klienter inte får använda godtyckliga offentliga resolvrar.
• hanterade Windows-endpoints ska skyddas även utanför företagsnätverket.

Den rekommenderade brandväggsvägen ser ut så här:

1. Sophos Central känner platsen som en Location.
2. Sophos Central tillhandahåller två IP-adresser för DNS Protection.
3. Sophos Firewall använder båda adresserna som DNS Forwarder.
4. DNS Request Routes skickar interna zoner till interna DNS-servrar.
5. DHCP delar ut brandväggen som resolver till klienterna.
6. En valfri NAT-regel tvingar klassisk DNS-trafik till denna väg.
7. Sophos Central loggar och utvärderar offentliga DNS-frågor.

Två metoder måste skiljas åt:

• Traditional DNS over IPv4: för brandväggar, routrar och lokala resolvrar. Sophos kopplar frågor till Location utifrån den offentliga käll-IP-adressen eller ett DDNS-FQDN.
• Secure DNS: DNS over HTTPS (DoH) för kompatibla enheter. Sophos Endpoint kan hantera denna väg på Windows-endpoints som stöds; Windows och macOS kan också konfigureras manuellt för Secure DNS.

En anpassad Location kan stödja båda metoderna. För vidarebefordran via brandväggen måste Traditional DNS och den offentliga IP-adressen eller FQDN konfigureras.

Före rollout måste licens, offentliga utgående adresser, interna DNS-zoner, DHCP-servrar och ansvariga för policies och undantag vara klarlagda. Xstream Protection täcker fristående DNS Protection. Endpoint DNS Protection kräver Workspace Protection och dessutom en lämplig Sophos Endpoint-licens.

Den fördefinierade Location Default kan användas för Secure DNS och tilldelas policies, men kan inte redigeras eller tas bort. Högst 50 Locations och 100 offentliga IPv4-/FQDN-poster per Location är tillåtna. Locations bör därför skapas per plats och internetutgång, inte per VLAN.

Konfigurera DNS Protection

1. Skapa en Location i Sophos Central

My Products > DNS Protection > Locations

1. Välj Add och ange ett unikt namn för platsen.
2. Aktivera Traditional DNS over IPv4.
3. Ange den offentliga WAN-IP-adressen eller ett stabilt DDNS-FQDN.
4. Vid Multi-WAN ska alla utgående adresser som faktiskt används beaktas.
5. Spara Location.

Privata IP-adresser är ogiltiga. Sophos måste känna igen den offentliga käll-IP-adress via vilken frågan når tjänsten. För dynamiska adresser kontrollerar Sophos DDNS-namnet regelbundet, men ett byte kan ändå orsaka ett kort avbrott. I Cloudflare måste DDNS-posten vara inställd på DNS only och får inte gå via proxyn.

Vid CGNAT eller en delad leverantörs-IP kopplas adressen till det kundkonto som registrerar den först. Ett FQDN löser inte problemet om det pekar på samma delade IP; en unik offentlig IP-adress krävs.

2. Hämta IP-adresserna för DNS Protection

My Products > DNS Protection > Installers

Under Installers finns två IP-adresser för DNS Protection. Kopiera alltid värdena från den egna Central-klientorganisationen och använd dem som DNS 1 och DNS 2. En extern resolver som extra fallback kan kringgå skyddet och synligheten.

IP-adresserna är tillgängliga även när Secure DNS är aktiverat. För brandväggsvägen är det avgörande att Traditional DNS också är konfigurerat i Location med den offentliga utgående adressen.

3. Konfigurera brandväggen som DNS Forwarder

Network > DNS

1. Välj Static DNS.
2. Fyll i DNS 1 och DNS 2 med de två Central-adresserna.
3. Lämna DNS 3 tomt om det inte finns ett medvetet dokumenterat specialfall.
4. Välj även Static DNS under IPv6 och ange inga IPv6-DNS-servrar.
5. Aktivera Choose IPv4 DNS server over IPv6.
6. Spara konfigurationen.

Tjänsten använder IPv4 men kan även slå upp AAAA-poster och därmed IPv6-mål. Vid SD-WAN, failover eller Policy Routing måste den faktiska utgående vägen motsvara en offentlig adress som har registrerats i Location.

4. Vidarebefordra interna domäner

Network > DNS
DNS request route section > Add

DNS Protection slår inte upp interna zoner. Därför krävs DNS Request Routes för Active Directory, interna applikationer och omvända uppslagningar.

Exempel:

• Host/domain name: firma.local eller corp.example.com
• Target servers: interna domänkontrollanter eller DNS-servrar

Hela förloppet beskrivs i Konfigurera DNS Request Routes på Sophos Firewall. Internt använda, offentligt registrerade domäner bör dessutom tillåtas i en domänlista om en kategori som Parked Domains blockerar dem.

5. Låt klienter använda brandväggen via DHCP

Network > DHCP

1. Redigera DHCP-servern för det berörda nätverket.
2. Dela ut brandväggens interna gränssnitts-IP som DNS-server.
3. Förnya leasen på en testklient.
4. Kontrollera vilken resolver som faktiskt används.

Sophos visar som exempel brandväggens IP som Primary DNS och en DNS Protection-IP som Secondary DNS. Klienter behandlar dock inte nödvändigtvis den andra posten som en ren reservserver. Direkta frågor till DNS Protection kringgår brandväggens DNS Request Routes. I nätverk med Active Directory eller interna zoner bör redundans därför lösas i resolvervägen, inte med en godtycklig andra DNS-server på klienten.

6. Förhindra direkt kringgående av DNS

En valfri DNAT-regel kan omdirigera klassisk DNS-trafik från interna klienter till brandväggen:

• Original source: berörda interna nätverk
• Original destination: utgående värdgrupp eller Internet IPv4
• Original service: DNS
• Translated destination: brandväggens interna IP
• Inbound interfaces: endast gränssnitt som motsvarar de interna källorna, aldrig WAN
• Position: högt upp, före mer allmänna NAT-regler

Undantag för interna DNS-servrar och specialenheter måste dokumenteras. Regeln omfattar endast DNS via UDP/TCP 53. DoH och DoT kräver separata kontroller i webbläsare, MDM, endpoint eller Web Policy. Testa intern namnuppslagning, VPN, gästnät och loggar före aktivering. Regelmekaniken förklaras mer ingående i Förstå NAT på Sophos Firewall.

Policies, endpoints och blockeringssidor

Filtering Policy och domänlistor

En Filtering Policy tilldelas en eller flera Locations under DNS Protection > Policies > Filtering policies. Endast en Filtering Policy kan vara aktiv per Location. Utöver kategorier kan domänlistor och alternativ som Safe Search definieras.

Domänlistor bör ha syfte, Owner och granskningsdatum. En Allow list åsidosätter normala kategoribeslut, men inte en SophosLabs-klassificering som Threat eller Security Risk. En tillåten domän kan dessutom förbli blockerad om dess CNAME-mål tillhör en blockerad kategori.

Följande beslut är särskilt viktiga för kategorierna:

• Infrastructure: tillåt normalt Content delivery, CRL och OCSP, eftersom uppdateringar och certifikatkontroller kan vara beroende av dem.
• Threats and liabilities: blockera vanligtvis kategorier som Phishing, Malware, Newly Registered Websites eller Anonymizers och hantera False Positives målinriktat.
• Data loss: bedöm molnlagring och webbmejl utifrån DLP- och efterlevnadskrav.
• Uncategorized: blockera inte blint; nya legitima eller interna tjänster kan tillfälligt sakna kategori.
• Produktivitet, Social Media och bandbredd: besluta utifrån nätverk och verksamhetsbehov, inte som en generell säkerhetsregel.

Endpoint DNS Protection

Endpoint DNS Protection Policy är avsedd för hanterade Windows-endpoints som ska skyddas även utanför företagsnätverket. Sophos Endpoint fångar DNS-frågorna och skickar dem via HTTPS till Secure-DNS-Location. Tillhörande Filtering Policy bestämmer den faktiska filtreringen.

Policyn stöder för närvarande varken Windows Server eller macOS. För macOS finns en separat manuell Secure DNS-profil; Linux, mobila enheter och specialenheter behöver också en egen nätverks-, VPN- eller MDM-lösning. Kontrollera aktuella krav för Endpoint-paketet i Sophos Central före rollout, eftersom de kan ändras med kort varsel.

Interna zoner hanteras uttryckligen som Domain Exclusions i Endpoint Policy. Det är mer tillförlitligt än ett nytt försök efter NXDOMAIN och undviker onödiga externa frågor. DNS Protection Root Certificate kan distribueras automatiskt till endpoints som stöds.

Root Certificate och blockeringssida

För HTTPS-blockeringssidor måste klienterna lita på DNS Protection Root Certificate. Det är inte samma certifikat som brandväggens CA för TLS Inspection; distributionen beskrivs i Distribuera Sophos Firewall CA-certifikat för TLS Inspection.

Certifikatet och konfigurationstestet finns under DNS Protection > Installers. Dessutom måste blockpage.dnsprotection.sophos.com kunna nås.

I Web Proxy Mode kan Pharming Protection störa blockeringssidan. Innan skyddsfunktioner inaktiveras globalt bör blockeringssidans domän tillåtas via en riktad HTTP/HTTPS-brandväggsregel utan Web Filter och anges som Do not decrypt i en TLS-regel.

Pilot, rollout och godkännande

Aktivera först DNS Protection i ett litet pilotnät. Dokumentera interna zoner, omvända uppslagningar och kritiska tjänster, konfigurera DNS Request Routes och förbered en tydlig rollback till tidigare resolvrar. Servernät behöver ett separat testfönster eftersom licenskontroll, uppdateringar, CRL/OCSP, backup eller klusterkommunikation kan vara DNS-beroende.

Före bred rollout måste följande tester lyckas:

• en offentlig domän slås upp via avsedd resolver.
• den interna AD-domänen och omvänd uppslagning fungerar via DNS Request Routes.
• konfigurationstestet under Installers visar förväntad bekräftelse.
• en ofarlig domän som avsiktligt blockeras av en testpolicy blockeras och kopplas till rätt Location.
• loggar visas i Sophos Central efter den förväntade rapporteringsfördröjningen.
• gästnätet använder planerad DNS-väg men inga interna DNS-servrar.
• VPN-klienten får lämpliga resolvrar och DNS-suffix.
• Browser DoH, Private Relay eller lokala profiler kringgår inte kontrollen oväntat.
• rollback till tidigare resolver är testad eller tydligt dokumenterad.

Testkommandon för klienter

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux med systemd-resolved och installerat dig:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

Ersätt <firewall-ip> med Sophos Firewalls interna gränssnittsadress. Om den uttryckliga frågan till brandväggen fungerar men den normala frågan inte gör det, ligger orsaken oftast i DHCP, VPN, Browser DoH eller en lokal DNS-konfiguration. Kommandona visar vilken klientresolver som används och dess svar, men bevisar inte i sig vilken upstream brandväggen använder.

Testa en intern zon:

dig @<firewall-ip> interner-host.corp.example.com

Frågan måste nå den interna DNS-servern via rätt DNS Request Route.

Troubleshooting

Location visas inte i Sophos Central

Kontrollera offentlig WAN-IP, DDNS-FQDN och faktisk Multi-WAN-utgång. En käll-IP som inte är konfigurerad kan avvisas av DNS Protection-tjänsten. För dynamiska adresser ska du kontrollera att FQDN externt pekar på aktuell IP; Cloudflare-poster måste vara inställda på DNS only.

Under My Environment > Alerts visas ogiltiga FQDN och IP-konflikter. Vid CGNAT eller delade proxy-/VPN-utgångar vinner den Location som registrerades först. Ett annat FQDN på samma IP ändrar inte kopplingen.

Interna namn fungerar inte längre

Kontrollera DNS Request Routes, interna DNS-servrar, omvända zoner, sökdomäner och klientsuffix. Kontrollera också att klienten använder brandväggen eller avsedd intern resolver och inte direkt en DNS Protection-IP.

En intern eller legitim domän blockeras

Kontrollera kategorisering, domänlista och CNAME-mål. Ett snävt undantag är bättre än att öppna en hel kategori. SophosLabs-klassificeringarna Threat och Security Risk kan inte åsidosättas med en Allow domain list.

Loggarna förblir tomma

Dashboard och rapporter ligger ungefär 15 till 25 minuter efter realtid. Kontrollera först därefter DHCP, klient-DNS, brandväggs-DNS, NAT-omdirigering, alternativa resolvrar, VPN-profiler och Location-tilldelning.

Med EDR, XDR eller MDR kan Threat Analysis Center > Live Discover dessutom analysera DNS Protection-data som Domain, Policy Action, Location och Source IP. Användar- och enhetsfält finns för endpointdata i standardrapporterna, inte i Live Discovers dokumenterade DNS-schema för brandväggen.

Blockeringssidan visas inte

Kontrollera DNS Protection Root Certificate, DNS-vägen och åtkomsten till blockpage.dnsprotection.sophos.com. Kontrollera även Pharming Protection, HTTP/HTTPS-regeln och TLS-undantaget Do not decrypt i Web Proxy Mode. VPN, Browser DoH och Apple Private Relay kan också leda testet förbi DNS Protection.

DoH eller Private DNS kringgår kontrollen

En NAT-omdirigering för port 53 omfattar inte DoH eller DoT. Policies för webbläsare, operativsystem och MDM måste kontrollera sådana resolvrar. Secure DNS i DNS Protection använder DoH; ett separat DNS Protection-läge via DoT är inte dokumenterat.

VPN-klienter beter sig annorlunda än LAN-klienter

Kontrollera tilldelade DNS-servrar, DNS-suffix, Split DNS, Full eller Split Tunnel och lokala resolvrar. DNS Protection kan fungera på kontoret men ändå kringgås vid fjärråtkomst. Det grundläggande VPN-valet förklaras i Sophos Connect eller SSL VPN: vilken fjärråtkomstlösning passar?.

Drift

DNS Protection är inte ett engångsbyte av DNS-server. Kontrollera regelbundet:

• Locations, offentliga utgående adresser och DDNS-upplösning.
• DHCP-inställningar och interna DNS Request Routes.
• policies, domänlistor, Owner och granskningsdatum.
• vanligaste blockerade domäner och dokumenterade False Positives.
• nya platser, gästnät, VPN-vägar och endpointplattformar.
• certifikatdistribution och åtkomst till blockeringssidans domän.
• rapporter efter ändringar och definierad rollbackväg.

Den som inte vill hantera dessa punkter löpande får ofta bättre resultat med robusta resolvrar och riktade skyddskontroller. DNS Protection är värdefullt där policies, rapportering och endpointskydd faktiskt används och övervakas.