DNS-MISBRUIK. Van herkenning tot preventie. Wilhelmina van Pruisenweg AN Den Haag. Versie : 2.2 Den Haag : 30 juli

DNS-MISBRUIK Van herkenning tot preventie

www.govcert.nl POSTADRES

Postbus 84011 2508 AA Den Haag BEZOEKADRES

Wilhelmina van Pruisenweg 104 2595 AN Den Haag TELEFOON

070 888 75 55 FAX

070 888 75 50 E-MAIL

[email protected]

Auteur Versie Den Haag

: GOVCERT.NL : 2.2 : 30 juli 2008

SAMENVATTING Het Domain Name System (DNS) is een fundamenteel onderdeel van het internet. Het systeem verzorgt de koppeling van IP-adressen aan voor mensen begrijpelijke namen, van alle aangesloten computers op het netwerk. De opslag en het opvragen van computernamen gebeurt met behulp van een wereldwijd, hiërarchisch systeem van samenwerkende DNS-servers. Deze DNS-servers communiceren met elkaar met het DNS-protocol. Het doel van dit rapport is het onder de aandacht brengen van DNS-misbruik en waar mogelijk het misbruik ervan terug te dringen. Dergelijk misbruik heeft tot gevolg dat internetverkeer omgeleid kan worden, vaak met als doel websites onbereikbaar te maken of om gebruikers te misleiden en naar kwaadaardige websites te sturen. Op deze sites proberen kwaadwillenden dan gevoelige gegevens als creditcard- of persoonsgegevens te ontfutselen. Misbruik van het huidige Domain Name System gebeurt vaak naar aanleiding van zwakheden in het DNS-protocol, maar ook van programmeer- en configuratiefouten in de DNS-software. Detectie en preventie van misbruik zijn lastig. De voornaamste oorzaak hiervan ligt in het feit dat beveiliging geen aandachtspunt is geweest bij de ontwikkeling van het DNS-protocol. Recent is er een zeer ernstige kwetsbaarheid ontdekt die misbruik van DNS mogelijk maakt. Daarover is een afzonderlijke GOVCERT.NL Factsheet gepubliceerd [FS-2008-06]. Hoewel lastig, kan DNS-misbruik wel degelijk worden voorkomen of bemoeilijkt. Preventief kunnen er verschillende maatregelen worden genomen die betrekking hebben op de configuratie en het onderhoud van DNS-servers binnen een organisatie. Ook kunnen veranderingen worden doorgevoerd in de functionaliteit van verschillende DNS-servers. De invoering van monitoring en Intrusion Detection Systemen (IDS) zijn maatregelen die detectie van DNS-misbruik kunnen vergemakkelijken. Een gedegen logstrategie is hiervoor een voorwaarde. Om binnen een organisatie adequaat te kunnen reageren op het moment dat daadwerkelijk misbruik van DNS wordt vastgesteld, is het van belang dat vooraf procedures worden vastgelegd. In deze procedures, die een onderdeel kunnen zijn van een algemeen calamiteitenplan, staan praktische zaken als bevoegdheden maar ook maatregelen die genomen kunnen worden om de gevolgen van het gedetecteerde misbruik te beperken. Om in de toekomst tot een goed beveiligd DNS te komen is DNSSEC in ontwikkeling. Dit systeem stelt gebruikers op het internet in staat om op een veilige manier naamgeving te gebruiken. De implementatie van DNSSEC op grote schaal zal echter nog geruime tijd in beslag nemen.

INHOUDSOPGAVE 1

INLEIDING ......................................................................................... 4

2

INTRODUCTIE DNS ............................................................................. 5 DNS IN HET KORT ...................................................................................................... 5

3

RISICO’S VAN DNS ............................................................................. 7 ONVOLKOMENHEDEN IN HET DNS-PROTOCOL........................................................................ 7 IMPLEMENTATIEFOUTEN VAN HET PROTOCOL IN SOFTWARE .......................................................... 7 CACHEVERVUILING ...................................................................................................... 8 CONFIGURATIEFOUTEN ................................................................................................. 9

4

PREVENTIE ....................................................................................... 10 CONFIGURATIE .........................................................................................................10 ONDERHOUD ...........................................................................................................11 SPLIT DNS (TEGEN IMPLEMENTATIE- EN CONFIGURATIEFOUTEN).................................................11 ANTI-SPOOFING .......................................................................................................12 BEVEILIGINGSBESEF BIJ DE GEBRUIKERS ............................................................................12

5

DETECTIE.......................................................................................... 13 LOGGING EN MONITORING ............................................................................................13 INTEGRITEIT VAN LOGGEGEVENS .....................................................................................13 SYNCHRONISATIE VAN DATUM EN TIJD. ..............................................................................13 CORRELATIE EN MONITORING ........................................................................................14 EEN VOORBEELD VAN MISBRUIK (CACHE POISONING): .............................................................14

6

REACTIE ........................................................................................... 16 TECHNISCHE MAATREGELEN ...........................................................................................16 ORGANISATORISCHE MAATREGELEN ..................................................................................16 INCIDENTAFHANDELING EN AANGIFTE ................................................................................16

7

CONCLUSIE ....................................................................................... 18

8

REFERENTIES ................................................................................... 19

9

AFKORTINGEN .................................................................................. 21

10

DISCLAIMER ..................................................................................... 22

11

DANKWOORD.................................................................................... 22

1

INLEIDING

GOVCERT.NL stelt zich onder andere ten doel ICT-gerelateerde beveiligingsincidenten te voorkomen binnen overheden. Dit document bevat een toelichting op de verschillende verschijningsvormen van misbruik van het Domain Name System. De intentie van dergelijk misbruik is het omleiden van internetverkeer. Dit kan gebeuren met als doel websites onbereikbaar te maken, maar ook om gebruikers te misleiden en naar kwaadaardige websites te sturen. Op deze sites proberen kwaadwillenden dan gevoelige gegevens als creditcard- of persoonsgegevens te ontfutselen. Vanuit een technische invalshoek wordt het misbruik dat gericht is op de naamgeving van het internet besproken. De verschillende kwetsbaarheden in DNS worden als leidraad gebruikt om de verschijningsvormen van DNS-misbruik te behandelen. Het gaat dan om programmeer- en configuratiefouten in de DNS-software, de mogelijkheid tot identiteitsvervalsing en onvolkomenheden in het DNS-protocol. Door de preventie en detectie van, en de reactie op DNS-misbruik te beschrijven krijgt dit rapport praktische waarde. Hierbij vormen de mensen die vanuit beheerperspectief met het internet werken de doelgroep van dit rapport. Enige voorkennis van naamgeving op het internet wordt dan ook voorondersteld aanwezig te zijn. Dit document bevat een introductie waarin kort wordt uitgelegd hoe DNS werkt en waarom het systeem kwetsbaar is voor misbruik. Het rapport gaat daarna inhoudelijk dieper in op de verschillende kwetsbaarheden in DNS. Met een aantal historische voorbeelden wordt duidelijk gemaakt wat er met DNSmisbruik in de praktijk bereikt kan worden. In de hoofdstukken die volgen wordt preventie van, detectie van, en reactie op DNSmisbruik behandeld. Hierbij komen zowel technische als organisatorische maatregelen aan de orde.

DNS-misbruik versie 2.2 30 juli 2008

4/22

2

INTRODUCTIE DNS

DNS in het kort DNS staat voor een wereldwijde gedecentraliseerde database waarin domeinnamen op een hiërarchische manier zijn vastgelegd. De concepten, regels en afspraken zijn vastgelegd in de Requests For Comments (RFC's) 1034 en 1035. [RFC1034] en [RFC1035]. De RFC's gebruiken het acroniem DNS voor Domain Name System. In de praktijk wordt de afkorting ook wel foutief gebruikt voor Domain Name Service of Domain Name Server. Iedere op internet aangesloten computer heeft ten minste één zogenaamd IP-adres in de vorm van een nummer. Dit IP-adres maakt het mogelijk om andere computers te adresseren en dus te bereiken. DNS is het technische systeem dat namen koppelt aan deze IP-adressen en zo elke computer op het internet bereikbaar maakt onder een voor mensen begrijpelijke naam. Het Domain Name System koppelt zo bijvoorbeeld de domeinnaam GOVCERT.NL aan het nummer 212.204.249.32. DNS heeft ook andere functionaliteiten, maar deze zijn voor dit document minder relevant. Hoe werkt DNS Het hart van het Domain Name System wordt gevormd door name-servers: de computers met de programmatuur die domeinnamen omzet naar IP-adressen. Deze naam wordt gebruikt voor zowel fysieke computers als voor de software die daarop draait. Binnen DNS zijn er twee verschillende functionaliteiten te onderscheiden: 1. Het zelf verantwoordelijk zijn voor een deel van de naamgeving van het internet. Name-servers die dit doen worden “authoritative” name-servers genoemd. Deze name-servers kunnen alleen IP-adressen vinden voor domeinen waar zij verantwoordelijk voor zijn. 2. Het vertalen van domeinnamen in IP-adressen met behulp van andere nameservers. De name-servers die dit doen noemen we “forwarders”. Deze forwarders worden gebruikt om computers de mogelijkheid te bieden om IPadressen op te zoeken bij alle voorkomende domeinnamen. Zij maken hiervoor gebruik van de authoritative name-servers. Neem bijvoorbeeld de computers van de abonnees van een provider of de computers uit een netwerk van een organisatie. Deze computers hebben het adres van een DNS-forwarder in de netwerkinstellingen staan en kunnen zo de IP-adressen van alle domeinnamen vinden, zonder zelf direct contact te hoeven maken met de authoritative name servers. DNS-programmatuur biedt beide functionaliteiten aan. Bij de implementatie van de name-server is het van belang deze apart te configureren. DNS-naamgeving is hiërarchisch opgebouwd en bestaat uit zones. Zones bevatten of domeinnamen of verwijzigen naar onderliggende zones. De onderliggende zones bevatten wederom domeinnamen of verwijzingen naar dieper gelegen zones. Zo ontstaat een hiërarchische boomstructuur van zones en domeinnamen. Het opzoeken van domeinnamen vanuit gebruikersapplicaties zoals webbrowsers verloopt in een proces waarbij de forwarding name-server de domeinnaam in stukken knipt (zones) en van de achterkant van de domeinnaam af op zoek gaat naar de verantwoordelijke (authoritative) name-server van de betreffende zone.


5/22

Bijvoorbeeld: in de .NL (spreek uit: punt nl) zone zitten een verwijzing naar de .GOVCERT.NL zone. In de .GOVCERT.NL zone vinden wij de domeinnaam COMPUTER02.GOVCERT.NL met het bijbehorende IP-adres. Dit laatste is een “Fully Qualified Domainname” of FQDN. Typerend voor een FQDN is het feit dat deze domeinnaam een IP-adres heeft.

.nl zone

.govcert.nl zone

www.govcert.nl 62.112.232.251

.waarschuwingsdienst.nl

computer02.govcert.nl 193.172.9.X

De eerder genoemde RFC1034 en RFC1035 beschrijven de specificaties en de implementatie van het DNS-protocol. Er wordt onder andere beschreven hoe er vragen aan name-servers gesteld kunnen worden, hoe deze worden verwerkt en welke antwoorden de name-servers kunnen geven. Beveiliging Zoals bij de ontwikkeling van veel protocollen van het internet, is bij de ontwikkeling van DNS geen rekening gehouden met mogelijk misbruik van het systeem. Bellovin toonde in 1990 al aan dat misbruik mogelijk was. Hij heeft dit vier jaar lang geheim gehouden om de gemeenschap de kans te geven de problemen op te lossen [Bellovin, 1995]

In 1998 vond echter toch een groot beveiligingsincident plaats:

“Eugene Kashpureff, oprichter van AlterNIC, is gearresteerd door de Canadese politie op beschuldiging van fraude. Aanleiding was de protestactie van AlterNIC tegen de monopoliepositie van InterNIC op 12 juli van 1998, waarbij alle verkeer naar de site van InterNIC werd doorgestuurd naar die van AlterNIC. Met de actie werd tevens aangetoond dat het Domain Name System voor de gek kan worden gehouden.” [Justice Department, 1998] InterNic was in 1998 de grootste domein registratie organisatie in de wereld. We kunnen misbruik van het DNS-systeem onderverdelen aan de hand van de volgende drie kwetsbaarheden: 1. onvolkomenheden in het protocol 2. implementatiefouten in DNS-software 3. configuratiefouten in DNS-software. In het volgende hoofdstuk zullen deze oorzaken nader bekeken worden.


6/22

3

RISICO’S VAN DNS

De toenemende afhankelijkheid van de op internet gebruikte technologieën heeft tot gevolg dat misbruik van DNS steeds lucratiever wordt. Door het steeds maar groeiende internet neemt ook de impact van het misbruik toe waardoor organisaties op relatief eenvoudige wijze grote schade kan worden berokkend door kwaadwillenden. Dit hoofdstuk beschrijft de delen van DNS die voor misbruik vatbaar zijn. Aan de meeste vormen van DNS-misbruik liggen onvolkomenheden in het DNS-protocol ten grondslag. Maar ook andere oorzaken zoals de implementatiefouten van het DNSprocotol en configuratiefouten van DNS-software dragen bij aan DNS-misbruik.

Onvolkomenheden in het DNS-protocol De werking van het Domain Name System ligt vast in eerder genoemde RFCprotocollen. Deze protocollen beschrijven onder andere hoe het IP-adres behorend bij een domeinnaam kan worden opgevraagd door het bevragen van de verschillende nameservers naar zone-informatie. Het DNS-protocol zoals dat nu gebruikt wordt op het internet, mist de mogelijkheden tot validatie van de integriteit en authenticiteit van de uitgewisselde informatie. Er wordt geen gebruik gemaakt van een mechanisme waarmee verkregen zone- of domeininformatie kan worden geverifieerd. Als een kwaadwillende in staat is om tijdens het uitwisselen van DNS-informatie gegevens te veranderen, kan hij een gebruiker misleiden. De gebruiker kan de informatie van de kwaadwillende niet meer onderscheiden van de authentieke informatie. Noot: In januari 2008 ontdekt Dan Kaminsky een kwetsbaarheid in verschillende DNS implementaties. De kwetsbaarheid stelt kwaadwillenden in staat om de cache van DNS servers te vervuilen met foutieve informatie (cache poisoning). Via dergelijke foutieve informatie kan een kwaadwillende gebruikers naar kwaadaardige websites leiden zonder dat de gebruiker dit merkt. Zie voor de details hieromtrent de GOVCERT.NL factsheet ‘De Kaminsky Code: Kwetsbaarheden in DNS’ [FS-2008-06] Alleen een grote protocolwijziging kan deze problematiek oplossen. DNSSEC beschreven in RFC 4033 tot 4035, die recentelijk de “proposed standard” status hebben bereikt, kunnen mogelijk een oplossing bieden. Mochten de voorstellen uit deze RFC's tot standaard worden verheven, dan duurt het nog vele jaren voordat alle huidige DNSservers zijn gemigreerd naar servers die hun diensten aanbieden op basis van het nieuwe protocol. DNSSEC is een complex protocol dat ingrijpende organisatorische veranderingen teweegbrengt. Het is dan ook de vraag of dit relatief nieuwe protocol het wel zal halen. Veel organisaties staan sceptisch tegenover de investeringen die gedaan moeten worden om DNSSEC te implementeren [cbronline].

Implementatiefouten van het protocol in software Tijdens het schrijven van software is men gehouden aan de standaarden die vastliggen in RFC's. Interpretatiefouten, programmeerfouten en/of eigen visies kunnen aanleiding geven tot kwetsbaarheden, die misbruikt kunnen worden. Veel van deze fouten betreffen het deel van de programmatuur dat de Resource Records verwerkt.


7/22

De DNS-programmatuur slaat de informatie van zones op met behulp van zogenaamde Resource Records (RR’s). Deze records worden binnen de DNS-server door de programmatuur opgeslagen en verwerkt. Een forwarder vraagt een authoritative nameserver naar de resource records van een bepaalde zone of domein. De DNSprogrammatuur in de forwarder verwerkt de zone-informatie en zal uiteindelijk door een iteratief proces van herhaalde vragen naar autoritatieve nameservers een IP-adres vinden bij een domeinnaam. Fouten in de verwerking van deze RR’s kunnen leiden tot verkeerde informatie over een zone, waarbij foutieve IP-adressen aan domeinnamen gekoppeld worden. Binnen de DNS-programmatuur wordt gebruik gemaakt van caching. Antwoorden op DNS-vragen (queries) worden tijdelijk opgeslagen om eventuele identieke queries sneller te kunnen beantwoorden. Normaal gesproken is deze dynamische informatie opgeslagen voor een groot aantal verschillende zones. Als foutieve informatie in de cache van een name-server belandt, wordt deze beschikbaar gesteld aan gebruikers die gebruik maken van deze 'vergiftigde' name server. Dit heet “cache poisoning”. DNS-software kent slechts een zeer beperkt aantal implementaties. Als gevolg hiervan gebruiken een groot aantal DNS-servers dezelfde software. Hierdoor is de impact van misbruik op een bepaalde DNS-software variant groot en blijft het dus interessant voor kwaadwillenden om DNS te misbruiken. In november 2003 bevatte BIND, veelgebruikte DNS-serversoftware, een implementatiefout [BindPo] die cache poisoning mogelijk maakte. Een kwaadwillende kon, door gebruik te maken van deze fout, servers onbereikbaar maken op het internet.

Cachevervuiling Cachevervuiling kan worden bereikt door misbruik te maken van een programmeerfout bij het verwerken van het “Additional section” resource record in een antwoord van de name-server. In de “Additional section” is informatie terug te vinden die een volgende DNS-query vereenvoudigen. Een voorbeeld hiervan is het opvragen van de mailservers die behoren bij een domein. Deze informatie is opgeslagen in zogenaamde MX resource records. MX records bevatten nooit IP-adressen maar vanuit het DNS-protocol per definitie een hostnaam. Bij het opvragen van de mail servers voor een domein moeten er dus 2 vragen beantwoord worden: 1. Wat zijn de bij het domein behorende mailservernamen (uit de mx records) 2. Wat zijn de IP-adressen die bij deze servernamen horen Om nu DNS-servers niet onnodig zwaar te belasten worden de IP-adressen van resource records gelijk meegegeven in “Additional Section” resource records. Ter illustratie worden hieronder met behulp van het UNIX programma DIG voor het domein GOVCERT.NL de mailservers opgevraagd. In de ANSWER SECTION staat de naam van de server: min.govcert.nl In de ADDITIONAL SECTION staat het IP-adres van deze server.


8/22

dig mx govcert.nl ; <<>> DiG 9.2.1 <<>> mx govcert.nl ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58829 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 1 ;; QUESTION SECTION: ;govcert.nl. ;; ANSWER SECTION: govcert.nl.

IN

MX

3600

IN

MX

5 min.govcert.nl.

3600

IN

A

81.175.82.27

. . . ;; ADDITIONAL SECTION: min.govcert.nl.

Voor het resource record: “Additional section” gelden specifieke randvoorwaarden. Deze informatie mag alleen mag worden gebruikt om een opvolgende vraag te beantwoorden. Na de opvolgende vraag moet de “Additional section” informatie worden verwijderd uit de cache. In de praktijk gebeurde dit niet in sommige implementaties van DNS-servers. Dit hield in dat de informatie kon blijven “hangen” in de name-server en name-server queries gefalsificeerd konden worden.

In 2001 was er een markant voorbeeld van “Additional section” misbruik. (Zie: [NTRR]) Het bleek toen dat de name-server software van Microsoft kwetsbaar was in de routines voor het verwerken van informatie uit de “additional section” (glue records). Deze programmeerfouten waren ook in 1997 [CERTBind] gevonden in de UNIX name-server software: BIND. Door het geven van aanvullende informatie aan deze kwetsbare serversoftware in additional records kon een kwaadwillende een slachtoffer misleiden en de gebruiker naar sites onder zijn controle leiden.

Configuratiefouten Naast de implementatie- of programmeerfouten in software, kan software ook verkeerd geconfigureerd worden. De complexiteit van de DNS-programmatuur maakt dat er veel parameters zijn binnen de software, die allerlei onderlinge relaties hebben. Hierdoor is het niet gemakkelijk om een goede en consistente configuratie te implementeren. Een groot deel van hoofdstuk 5 gaat inhoudelijk in op de configuratie en mogelijke fouten van DNS.


9/22

4

PREVENTIE

Om DNS-misbruik te voorkomen, of te bemoeilijken, kunnen verschillende maatregelen genomen worden. Deze maatregelen hebben betrekking op de configuratie en onderhoud van de DNS-servers, anti-spoofing en de netwerkarchitectuur voor DNS binnen de organisatie.

Configuratie Om configuratiefouten te voorkomen dient de configuratie van de programmatuur voor DNS beheerd en beheerst te worden. Dit houdt in dat binnen de organisatie er kennis aanwezig moet zijn over de specifieke configuratie van de aanwezige name-servers. Bedenk daarbij dat DNS een complex systeem is en dat er voldoende resources moeten worden vrijgemaakt voor de initiële configuratie en het bijhouden ervan. Het is belangrijk dat de DNS-functionaliteit binnen een organisatie vastligt, zodat de impact van eventuele kwetsbaarheden en de daarbij behorende risico’s goed kunnen worden ingeschat. Met behulp van goede architectuur van het interne netwerk kan de DNS-functionaliteit eenduidig blijven. Hierbij is het onder andere van belang dat alle computers binnen de organisatie dezelfde name-servers gebruiken. Dit kan bijvoorbeeld worden bereikt door met behulp van firewalls het DNS-verkeer uitsluitend toe te staan naar een beperkt aantal betrouwbare DNS-servers. Bedenk daarbij dat dit tot gevolg heeft, dat de organisatie afhankelijk wordt van deze name-servers.

Een voorbeeld: AXFR (Asynchronous Full Transfer Zone) Een voorbeeld van omstreden configuratie-opties, zijn de opties voor de zonetransfers of AXFR. Om redundantie tussen name-servers te bewerkstelligen is er een replicatiemechanisme ontwikkeld om de totale informatie van een zone te kopiëren van een server (de master) naar een andere server (de slave). De naam van dit mechanisme is zonetransfer of AXFR. Een zonetransfer wordt door de slave geïnitieerd. De mogelijkheid tot zonetransfer houdt in dat alle informatie van de zone bekend wordt aan de slave. Als de zone's van het interne netwerk vanuit het internet beschikbaar zijn voor een transfer, kan een kwaadwillende op een eenvoudige manier aan een lijst komen met interne servers door een transfer uit te voeren naar zijn eigen systeem. Hij heeft daarmee de mogelijkheid om inzicht te verkrijgen in de architectuur van het gehele netwerk. De configuratie van de name-server maakt het mogelijk om zonetransfers te beperken tussen een master en slaves. Belangrijk is dat de opties voor de configuratie van zonetransfers goed bekend zijn bij het serverbeheer. Er dient dus een weloverwogen keuze gemaakt te worden of, en zo ja welke, servers zonetransfers mogen initiëren voor de autoritatieve zones.


10/22

Zoals eerder beschreven biedt DNS de mogelijkheid een functionele scheiding te maken tussen het beantwoorden van vragen waarvoor de name-server autoritatief is en het beantwoorden van vragen waarvoor de server niet autoritatief is. Zo wordt een onderscheid gemaakt tussen autoritatieve name-servers en zogenaamde forwarders. Autoritatieve name-servers zijn autoritatief voor één of meerdere zones. Uit beveiligingsoverwegingen is het verstandig om de name-servers binnen een organisatie in te richten uitsluitend als forwarder of als autoritatieve name-server. Hierbij is het belangrijk dat de configuratie dit ook ondersteunt. De functionaliteit die niet geboden wordt, dient vervolgens expliciet in de configuratie uitgezet te worden. De relatie tussen de configuratieopties en de daaraan gekoppelde functionaliteit dient ook goed bekend te zijn. Recente versies van DNS-programmatuur hebben verschillende mogelijkheden om transacties te beveiligen door middel van autenticatie en encryptie (TSIG: Transaction Signatures). Hoewel de mogelijkheden per implementatie verschillen, en een uitputtende beschrijving buiten het blikveld van dit document valt, zijn er twee referenties opgenomen die het een en ander beschrijven: [RFC2845] [TSIGLui]

Onderhoud Vanzelfsprekend is het van belang om de DNS-software die binnen de organisatie gebruikt wordt, goed up-to-date te houden. Dit om eventueel misbruik van implementatiefouten in de DNS-software te voorkomen. De patchinformatie van de leverancier en ontwikkelaars dient regelmatig geëvalueerd te worden. Updates, waarbij de beveiliging een rol speelt, moeten worden beoordeeld op impact voor de organisatie en uitgevoerd waar nodig. Specifieke functionaliteiten van DNS-servers binnen een organisatie kunnen vragen om verschillende maatregelen. Een DNS-server die uitsluitend als forwarder is ingericht en dus gebruikt wordt voor het bedienen van werkstations zal bijvoorbeeld gevoelig zijn voor cache poisoning [FS-2008-06], terwijl een autoritatieve server daar geen last van heeft. Updates die betrekking hebben op cache poisoning zullen dus eerder op de forwarders binnen de organisatie moeten worden toegepast.

Split DNS (Tegen implementatie- en configuratiefouten) Een manier om DNS-misbruik te beperken, is het scheiden van de forwarderfunctionaliteit van de autoritatieve DNS functionaliteit. Autoritatieve DNS-functionaliteit is bijvoorbeeld nodig voor het bedienen van eigen “toplevel” domeinen. Bedenk hierbij dat naast deze domeinen naamgeving voor het interne netwerk ook in een “autoritative” zone staat. Spit DNS: de scheiding tussen interne en externe (internet) naamgeving maakt de kans op misbruik kleiner. Door gebruik te maken van Split DNS splitst men de functionaliteit van het opzoeken van willekeurige domeinnamen en de (interne) domeinnamen waarvoor de organisatie autoritatief is. Split DNS zorgt er onder andere voor dat kwaadwillende op het internet geen mogelijkheid hebben om de caches van de autoritatieve nameservers te vervuilen. Daarnaast voorkomt het de mogelijkheid om een AXFR (zonefransfer) uit te voeren op het interne name-server vanaf het internet. Bij de implementatie van split DNS worden er twee typen nameservers ingericht een caching/forwarding name-server en een autoritatieve nameserver.


11/22

De caching/forwarding name-server vertaalt domeinnamen voor het intern netwerk. Op deze server worden geen externe domeinen gehost. De autoritatieve name-servers vertaalt de domeinen die een organisatie host. Dit zijn zowel de interne alsook de externe domeinen. Queries voor de domeinen van deze organisatie worden door deze autoritatieve nameserver beantwoord. Deze name-server heeft geen caching functionaliteit. Het inrichten van Split DNS is een maatregel tegen configuratiefouten en implementatiefouten van de software. De configuratie van alleen een autoritatieve name-server of alleen een caching name-server is namelijk een stuk eenvoudiger in opzet. Als er implementatiefouten in de DNS-software zitten is de kans dat die zowel in de forwarding-software als in de autoritatieve software zit nihil. Er zal dus maar een deel van de functionaliteit kwetsbaar zijn.

Anti-Spoofing Preventieve maatregelen tegen DNS-spoofing of poisoning zijn niet eenvoudig te implementeren. Vaak geeft goed geconfigureerde DNS-logging voldoende informatie om misbruik te detecteren. Detectie gebeurt dan wel achteraf. Een grotere investering vraagt de implementatie van een Intrusion Detection System. Een Intrusion Detection Systeem (IDS) is in staat om te controleren of de inhoud van netwerkpakketten aan bepaalde voorwaarden voldoet. Hierdoor is een IDS in staat om van toegestane legitieme verkeersstromen te bepalen wat ‘normaal’ is en wat een aanval zou kunnen zijn. Een IDS is niet uitsluitend gemaakt om DNS-aanvallen te herkennen, maar ook om andere bekende aanvallen naar kwetsbaarheden in software te herkennen. Naast de implementatie van een IDS, zijn er andere basale maatregelen om spoofing tegen te gaan. Een en ander is beschreven in [DDOS].

Beveiligingsbesef bij de gebruikers Gebruikers dienen zich te beseffen dat het mogelijk is om misleid te worden met betrekking tot domeinnamen. Zij zijn tenslotte degenen die problemen zullen ondervinden als er misbruik van DNS plaatsvindt. Gebruikers die zich bewust zijn van de risico’s en van de symptomen (bijvoorbeeld foutmeldingen met betrekking tot het SSL-certificaat van een website) kunnen bijdragen aan het vroegtijdig signaleren van problemen met DNS.


12/22

5

DETECTIE

Dit hoofdstuk gaat dieper in op het detecteren van DNS-misbruik. Eerst wordt het gereedschap behandeld om DNS-misbruik te detecteren: logging en monitoring. Vervolgens wordt aan de hand van een voorbeeld van (een poging tot) DNS-misbruik duidelijk gemaakt dat het moeilijk is om DNS-misbruik operationeel te detecteren. Ondanks dat detectie van DNS-misbruik moeilijk is kan logging en monitoring alle drie de oorzaken van misbruik aan het licht brengen. Onvolkomenheden in het protocol, implementatiefouten en configuratiefouten kunnen in sommige gevallen gevonden worden in de logging. In dit hoofdstuk wordt een voorbeeld gegeven waarin een kwaadwillende tracht een implementatiefout in de software gecombineerd met een “protocol onvolkomenheid” uit te buiten, waardoor hij gebruikers van een name-server kan misleiden.

Logging en Monitoring Zoals hierboven gesteld is het detecteren van DNS-misbruik moeilijk. Dit wordt voornamelijk veroorzaakt doordat een DNS-server in de regel grote aantallen queries verwerkt, waardoor grote hoeveelheden logdata kunnen ontstaan. Het is belangrijk dat de loggegevens van de DNS-systemen in een netwerk zo betrouwbaar mogelijk zijn. Een logstrategie kan een grote bijdrage leveren aan deze betrouwbaarheid. Om te komen tot een goede logstrategie worden de belangrijkste onderdelen hiervoor behandeld: • Integriteit van loggegevens • Synchronisatie van datum en tijd • Correlatie en Monitoring

Integriteit van loggegevens Het eerste element bij het opzetten van een logstrategie is het waarborgen van de integriteit van de loggegevens. De integriteit van loggegevens kan het beste worden behouden wanneer de binnenkomende loggegevens op verschillende plaatsen worden opgeslagen. Het opslaan van de loggegevens op een “read” en “append-only” opslagmedium draagt ook bij aan het behoud van de integriteit. Vanuit een beveiligingsperspectief is het het beste om loggegevens via het syslogprotocol naar een andere server, de syslog-server weg te schrijven. De syslog-server dient zo volledig mogelijk afgeschermd te zijn, zodat kwaadwillenden niet de mogelijkheid hebben om de integriteit van loggegevens op deze server te aan te tasten. Voor meer informatie zie [SysLog] Er zijn ook kantekeningen te plaatsen bij het gebruik van een syslog-server. Het syslogprotocol gebruikt UDP om de data naar de syslog-server te verzenden. Dit maakt dat de afzendadressen van de syslogdata makkelijk te vervalsen zijn. Het feit dat er bij gebruik van UDP geen gegarandeerde datatransporten plaatsvinden, maakt het mogelijk dat er datapakketten verloren kunnen gaan tijdens transport. In principe is dit zichtbaar in de syslog, maar er kunnen theoretisch hele logregels wegvallen als er erg veel verkeer is. [RFC3164]

Synchronisatie van datum en tijd. Om de gebeurtenissen op een of meerdere systemen te kunnen correleren, dient de tijdregistratie bij deze gebeurtenissen gesynchroniseerd te zijn. De tijd kan via het NTP-protocol (Network Time Protocol) centraal vanuit één bron worden gesynchroniseerd voor alle betrokken systemen. NTP bevat mechanismen om


13/22

afwijkende systeemtijden op een correcte wijze te kunnen herstellen. Er zijn op het internet diverse NTP-servers te vinden waarmee de tijdsynchronisatie kan plaatsvinden.

Correlatie en Monitoring Als er DNS-misbruik wordt vermoed, is het van belang dat er op een eenvoudige manier een goede analyse van de logbestanden kan worden gemaakt. Het bewaren van de loggegevens van systemen op een syslog-server maakt het makkelijker om een analyse uit te voeren. Alle gegevens staan immers op een centrale plaats. Er zijn diverse programma’s die de analyse van loggegevens eenvoudiger kunnen maken. Voor meer informatie zie:[LogAna] Een ander voordeel van een centrale opslagplaats van loggegevens is de mogelijkheid om activiteit te kunnen monitoren. Systeembeheerders kunnen, door middel van een monitoringsprogramma, direct worden ingelicht wanneer zich onregelmatigheden voordoen in logbestanden. Een monitoringsprogramma kan dus ook bijdragen aan een snelle detectie van DNS misbruik. Controle van alleen de loggegevens van de server waarop de DNS software draait is niet voldoende. Controleer en vergelijk ook de logbestanden van andere servers op onregelmatigheden. Door deze loggegevens van diverse systemen of applicaties te correleren, kunnen onregelmatigheden sneller gedetecteerd worden.

Een voorbeeld van misbruik (cache poisoning): Er zijn omstandigheden waarbij, uit de logging van een server, gedetecteerd kan worden dat er (poging tot) DNS-misbruik was. Vaak gaat het om een poging tot het omleiden van internetverkeer van een bonafide naar een malafide server. De identiteit (IP-adres) van de misbruiker is moeilijk of niet te achterhalen. Dit komt mede doordat het DNS-protocol gebruik maakt van het connectieloze UDP. Het ontbreken van een connectie maakt IP-spoofing makkelijker. Bij gebruik van het UDP-protocol worden namelijk veel minder gegevens bijgehouden. De mogelijkheden om controle uit te voeren op binnenkomende informatiepakketten zijn in dit geval kleiner, waarmee misbruik makkelijker wordt en het traceren van de kwaadwillende moeilijker. Hieronder wordt aan de hand van een voorbeeld beschreven, hoe een poging tot DNSmisbruik er uit ziet. De volgende loggegevens werden gevonden op een forwarding DNS (IP-adressen en domeinnamen zijn zo aangepast dat dit geen mogelijke ip-adressen zijn): client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr client:Apr

17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17

13:20:28.942 13:20:40.788 13:22:02.131 13:23:01.098 13:25:04.421 13:25:06.874 13:27:36.361 13:27:39.403 13:27:42.999 13:30:16.076 13:30:19.172 13:30:58.606 13:31:06.155 13:31:06.156 13:31:06.819 13:31:12.105 13:32:50.200

queries: queries: queries: queries: queries: queries: queries: queries: queries: queries: queries: queries: queries: queries: queries: queries: queries:


info: info: info: info: info: info: info: info: info: info: info: info: info: info: info: info: info:

client client client client client client client client client client client client client client client client client

941.134.7.234#53: query: stfu.rout.gg IN A 941.134.7.227#53: query: hoeee.rout.gg IN A 941.134.7.226#53: query: duck.rout.gg IN A 941.134.7.227#53: query: www.cbs.gov.xx IN A 941.134.7.226#53: query: duck.rout.gg IN A 941.134.7.245#53: query: duck.rout.gg IN A 817.76.23.251#53: query: hoeee.rout.gg IN A 941.134.7.226#53: query: duck.rout.gg IN A 941.134.7.245#53: query: duck.rout.gg IN A 941.134.7.226#53: query: duck.rout.gg IN A 941.134.7.245#53: query: duck.rout.gg IN A 817.76.23.251#53: query: duck.rout.gg IN A 813.51.129.177#5353: query: eric.mof.gov.xx IN A 813.51.129.177#5353: query: uri.tehila.gov.xx IN A 813.51.129.178#5353: query: dns.gov.xx IN A 813.51.144.178#5353: query: hoeee.rout.gg IN A 941.134.7.245#53: query: duck.rout.gg IN A

14/22

Uit deze log blijkt dat er een groot aantal zone-queries uitgevoerd worden op de DNSserver voor zones met “ vreemde namen” op verzoek van “client”. Navraag, bij de eigenaren van de client IP-adressen, gaf aan dat de queries kwamen van nameservers van binnen de clientnetwerken. Deze servers deden zelf niet aan logging, waardoor de bron van de queries niet te achterhalen was. Opgemerkt moet worden dat de logdata gefilterd is op Nederlandse IP-adressen en dat er veel meer queries in de oorspronkelijke log stonden. Een mogelijke manier waarop deze DNS-aanval bedoeld was te werken, is dat de veel opgevraagde zones (duck.rout.gg) “additional sections” bevatten. Deze “additional sections” bevatten dan informatie voor zones waar de gebruikers van de name-server voor misleid zouden worden Bijvoorbeeld: %dig duck.rout.gg ; <<>> DiG 8.3 <<>> govcert.nl ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18870 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; hoeeerout.gg, type = A, class = IN ;; ANSWER SECTION: hoeee.rout.gg.

1H IN A

172.16.32.13

;; AUTHORITY SECTION: hoeee.rout.gg.

1H IN NS

ns1.rr.gg.

;; ADDITIONAL SECTION: com.

1H IN A

172.22.34.60

;; Total query time: 2 msec De .com zone wordt voor deze name-server omgeleid naar de server met IP-adres 172.22.34.60. Effectief betekent dit dat voor de gebruikers van deze DNS server alle domeinen die eindigen op .com worden omgeleid naar de server met IP-adres 172.22.34.60. De cache van de betrokken name-server zou in dit geval vervuild zijn voor alle .com domeinen.


15/22

6

REACTIE

De maatregelen die bij de hoofdstukken ‘Preventie’ en ‘Detectie’ zijn beschreven helpen om adequaat te kunnen handelen tegen DNS-misbruik. Maar wat doet u als u daadwerkelijk DNS-misbruik detecteert? Hoewel het bewijzen van DNS-misbruik erg moeilijk is, proberen we in dit hoofdstuk kort aan te geven wat u kunt doen na detectie van DNS-misbruik.

Technische maatregelen Er zijn een aantal eenvoudige en praktische maatregelen die de gevolgen van gedetecteerd DNS-misbruik beperken. Als bekend is dat een forwarding DNS vervuild is, zal een herconfiguratie (tezamen met een herstart van de server) de problemen oplossen. Als interne forwarders worden misbruikt, zal het verplaatsen van de DNSfunctionaliteit naar een ander platform en/of software het misbruik tegengaan. Al deze maatregelen hebben een bepaalde impact binnen uw organisatie. Belangrijk is dat per maatregel de impact van de maatregel bekeken wordt en er een weloverwogen besluit genomen wordt over de uitvoering ervan.

Organisatorische maatregelen Om bovenstaande maatregelen tijdens DNS-misbruik adequaat te uit kunnen voeren, is het van belang om te handelen volgens van tevoren vastgelegde procedures. Dit hoeven geen specifieke "DNS-misbruikprocedures" te zijn. De maatregelen kunnen een onderdeel vormen van een algemeen calamiteitenplan. Belangrijk is dat bekend is hoe de DNS (maar ook andere elementaire systemen) is ingericht voor de organisatie. Verder moeten beheerders tijdens incidenten de (toegang tot) kennis en bevoegdheden hebben om maatregelen te kunnen nemen.

Incidentafhandeling en aangifte Na de constatering van een incident is het belangrijk om te overwegen het incident te melden aan de politie (aangifte doen). Voor het doen van een melding is het niet noodzakelijk om al bewijsmateriaal verzameld te hebben. Mogelijk is er geen basis voor strafrechtelijke vervolging. Er kan besloten worden om een civielrechtelijk proces te starten. In beide gevallen is het noodzakelijk dat het bewijsmateriaal op een degelijke manier, dat wil zeggen forensisch verantwoord, verzameld is. Voor het vaststellen van DNS-misbruik zijn de o.a. volgende gegevens nodig: • Tijdstip van het misbruik • Betrokken zone-namen • Destination IP-adres • Poortnummers • Loggegevens van aanpassing van een zone of onderdeel van een zone Deze informatie is, mits goed geconfigureerd, uit de logging van betrokken DNS-servers te halen. Wettelijk gezien moet “verstoring in het geautomatiseerde werk” aangetoond worden. Met de juiste gegevens is dit ook mogelijk, aangezien de normale DNSfunctionaliteit verstoord wordt en er gegevens veranderd worden.


16/22

Naast een (straf)rechtelijke proces zijn er andere redenen voor het doen van een melding. Voorbeelden hiervan zijn het verkrijgen van technische ondersteuning en het verzamelen van gegevens voor statistieken om tot een betere inzage te komen in de cybercrime activiteiten. Hierdoor wordt de kennis op dit gebied vergroot. Organisaties en particulieren hebben hier direct of indirect baat bij. De “Handleiding Cyber Crime: Van herkenning tot aangifte” [Cybercrime] geeft uitgebreide informatie over hoe om te gaan met ICT-incidenten.


17/22

7

CONCLUSIE

Gesteld kan worden dat misbruik van het huidige Domain Name System niet of moeilijk gedetecteerd of tegengegaan kan worden. De oorzaak ligt in het feit dat het DNS protocol niet ontwikkeld is op het gebied van beveiliging. Een goed geconfigureerde DNS-server kan de kans op misbruik aanzienlijk verminderen. Dit houdt in dat er weloverwogen keuzes gemaakt moeten worden betreffende de plaatsing van forwarding- en autoritatieve functionaliteit in het netwerk. Daarnaast zijn er een aantal maatregelen te nemen die detectie vereenvoudigen: monitoring en Intrusion Detection Systemen. Hierbij vergt het implementeren van een IDS de grootste inspanning. Het is van belang dat er altijd voldoende technische kennis binnen de organisatie aanwezig is om problemen het hoofd te kunnen bieden. Een calamiteitenplan waarin verantwoordelijkheden en taken beschreven staan kan bijdragen aan de snelle afhandeling en oplossing van DNS-misbruik. Om in de toekomst tot een goed beveiligd DNS te komen is DNSSEC in ontwikkeling. Dit systeem stelt gebruikers op het internet in staat om op een veilige manier het Domain Name System te gebruiken. De protocollen van dit systeem zijn net geaccepteerd en het zal nog geruime tijd duren voordat DNSSEC wereldwijd geïmplementeerd en gebruikt wordt.


18/22

8

REFERENTIES [Alternic]

www.alternic.net

[Bellovin]

Steven M. Bellovin, Using the Domain Name System for System Break-ins 1995 http://citeseer.ist.psu.edu/bellovin95using.html

[BindPo]

US-CERT ISC BIND 8 vulnerable to cache poisoning via negative responses November 2003 http://www.kb.cert.org/vuls/id/734644

[cbronline]

Computer business review Secure DNS faces resistance http://www.cbronline.com/article_news.asp?guid=5CB022921149-4657-BA91-3F67AA4C91B5

[CERTBind]

CertCC & Microsoft Kwetsbaarheden in DNS server software BIND en Microsofts DNS. http://www.cert.org/advisories/CA-1997-22.html http://www.kb.cert.org/vuls/id/109475

[CyberCrime]

Van herkenning tot aangifte. Handleiding Cyber Crime GOVCERT / (KLPD) - April 2005 http://www.govcert.nl/render.html?it=39

[DDOS]

Aanbevelingen ter bescherming tegen Denial-Of-Service aanvallen GOVCERT.NL - Februari 2005

[DNSCertCC]

Allen Householder, Brian King Securing an internet Name Server CERT® Coordination Center - Augustus 2002 http://www.cert.org/archive/pdf/dns.pdf

[FBI]

www.fbi.gov

[GIACgreen]

Ian Green DNS Spoofing By The Man in The Middle januari 2005 http://www.giac.org/certified_professionals/practicals/gsec/425 7.php

[INTERNIC]

www.internic.net


19/22

[JUSTDEP]

Justice Department, Eugene E. Kashpureff Pleaded Guilty to Unleashing Software on the internet…. 1998 http://www.usdoj.gov/criminal/cybercrime/kashpurepr.htm

[LogAna]

http://www.uu.se/Software/Analyzers/Access-analyzers.html

[NTRR]

US-CERT Microsoft Windows NT and 2000 Domain Name Servers allow non-authoritative RRs to be cached by default 2001 http://www.kb.cert.org/vuls/id/109475

[RFC1034]

DOMAIN NAMES - CONCEPTS AND FACILITIES ftp://ftp.isi.edu/in-notes/rfc1034.txt

[RFC1035]

DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION ftp://ftp.isi.edu/in-notes/rfc1034.txt

[RFC2845]

Secret Key Transaction Authentication for DNS (TSIG) http://www.faqs.org/rfcs/rfc2845.html

[RFC3164]

The BSD syslog Protocol http://www.faqs.org/rfcs/rfc3164.html

[RFC4033 etc] The new DNSSEC-bis RFC's http://www.rfc-archive.org/getrfc.php?rfc=4033 http://www.rfc-archive.org/getrfc.php?rfc=4034 http://www.rfc-archive.org/getrfc.php?rfc=4035 [SANSCarli]

Florent Carli Security Issues with DNS SANS Institute 2003 http://www.sans.org/rr/whitepapers/dns/1069.php

[SysLog]

http://www.loganalysis.org/

[TSIGLui]

Lui Cricket Securing DNS http://www.linux-mag.com/content/view/888/2238/

[FS-2008-06]

GOVCERT.NL Factsheet 2008-06 ‘De Kaminsky Code’: Kwetsbaarheden in DNS https://www.govcert.nl/download.html?f=118


20/22

9

AFKORTINGEN AXFR DNS DNSSEC NTP MITM RR RFC UDP

Asynchronous Full Transfer Zone Dynamic Name System secure DNS Network Time Protocol Man In The Middle Resource Records Request For Comments User Datagram Protocol


21/22

10 DISCLAIMER GOVCERT.NL betracht grote zorgvuldigheid bij het samenstellen en onderhouden van de informatie. GOVCERT.NL is echter niet verantwoordelijk voor de volledigheid, juistheid en actualiteit van de informatie en aanvaardt geen aansprakelijkheid voor eventuele directe of indirecte schade als gevolg van de activiteiten die door een gebruiker worden ondernomen op basis van de informatie, adviezen en waarschuwingen die door middel van dit document wordt verstrekt. Indien er verwezen wordt naar externe bronnen staat GOVCERT.NL niet garant voor de juistheid en volledigheid van deze informatie. Gezien de technologische ontwikkelingen wordt niet gepretendeerd dat het document uitputtend is.

11 DANKWOORD Dit document is door GOVCERT.NL opgesteld met bijdrage van Coen de Voogd (op persoonlijke titel)


22/22

DNS-MISBRUIK. Van herkenning tot preventie. Wilhelmina van Pruisenweg AN Den Haag. Versie : 2.2 Den Haag : 30 juli

Recommend Documents