DNS Resolution Required kan het internet veiliger maken
Een nieuw beveiligingsmechanisme in de strijd tegen malware (deel 1 van 2)
De oorspronkelijke blog is in het Engels. Dit is de Nederlandse vertaling.
In deze blogpost introduceren we het concept van DNS Resolution Required (DRR). Dit is een nieuw mechanisme voor edgenetwerken dat een client alleen toestaat om een netwerkverbinding met een extern eindpunt te initiëren als er een DNS-zoekactie op een geautoriseerde DNS-server aan vooraf is gegaan. Dit eenvoudige maar doeltreffende idee kan een waardevolle bijdrage leveren aan de strijd tegen botnets en andere malware die wijzigingen aanbrengen in DNS-instellingen of zelf DNS-resolutie uitvoert, zoals DNSChanger en Feederbot.
DRR kan de bescherming die door DNS-firewalls wordt geboden, aanzienlijk vergroten en systemen zonder DNS-firewall extra bescherming bieden. Tegelijkertijd is het zowel effectiever als flexibeler dan simpelweg al het DNS-verkeer blokkeren. DRR heeft enkele limitaties, maar in omgevingen waar deze niet relevant zijn of kunnen worden omzeild, denken we dat DRR een belangrijke extra beveiligingslaag biedt. We zien DRR vooral als waardevol in beperkte omgevingen, waar beheertoegang tot met het internet verbonden apparaten beperkt is (zoals bij het Internet of Things) of waar behoefte is aan extra beveiliging (zoals bij medische apparaten die verbonden zijn met het internet). In dit eerste deel van onze tweedelige blogpost bespreken we het concept van DRR en de relevantie ervan. In deel twee gaan we in op de operationalisering van DRR.
DNS-blokkering en DNS-firewalls
DNS-blokkering is een bekende, veelgebruikte techniek die clients beschermt tegen kwaadaardig verkeer door domeinnamen te blokkeren waarvan bekend is dat ze kwaadaardig zijn. DNS-servers waarbij DNS-blokkering geïmplementeerd is, worden DNS-firewalls genoemd. Ze houden een blokkeringslijst bij van domeinnamen en IP-adressen waarvan bekend is dat ze command-and-control centra voor malware of botnets hosten. Als een client probeert om een domein op de lijst om te zetten, retourneren ze een fout in plaats van het omgezette adres. Voorbeelden van DNS-firewalls zijn publieke resolverdiensten zoals OpenDNS, waarmee gebruikers filterregels kunnen instellen, en lokale DNS-resolvers die DNS Response Policy Zones (RPZ) implementeren, zoals BIND of Unbound. Unbound kan bijvoorbeeld worden geconfigureerd met een RPZ, om te voorkomen dat de bots in een botnet (zoals Feederbot) contact maken met hun command-and-control-domeinen. Dit verstoort de werking van het botnet en voorkomt dat andere machines door het botnet worden geïnfecteerd of ten prooi vallen aan door botnets aangedreven DDoS-aanvallen.
Het probleem: DNS-firewalls bieden beperkte bescherming tegen malware
Het probleem met DNS-firewalls is dat ze maar een beperkte mate van bescherming tegen malwarebieden: malware kan zelf de DNS-resolutie uitvoeren (bv. Cutwail), de DNS-resolutie gewoon helemaal overslaan (bv. Nugache) of zelfs de DNS-configuratie van het systeem volledig veranderen (bv. DNSChanger). In dit soort scenario's is de malware niet afhankelijk van de DNS-resolver die door de systeembeheerder of ISP is ingesteld. DNS-firewalls bieden geen enkele bescherming tegen dergelijke malware, dus zijn er aanvullende beveiligingsmaatregelen nodig.
Effectievere bescherming tegen malware met DNS Resolution Required
We moeten edgenetwerken beter beschermen tegen dergelijke malware door ze uit te rusten met een extra beveiligingsfunctie die we de naam "DNS Resolution Required" (DRR) hebben gegeven. In het kort komt het erop neer dat een netwerk met DRR ervoor zorgt dat elke verbinding tussen een client en een externe dienst pas tot stand komt na een DNS-antwoord van een van de geautoriseerde DNS-resolvers van het netwerk, welke we definiëren als de resolvers die zijn geconfigureerd door de gebruiker of netwerkbeheerder (van bijvoorbeeld de ISP of het bedrijfsnetwerk). DRR doet dat door het DNS-verkeer op het netwerk te analyseren. Standaard wordt al het uitgaande verkeer van clients naar welk IP-adres dan ook geblokkeerd, behalve DNS-verkeer naar specifieke geautoriseerde DNS-resolvers. Als er als reactie op een DNS-verzoek van een client een DNS-antwoord van een van die resolvers wordt waargenomen, wordt de firewall van het lokale systeem of lokale netwerk dynamisch geopend voor de IP-adressen in dat antwoord. Een DRR-systeem is een aanvulling op een DNS-firewall. Zonder firewall biedt DRR bescherming tegen DNS-lekken, malware die DNS-wijzigingen aanbrengt en malware die de lokale DNS-configuratie probeert te omzeilen, bijvoorbeeld om zichzelf te beschermen tegen inbraakdetectie op basis van DNS. Maar de echte waarde van DRR ligt in de combinatie met een DNS-resolver die blokkeringslijsten met DNS-malware implementeert: DNS-query's kunnen alleen naar die resolver worden gestuurd en verkeer wordt alleen toegestaan als die resolver een geldig antwoord heeft geretourneerd.
Bestaande oplossingen
Er bestaan al maatregelen tegen sommige van de hierboven genoemde soorten malware. Het is bijvoorbeeld mogelijk om simpelweg al het verkeer naar poort 53 te blokkeren, behalve het verkeer naar de geautoriseerde resolver. Een andere mogelijkheid is om al het DNS-verkeer op de firewall te kapen en om te leiden naar de geconfigureerde resolver. Dergelijke oplossingen zijn effectief in situaties waarin de malware zelf de DNS-resolutie uitvoert, maar alleen als daarbij gebruik wordt gemaakt van DNS over poort 53 (de klassieke aanpak) en niet van bijvoorbeeld DNS over HTTPS. Ze hebben ook geen effect bij malware die rechtstreeks verbinding met IP-adressen maakt. DRR is een nieuw concept dat bescherming biedt tegen álle soorten malware die hierboven zijn genoemd. Vooral als het wordt gebruikt in combinatie met een up-to-date DNS-firewall. De DNS-firewall houdt bekende malware tegen, terwijl DRR beschermt tegen alles wat het gebruik van de DNS-firewall zou kunnen omzeilen.
Hoe DNS Resolution Required werkt
Figuur 1 geeft een globaal overzicht van de manier waarop een DRR-systeem opereert. Als een client een DNS-zoekactie uitvoert en een van de geautoriseerde DNS-resolvers een antwoord retourneert dat IP-adressen bevat, staat het DRR-systeem verkeer naar die externe IP-adressen toe door de firewall de benodigde instructies te sturen. Zodra de DNS Time to Live (TTL) is verstreken, worden de IP-adressen weer geblokkeerd.
Figuur 1: DRR-sequentiediagram Het resultaat is dat een client in het netwerk geen contact kan maken met een extern IP-adres totdat het IP-adres is verschenen in een DNS-antwoord. Als de client dus malware uitvoert en met een andere niet-geautoriseerde resolver werkt of rechtstreeks externe IP-adressen gebruikt, wordt het verkeer op de firewall geblokkeerd en kan de malware geen schade meer aanrichten.
Vereisten en limitaties van DRR
Om te functioneren moet een DRR-systeem het DNS-verkeer kunnen zien, vooral de DNS-antwoorden van de geconfigureerde resolver. In zijn meest elementaire vorm vereist dat het gebruik van standaard, onversleuteld DNS-verkeer over poort 53. Het gebruik van DNS over HTTPS (DoH) of DNS over TLS (DoT) zou resulteren in verbindingsfouten, omdat DRR de firewall niet zou openen voor de omgezette domeinnamen. Om met DoH of DoT te kunnen werken, zou het DRR-systeem ofwel een DNS-proxy moeten zijn, ofwel een out-of-band-verbinding met de resolver nodig hebben om de benodigde informatie op te halen. Natuurlijk moet het DRR-systeem ook communiceren met de firewall. Het moet worden geïntegreerd in de firewallsoftware zelf of zo worden geconfigureerd dat het de firewall de juiste open- en sluitopdrachten stuurt voor omgezette domeinnamen en IP-adressen. Een gegeneraliseerd DRR-systeem zou daarom een modulair ontwerp moeten hebben, zodat het met diverse firewallimplementaties kan werken.
Omdat verkeer alleen is toegestaan van en naar IP-adressen die zijn waargenomen in DNS-antwoorden, heeft DRR de limitatie dat verkeer dat geen gebruik maakt van DNS om IP-adressen te vinden, ook wordt geblokkeerd. Peer-to-peersoftware en een aantal VoIP-oplossingen (voice-over-IP) communiceren bijvoorbeeld IP-adressen binnen hun eigen protocollen, en die adressen zullen standaard door een DRR-systeem worden geblokkeerd.
Volgende blog
In deze blog hebben we het algemene concept van DRR beschreven. De limitaties kunnen een probleem zijn in situaties waarin wordt gewerkt met VoIP, peer-to-peer of een soortgelijk protocol. We zijn echter van mening dat de voordelen van DRR zwaarder wegen dan de limitaties, vooral in omgevingen met beperkte toegang of extra beveiligingseisen. In dergelijke scenario's denken we dat DRR de veiligheid van het netwerk aanzienlijk zou kunnen verbeteren, helemaal in combinatie met een DNS-firewall. In deel 2 bespreken we mogelijke implementatiescenario's en de eerste prototypen van ons DRR-systeem.
