Sophos DNS Protection instellen met Sophos Firewall

Sophos DNS Protection beschermt DNS-verzoeken via een cloudgebaseerde DNS-dienst met beleid en rapportage in Sophos Central. De functie kan kwaadaardige domeinen, phishing, command-and-control-doelen en ongewenste categorieën blokkeren voordat een client ook maar verbinding maakt met de daadwerkelijke website of infrastructuur.

Met Sophos Firewall is de meest gebruikelijke standaardopstelling: clients gebruiken de firewall als DNS-resolver, de firewall stuurt openbare DNS-verzoeken door naar DNS Protection, en interne domeinen worden via DNS Request Routes naar interne DNS-servers gestuurd. Zo blijft interne naamresolutie stabiel, terwijl openbare DNS-verzoeken centraal worden gecontroleerd en gelogd.

DNS Protection vervangt geen Web Protection, geen Threat Feeds en geen NDR. Het is een eigen beschermingspunt op DNS-niveau. Daarom moet de functie bewust worden gepland en niet zomaar openbare DNS-servers worden vervangen.

Videohandleiding

Avanet-indeling: DNS Protection bewust inzetten

DNS Protection is technisch interessant, maar niet in elke omgeving automatisch de beste keuze. In veel projecten zetten we DNS Protection bewust niet als standaard in, maar geven we de voorkeur aan snelle, hoogbeschikbare DNS-resolvers en blokkeren we bekende kwaadaardige doelen extra via Sophos Firewall Threat Feeds of vergelijkbare threat-intelligencebronnen op de firewall.

De reden is eenvoudig: DNS is een basisfunctie. Als DNS traag is, niet redundant werkt of te veel false positives genereert, voelt het netwerk voor gebruikers al snel defect aan. DNS-bescherming moet daarom niet alleen veilig zijn, maar ook stabiel, snel, begrijpelijk en goed beheersbaar.

De beslissing hangt af van het doel:

• Snelle en hoogbeschikbare DNS-resolvers: zeer goede performance, robuuste naamresolutie en weinig operationeel risico. Daarvoor is er geen centraal DNS-beleid en geen DNS-reporting in Sophos Central.
• Threat Feeds op de Sophos Firewall: bekende kwaadaardige doelen kunnen aan de perimeter worden geblokkeerd zonder de DNS-route om te bouwen. Dat is echter niet hetzelfde als DNS-categoriefiltering; kwaliteit, tuning en false-positiveproces blijven belangrijk.
• Sophos DNS Protection: DNS-policies, categorieën, Locations, logs en Endpoint DNS Protection worden in Sophos Central beheerd. Daarvoor ontstaat een extra afhankelijkheid in het DNS-pad; rollout, certificaten, uitzonderingen en monitoring moeten goed worden gepland.

DNS Protection is dus vooral geschikt wanneer DNS-logs in Sophos Central, locatiegebaseerde DNS-beleid, categoriefiltering of Endpoint DNS Protection voor roaming-clients uitdrukkelijk gewenst zijn. Als het doel primair snelle en hoogbeschikbare naamresolutie met extra blokkering van bekende slechte doelen is, zijn goede DNS-resolvers plus Threat Feeds vaak de pragmatischere oplossing.

Wanneer DNS Protection zinvol is

DNS Protection is bijzonder sterk wanneer veel clients via een centrale firewall of een lokale DNS-resolver het internet op gaan.

Typische gebruikssituaties:

• Clients mogen geen willekeurige openbare DNS-resolvers gebruiken.
• Malware-, phishing- en C2-domeinen moeten vroeg worden geblokkeerd.
• DNS-verzoeken moeten zichtbaar worden in Sophos Central.
• Verschillende locaties moeten eigen DNS-beleid krijgen.
• Interne DNS-namen moeten blijven werken via lokale DNS-servers.
• Web Protection moet worden aangevuld met een voorafgaande DNS-controle.

DNS Protection is echter geen vervanging voor inhoudscontrole. Als een toegestaan domein later schadelijke inhoud levert of HTTPS-verkeer nauwkeuriger moet worden gecontroleerd, blijven Web Protection, TLS Inspection, IPS, Endpoint-bescherming en logging relevant.

Niet ideaal is DNS Protection wanneer alleen een snelle externe DNS-forwarder wordt gezocht of wanneer al een zeer stabiele DNS-werking met aparte Threat Feeds, Web Protection, Endpoint-bescherming en goed monitoring bestaat. Dan moet eerst worden onderzocht welke extra waarde DNS Protection concreet biedt en wie het beleid, uitzonderingen en false positives beheert.

Architectuur met Sophos Firewall

Voor Sophos Firewall is deze opstelling meestal het duidelijkst:

1. Sophos Central kent de locatie als Location.
2. Sophos Central biedt twee DNS Protection IP-adressen.
3. Sophos Firewall gebruikt deze IP-adressen als DNS-forwarder.
4. Interne domeinen worden via DNS Request Routes naar interne DNS-servers gestuurd.
5. DHCP verspreidt de firewall als DNS-resolver naar clients.
6. Optioneel dwingt een NAT-regel af dat uitgaand DNS-verkeer naar de firewall wordt omgeleid.
7. DNS Protection logs en rapporten worden geëvalueerd in Sophos Central.

Deze opstelling zorgt ervoor dat clients niet direct op de Sophos-DNS-dienst hoeven te worden geconfigureerd. De firewall blijft de centrale resolver in het LAN en kan interne uitzonderingen beter behandelen.

Belangrijk is het onderscheid tussen Traditional DNS en Secure DNS:

• Traditional DNS over IPv4: voor firewalllocaties, routers, lokale DNS-servers of netwerken met vaste openbare IP of DDNS-FQDN. Sophos Central koppelt DNS-verzoeken via de openbare Source IP of de FQDN aan de Location.
• Secure DNS: voor Endpoint DNS Protection via Sophos Endpoint. Sophos Central maakt een uniek DNS-over-HTTPS-pad voor de Location.

Voor een Sophos Firewall als DNS-Forwarder is normaal Traditional DNS over IPv4 het juiste pad. Secure DNS hoort bij het Endpoint-pad en mag niet worden verward met de DNS-Forwarder-instellingen van de firewall.

Vereisten

Voor de uitrol moeten deze punten worden opgehelderd:

• Toegang tot Sophos Central met toestemming voor DNS Protection.
• Passende licentie: Xstream Protection voor standalone DNS-Protection of Workspace Protection voor Endpoint DNS-Protection.
• Openbare WAN-IP of een stabiele FQDN/DDNS-naam voor de locatie.
• Beslissing of de Location voor Traditional DNS of Secure DNS wordt gebruikt.
• Sophos Firewall wordt als DNS-resolver voor de betrokken netwerken gebruikt of moet dat worden.
• Interne domeinen, Active Directory-zones en reverse lookups zijn bekend.
• DHCP-servers voor clientnetwerken zijn geïdentificeerd.
• Uitzonderingen voor interne domeinen en kritieke diensten zijn gepland.
• Bij Endpoint DNS Protection: ondersteunde Endpoint-platformen en rolloutgroep zijn gecontroleerd.
• Verantwoordelijken voor DNS-beleid, false positives en logging zijn gedefinieerd.

Als het openbare IP-adres vaak verandert, moet voor de uitrol worden opgehelderd of een DDNS-configuratie stabiel genoeg is. Sophos DNS Protection kan locaties ook identificeren via een FQDN, maar een IP-wijziging kan toch tijdelijk onderbrekingen veroorzaken.

Voor grote omgevingen moet de Location-structuur bewust worden gepland. Locations zijn een beheer- en policy-object, geen vervangende structuur voor elk VLAN, elke verdieping of elke kleine speciale groep. De vooraf gedefinieerde Location Default is gereserveerd en kan niet als eigen locatie worden gebruikt. Vaak passen locatie-, firewall- of tenantlogica beter dan zeer fijne technische onderverdelingen.

Sophos DNS Protection staat maximaal 50 Locations toe. Per Traditional-DNS-Location kunnen meerdere openbare IP-adressen of FQDN’s worden vastgelegd; Sophos noemt daarvoor een maximum van 100 vermeldingen. Dat klinkt ruim, maar is toch een argument tegen een te fijne Location-structuur. Voor policies moet men eerder snijden op locatie, internet-egress en verantwoordelijkheid dan op elk afzonderlijk VLAN.

1. Locatie in Sophos Central aanmaken

In Sophos Central wordt eerst de locatie aangemaakt:

My Products > DNS Protection > Locations

Praktische procedure:

1. Add selecteren.
2. Locatienaam en beschrijving invoeren.
3. Voor firewalllocaties Traditional DNS over IPv4 gebruiken.
4. Openbare WAN-IP van de Sophos Firewall invoeren.
5. Bij meerdere WAN-interfaces alle relevante openbare IP-adressen of een passend bereik invoeren.
6. Bij dynamisch IP een DDNS-FQDN gebruiken als het ontwerp daarop is gebaseerd.
7. Locatie opslaan.

De locatie is belangrijk omdat DNS Protection inkomende DNS-verzoeken aan het juiste klantaccount en het juiste beleid moet toewijzen. Als de locatie ontbreekt of het openbare IP niet klopt, ziet Sophos Central de locatie niet correct.

Private IP-adressen horen niet in een DNS-Protection-Location. Sophos Central moet het openbare Source IP zien waarmee de DNS-verzoeken bij de dienst aankomen. Als Central automatisch een openbaar IP herkent, moet men toch controleren of dit adres echt het geplande uitgangspad van de firewall is. Bij latere IP-wijzigingen moet de Location worden bijgehouden; automatische herkenning vervangt geen operationele bewaking.

2. DNS Protection IP-adressen kopiëren

De DNS Protection IP-adressen zijn te vinden in Sophos Central onder:

My Products > DNS Protection > Installers

Daar worden twee IP-adressen verstrekt. Deze worden op de Sophos Firewall gebruikt als primaire en secundaire DNS-server. Geen andere openbare DNS-servers als fallback invoeren als het verkeer volledig via DNS Protection moet lopen. Anders kunnen DNS-servers afhankelijk van het gedrag van de resolver buiten DNS Protection worden gebruikt, en gaan bescherming en zichtbaarheid verloren.

Bij Secure DNS ziet de procedure er anders uit: daar werkt de Endpoint-component met een DNS-over-HTTPS-doel, niet met de klassieke DNS-Forwarder-IP-adressen van de firewall. Als men op deze plek IP-adressen voor de firewall verwacht, maar een Secure-DNS-Location heeft aangemaakt, is waarschijnlijk het verkeerde Location-type gekozen.

3. Sophos Firewall DNS-forwarder configureren

Op de Sophos Firewall:

Network > DNS

Aanbevolen procedure:

1. Static DNS selecteren.
2. DNS 1 instellen op het eerste DNS Protection IP-adres.
3. DNS 2 instellen op het tweede DNS Protection IP-adres.
4. DNS 3 leeg laten, tenzij er een bewuste uitzondering is.
5. Onder IPv6 eveneens Static DNS kiezen, geen IPv6-DNS-servers invoeren en Choose IPv4 DNS server over IPv6 selecteren als de locatie via de IPv4-gebaseerde DNS-Protection-servers moet lopen.
6. Instelling opslaan en toepassen.

DNS Protection werkt als een IPv4-gebaseerde DNS-dienst, maar kan ook IPv6-adressen oplossen. Daarvoor is dus niet automatisch een aparte IPv6-DNS-server nodig.

Als een firewall meerdere WAN-paden gebruikt, moet de Location passen bij het daadwerkelijke uitgaande Source IP. SD-WAN, failover, Policy Routing of een ander NAT-design kunnen ertoe leiden dat DNS-verzoeken via een ander openbaar adres naar buiten gaan dan verwacht. Dat moet in de pilot bewust worden getest.

4. Interne domeinen met DNS Request Routes beschermen

DNS Protection lost geen interne domeinen op. Als in het netwerk Active Directory, interne applicaties, lokale zones of reverse lookups worden gebruikt, moeten deze verzoeken naar interne DNS-servers gaan.

Daarvoor gebruikt men op de Sophos Firewall:

Network > DNS > DNS request route

Voorbeeld:

• Host/domain name: bedrijf.local of corp.example.com
• Target servers: interne Domain Controllers of DNS-servers

Zonder deze routes zouden interne namen naar DNS Protection worden gestuurd en daar niet correct worden opgelost. De exacte procedure staat in DNS Request Routes op Sophos Firewall configureren.

Voor productieve omgevingen moet men interne domeinen ook in DNS Protection als domeinlijst opnemen als het domein door een categorie zou kunnen worden geblokkeerd. Typische voorbeelden zijn interne sites of diensten die anders onder problematische categorieën zoals Parked Domains zouden kunnen vallen.

5. Clients via DHCP naar de firewall laten wijzen

Clients moeten de Sophos Firewall als DNS-resolver gebruiken, niet direct willekeurige externe resolvers.

Als de Sophos Firewall DHCP levert:

Network > DHCP

Praktische procedure:

1. DHCP-server van de betrokken interface bewerken.
2. IP-adres van de firewall-interface als primaire DNS-server verspreiden.
3. Bewust beslissen over Secondary DNS.
4. DHCP-lease vernieuwen of testclient opnieuw verbinden.
5. Met een testclient controleren welke DNS-server daadwerkelijk wordt gebruikt.

Sophos toont in de officiële voorbeeldconfiguratie vaak het firewall-interface-IP als primaire DNS-server en een DNS-Protection-IP als Secondary DNS. Dat kan als fallback werken, maar is niet in elke omgeving de beste variant. Als clients direct de Secondary DNS gebruiken, omzeilen ze de firewall als resolver. Interne DNS Request Routes, lokale speciale zones en afzonderlijke controlepunten op de firewall gelden dan voor deze verzoeken niet zoals verwacht.

In omgevingen met Active Directory, interne zones of een duidelijke resolverarchitectuur is het vaak netter om alleen de firewall of de interne DNS-resolver aan clients uit te delen en redundantie in het resolverpad op te lossen.

Als een Windows-DNS-server of andere interne resolver in gebruik is, kan deze resolver in plaats van de clients naar DNS Protection doorsturen. Dan moet echter duidelijk zijn waar interne domeinen worden opgelost en welke server openbare verzoeken doorstuurt.

6. Directe DNS-omzeiling voorkomen

Veel clients gebruiken de via DHCP verspreide DNS-server. Sommige apparaten, browsers, IoT-systemen of opzettelijk geconfigureerde clients kunnen echter eigen DNS-servers gebruiken.

Een mogelijke tegenmaatregel is een NAT-regel die uitgaand DNS-verkeer uit interne netwerken naar de firewall omleidt. Praktisch betekent dit: DNS-verkeer uit de interne bronnetwerken wordt per DNAT naar het interne firewall-adres geleid, zodat het verzoek via DNS Protection kan worden geëvalueerd.

Belangrijk:

• Alleen interne bronnetwerken opnemen.
• Geen WAN-interfaces als Inbound interface gebruiken.
• Regelpositie bewust zeer hoog instellen.
• Uitzonderingen voor interne DNS-servers en uitzonderingen documenteren.
• Alleen klassiek DNS-verkeer op UDP/TCP 53 verwachten; DoH en DoT moeten apart via client-, browser-, MDM- of Web-Policy-controles worden behandeld.
• Daarna testen of interne DNS-resolutie, DNS Protection en logs nog steeds kloppen.

De NAT-grondslagen staan in NAT op Sophos Firewall begrijpen. Een DNS-afdwinging moet niet blind worden geactiveerd, omdat het interne resolvers, VPN-clients, DoH/DoT-gedrag of speciale apparaten kan beïnvloeden.

Uitrol in fasen plannen

DNS Protection moet niet meteen voor alle netwerken tegelijk worden afgedwongen. DNS is een basisfunctie: als interne namen, certificaatcontroles, software-updates of SaaS-diensten niet meer correct worden opgelost, lijkt dat al snel op een algemene internetuitval.

Een gecontroleerde uitrol ziet er in de praktijk zo uit:

1. Pilotnetwerk of kleine testgroep selecteren.
2. Interne domeinen, reverse zones en zoekdomeinen documenteren.
3. DNS Request Routes voor interne zones instellen.
4. Firewall als DNS-resolver via DHCP verspreiden.
5. DNS Protection IP-adressen op de firewall instellen.
6. Blokkeerpagina-certificaat op testclients installeren.
7. Logs in Sophos Central controleren.
8. Pas daarna andere netwerken, gastnetwerk, servernetwerken of VPN-netwerken opnemen.

Voor servernetwerken moet men bijzonder voorzichtig zijn. Sommige systemen gebruiken DNS voor licentiecontrole, updates, CRL/OCSP, back-up, monitoring of clustercommunicatie. Daar is een testvenster met rollback belangrijker dan bij normale clientnetwerken.

Acceptatietest voor de brede uitrol

Voor de productieve uitrol moet duidelijk zijn waaraan men een functionerende DNS-Protection-implementatie herkent. Alleen de Sophos-testlink is daarvoor niet voldoende.

• Openbaar domein oplossen: client vraagt de firewall of de beoogde interne resolver.
• Interne AD-domein oplossen: verzoek gaat via DNS Request Route naar interne DNS-servers.
• Reverse Lookup testen: interne PTR-zones blijven werken.
• Geblokkeerd testdomein openen: DNS Protection blokkeert en logt de treffer.
• Sophos Central Logs controleren: treffer verschijnt bij de juiste Location.
• Gastnetwerk testen: gasten gebruiken het geplande DNS-pad en geen interne DNS-servers.
• VPN-client testen: Split-DNS, interne domeinen en openbare domeinen gedragen zich zoals gepland.
• Browser-DoH controleren: browser of besturingssysteem omzeilt de controle niet onverwacht.

Als een van deze tests mislukt, moet niet meteen het beleid worden geopend. Eerst moet duidelijk zijn of het probleem bij DHCP, DNS Request Routes, locatie-toewijzing, clientprofiel, browser-DoH, VPN-split-tunnel of domeincategorisering ligt.

7. Beleid en domeinlijsten plannen

DNS Protection kan veiligheidsrelevante domeinen ook zonder eigen beleid blokkeren als SophosLabs deze als bedreiging of veiligheidsrisico classificeert. Eigen beleid vult deze basislijn aan met bedrijfsrichtlijnen.

Typische beleidsvragen:

• Welke locaties krijgen welk beleid?
• Welke categorieën moeten worden geblokkeerd?
• Welke categorieën zijn alleen voor bepaalde locaties problematisch?
• Welke domeinen moeten expliciet worden toegestaan?
• Wie beslist over false positives?
• Hoe lang blijven uitzonderingen geldig?

Domeinlijsten moeten nauwkeurig worden beheerd. Een brede toestemmingslijst kan de beschermingswerking verminderen. Een brede blokkeerlijst kan bedrijfsprocessen verstoren. Elke lijst heeft een doel, eigenaar en beoordelingsdatum nodig.

Filtering Policy of Endpoint DNS Protection Policy?

In Sophos Central zijn er twee beleidsniveaus die men niet moet verwarren.

• Filtering policy: locatie-, firewall- of netwerkgebaseerde DNS-filtering. Gebruiken voor kantoren, firewalls, DNS-servers, servernetwerken, gasten, IoT en apparaten zonder Sophos Endpoint.
• Endpoint DNS Protection policy: endpoint-gebaseerde DNS Protection via Sophos Endpoint. Gebruiken voor beheerde clients, notebooks en gebruikers die ook buiten het bedrijfsnetwerk beschermd moeten worden.

Een Filtering policy wordt onder DNS Protection > Policies > Filtering policies aangemaakt en toegewezen aan een of meerdere locaties of firewalls. Per locatie kan slechts één Filtering Policy actief zijn. In dit beleid definieert men categorieën, domeinlijsten en extra opties zoals Safe Search.

Een Endpoint DNS Protection policy gebruikt Sophos Endpoint. De Endpoint onderschept DNS-verkeer op het apparaat en stuurt het veilig via HTTPS naar DNS Protection. Hierdoor hoeft men de client niet handmatig op de DNS-Protection-IP-adressen te configureren. De apparaten worden in het Endpoint-beleid toegewezen aan een DNS-Protection-locatie en worden vervolgens door het bij deze locatie passende Filtering Policy gestuurd.

Praktisch betekent dit:

• Voor een kantoor met Sophos Firewall is de Location plus Filtering policy de normale netwerkroute.
• Voor roaming-clients is de Endpoint DNS Protection policy zinvol, omdat de bescherming ook buiten het bedrijfsnetwerk kan gelden.
• Endpoint DNS Protection is niet automatisch voor elk besturingssysteem in het bedrijf beschikbaar. Sophos ondersteunt de Endpoint-DNS-Protection-policy via Sophos Endpoint momenteel voor Windows Endpoints. Windows Server is daarvoor niet bedoeld. Voor macOS beschrijft Sophos een Secure-DNS-setup-pad dat apart moet worden gepland. Servers, Linux, mobiele en speciale apparaten moeten verder via netwerk-DNS, VPN-design, MDM of andere controles worden beoordeeld.
• Voor gemengde omgevingen combineert men beide benaderingen: firewall-locaties via locaties, beheerde endpoints extra via Endpoint DNS Protection.
• Voor interne domeinen moeten in Endpoint Policies domeinuitzonderingen worden onderhouden. Sophos raadt aan interne zones expliciet uit te sluiten in plaats van alleen op een NXDOMAIN-retry te vertrouwen.
• Blokkeerpagina’s op endpoints vereisen het DNS Protection Root Certificate. Met Sophos Endpoint kan het certificaat automatisch worden verspreid.

Welke categorieën kan men blokkeren?

DNS Protection biedt categorieën die in Sophos Central in groepen zijn georganiseerd. Sommige categorieën zijn meer productiviteitsgericht, andere zijn duidelijk veiligheidsrelevant. De namen blijven hier bewust in het Engels, omdat ze zo ook in Sophos Central worden weergegeven.

• Productivity-related categories: bevat onder meer Advertisements, Auctions & classified ads, Dynamic DNS & ISP sites, Entertainment, Fashion & beauty, Gambling, Games, Hobbies, Hunting & fishing, Kid’s sites, News, Online chat, Online shopping, Personal sites, Photo galleries, Portal sites, Religion & spirituality, Restaurants & dining, Sports, Stocks & trading, Surveillance, Travel, Society & culture en Vehicles. Afhankelijk van bedrijfsbeleid toestaan, blokkeren of alleen voor bepaalde netwerken beperken.
• Social networking: bevat Blogs & forums, Personals & dating en Social networks. Meestal geen pure veiligheidskwestie; voor productieve netwerken bewust beslissen in plaats van algemeen blokkeren.
• Adult and potentially inappropriate categories: bevat onder meer Alcohol & tobacco, Controlled substances, Criminal activity, Download freeware & shareware, Extreme, Intellectual piracy, Intolerance & hate, Legal highs, Marijuana, Militancy & extremist, Nudity, Plagiarism, Pro-suicide & self harm, Sex education, Sexually explicit, Swimwear & lingerie en Weapons. In veel bedrijfsomgevingen blokkeren, uitzonderingen alleen met duidelijke reden.
• Categories likely to cause excessive bandwidth usage: bevat Live audio, Live video, Peer-to-peer & torrents, Radio & audio hosting, Video hosting en Voice & video calls. Voor gast- en clientnetwerken vaak relevant. Bij collaboration-tools vooraf controleren, zodat legitieme calls niet worden verstoord.
• Business-relevant site categories: bevat onder meer General business, Business networking, Educational institutions, Financial services, Government, Health & medicines, Information technology, Job search, Reference, Search engines, Software updates en Translators. Meestal toestaan. Afzonderlijke categorieën kunnen in hoogbeveiligde netwerken worden beperkt.
• Infrastructure: bevat Content delivery, CRL en OCSP. Normaal toestaan, omdat deze categorieën belangrijk kunnen zijn voor updates, certificaatcontrole en veel clouddiensten.
• Threats and liabilities: bevat Anonymizers, Hacking, Newly registered websites, Parked domains, Phishing & fraud, Spam URLs, Spyware & malware en Unauthorized software stores. In de regel blokkeren. Bij false positives gericht met domeinlijsten werken, niet hele groepen openen.
• Data loss: bevat Business cloud apps, Personal cloud apps, Personal network storage en Web E-mail. Sterk afhankelijk van DLP-, cloud- en compliance-eisen. Voor server- en adminnetwerken vaak strenger behandelen dan voor normale gebruikers.
• Uncategorized: niet blind blokkeren. Eerst evalueren, omdat legitieme nieuwe of interne diensten tijdelijk uncategorized kunnen zijn.

Domeinlijsten hebben voorrang boven categorieën. Een toegestaan domein in een domeinlijst blijft toegestaan, zelfs als de categorie zou worden geblokkeerd. Een geblokkeerd domein blijft geblokkeerd, zelfs als de categorie zou worden toegestaan. Daarom moeten domeinlijsten worden gedocumenteerd en regelmatig worden gecontroleerd.

8. Blokkeerpagina’s en certificaten

Voor geblokkeerde domeinen kan DNS Protection een HTTPS-blokkeerpagina weergeven. Om ervoor te zorgen dat gebruikers deze blokkeerpagina correct zien, moet het DNS Protection Root Certificate op de betrokken apparaten als vertrouwd zijn geïnstalleerd.

Als daarnaast TLS Inspection of webfiltering op de firewall actief is, moeten de certificaat- en uitzonderingsplanning overeenkomen. Voor de firewall-CA past Sophos Firewall CA-certificaat voor TLS Inspection verspreiden.

Het certificaat en de Blockpage-test staan in Sophos Central onder DNS Protection > Installers. Daarnaast moet blockpage.dnsprotection.sophos.com bereikbaar zijn. Als dit domein door Web Protection, TLS Inspection, DNS-policy of een andere controle wordt verstoord, kan de eigenlijke DNS-Protection-beslissing correct zijn, maar de blokkeerpagina toch verkeerd of helemaal niet verschijnen.

Als blokkeerpagina’s niet worden weergegeven, moet men niet meteen aan het beleid draaien. Vaak ontbreken certificaten, gebruikt de client een andere DNS-route, wordt blockpage.dnsprotection.sophos.com verstoord of leidt browser-/besturingssysteembescherming zoals DoH, Private Relay of een VPN-profiel de test langs DNS Protection.

DNS Protection testen

Sophos Central biedt onder DNS Protection > Installers een testlink. Als de configuratie correct is, toont de browser een bevestiging.

Daarnaast moet men praktijkgericht testen:

• Client gebruikt de firewall als DNS-server.
• Openbaar domein wordt via DNS Protection opgelost.
• Intern domein wordt via DNS Request Route correct opgelost.
• Geblokkeerd testdomein wordt geblokkeerd.
• Logs verschijnen in Sophos Central.
• DNS-verzoeken verschijnen op de juiste locatie.
• Alternatieve DNS-servers worden niet gebruikt.
• VPN- of gastnetwerk gedraagt zich zoals gepland.

Voor echte foutanalyse moet men niet alleen de browser testen. nslookup, dig, firewall-logs, DHCP-leases en Sophos-Central-logs samen geven een beter beeld.

Testcommando’s voor clients

Op een testclient moet men eerst controleren welke DNS-server daadwerkelijk wordt gebruikt. Een succesvolle browsertest is niet voldoende als de client parallel een andere resolver, DoH of een VPN-profiel gebruikt.

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:

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

Daarbij moet <firewall-ip> worden vervangen door het interne interface-adres van de Sophos Firewall dat in het betreffende netwerk als DNS-resolver moet dienen. Als de query tegen de firewall werkt, maar de normale query een andere resolver gebruikt, ligt het probleem meestal bij DHCP, besturingssysteemprofiel, VPN-client, browser-DoH of een lokale DNS-configuratie.

Voor interne domeinen moet daarnaast een test met een interne zone worden uitgevoerd:

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

Deze test moet via de juiste DNS Request Route bij de interne DNS-server landen. Als openbare domeinen werken, maar interne namen niet, is DNS Protection zelden de eigenlijke oorzaak. Dan moeten DNS Request Routes, interne DNS-servers, zoekdomeinen en client-DNS-suffixen worden gecontroleerd.

Probleemoplossing

Locatie verschijnt niet in Sophos Central

Controleren of het openbare WAN-IP of de DDNS-FQDN in de locatie klopt. Bij meerdere WAN-lijnen moeten alle relevante uitgaande adressen worden meegenomen. Bij dynamische IP-adressen kan het even duren voordat DNS Protection de wijziging herkent.

Controleer daarnaast of het Location-type bij het design past. Een firewall die klassieke DNS-verzoeken naar de verstrekte IP-adressen stuurt, hoort in het Traditional-DNS-pad. Endpoint DNS Protection gebruikt daarentegen Secure DNS via de Endpoint-component.

Als de Location via een FQDN wordt onderhouden, moet men daarnaast controleren of de FQDN van buitenaf echt naar het actuele openbare IP wijst. Sophos Central kan een automatisch herkend adres tonen, maar latere wijzigingen moeten tijdens bedrijf worden gecontroleerd.

Als ondanks correcte firewallconfiguratie geen Location-toewijzing zichtbaar is, moet men ook My Environment > Alerts in Sophos Central controleren. Problemen kunnen ontstaan wanneer een FQDN niet naar een geldig openbaar IP wijst of wanneer hetzelfde openbare IP al in een andere DNS-Protection-Location van een ander klantaccount wordt gebruikt. Dat is vooral relevant bij CGNAT, gedeelde provideradressen, centrale proxy-/VPN-uitgangen of verkeerd onderhouden DDNS-namen.

Interne namen werken niet meer

Dan ontbreken meestal DNS Request Routes of vragen de clients niet de verwachte resolver. Interne AD-domeinen, reverse zones en applicatiedomeinen moeten expliciet naar interne DNS-servers worden doorgestuurd.

DNS Protection blokkeert een interne of legitieme domein

Eerst ophelderen of het domein intern, openbaar, verkeerd gecategoriseerd of daadwerkelijk risicovol is. Daarna domeinlijst en beleid controleren. Geen brede toestemmingsregel instellen voordat oorzaak en betrokken gebruikers bekend zijn.

Logs blijven leeg

Als er geen logs in Sophos Central verschijnen, gebruikt de client mogelijk niet DNS Protection. Controleren: DHCP, client-DNS, firewall-DNS, NAT-omleiding, alternatieve resolvers, VPN-profiel en of de locatie in Sophos Central correct wordt herkend.

Voor diepere analyse kan daarnaast Threat Analysis Center > Live Discover worden gebruikt, als de omgeving de benodigde Central-functies gebruikt. Daar kunnen DNS-Protection-gegevens gedetailleerder worden opgevraagd dan in de standaardrapporten, bijvoorbeeld op domain, Policy Action, Location, gebruiker of apparaat. Voor normale acceptatie zijn eerst Logs & Reports, testclient en resolvercontrole voldoende.

Blokkeerpagina verschijnt niet

Dan is vaak het DNS Protection Root Certificate niet geïnstalleerd, gebruikt de client een andere DNS-route, of beïnvloedt een andere veiligheidscontrole de verbinding. Ook TLS Inspection en Web Protection moeten worden gecontroleerd.

Controleer daarnaast of de Blockpage-domain bereikbaar is en niet door een voorafgaande policy wordt geblokkeerd. Als een browser DoH, een VPN-profiel of Apple Private Relay gebruikt, ziet men mogelijk geen Sophos-blokkeerpagina, hoewel het normale netwerk-DNS-pad correct zou zijn.

DoH of private DNS omzeilt de controle

Browsers en besturingssystemen kunnen DNS over HTTPS of private DNS-functies gebruiken. Afhankelijk van de omgeving moet men deze functies via browser-, MDM- of besturingssysteembeleid beheren. DNS Protection op de netwerkroute helpt alleen als de verzoeken daadwerkelijk via de beoogde resolver lopen.

VPN-clients gedragen zich anders dan LAN-clients

Bij VPN-clients hangt het gedrag sterk af van het profiel. Full Tunnel, Split Tunnel, DNS-suffixen, zoekdomeinen en lokale resolvers van de client kunnen de naamresolutie beïnvloeden. Als DNS Protection in het LAN werkt, maar via VPN niet, moet men eerst VPN-profiel, toegewezen DNS-servers, DNS-suffixen en firewall-regels controleren. Voor remote-accessomgevingen past daarnaast Sophos Connect of SSL VPN: Welke remote-accessoplossing past?.

Bedrijfsaanbeveling

DNS Protection moet worden beheerd als een veiligheidscontrole, niet als een eenmalige DNS-serverwisseling.

Vanuit Avanet-perspectief moet men vooraf eerlijk beslissen of DNS Protection daadwerkelijk het juiste hulpmiddel voor de omgeving is. Voor veel klassieke firewallinstallaties zijn snelle, redundante DNS-resolvers plus goed onderhouden Threat Feeds op de firewall de robuustere bedrijfsvariant. DNS Protection is vooral de moeite waard als de bedrijfsvoering ook de Central-beleid, logs, categorieën, domeinlijsten en Endpoint-component actief wil gebruiken.

Regelmatig controleren:

• Locaties en WAN-IP-adressen kloppen.
• DHCP verspreidt nog steeds de juiste DNS-servers.
• Interne DNS Request Routes zijn actueel.
• Beleid en domeinlijsten hebben eigenaar en beoordelingsdatum.
• Logs worden geëvalueerd.
• Geblokkeerde topdomeinen worden op false positives gecontroleerd.
• Nieuwe locaties, VPN-netwerken en gastnetwerken zijn in het ontwerp meegenomen.

Voor detectiethema’s kan Sophos Firewall NDR en Active Threat Response beheren aanvullen. Voor bekende kwaadaardige IP’s, domeinen en URL’s op firewallniveau blijven Sophos Firewall Threat Feeds relevant.

Checklist

• Sophos Central DNS Protection licentie gecontroleerd.
• Locatie als locatie aangemaakt.
• Location-type correct gekozen: Traditional DNS voor firewalllocaties, Secure DNS voor Endpoint DNS Protection.
• Openbare WAN-IP of DDNS-FQDN correct ingevoerd.
• Location-limiet en IP-/FQDN-vermeldingen bewust gepland.
• DNS Protection IP-adressen uit Central gekopieerd.
• Sophos Firewall gebruikt DNS Protection als DNS-forwarder.
• Interne domeinen met DNS Request Routes gedekt.
• DHCP verspreidt de firewall als DNS-resolver.
• Secondary DNS op clients bewust beslist en niet per ongeluk als bypass gebouwd.
• Directe DNS-omzeiling gecontroleerd en indien nodig via NAT omgeleid.
• DoH, DoT, VPN-profielen en browserrichtlijnen apart gecontroleerd.
• DNS Protection Root Certificate voor blokkeerpagina’s gepland.
• Endpoint-platformen en niet-ondersteunde apparaten apart beoordeeld.
• Testlink uit Sophos Central succesvol gecontroleerd.
• Logs en rapporten in Sophos Central gecontroleerd.
• False-positiveproces en domeinlijstbeoordeling gedefinieerd.

FAQ