DNS koppelt een leesbare domeinnaam aan een IP-adres dat door netwerkapparatuur kan worden gebruikt. De TCP-poorten bepalen welke diensten een inkomende verbinding accepteren of weigeren. Deze twee mechanismen, die vaak eenmaal worden geconfigureerd en daarna worden vergeten, zijn echter belangrijke aanvalsvectoren wanneer ze slecht worden beheerd.
DNS-resolutie en aanvalsvector: wat verandert de encryptie
Standaard circuleren DNS-verzoeken in het helder op UDP-poort 53. Een aanvaller die zich op het netwerk bevindt, kan deze verzoeken onderscheppen, ze wijzigen of het verkeer naar een kwaadaardige server omleiden. De klassieke DNS-filtering is juist gebaseerd op deze zichtbaarheid: de beheerder inspecteert de verzoeken om gevaarlijke domeinen te blokkeren.
De komst van DNS over HTTPS (DoH) verstoort deze balans. DoH encapsuleert DNS-verzoeken in standaard HTTPS-verkeer, op TCP-poort 443. De inhoud van de verzoeken wordt onzichtbaar voor netwerkbewakingshulpmiddelen. Een werkstation dat is geconfigureerd om een externe DoH-resolver te gebruiken, kan zo de volledige DNS-filtering van het bedrijf omzeilen zonder een waarschuwing te veroorzaken.
De oplossing is niet om DoH blindelings te blokkeren. De aanbevolen aanpak is om een interne, DoH-compatibele DNS-resolver te definiëren, en vervolgens het gebruik ervan op de werkstations af te dwingen via groepsbeleid of een MDM.
Verzoeken naar niet-goedgekeurde externe resolvers worden dan op het niveau van de firewall geblokkeerd. Deze configuratie behoudt de vertrouwelijkheid van DNS-uitwisselingen terwijl de filtercapaciteit behouden blijft, zoals gedetailleerd in de beveiligingsgids op Open Syd in het gedeelte dat gewijd is aan het versterken van netwerkbeleid.
Open TCP-poorten: de blootgestelde oppervlakte van het netwerk verkleinen
Elke open TCP-poort op een server vertegenwoordigt een potentieel toegangspunt. Een dienst die luistert op een ongebruikte of niet-gecontroleerde poort biedt een directe kans voor een aanvaller om een verbinding te proberen, een kwetsbaarheid te exploiteren of een commandokanaal op te zetten.
Identificeer de werkelijk noodzakelijke poorten
De eerste stap is een inventarisatie. Te veel omgevingen behouden open poorten die zijn overgebleven van oude configuraties: testdiensten, tijdelijke beheersinterfaces, verouderde protocollen. Een regelmatige scan van de blootgestelde poorten, van buiten het netwerk, onthult vaak diensten waarvan niemand het bestaan vermoedde.
De poorten die prioriteit hebben voor monitoring:
- Poort 53 (DNS) moet beperkt zijn tot alleen de goedgekeurde interne DNS-servers, en het uitgaande DNS-verkeer naar niet-goedgekeurde externe resolvers moet op de firewall worden geblokkeerd
- Poort 443 (HTTPS) verdient bijzondere inspectie omdat DoH daarover loopt, waardoor het mogelijk is om gegevens te exfiltreren of beveiligingsbeleid te omzeilen
- De poorten voor externe administratie (22 voor SSH, 3389 voor RDP) mogen nooit direct op internet worden blootgesteld zonder tussenliggende gateway of VPN
- De poorten die zijn gekoppeld aan legacy-diensten (Telnet op poort 23, FTP op poort 21) zouden moeten worden uitgeschakeld ten gunste van hun versleutelde tegenhangers
Pas het principe van de minste privileges toe op netwerkverkeer
Elke firewallregel zou een specifieke bron, bestemming en poort moeten specificeren. “Any to any” regels op een bepaalde poort komen neer op het openlaten van een deur voor iedereen die het adres kent. Netwerksegmentatie aanvult deze aanpak: het plaatsen van DNS-servers in een toegewijd segment beperkt de laterale verspreiding in geval van compromittering.
DNSSEC en bescherming van het DNS-account: twee complementaire lagen
DNSSEC ondertekent cryptografisch de DNS-antwoorden om te garanderen dat de informatie die door de klant wordt ontvangen, overeenkomt met die welke door de legitieme server is gepubliceerd. Zonder deze validatie kan een aanvaller valse antwoorden injecteren (cachevergiftiging) en het verkeer omleiden naar kwaadaardige servers zonder dat de gebruiker iets opmerkt.
De implementatie van DNSSEC blijft een operationeel onderwerp net zo goed als een cryptografisch onderwerp. Configuratiefouten, met name bij het roteren van de handtekening sleutels, kunnen leiden tot onderbrekingen van de dienst. Activatie vereist daarom voorafgaande tests en een gedocumenteerde rollbackprocedure.
Een vaak verwaarloosd aspect betreft de bescherming van het account dat de DNS-records beheert. Controle over dit account stelt in staat om direct de DNS-antwoorden te wijzigen, het verkeer om te leiden of frauduleuze TLS-certificaten te genereren. Het Amerikaanse agentschap CISA beveelt aan deze toegang te beschermen met multi-factor authenticatie, regelmatig de gepubliceerde records te auditen en de Certificate Transparency-logboeken te monitoren om ongeautoriseerde certificaatuitgifte te detecteren.
NIS2-richtlijn en risicobeheer van DNS in Europa
De Europese richtlijn NIS2 breidt de reikwijdte uit van entiteiten die onderworpen zijn aan cybersecurityverplichtingen. DNS-diensten zijn expliciet opgenomen onder de betrokken entiteiten. De Europese uitvoeringsverordening 2024/2690 specificeert de verwachte technische vereisten, met name op het gebied van cyberrisicobeheer.
Voor organisaties die hun eigen DNS-infrastructuur exploiteren, houdt deze regelgevende evolutie in dat verschillende praktijken geformaliseerd moeten worden:
- Documenteer het beleid voor het beheer van DNS-zones, inclusief zone-overdrachten en replicatiemechanismen
- Implementeer logging van wijzigingen in records en toegang tot DNS-servers
- Integreer de DNS-componenten in de reikwijdte van periodieke beveiligingsaudits
Deze vereisten zijn technisch gezien niet nieuw. NIS2 maakt ze juridisch bindend, met sancties in geval van niet-naleving.
De gezamenlijke beheersing van DNS en TCP-poorten vormt een basis voor netwerkbeveiliging die noch applicatiefirewalls noch antivirussoftware kunnen vervangen. Een correct geconfigureerde DNS-resolver en strikt gefilterde poorten verkleinen de aanvalsvector nog voordat een detectietool in het spel komt.
