DNS resolution required voor het Internet of Things in de praktijk brengen
Een nieuw beveiligingsmechanisme in de strijd tegen malware (deel 2 van 2)
Kies jouw kleur
Veel bezocht
Veelgestelde vragen
Via de Whois kun je de huidige houder van een domeinnaam opzoeken. Om de persoonsgegevens in te zien moet je vanwege de privacygevoelige informatie eerst de gebruikersvoorwaarden van de Whois accepteren. Gegevens van privé personen kunnen ook afgeschermd zijn vanwege de AVG (Algemene verordening gegevensbescherming).
Op de pagina domeinnaam zoeken lees je meer over wat een domeinnaam is, de werking van de Whois en de privacy van persoonsgegevens.
Je wilt je domeinnaam verhuizen naar een andere registrar. Vraag dan je verhuistoken op bij je huidige registrar. Lees de verhuisstappen op de pagina domeinnaam verhuizen.
Neem contact op met je registrar. Jouw registrar kan de contactgegevens bij je domeinnaam voor je aanpassen. Wij raden je aan het resultaat te controleren via de Whois. Lees meer over het aanpassen van je gegevens bij contactgegevens wijzigen.
Wij weten niet wat de reden van de opheffing is. Neem contact op met je registrar. Het voordeel van de quarantaine is dat je altijd de mogelijkheid hebt om een opheffing die je niet had bedoeld te herstellen.
Voorbeeld: In de voorwaarden van je registrar staat dat je elk jaar je abonnement moet verlengen. Dat gebeurt dan niet automatisch. Zo kan het gebeuren dat je domeinnaam wordt opgeheven zonder dat je er om gevraagd hebt.
Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.
Wil je zelf direct domeinnamen kunnen registreren bij SIDN voor je klanten of voor je eigen organisatie? Dan kun je .nl-registrar worden. Lees meer over de voorwaarden en de manier waarop je je kunt inschrijven als registrar via de pagina registrar worden.
Een nieuw beveiligingsmechanisme in de strijd tegen malware (deel 2 van 2)
De oorspronkelijke blog is in het Engels. Dit is de Nederlandse vertaling.
In een eerder artikel hebben we het concept van DNS Resolution Required (DRR) geïntroduceerd, een nieuwe beveiligingsfunctie om de schade te beperken van malware die het gebruik van geconfigureerde DNS-resolvers op een netwerk wijzigt of omzeilt. DRR is met name nuttig in netwerken met Internet of Things (IoT) apparaten.
In dit artikel bespreken we hoe we DRR hebben geïmplementeerd in een prototype en de resultaten van experimenten met dat prototype. Daarnaast bespreken we alternatieve implementaties en hun voor- en nadelen en ten slotte de generalisatie van DRR buiten het IoT en de beperkingen in niet-IoT-netwerken.
Bij een typische thuisomgeving met IoT-apparaten kunnen we het verkeer filteren op de router. Immers, al het verkeer van de IoT-apparaten naar het internet gaat door (de firewall van) de router heen.
Een veel voorkomende opstelling ziet eruit als in Figuur 1. In dit scenario bevindt de DNS-resolver zich buiten het lokale netwerk. Deze resolver kan worden beheerd door de ISP, of een DNS-dienstverlener zoals Quad9 of Cloudflare.
Als de hosts hun queries rechtstreeks naar een externe DNS-resolver sturen, gebruikmakend van standaard plain-text DNS, is het mogelijk om DRR te implementeren door het DNS-verkeer op te vangen bij de router. In dit scenario beschermt DRR elk apparaat in het lokale netwerk en hoeven de apparaten zelf niet te worden aangepast of bijgewerkt.
Figuur 1: Een algemene opstelling met een externe resolver.
We hebben een eerste prototype van DRR ontwikkeld om het DRR-concept te valideren in het hierboven beschreven scenario. Het prototype draait op de router en werkt door het onderscheppen van DNS-verkeer terwijl de lokale firewallregels worden bijgewerkt.
Om precies te zijn, onderschept de implementatie DNS-verkeer, geeft het door naar de userland daemon van het prototype, werkt de configuratie van de firewall bij, en stuurt dan pas het DNS-antwoord naar de client.
Dit betekent dat DNS-antwoorden worden vertraagd met de tijd die het kost om de firewallregels bij te werken. Een alternatieve aanpak zou geweest zijn om het DNS-antwoord onmiddellijk aan de client door te geven en de firewallupdate op de achtergrond uit te voeren. Die aanpak zou echter problemen kunnen veroorzaken: als de clientapplicatie contact probeert te maken met het externe IP-adres voordat de firewall is bijgewerkt, zou het verkeer nog steeds geblokkeerd worden.
De huidige implementatie van ons prototype ondersteunt alleen iptables met de nfqueue-module. Het is mogelijk om vergelijkbare functionaliteit te bieden voor OpenBSD’s Packet Filter (PF) door middel van divert(4), maar dat hebben we in dit prototype nog niet geïmplementeerd.
We hebben het prototype geëvalueerd door onze dagelijkse activiteiten uit te voeren terwijl we de applicatie draaiden op ons werkstation in een thuisnetwerkomgeving. Hoewel dit niet het echte doelscenario is dat we in gedachten hebben voor DRR, geeft het wel een goed gevoel van de effecten van het gebruik van DRR in een thuisnetwerk.
Bij bezoeken van webpagina’s namen we geen mislukte verbindingen waar. Maar browsen met het DRR-prototype was merkbaar langzamer dan wanneer DRR niet was ingeschakeld. Dat is niet vreemd, omdat elk DNS-antwoord werd onderschept en verwerkt voordat het werd afgeleverd bij onze browser. Dit vertraagt elke verbinding waarvoor een DNS-lookup nodig is en de relevante gegevens niet lokaal in de cache zijn opgeslagen. Aangezien het laden van een webpagina veel DNS-query’s nodig kan hebben is de vertraging aanzienlijk als een website voor de eerste keer wordt bezocht. In gevallen waarin een cliënt maar contact hoeft te maken met een paar externe diensten, zoals in een IoT-scenario, heeft deze vertraging geen merkbaar effect. Een mogelijke manier om de vertraging te verbeteren is het gebruik van een systeem als ipset voor efficiëntere updates.
Het prototype bleek nog een ander probleem te hebben, dat zeker kon worden opgelost met een betere implementatie. Het prototype is geschreven in Python en gebruikt nfqueue om de DNS-pakketten te vertragen. De Python-nfqueue-wrapper is niet direct beschikbaar op veel routers, wat het prototype moeilijk inzetbaar maakt op de meeste netwerken. Het draaien ervan op onze werkstations was makkelijk, maar het inzetten op onze OpenWRT-router was niet zo eenvoudig. Een implementatie in een meer low-level taal, of in een taal waar nfqueue-modules direct beschikbaar zijn zou dit probleem oplossen.
De firewallregels die verkeer naar bepaalde IP-adressen toelaten zouden niet voor altijd geldig moeten blijven. Daarom heeft een DRR-implementatie een mechanisme nodig om de regels op een bepaald moment weer in te trekken. Een voor de hand liggende mogelijkheid is om de Time to Live (TTL) van een DNS-antwoord te gebruiken als de geldigheidsperiode van de firewallregel. Dit zou echter mis kunnen gaan bij verbindingen die lang openblijven, aangezien er in die situatie geen nieuwe DNS-query’s worden gedaan.
We zien op dit moment 2 mogelijke oplossingen voor dit probleem: (1) het bijhouden van alle open verbindingen, en (2) TCP-pakketten die geen verbindingsinitiators zijn altijd toestaan (d.w.z. bij TCP-pakketten alleen de SYN-pakketten blokkeren). Deze 2 oplossingen bespreken we in iets meer detail.
Het verkeer direct bijhouden. Als een verbinding langer openblijft dan de TTL van het DNS-antwoord, kunnen we gewoon verkeer naar de bestemming laten doorgaan zolang de verbinding openblijft. Als er al een tijdje geen verkeer is geweest, en de DNS-TTL is verlopen, kan het adres verwijderd worden van de lijst met toegestane adressen. Deze aanpak betekent wel dat de DRR-implementatie de status moet gaan bijhouden van alle openstaande verbindingen, iets dat waarschijnlijk beter aan de firewall zelf overgelaten kan worden.
De tweede optie is om TCP-verkeer van bestaande verbindingen altijd toe te staan. TCP-verbindingen worden geïnitieerd door middel van een handshake, dus in theorie zou de standaardblokkeerregel een uitzondering kunnen maken voor pakketjes die geen deel uitmaken van deze handshake (maar een voortzetting zijn van een bestaande verbinding). Stateful firewalls houden deze informatie al bij, en laten ofwel pakketten van bestaande verbindingen door, ofwel dat kan relatief eenvoudig worden ingeschakeld. Deze aanpak heeft het voordeel dat een DRR-implementatie de huidige status van verbindingen niet zelf bij hoeft te houden.
In ons prototype hebben we voor deze tweede aanpak gekozen om ervoor te zorgen dat bestaande verbindingen niet worden onderbroken wanneer de TTL van een DNS-antwoord verloopt.
In deze sectie bespreken we 2 andere scenario’s dan degene die wij in gedachten hadden bij de ontwikkeling van ons eerste DRR-prototype. De scenario’s verschillen voornamelijk in termen van waar de DNS-resolver zich bevindt, wat van invloed is op hoe en waar DRR kan worden ingezet. We noemen het oorspronkelijke scenario met een externe resolver Scenario A.
In het alternatieve scenario B draait de router zelf een resolver. Figuur 2 toont de opstelling in dat scenario. De router fungeert als resolver, en filterregels kunnen worden gebaseerd op de antwoorden naar de stub resolvers. Ook in dit scenario is de beste plaats om DRR te implementeren op de router, en in feite zou dezelfde opstelling gebruikt kunnen worden als in scenario A.
Maar in dit scenario zou DRR ook kunnen worden geïmplementeerd als uitbreiding van de resolver zelf. In dat geval heeft DRR de beschikking over alle benodigde DNS-informatie zonder deze zelf te hoeven onderscheppen. Dit heeft als grote voordeel dat het niet afhankelijk is van het gebruik van plain-text DNS, waardoor DRR ook kan werken als het DNS-verkeer versleuteld is met bijvoorbeeld DNS-over-HTTPS (DoH) of DNS-over-TLS (DoT). Dit kan niet in scenario A.
Figuur 2: Scenario B met een lokale resolver.
In het derde scenario C is er een forwarding resolver die op de router draait. Dit is in wezen een combinatie van scenario A en scenario B, zoals weergegeven in figuur 3. Wat betreft potentiële filterlocaties is dit scenario hetzelfde als scenario B; de filterregels kunnen worden gebaseerd op de resultaten van de forwarding resolver, en DRR zou kunnen worden geïmplementeerd als een uitbreiding op deze forwarding resolver.
Figuur 3: Scenario C met een forwarding resolver.
Tot nu toe hebben we filtering bij de router of resolver besproken. Een alternatieve aanpak bestaat uit filteren op de lokale host en omvat filteren op de stub resolvers op de hosts zelf. Dit heeft het voordeel dat het haalbaar is in elk scenario, ongeacht de opzet van het netwerk, maar maakt de hosts zelf verantwoordelijk voor het filteren. Dit kan niet altijd, bijvoorbeeld met IoT-apparaten die beperkte capaciteit hebben voor extra verwerking, of als er helemaal geen firewallfunctionaliteit op het systeem aanwezig is. Een ander nadeel is dat het de host nog steeds kwetsbaar maakt voor kwaadaardige software die de systeembrede DNS-instellingen wijzigt, aangezien de malware ook de DRR-instellingen kan wijzigen.
Bij het nadenken over het concept van DRR en ons prototype hebben we vooral een netwerk met beperkte IoT-apparaten overwogen. Het concept van DRR kan ook buiten het toepassingsscenario, een IoT-thuisnetwerk netwerk, heel nuttig zijn. Maar er zijn een paar kanttekeningen en beperkingen als DRR buiten het IoT gebruikt wordt. Sommige daarvan noemden we al in ons eerste artikel. Recente experimenten brachten er nog een paar aan het licht, dus de lijst is uitgebreid. Sommige van de beperkingen komen door de opzet van het prototype en kunnen worden opgelost met een betere implementatie. Andere beperkingen zijn inherent aan het DRR-concept en kunnen in bepaalde omstandigheden zelfs als voordelen worden gezien.
De eerste beperking is snelheid: DNS-antwoorden moeten worden vertraagd totdat de firewallregels zijn bijgewerkt, zodat clients niet al een verbinding proberen op te zetten voordat de firewall is bijgewerkt. Het effect van een dergelijke vertraging hangt grotendeels af van hoe snel de firewallregels worden bijgewerkt en hoe efficiënt de DRR-implementatie zelf is. In onze experimenten ontdekten we dat vertraging merkbaar is in scenario’s waarbij een gebruiker direct betrokken is, zoals bij het bezoeken van webpagina’s. Hoe groot dit probleem in de praktijk zou zijn is moeilijk te zeggen op basis van (inefficiënte) prototypes. Een dergelijke vertraging is vooral een probleem bij het browsen, omdat websites vaak veel DNS-queries nodig hebben, en zelfs vertragingen van een paar honderd milliseconden zijn merkbaar voor gebruikers. Voor IoT-apparaten zouden dergelijke vertragingen echter niet zo’n probleem moeten zijn.
Een andere beperking heeft betrekking op verkeer naar lokaal geconfigureerde IP-adressen, zoals die in configuratiebestanden of in het hosts-bestand. Dergelijke adressen worden niet opgezocht via DNS en worden daarom door DRR geblokkeerd. Een DRR-systeem zou een manier moeten hebben om vertrouwde adressen in te stellen en deze adressen toe te staan zelfs als er geen gerelateerd DNS-lookup is. Dit is vooral een kwestie van het toevoegen van configuratieopties.
Een gedeeltelijk verwante, maar ernstigere, beperking is dat protocollen die IP-adressen in-band uitwisselen niet meer zullen werken. Dergelijke uitwisselingen slaan het DNS over, dus de IP-adressen die worden uitgewisseld en vervolgens worden gebruikt zijn niet bekend bij het DRR-systeem en worden daarom geblokkeerd door de firewall. Voorbeelden van zulke protocollen zijn SIP, BitTorrent en, meer in het algemeen, veel voice-over-IP (VoIP) en peer-to-peer communicatieprotocollen. Hier is geen eenvoudige oplossing voor, omdat deze IP-adressen niet van tevoren bekend zijn. Maar omdat zulke protocollen vaak problemen ondervinden als ze worden gebruikt met netwerkadresvertaling (NAT), en daarvoor omzeilingen hebben geïmplementeerd, zou een soortgelijke oplossing misschien ook mogelijk zijn voor DRR. Misschien zou een DRR-systeem kunnen inhaken op een STUN-oplossing of soortgelijke helperfunctionaliteit, maar we hebben deze mogelijkheid nog niet onderzocht.
Een vierde beperking hangt af van de manier waarop DRR wordt geïmplementeerd, en is al eerder genoemd: een implementatie voor algemeen gebruik, zoals ons prototype, luistert naar plain-text DNS-pakketten. Dit zal duidelijk mislukken als een vorm van versleutelde DNS wordt gebruikt, zoals DNS over HTTPS (DoH) of DNS over TLS (DoT). In sommige opzichten zou dit een voordeel kunnen zijn: malware is dan ook niet in staat DoH of DoT te gebruiken om zijn DNS-gebruik te verbergen. Maar alle legitieme versleutelde DNS-toepassingen zouden ook niet meer werken. De enige echte oplossing hiervoor zou zijn om een beveiligd kanaal te hebben naar de eigenlijke resolver, en een protocol om IP-adressen en TTL’s uit te wisselen. Je zou je ook kunnen voorstellen dat de resolver zelf DRR implementeert, met een klein lokaal programma om firewallregels bij te werken.
Onze korte evaluatie van ons prototype laat zien dat DRR inderdaad kan werken. Hoewel het enkele beperkingen heeft die het onpraktisch zouden kunnen maken voor algemeen gebruik op pc’s (het is bijvoorbeeld niet compatibel met VoIP en peer-to-peer protocollen), denken wij dat het een aanzienlijke netwerkbeveiliging kan toevoegen in meer beperkte scenario’s.
DRR zou bijvoorbeeld kunnen worden gebruikt om IoT-apparaten in een thuisnetwerk te beschermen of alleen worden gebruikt in een netwerk waar hoge beveiligingseisen gelden, zoals in de medische sector.
We overwegen momenteel om een ‘echte’ implementatie te schrijven die de belangrijkste problemen van het tweede prototype aanpakt (namelijk snelheid en inzetbaarheid). Ben je geïnteresseerd in zo’n systeem, laat het ons weten!
Natuurlijk zijn feedback en vragen welkom, dus laat het ons weten!
We hebben de broncode van het prototype nog niet gepubliceerd, maar als je geïnteresseerd bent is deze op verzoek beschikbaar.
Artikel door:
Deel dit artikel