Deze blogpost behandelt enkele overwegingen met betrekking tot het ontwerp en de implementatie van een beveiligd Domain Name System (DNS) op een intern netwerk (KMO en/of corporate).
De doelgroep voor deze uiteenzetting is mensen met een brede technische ICT-gerelateerde kennis in het algemeen en een conceptuele kennis over netwerken en DNS.
Een uitstekende uitleg over DNS en de verschillende DNS-rollen vindt u hier . Een uitgebreide uitleg over Active Directory is hier te vinden. Houd er rekening mee dat de gekoppelde inhoud door derden wordt beheerd en daarom kan tomsnauwaert.com geen enkele verantwoordelijkheid accepteren voor de (beschikbaarheid van de) inhoud die daarin wordt gepresenteerd.
De volgende onderwerpen worden in deze post behandeld.
De publieke authoritative DNS-server is de uiteindelijke houder van het IP-adres van de FQDN (Fully Qualified Domain Name) van een machine op het internet dat u wenst te bereiken. Het is de nameserver die de originele zonerecords heeft. Het is geconfigureerd vanuit de oorspronkelijke bron en retourneert antwoorden op vragen die vooraf bepaald zijn door de administratieve autoriteit voor die specifieke zone. Deze DNS-servers geven enkel antwoord op vragen voor de zones die waarvoor geconfigureerd zijn. Dit maakt ze zeer efficiënt en snel.
In het geval van beschadigde of gewijzigde gegevens op de authoritative DNS-servers, kan uw bedrijf volledig geïsoleerd worden van het Internet. Alle communicatie op het Internet is afhankelijk van de authoritative DNS-servers om DNS-records (hostnamen, e-maildomeinen, ...) te vertalen (op te lossen) naar IP-adressen, omdat de feitelijke communicatie op het Internet wordt uitgevoerd tussen IP-adressen.
Om redenen van onafhankelijkheid van domeinregisters en internetproviders kan er besloten worden om een eigen set publieke authoritative DNS-servers te gebruiken.
Het is echter belangrijk dat de onderstaande best practices worden gevolgd bij het beheren van publieke authoritative DNS-servers:
Figuur 1 - Publieke Authoritative DNS Infrastructuur
Figuur 1 hierboven laat zien dat onze publieke authoritatieve DNS-servers beschikbaar worden gesteld voor queries vanuit het Internet met behulp van publieke virtuele IP-adressen (VIP) die gerouteerd worden via 2 onafhankelijke internetproviders. Deze ontwerpbeslissing is genomen om ervoor te zorgen dat de publieke authoritatieve DNS-service beschikbaar blijft in het geval van een onderbreking van de service van een van de ISP's.
De servers die verantwoordelijk zijn voor het verwerken van de DNS-query's komende van het Internet zijn slave DNS-servers, die verborgen zijn achter een redundante Internet Access Street. Ze bevinden zich op een DMZ (gedemilitariseerde zone) met private IP-adressen. De Firewall-component van de Internet Access Street is verantwoordelijk voor de NATting (Network Address Translation) van de VIP-adressen naar de private adressen. Enkel DNS (UDP-poort 53) en mogelijk ook ICMP-verkeer zijn toegestaan naar de slave DNS-servers via de Internet Access Street. De Internet Access Street moet toepassingsbewust zijn en dus in staat zijn om foutieve en eventueel kwaadwillige DNS (en ICMP) pakketten uit te filteren die mogelijk invloed hebben op de slave DNS-servers.
De authoritatieve master DNS-server die de originele kopie van de authoritatieve zonebestanden bevat, is om veiligheidsredenen niet toegankelijk via het Internet. De DNS-replicatie van de zonebestanden naar de slave DNS-servers wordt uitgevoerd via het Out of Band (OoB) beheernetwerk (VLAN).
Het operationele beheer van de DNS-servers wordt ook uitgevoerd met behulp van het OoB-beheernetwerk. De slave DNS-servers moeten luisteren op UDP-poort 53 (DNS) op zowel de DMZ- als de Management-interface. De reden is dat de slave DNS-servers meldingen van de master-DNS-server moeten kunnen ontvangen in geval van wijzigingen in authoritatieve DNS-zones, zodat de slave DNS-servers een replicatie kunnen initiëren. Potentieel monitoring- en logging-verkeer verloopt ook via het OoB-netwerk om ervoor te zorgen dat het productieverkeer niet wordt beïnvloed.
Mijn voorkeursplatform (kosteneffectief en gemakkelijk te onderhouden) voor het ter beschikking stellen van authoritative DNS-servers is een virtuele machine met een minimale voetafdruk (kern) van een stabiele distributie van Linux (bijvoorbeeld RHEL/CentOS 7 of 8) en een stabiele versie van bind. Om een extra beveiligingslaag op de toonaangevende DNS-server zelf te garanderen, zorg ik ervoor dat de netwerkadapters worden beheerd door NetworkManager. Ik zorg er ook voor dat de netwerkadapters geconfigureerd zijn in de juiste firewallzone en dat alleen de vereiste protocollen zijn toegestaan voor de respectieve zones. Bovendien zorg ik ervoor dat SELinux is ingeschakeld en dat het SELinux-beleid is ingesteld op 'enforcing'.
Een recursive DNS-server ontvangt DNS-query's van clients en servers, en mogelijk ook andere DNS-servers. de recursive DNS-server voert vervolgens een zoekopdracht van de query uit op de authoritative servers volgens de volledige DNS-hiërarchie (rootservers, top level domain servers, authoritative servers). Wanneer het record dat het onderwerp van de DNS-query was, wordt gevonden, sturen de recursive DNS-servers het antwoord terug naar de machine die de query initieerde en slaan het antwoord gedurende een vooraf bepaalde periode op in het cachegeheugen (gedefinieerd in de authoritative zone), om toekomstige DNS-zoekopdrachten te versnellen.
Figuur 2 - Recursive DNS Infrastructuur
De recursive DNS-servers zijn verbonden met elk subnet dat clients bevat, die hun vragen rechtstreeks naar de recursive DNS-servers verzenden. Deze clients zijn interne authoritative DNS-servers, die in de volgende sectie worden besproken, mobiele en andere IoT-apparaten (Internet of Things), mogelijke industriële ICT-apparaten op een productienetwerk. De multihomed setup van de DNS-servers is gedaan om de noodzaak van extra Firewall-policies of zelfs extra IP-routes te elimineren. Het gekozen ontwerp is ook performanter dan een ontwerp waarin de DNS-query's via het interne netwerk worden gerouteerd.
De recursive DNS-servers hebben geen authoritative zones, behalve de zone met records van de rootservers. Het enige doel van de recursive DNS-servers is het oplossen van vragen van de clients. Houd er rekening mee dat het mogelijk is om forwarding naar recursive DNS-servers van ISP's te definiëren, maar de ervaring leert dat dit niet altijd de beste oplossing is als het gaat om prestaties en beschikbaarheid.
De recursive DNS-servers mogen alleen op de DNS-poort (UDP 53) luisteren (en mogelijk ook ICMP). Op het beheer-VLAN kunnen extra vereiste poorten zoals SSH en worden toegestaan.
Net als voor de authoritative DNS-architectuur is mijn voorkeursplatform (kosteneffectief en gemakkelijk te onderhouden) om recursive DNS-servers ter beschikking te stellen een virtuele machine met een minimale voetafdruk (kern) van een stabiele distributie van Linux (bijv. RHEL/CentOS 7 of 8) en een stabiele versie van bind. Om een extra beveiligingslaag op de toonaangevende DNS-server zelf te garanderen, zorg ik ervoor dat de netwerkadapters worden beheerd door NetworkManager. Ik zorg er ook voor dat de netwerkadapters zijn geconfigureerd in de juiste firewallzone en dat alleen de vereiste protocollen zijn toegestaan voor de respectieve zones. Bovendien zorg ik ervoor dat SELinux is ingeschakeld en dat het SELinux-beleid is ingesteld op 'enforcing'.
De interne authoritative DNS-server is de houder van het IP-adres van de FQDN (Fully Qualified Domain Name) van de machines op de interne VLAN's die in het interne domein zijn gedefinieerd. Het is de naamserver die de oorspronkelijke zonerecords voor het interne netwerk heeft. In de meeste gevallen bestaan de interne authoritative DNS-servers uit een set Microsoft Active Directory-servers.
Hoewel het feit dat machines die aangesloten zijn op het active directory-domein automatisch geregistreerd worden in het DNS-domein, is het mogelijk om apparaten (zoals netwerkapparaten, Linux-servers, ...) handmatig toe te voegen aan het interne DNS-domein(en). In de meeste gevallen dienen de interne authoritative DNS-servers ook als recursive servers, omdat de meeste apparaten in het Active Directory-domein verwijzen naar de domeincontrollers (die ook de interne authoritative DNS-servers bevatten) voor DNS-resolutie.
Het is mogelijk om de interne authoritative DNS-servers de hele DNS-hiërarchie op internet (root-servers, top-level domeinservers en authoritative servers) te laten doorzoeken. Ik configureer bij voorkeur forwarders op de interne authoritative DNS-servers om de belasting over te dragen naar speciale recursive DNS-servers zoals besproken in de vorige sectie.
Figuur 3 - Interne Authoritative DNS Infrastructuur
n het geval van een Microsoft Active Directory-implementatie worden de authoritative DNS-zonerecords geïntegreerd in de active directory. De replicatie van deze zones wordt afgehandeld door de active directory zelf (DFS-replicatie).
Ik gebruik liever geen multi-homed configuratie voor de Microsoft Active Directory-servers (onder andere omdat in veel gevallen het beheersubnet als een site in de Active Directory-servers wordt gedefinieerd en Active Directory-servers bevat). In plaats daarvan wordt het operationele beheer van de Microsoft Active Directory-servers uitgevoerd via de interne firewalls.
Merk op dat de publieke authoritative DNS-servers en de recursive DNS-servers verwijzen naar de interne authoritative DNS-servers voor hun eigen DNS-clientresolutie (bijvoorbeeld voor de resolutie van de adressen van de websites die patches en updates bevatten). De interne authoritative DNS-servers wijzen naar elkaar voor hun eigen DNS-resolutie.
Een DNS Firewall is een netwerkbeveiligingsoplossing die voorkomt dat netwerkgebruikers en systemen verbinding maken met bekende kwaadaardige internetlocaties. Een DNS Firewall werkt met behulp van DNS Response Policy Zones (RPZ's) en bruikbare informatie over bedreigingen om exfiltratie van gegevens te voorkomen.
DNS Firewalls kunnen ook inzicht bieden in bedreigingen, helpen met het isoleren en herstellen van geïnfecteerde apparaten en bijblijven met het veranderende landschap van bedreigingen via een geautomatiseerde feed met bedreigingsinformatie.
De Internet Access Street bevat een DNS Firewall die alle vragen inspecteert die afkomstig zijn van de recursive DNS-servers die in dit gedeelte worden besproken.
Ik heb een paar pogingen gedaan om één uitgebreid schematisch overzicht te maken van al het bovenstaande, maar om eerlijk te zijn, het resultaat was nogal rommelig. In plaats daarvan besloot ik een paar scenario's met DNS-query's te documenteren om het hele ontwerp te verduidelijken.
In dit scenario wil een gebruiker die op een Microsoft Windows 10-pc werkt die zich op het interne netwerk bevindt, op het Internet surfen naar https://www.google.com. We gaan ervan uit dat er geen proxy-servers zijn geconfigureerd en dat de client-pc rechtstreeks verbinding maakt met het Internet via de Internet Access Street. Om dit te kunnen doen, moet de client-pc het IP-adres van de host www.google.com opzoeken.
Figuur 4 - DNS request van interne client
In bovenstaande figuur 4 vertegenwoordigen de genummerde pijlen de verschillende DNS-query's van dit scenario. De query's worden aangeduid met het nummer in de figuur, gevolgd door een Q. De antwoorden op deze query's zijn gelabeld met een R.
0Q: De client zoekt in zijn eigen DNS-cache naar het adres van www.google.com. Als een overeenkomst wordt gevonden, is het proces voltooid.
1Q: De client-pc verzendt de zoekopdracht voor www.google.com naar de geconfigureerde DNS-servers, in dit geval de interne authoritative DNS-servers.
2Q: De interne authoritative DNS-servers controleren of het adres voor www.google.com in de cache is opgeslagen. Als het adres van www.google.com in de cache is opgeslagen, wordt de rest van het proces overgeslagen tot stap 1R. De query wordt doorgestuurd naar alle geconfigureerde forwarders, de recursive DNS-servers. In de bovenstaande configuratie zijn beide recursive DNS-servers geconfigureerd als forwarder van de interne authoritative DNS-servers (active directory-servers).
3Q: De recursive DNS-servers controleren hun cache voor www.google.com. Als het adres beschikbaar is in de cache, gaat het proces verder bij stap 2R. Anders sturen de recursive DNS-servers een query naar de rootservers om het adres of de adressen van de DNS-servers voor het .com top level domein te vinden.
3R: De DNS-rootserver beantwoordt de query van de recursive servers met het adres van de top level DNS-servers voor het .com top level domein.
4Q: De recursive DNS-servers sturen een query naar de DNS Top Level Domain Servers om het adres(sen) van de authoritative DNS-servers voor het google.com-domein te vinden.
4R: De DNS Top Level Domain-server beantwoordt de vraag van de recursive servers met het adres of de adressen van de authoritative DNS-servers voor het google.com-domein.
5Q: De recursive DNS-servers sturen een vraag naar de authoritative DNS-servers voor google.com om het adres of de adressen van de host www.google.com te vinden.
5R: De authoritative DNS-server voor het domein google.com beantwoordt de vraag van de recursive servers met het adres of de adressen van de host www.google.com. Het antwoord op de vraag wordt ook opgeslagen in de cache van de recursive DNS-server.
2R: De recursive DNS-server beantwoordt de vraag 2Q van de interne authoritative DNS-servers met het adres of de adressen van de host www.google.com. Het antwoord op de vraag wordt ook opgeslagen in de cache van de interne authoritative DNS-server die in dit geval als een recursive DNS-server functioneert.
1R: De interne authoritative DNS-server beantwoordt de vraag 1Q van de client-pc met het adres of de adressen van de host www.google.com.
De vragen 3R, 4R & 5R worden allemaal geïnspecteerd door de DNS Firewall in de Internet Access Street. In het geval dat een query voor een kwaadaardig domein/host wordt gedetecteerd, wordt de query geblokkeerd en wordt een vooraf geconfigureerd adres geretourneerd.
In dit scenario wil de interne authoritative DNS-server, een Microsoft Windows Active Directory-server die zich op het interne netwerk bevindt, een controle op updates uitvoeren. Daarom moet de FQDN update.microsoft.com worden opgezocht. We gaan ervan uit dat er geen proxyservers zijn geconfigureerd en dat de Active Directory-server rechtstreeks verbinding maakt met het Internet via de Internet Access Street.
U zult zien dat dit scenario erg lijkt op scenario 1. Ik heb dit scenario toch toegevoegd, omdat de Active Directory-server ook naar zichzelf verwijst voor DNS-resolutie.
Figuur 5 - AD Server DNS request
In bovenstaande figuur 5 vertegenwoordigen de genummerde pijlen de verschillende DNS-query's van dit scenario. De query's worden aangeduid met het nummer in de figuur, gevolgd door een Q. De antwoorden op deze query's zijn gelabeld met een R.
0Q: De DNS-client van Active Directory Server 2 zoekt in zijn eigen DNS-cache (dus niet de cache van de DNS-server die wordt uitgevoerd op Active Directory Server 2) naar het adres update.microsoft.com. Als een overeenkomst wordt gevonden, is het proces voltooid.
1Q: De DNS-client van Active Directory Server 2 verzendt de query voor update.microsoft.com naar de geconfigureerde DNS-servers, in dit geval de interne authoritative DNS-servers, dit omvat ook de machine Active Directory Server 2. Dit betekent dat de DNS-client die actief is op Active Directory Server 2 de query inderdaad ook naar de DNS-server op de machine zelf zal versturen.
2Q: De interne authoritative DNS-servers (actieve directoryservers) controleren of het adres voor update.microsoft.com in de cache is opgeslagen (let op het verschil tussen de cache van het DNS-clientproces en de cache van het DNS-serverproces). Als het adres van update.microsoft.com in de cache is opgeslagen, wordt de rest van het proces overgeslagen tot stap 1R. De query wordt doorgestuurd naar alle geconfigureerde forwarders, de recursive DNS-servers. In de bovenstaande configuratie zijn beide recursive DNS-servers geconfigureerd als forwarder van de interne authoritative DNS-servers (active directory-servers).
3Q: De recursive DNS-servers controleren hun cache op update.microsoft.com, als het adres beschikbaar is in de cache, gaat het proces verder bij stap 2R. Anders sturen de recursive DNS-servers een query naar de rootservers om het adres of de adressen van de DNS-servers voor het .com top level domein te vinden.
3R: De DNS-rootserver beantwoordt de query van de recursive servers met het adres van de top level DNS-servers voor het .com top level domein.
4Q: De recursive DNS-servers sturen een query naar de DNS Top Level Domain Servers om het adres(sen) van de authoritative DNS-servers voor het microsoft.com domein te vinden.
4R: De DNS Top Level Domain-server beantwoordt de query van de recursive server met het adres of de adressen van de authoritative DNS-servers voor het microsoft.com domein.
5Q: De recursive DNS-servers sturen een query naar de authoritative DNS-servers voor microsoft.com om het adres of de adressen van de host update.microsoft.com te vinden.
5R: De authoritative DNS-server voor het domein microsoft.com beantwoordt de query van de recursive servers met het adres of de adressen van de host update.micrsoft.com. Het antwoord op de vraag wordt ook opgeslagen in de cache van de recursive DNS-server.
2R: De recursive DNS-server beantwoordt de vraag 2Q van de interne authoritative DNS-server met het adres of de adressen van de host update.microsoft.com. Het antwoord op de vraag wordt ook opgeslagen in de cache van de interne authoritative DNS-server die in dit geval als een recursive DNS-server functioneert.
1R: De interne authoritative DNS-server beantwoordt de vraag 1Q van de DNS-client op de machine Active Directory Server 2 met het adres of de adressen van de host update.microsoft.com.
De vragen 3R, 4R & 5R worden allemaal geïnspecteerd door de DNS Firewall in de Internet Access Street. In het geval dat een query voor een kwaadaardig domein/host wordt gedetecteerd, wordt de query geblokkeerd en wordt een vooraf geconfigureerd adres geretourneerd.
In dit scenario wil een gebruiker die ergens op het Internet met een pc werkt naar https://www.tomsnauwaert.com surfen. We gaan ervan uit dat er geen proxyservers zijn geconfigureerd voor de externe client en dat de externe client rechtstreeks met het Internet verbonden is. Om dit te kunnen doen, moet de externe client-pc het IP-adres van de host www.tomsnauwaert.com opzoeken.
Figuur 6 - DNS resolutie voor request van externe client
In bovenstaande figuur 6 vertegenwoordigen de genummerde pijlen de verschillende DNS-query's van dit scenario. De query's worden aangeduid met het nummer in de figuur, gevolgd door een Q. De antwoorden op deze query's zijn gelabeld met een R.
0Q: De client zoekt in zijn eigen DNS-cache naar het adres van www.tomsnauwaert.com. Als een overeenkomst wordt gevonden, is het proces voltooid.
1Q: De client-pc verzendt de zoekopdracht voor www.tomsnauwaert.com naar de recursive DNS-server van zijn ISP.
2Q: De recursive DNS-server controleert de cache op www.tomsnauwaert.com. Als het adres beschikbaar is in de cache, gaat het proces verder bij stap 1R. Anders sturen de recursive DNS-servers een query naar de rootservers om het adres of de adressen van de DNS-servers voor het .com top level domein te vinden.
2R: De DNS-rootserver beantwoordt de query van de recursive servers met het adres van de Top Level DNS-servers op het hoogste niveau voor het .com top level domein.
3Q: De recursive DNS-servers sturen een query naar de DNS Top Level Domain Servers om het adres(sen) te vinden van de authoritative DNS-servers voor het tomsnauwaert.com-domein, onze publieke authoritative DNS-server.
3R: De top level domein DNS-server beantwoordt de vraag van de recursive servers met het publieke adres van onze authoritative DNS-servers voor het domein tomsnauwaert.com.
4Q: De recursive DNS-servers sturen een vraag naar onze authoritative DNS-servers voor tomsnauwaert.com om het adres(sen) van de host www.tomsnauwaert.com te vinden.
4R: Onze authoritative DNS-server voor het domein tomsnauwaert.com beantwoordt de vraag van de recursive servers met het adres(sen) van de host www.tomsnauwaert.com. Het antwoord op de vraag wordt ook opgeslagen in de cache van de recursive DNS-server.
1R: De recursive DNS-server beantwoordt de vraag 1Q van de client-pc met het adres(sen) van de host www.tomsnauwaert.com.
De vraag 4R wordt geïnspecteerd door de Internet Access Street. In het geval dat een kwaadwillige zoekopdracht is verzonden, wordt de zoekopdracht geblokkeerd in de Internet Access Street en wordt er geen adres geretourneerd.
In dit scenario voert een van onze publieke authoritative DNS-servers een controle uit op updates, waarvoor de FQDN mirror.centos.org moet worden opgelost.
Figure 7 - DNS Client op publieke authoritative server zoekt adres op
In bovenstaande figuur 7 vertegenwoordigen de genummerde pijlen de verschillende DNS-query's van dit scenario. De query's worden aangeduid met het nummer in de figuur, gevolgd door een Q. De antwoorden op deze query's zijn gelabeld met een R.
0Q: De DNS-client van de publieke authoritative DNS Server zoekt in zijn eigen cache naar het adres van mirror.centos.org. Als een overeenkomst wordt gevonden, is het proces voltooid.
1Q: De DNS-client van de publieke authoritative DNS- erver verzendt de query voor mirror.centos.org naar de geconfigureerde DNS-servers, in dit geval de interne authoritative DNS-servers die zich op de beheer-VLAN bevinden.
2Q: De interne authoritative DNS-servers controleren of het adres voor mirror.centos.org in de cache is opgeslagen. Als het adres van mirror.centos.org in de cache is opgeslagen, wordt de rest van het proces overgeslagen tot stap 1R . De query wordt doorgestuurd naar alle geconfigureerde forwarders, de recursive DNS-servers. In de bovenstaande configuratie zijn beide recursive DNS-servers geconfigureerd als forwarders van de interne authoritative DNS-servers (active directory-servers).
3Q: De recursive DNS-servers controleren hun cache op mirror.centos.org, als het adres beschikbaar is in de cache, gaat het proces verder bij stap 2R. Anders sturen de recursive DNS-servers een query naar de rootservers om het adres of de adressen van de DNS-servers voor het .org top level domain te vinden.
3R: De DNS-rootserver beantwoordt de query van de recursive servers met het adres van de top level DNS-servers voor het .org top level domein.
4Q: De recursive DNS-servers sturen een query naar de DNS Top Level Domain Servers om het adres(sen) van de authoritative DNS-servers voor het centos.org-domein te vinden.
4R: De DNS Top Level Domain-server beantwoordt de vraag van de recursive servers met het adres of de adressen van de authoritative DNS-servers voor het centos.org-domein.
5Q: De recursive DNS-servers sturen een query naar de authoritative DNS-servers voor centos.org om het adres of de adressen van de host mirror.centos.org te vinden.
5R: De authoritative DNS-server voor het domein centos.org beantwoordt de query van de recursive servers met het adres(sen) van de host mirror.centos.org. Het antwoord op de vraag wordt ook opgeslagen in de cache van de recursive DNS-server.
2R: De Recursive DNS-server beantwoordt de vraag 2Q van de interne authoritative DNS-servers met het adres of de adressen van de host mirror.centos.org. Het antwoord op de vraag wordt ook opgeslagen in de cache van de interne authoritative DNS-server die in dit geval als een recursive DNS-server functioneert.
1R: De interne authoritative DNS-server beantwoordt de vraag 1Q van de publieke authoritative DNS-server met het adres(sen) van de host mirror.centos.org.
De vragen 3R, 4R & 5R worden allemaal geïnspecteerd door de DNS Firewall in de Internet Access Street. In het geval dat een query voor een kwaadaardig domein/host wordt gedetecteerd, wordt de query geblokkeerd en wordt een vooraf geconfigureerd adres geretourneerd.
Dat is het! Ik hoop dat je deze blogpost interessant vond. Neem gerust contact met me op in het geval van opmerkingen en/of vragen.
18 November 2019, door Tom Snauwaert.