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 überhaupt 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:
| Aanpak | Sterkte | Beperking |
|---|---|---|
| Snelle en hoogbeschikbare DNS-resolvers | Zeer goede prestaties, robuuste naamresolutie, weinig operationeel risico | Geen centraal DNS-beleid en geen DNS-rapportage in Sophos Central |
| Threat Feeds op de Sophos Firewall | Bekende kwaadaardige doelen kunnen aan de perimeter worden geblokkeerd zonder de DNS-route te wijzigen | Niet hetzelfde als DNS-categoriefiltering; kwaliteit, tuning en false-positiveproces zijn belangrijk |
| Sophos DNS Protection | DNS-beleid, categorieën, locaties, logs en Endpoint DNS Protection in Sophos Central | Extra afhankelijkheid in de DNS-route; uitrol, 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:
- Sophos Central kent de locatie als Location.
- Sophos Central biedt twee DNS Protection IP-adressen.
- Sophos Firewall gebruikt deze IP-adressen als DNS-forwarder.
- Interne domeinen worden via DNS Request Routes naar interne DNS-servers gestuurd.
- DHCP verspreidt de firewall als DNS-resolver naar clients.
- Optioneel dwingt een NAT-regel af dat uitgaand DNS-verkeer naar de firewall wordt omgeleid.
- 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.
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.
- 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.
- 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.
1. Locatie in Sophos Central aanmaken
In Sophos Central wordt eerst de locatie aangemaakt:
My Products > DNS Protection > Locations
Praktische procedure:
Addselecteren.- Locatienaam en beschrijving invoeren.
- Openbare WAN-IP van de Sophos Firewall invoeren.
- Bij meerdere WAN-interfaces alle relevante openbare IP-adressen of een passend bereik invoeren.
- Bij dynamisch IP een DDNS-FQDN gebruiken als het ontwerp daarop is gebaseerd.
- 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.

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.

3. Sophos Firewall DNS-forwarder configureren
Op de Sophos Firewall:
Network > DNS
Aanbevolen procedure:
Static DNSselecteren.DNS 1instellen op het eerste DNS Protection IP-adres.DNS 2instellen op het tweede DNS Protection IP-adres.DNS 3leeg laten, tenzij er een bewuste uitzondering is.- Onder IPv6 geen aparte IPv6-DNS-servers instellen als de locatie via de IPv4-gebaseerde DNS-Protection-servers moet lopen.
- 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.
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:
| Veld | Voorbeeld |
|---|---|
| Host/domain name | bedrijf.local of corp.example.com |
| Target servers | interne domeincontrollers 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:
- DHCP-server van de betrokken interface bewerken.
- IP-adres van de firewall-interface als primaire DNS-server verspreiden.
- Geen externe DNS-servers als alternatieve client-DNS verspreiden als DNS Protection consequent moet werken.
- DHCP-lease vernieuwen of testclient opnieuw verbinden.
- Met een testclient controleren welke DNS-server daadwerkelijk wordt gebruikt.
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.
- 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:
- Pilotnetwerk of kleine testgroep selecteren.
- Interne domeinen, reverse zones en zoekdomeinen documenteren.
- DNS Request Routes voor interne zones instellen.
- Firewall als DNS-resolver via DHCP verspreiden.
- DNS Protection IP-adressen op de firewall instellen.
- Blokkeerpagina-certificaat op testclients installeren.
- Logs in Sophos Central controleren.
- 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.
| Test | Verwacht resultaat |
|---|---|
| Openbaar domein oplossen | Client vraagt de firewall of de beoogde interne resolver |
| Intern 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 locatie |
| Gastnetwerk testen | Gasten gebruiken de geplande DNS-route 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.
| Policy-type | Voor bedoeld | Wanneer gebruiken |
|---|---|---|
| Filtering policy | Locatie-, firewall- of netwerkgebaseerde DNS-filtering | Voor kantoren, firewalls, DNS-servers, servernetwerken, gasten, IoT en apparaten zonder Sophos Endpoint |
| Endpoint DNS Protection policy | Endpoint-gebaseerde DNS-Protection via Sophos Endpoint | Voor beheerde clients, laptops 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.
- 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.
| Categoriegroep | Typische categorieën | Aanbeveling |
|---|---|---|
| Productivity-related categories | 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, Vehicles | Afhankelijk van bedrijfsbeleid toestaan, blokkeren of alleen voor bepaalde netwerken beperken. |
| Social networking | Blogs & forums, Personals & dating, Social networks | Meestal geen pure veiligheidskwestie. Voor productieve netwerken bewust beslissen in plaats van algemeen blokkeren. |
| Adult and potentially inappropriate categories | 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, Weapons | In veel bedrijfsomgevingen blokkeren. Uitzonderingen alleen met duidelijke reden. |
| Categories likely to cause excessive bandwidth usage | Live audio, Live video, Peer-to-peer & torrents, Radio & audio hosting, Video hosting, Voice & video calls | Vaak relevant voor gast- en clientnetwerken. Bij samenwerkingstools vooraf controleren, zodat legitieme oproepen niet worden verstoord. |
| Business-relevant site categories | General business, Business networking, Educational institutions, Financial services, Government, Health & medicines, Image search, Information technology, Job search, Military, NGOs & non-profits, Political organizations, Professional & workers organizations, Real estate, Reference, Search engines, Software updates, Translators | Meestal toestaan. Bepaalde categorieën kunnen in hoogbeveiligde netwerken worden beperkt. |
| Infrastructure | Content delivery, CRL and OCSP | Normaal gesproken toestaan. Deze categorieën kunnen belangrijk zijn voor updates, certificaatcontrole en veel clouddiensten. |
| Threats and liabilities | Anonymizers, Hacking, Newly registered websites, Parked domains, Phishing & fraud, Spam URLs, Spyware & malware, Unauthorized software stores | In de regel blokkeren. Bij false positives gericht met domeinlijsten werken, niet hele groepen openen. |
| Data loss | Business cloud apps, Personal cloud apps, Personal network storage, Web E-mail | Sterk afhankelijk van DLP-, cloud- en compliance-vereisten. Voor server- en admin-netwerken vaak strenger behandelen dan voor normale gebruikers. |
| Uncategorized | Uncategorized | Niet blind blokkeren. Eerst evalueren, omdat legitieme nieuwe of interne diensten tijdelijk ongecategoriseerd 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.
Als blokkeerpagina’s niet worden weergegeven, moet men niet meteen aan het beleid draaien. Vaak ontbreken certificaten, gebruikt de client een andere DNS-route, of wordt blockpage.dnsprotection.sophos.com door een andere controle verstoord.
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.
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.
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.
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.
- Openbare WAN-IP of DDNS-FQDN correct ingevoerd.
- 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.
- Directe DNS-omzeiling gecontroleerd en indien nodig via NAT omgeleid.
- DNS Protection Root Certificate voor blokkeerpagina’s gepland.
- Testlink uit Sophos Central succesvol gecontroleerd.
- Logs en rapporten in Sophos Central gecontroleerd.
- False-positiveproces en domeinlijstbeoordeling gedefinieerd.