DNSSEC en säkerhetsförbättring av DNS -en studie om Svenska kommuners syn på DNSSEC

Examensarbete DNSSEC en säkerhetsförbättring av DNS -en studie om Svenska kommuners syn på DNSSEC Författare: Henric Telling och Anders Gunnarsson Handledare: Ola Flygt Examinator: Mathias Hedenborg Henric Telling och Anders Gunnarsson 2010-11-29 Ämne: Datalogi Nivå: Kandidatexamen inom datalogi Kurskod: 2DV00E

Sammanfattning Syftet med uppsatsen är att undersöka varför få svenska kommunerna valt att installera DNSSEC på sina domäner. DNS är en av de viktigaste protokollen på Internet och behövs för att sammanlänka IP-adresser med mer lättförståeliga adresser för oss människor. DNS skapades utan att tänka på säkerheten, för att kunna göra DNS säkrare utvecklades ett säkerhetstillägg till DNS detta fick namnet DNSSEC. Vi har använt oss av litteraturstudie, experiment och intervjuer för att skapa en djupare kunskap och förståelse om hur DNS och DNSSEC fungerar samt besvara varför få kommuner har valt att installera DNSSEC. Under vår litteraturstudie läste vi om flera sårbarheter i DNS och hur dessa kan utnyttjas för att utsätta en organisation för attacker såsom cacheförgiftning och MITM. Vi testade dessa sårbarheter och bekräftade det. Efter installationen av DNSSEC kunde inte angreppen längre genomföras i vår testmiljö. Under intervjuerna kom vi fram till att den vanligaste orsaken att kommuner inte väljer att installera DNSSEC är okunskap om tillvägagångsättet för en installation och att de tycker deras nuvarande DNS fungerar bra, det blir då ingen prioriterad fråga. Kommunerna som installerat DNSSEC är nöjda med sin installation och bara en kommun har upplevt problem vid införandet. För att vi ska kunna fortsätta utveckla Internet är en kontroll av säkerheten en nödvändighet och då är DNSSEC en vägvisare. Kommunerna borde föregå med gott exempel och vara bland de första som inför DNSSEC så besökarna till deras hemsidor kan känna sig säkra att informationen på deras sidor är korrekt. Nyckelord: DNS, DNSSEC, IP, Säkerhet, Cache, MITM, Internet,.SE, ARP, Intrång, Windows, Server, DoS. i

Abstract The purpose of this paper is to investigate why few Swedish municipalities have chosen to install DNSSEC on their domains. DNS is one of the most important protocols on the Internet and used to link IP-addresses to understandable addresses for users. DNS was created without thinking about security, to make DNS more secure a security extension was developed to DNS, named DNSSEC. We have used literature review, experiments and interviews to create a deeper knowledge and understanding about DNS and DNSSEC, how it works and why few municipalities have chosen to install DNSSEC. In the literature we read about several vulnerabilities in DNS and it can easily be exposed to attacks such as cache poisoning and MITM. We tested these vulnerabilities and confirmed them. After installation of DNSSEC we could not expose our implemented DNS anymore in our test environment. During the interviews, we concluded that the most common reason why municipalities do not choose to install DNSSEC is ignorance of an installation and they think that their current DNS works well and it does not become a priority. The municipalities that have installed DNSSEC are satisfied with its installation and only one municipality has experienced difficulties during the implementation. In order for us to continue developing the Internet a control of security is a necessity and DNSSEC is a good example. Local authorities should lead by good example and be among the first to implement DNSSEC, so users of their websites can be assured that the information on their pages is accurate. Keywords: DNS, DNSSEC, IP, Security, Cache, MITM, Internet,.SE, ARP, Intrusion, Windows, Server, DoS. ii

Förord Uppsatsen är en kandidatuppsats inom datalogi på institutionen för datavetenskap, fysik och matematik på Linnéuniversitetet i Växjö. Uppsatsen omfattar 15 högskolepoäng och utfördes under höstterminen 2010. Arbetet inriktas mot kommuner och vi vill tacka de kommuner som valt att ställa upp för intervju vilket gjort vårt arbete möjligt. Vi vill tacka Växjö-, Gävle-, Gislaved-, Älmhult-, Lund- och Leksands kommun. Vi vill även tacka enskilda personer som på sitt sätt bidragit till uppsatsen. Ola Flygt, Linnéuniversitetet Kontinuerlig handledning som bidragit med goda råd samt diskussioner och under arbetets gång. Fredrik Ringberg, Växjö kommun Första kontaktperson inom en kommun som bidragit med många tips för vidare kontakter för intervjuer. Håkan Larsson, Wexnet Bidrog med att bjuda in oss på föreläsning om DNSSEC från ett företag som tillhandahålla tjänsten. Växjö, 2010-11-29 Henric Telling Anders Gunnarsson iii

Innehåll 1. Inledning... 1 1.1 Bakgrund... 1 1.2 Syfte... 2 1.3 Tidigare forskning... 2 1.4 Avgränsningar... 2 1.5 Målgrupp... 2 1.6 Rapportstruktur... 2 2. Metod... 3 2.1 Litteraturstudie... 3 2.2 Experiment... 3 2.3 Fallstudie... 3 2.3.1 Intervju... 4 3. DNS... 5 3.1 Introduktion... 5 3.2 Trädstrukturen i DNS... 5 Figur 3.1 : Visualisering av DNS-trädstruktur.... 5 3.3 Auktoritativa namnservrar, zoner och zonfiler... 5 3.4 DNS-uppslagning... 6 3.5 Mellanlagring... 7 3.6 Säkerhetsbrister... 8 3.6.1 Man-in-the-middle... 8 3.6.2 Cacheförgiftning... 9 3.6.3 DoS-attacker... 10 3.6.4 Visualisering av sårbarheterna inom DNS... 11 4. DNSSEC... 12 4.1 Varför DNSSEC... 12 4.2 Hur fungerar DNSSEC... 12 4.3 Lösningar till DNS- säkerhetsbrister... 14 4.4 Säkerhetsbrister i DNSSEC... 14 4.5 DNSSEC validering för användare... 14 5. DNSSEC i Sverige och världen... 15 5.1 Historik... 15 5.2 Checklista för implementation av DNSSEC... 16 iv

5.3 Olika produkter för att installera DNSSEC... 17 5.3.1 Microsoft Server 2008 R2 DNS... 17 5.3.2 BIND... 17 5.2.3 OpenDNSSEC... 17 6. Installation av DNS och DNSSEC i testmiljö... 18 6.1 Syfte... 18 6.2 Planering... 18 6.2.1 Faktorer... 18 6.3 Installation av DNS... 19 6.3.1 ARP och DNS-förgiftnings attack... 21 6.3.2 DNS-cache förgiftningsattack... 23 6.3.3 DoS-attack... 26 6.3.4 Intrång i Windows Server 2003... 26 6.5 Installation av DNSSEC... 27 6.5.1 ARP och DNS-förgiftningsattack... 29 6.5.2 DNS-cache förgiftningsattack... 30 6.5.3 DoS-attack... 30 6.5.4 Intrång i Windows Server 2008... 31 7. Resultat... 32 7.1 Intervjuer... 32 7.1.1 Intervjuresultat... 32 7.2 Statistik... 33 8. Analys och Diskussion... 35 8.2 Framtida forskning... 36 Referenser... 37 Appendix A Ordlista... 41 Appendix B DNS-post definition... 44 v

Figur- och tabellförteckning Figur 3.1 : Visualisering av DNS-trädstruktur.... 5 Figur 3.2 : Visualisering av en DNS-uppslagning från en användare.... 7 Figur 3.3 : Visualisering av sårbarheterna inom DNS under DNS-uppslagning.... 11 Figur 4.1 : Visualisering av NSEC-uppslagning mellan olika namnservrar.... 13 Figur 5.1 : Karta med kommuner med DNSSEC [44].... 16 Figur 6.1 : Testmiljöns infrastruktur för implementering av DNS.... 19 Tabell 6.1 : Visar egenskaper och inställningar för varje nod i infrastrukturen för implementering av DNS.... 20 Figur 6.2 : Resultat av angripen DNS-server med dig-kommando.... 22 Figur 6.3 : Resultat av icke-angripen DNS-server med dig-kommando.... 22 Figur 6.4 : Resultat av porttest för DNS-server 1.... 23 Figur 6.5 : Ansatta parametrar i Metasploit inför attack.... 24 Figur 6.7 : Korrupt svar från DNS-server 1 med nslookup.... 25 Figur 6.8 : Korrupt svar från DNS-server 2 med dig... 25 Tabell 6.2 : Visar egenskaper och inställningar för varje nod i infrastrukturen för implementering av DNSSEC.... 28 Figur 6.9 : Domänen www.lab är säkrad med DNSSEC och visar en godkänd validering.... 29 Figur 6.10 : Säkert DNS-svar innehållande RRIG för domänen www.lab.... 29 Figur 6.11 : Domänen www.lab är säkrad med DNSSEC och visar därför att sidan är korrupt.... 30 Figur 6.12 : Resultat av porttest för DNS-server 1.... 30 Figur 7.1 : Visar antalet registrerade DNSSEC-domäner under de senaste 90 dagarna. 33 Figur 7.2 : Visar antalet registrerade DNSSEC-domäner vid de 15 senaste månaderna.34 Figur B.1 : Visar DNS-postformatet och dess fält... 44 Tabell B.1 : Förklaring av definierade fält för DNS-poster.... 44 Tabell B.2 : Förklaring av definierade TYPE värden.... 45 Tabell B.3 : Förklaring av definierade QTYPE värden.... 45 Tabell B.4 : Förklaring av definierade CLASS värden.... 45 Tabell B.5 : Förklaring av definierade QCLASS värden.... 45 Figur B.2 : Visar SOA-format.... 46 Tabell B.6 : Förklaring av definierade SOA värden.... 47 Figur B.4 : Visar de olika fälten i pakethuvudet... 47 Tabell B.7 : Förklaring av definierade fält pakethuvudet.... 48 Figur B.5 : Visar format för en DNS-fråga.... 48 Tabell B.8 : Förklaring av definierade fälten i DNS-frågan.... 49 Figur B.6 : Visar DNS-postformatet och dess fält... 49 Tabell B.9 : Förklaring av definierade fält i en DNS-post.... 49 vi

1. Inledning Detta kapitel presenterar arbetets bakgrund, syfte, tidigare forskning, avgränsningar, målgrupp och förklarar rapportens struktur. En av de viktigaste tjänsterna som får Internet att fungera är DNS (Domain Name System). DNS är ett protokoll som mappar datorernas IP-adresser till förståeliga adresser för oss användare. DNS är skapat i dess enklaste form och innehåller många säkerhetsbrister. Paketen som skickas med DNS kan enkelt stoppas eller förvrängas och på så sätt visar användaren fel information. DNSSEC (DNS Security Extention) är lösningen för de flesta säkerhetsbrister i DNS då DNSSEC skapar integritet samt bevisar äkthet för paketen med hjälp av digitala signaturer [1]. Trots att denna säkerhetsförbättring funnits tillgänglig sedan ett par år tillbaka visar undersökningar och statistik att bara ett fåtal valt att implementera DNSSEC. Anne-Marie Eklund Löwinder som är kvalitets- och säkerhetsansvarig på den svenska toppdomänen.se håller med om att säkerheten är dålig bland kommunerna och att kunderna som använder deras e- tjänster riskerar att bli lurade [2]. 1.1 Bakgrund Varje dator som är uppkopplad mot Internet har en egen IP (Internet Protocol) -adress, dessa behövs för att vi ska kunna skicka datatrafik mellan datorerna. För att göra det lättare att komma ihåg IP-adresserna har de tilldelats domännamn. DNS är kopplingen mellan IP-adresser och domännamnen [8]. DNS kan ses som en telefonbok för Internet. För att besöka en hemsida skrivs adressen in i webbläsaren och då sker en DNS-uppslagning, programvaran som utför DNS-uppslagningen åt användaren kallas resolver. När detta är gjort skickas informationen tillbaka till datorn som efterfrågade informationen och datorn kan sedan tillgå den efterfrågade hemsidan. DNS skapades utan säkerhetsaspekter och det finns en rad kända hot mot DNS och alla dessa ses som allvarliga attacker, de kan skada användarna på Internet och göra att organisationen tappar kontroll över sin hemsida [45]. DNS innehåller säkerhetsbrister och IETF (Internet Engineering Task Force) ger exempel på angrep som kan förekomma emot DNS i RFC (Request For Comments) 3833 [3]. I november 1993 arrangerade IETF en sammankomst där de diskuterade DNSSEC som skulle lösa säkerhetsproblemen inom DNS. Målen var att skapa något som var bakåtkompatibelt med DNS, skapa dataintegritet, dataautentisering samt innehålla digitala signaturer [3]. Mars 1999 publicerade IETF RFC 2535 och DNSSEC hade skapats [4]. Trots att DNSSEC skapades för 11 år sedan finns det fortfarande ett stort antal företag och myndigheter som har bristfällig DNS-säkerhet. Den svenska toppdomänen.se förespråkar implementeringen av DNSSEC på de svenska domänerna. De utför varje år undersökningar för att utreda hälsoläget för Internet och undersöker hur implementeringen av DNSSEC fortskrider [5]. 1

1.2 Syfte Syftet är att undersöka varför ett fåtal har valt att implementera DNSSEC när den finns tillgänglig och kan förebygga attacker. Hur fungerar DNS och DNSSEC? Fördelar och nackdelar med DNSSEC? Hur genomförs en installation av DNS och DNSSEC? Vad finns det för säkerhetshot i DNS och DNSSEC? Varför väljer inte fler kommuner att övergå till DNSSEC? 1.3 Tidigare forskning Under de tre senaste åren har IIS (Stiftelsen för Internetinfrastruktur) som är ansvariga för Sveriges toppdomän.se utfört undersökningar om svenska domäner. Målet med deras rapporter är att undersöka kvalitén och nåbarheten i domänsystemet inom.sezonen. Under 2009 testades 663 domäner och 867 unika servrar. Resultaten visar att 23 procent lider av allvarliga fel och 34 procent genererar felmeddelanden och markeras med en varning. Exempel på felmeddelanden i rapporten kan vara om namnservern är rekursiv eller att enbart en namnserver används [5]. Domänerna som testades är inte enbart kommuner. 1.4 Avgränsningar Vi kommer att inrikta oss mot svenska kommuner som ingår i toppdomänen.se. 1.5 Målgrupp Vi riktar oss mot personer som har kandidatexamen eller liknade inom ämnet datalogi. Vi riktar oss även till personer som är sakkunniga inom området. 1.6 Rapportstruktur Första kapitlet beskriver uppsatsens bakgrund och syfta samt tidigare forskning inom ämnet. Andra kapitlet beskriver uppsatsens val av ansats. Motivering samt förklaringar av valda metoder finns under detta kapitel. Tredje kapitlet förklarar DNS teoretisk, hur DNS fungerar samt dess säkerhetsbrister. Fjärde kapitlet förklarar DNSSEC teoretiskt, hur DNSSEC fungerar samt kvarstående säkerhetsproblem. Femte kapitlet beskriver det aktuella läget av införande av DNSSEC i Sverige och världen. Sjätte kapitlet förklarar och beskriver vår testmiljö där vi installerat DNS och DNSSEC samt utfört olika typer av angrepp mot DNS. Resultat och tillvägagångssätt förklaras. Sjunde kapitlet representeras vårt resultat utifrån intervjuer samt aktuell statistik över införande av DNSSEC i Sverige. Åttonde kapitlet redovisar våra slutsatser utifrån vår undersökning. Vi presenterar även förslag på tillvägagångssätt för ett ökat införande av DNSSEC samt förslag på fortsatt forskning inom området. 2

2. Metod Detta kapitel förklarar och motiverar arbetets metodik. I kapitlet beskrivs varje delmoment i arbetet och motiveras varför de används. Tidigare forskning från IIS påvisar en kvantitativ undersökning där resultatet visas i form av statistik. De har utfört tester och experiment vilket visar en kvantitativ undersökning [6]. Vi kommer att ta del tidigare kvantitativ forskning för att utföra en kvalitativ och empirisk undersökning där vi skall skaffa oss en djupare förståelse för verkligheten i form av vetenskapliga artiklar, egna experiment samt intervjuer. 2.1 Litteraturstudie En litteraturstudie ingår i den kvalitativa forskningsprocessen. Litteraturstudien ger en överblick av tidigare samlade kunskaper inom området vilket skapar en större förståelse för problemen. Studien ger stöd vid problemformuleringen eftersom en bredare överblick av problemen skapas [6]. Vi kommer utföra en litteraturstudie av vetenskapliga artiklar som publicerats samt böcker inom ämnet för att skapa en bättre förståelse för problem och begrepp inom valt ämne. 2.2 Experiment Experiment används för att lokalisera orsakssamband samt förklara vad olika fenomen beror på. Ett experiment är en fix design vilket innebär att inget kan ändras under experimentets gång. Frågeställning som vad ska analyseras? Vilket syfte? ska definieras. Utifrån frågeställningen formuleras en hypotes, ett antagande om det som ska undersökas. I planeringen måste faktorer som kan påverka undersökningen anges i form av oberoende variabler [15]. Vi kommer genomföra experiment genom att installera en DNS-server samt angripa den med kända attacker. En DNSSEC-server kommer även installeras för att skapa oss en egen uppfattning om implementering av DNSSEC. Eftersom vi även kommer utföra en fallstudie anser vi att ett experiment inom området krävs för att förstå den realistiska miljön. 2.3 Fallstudie En fallstudie används för att undersöka ett fenomen i dess realistiska miljö. Dess omständigheter tilltalar och passar det kvalitativa perspektivet. Fallstudier anses särskilt bra att tillämpa då studien är komplex. Målet är att förklara samt förstå organisationer och dess system. En fallstudie behöver inte inrikta sig mot enbart ett fall, utan flera fall kan undersökas i samma studie [6]. Fallstudien ger kunskaper på djupet och designen är flexibel där ändringar av frågor och inriktning under studiens gång kan förändras. Fallstudien använder sig av intervjuer vilket vi kommer utnyttja [15]. En fallstudie är en passande studie då vår frågeställning inriktar sig mot olika kommuner. Eftersom vi redan vet att de kommuner vi ska undersöka skiljer sig mot varandra passar denna studie. Den ger oss flexibilitet under studiens gång och vi behöver undersöka flera olika fall där utsagorna skiljer sig från varandra. 3

2.3.1 Intervju En intervju kan utformas på olika sätt, de finns strukturerade, halvstrukturerade och öppenriktade intervjuer. En strukturerad intervju kan ses som en muntlig enkät där en fördefinierad frågelista finns och den följs till punkt och pricka. Halvstrukturerad har en uppsättning av frågor som används som ett stöd genom intervjun där ordningen och formuleringarna kan variera. I en öppenriktad intervju låts den intervjuande till stor del styra vad som ska tas upp [15]. Vi kommer använda oss av halvstrukturerade intervjuer eftersom vi behöver anpassa intervjufrågorna utifrån den intervjuande därför valde vi att inte använda oss av enkäter. Halv-strukturen ger oss den bästa möjligheten att genom intervjuer utreda vår frågeställning. En strukturerad intervju är inte möjlig eftersom varje fall skiljer sig från mängden och genom en öppenriktad intervju kan vi inte strukturera vår frågeställning på ett effektivt sätt. Datainsamlingen sker genom ljudinspelning på ett ljudmedium för att sedan transkriberas till skriven text för senare analys. 4

3. DNS Detta kapitel förklarar hur DNS-protokollet är uppbyggt och hur det fungerar. Även DNS säkerhetsbrister förklaras i form av olika angrepp som kan utföras emot DNS. 3.1 Introduktion DNS-protokollet används för att översätta datorernas IP-adresser till mer förståeliga adresser för oss människor. DNS är en distribuerad databas med hierarkisk struktur som är uppdelat i zoner [7]. En distribuerad databas betyder att all information fördelas mellan flera olika serverar. Hierarkistrukturen innebär att all information lagras i en trädstruktur. Designen av DNS ger ett snabbt uppslag om vilken IP-adress som tillhör ett domännamn, detta görs med hjälp av en namnserver [8]. 3.2 Trädstrukturen i DNS Figur 3.1 visar en visualisering av DNS-trädstruktur. I toppen av trädet finns enbart en nod, den kallas root. En nivå ner i trädstrukturen finns noderna vilka benämns som toppdomäner där bland annat.se ingår. Varje nod i trädet tilldelas ett domännamn förutom root-noden och en punkt används för att avgränsa noderna. På så sätt kan en sökväg skapas vilket leder rakt genom trädet. Exempel på en sökväg som även figur 3.1 illustrerar är www.exempel.se. Trädstrukturen där samtliga noder ingår benämns som domännamnrymd där alla domäner för hela Internet ingår. För varje domän som ingår i domännamnrymden finns en auktoritativ namnserver [8]. Alla färgade noder i figur 3.1 visar att de ingår i.se-domänen. De tre mörkare noderna ingår i exempel.se-domänen och den allra mörkaste ensamma noden tillhör www.exempel.se-domänen. Figur 3.1 : Visualisering av DNS-trädstruktur. 3.3 Auktoritativa namnservrar, zoner och zonfiler En namnserver som ansvarar för en domän benämns som en auktoritativ namnserver. Namnservers uppgift är att översätta domännamnet till en IP-adress. Eftersom DNS 5

består av en hierarkis struktur behöver inte toppdomänen.se lagra all information om underliggande noder eftersom ansvaret kan delegeras till flera olika auktoritativa namnservrar. Dessa namnservrar innehåller bara information om en del av sin domän och benämns som en zon [8]. Varje namnserver som ansvar för en zon lagrar en zonfil vilket innehåller information om alla domännamn som ingår i domänen, så mappningen från domännamn till IP-adresser kan ske. Zonfilen är uppdelad i DNS-poster där varje post innehåller information om varje enskilt domännamn. Namnservern använder DNS-posterna för att svara på olika frågor om varje domän som resolver ställer. En DNS-överföring kan ses som en serie av frågor och svar mellan två aktörer, resolver och namnservern. Aktörerna som integrerar är programvaror hos klienten och servern [9]. 3.4 DNS-uppslagning En DNS-uppslagning går till på så sätt att resolvern ställer frågan om vilken IP-adress ett specifikt domännamn har, namnservern svarar med information som finns lagrat. Teoretiskt tolkas det att enbart en fråga ställs med ett svar. Det som sker är att resolvern, vilket kan vara en användares webbläsare till exempel kontaktar en stubb-resolver som innehåller en lista av rekursiva-resolvers som antingen vet vilken namnservern som har informationen eller vidarebefordrar frågan till en annan zon [9]. Skillnaden mellan stubb-resolver och en rekursiv-resolver är att rekursiva-resolvers genomför en DNSuppslagning genom att ställa frågan om domännamnet om och om igen tills den får svar. Stubb-resolvern ställer frågan om domännamnet en gång till en rekursiv-resolver [8]. Om den aktuella zonen inte har informationen eller IP-adressen som efterfrågas kommer den rekursiva namnservern söka efter informationen högs upp i hierarkin, till root där vidare sökningar sker ner i DNS-trädet tills antingen ett svar kan ges eller returneras ett felmeddelande [9]. Figur 3.2 illustrerar en DNS-uppslagning och nedan följer en förklaring om vad som sker vid de olika stegen [8]. 1. En användare anger adressen www.exempel.se i sin webbläsare. 2. Stubb-resolvern i användarens dator frågar den rekursiva-resolvern vilken IPadress som motsvarar domänen www.exempel.se. 3. Den rekursiva-resolvern vidarebefordrar frågan högre upp i hierarkin, till root. 4. Uppslag i root-serverns zonfil indikerar att.se-domäner är delegerade till.sezonen. Root-servern svarar med en hänvisning till auktoritativservrarna för.sezonen. 5. Resolvern upprepar frågan till auktoritativservrarna för.se-zonen. 6. Uppslag i auktoritativservrarnas zonfil för.se-zonen visar att example.se har delegerats och.se-namnserver svarar med en hänvisning till de auktoritativservrarna som pekas ut för domännamnet. 7. Resolvern upprepar frågan igen till de utpekade auktoritativa servrarna för exampel.se. 8. Auktoritativa servern för example.se svarar med IP-adressen som motsvarar www.example.se. 6

9. Den rekursiva servern vidarebefordrar IP-adressen till stubb-resolvern i användarens dator. 10. Stubb-resolvern vidarebefordrar IP-adressen till webbläsaren. 11. Webbläsaren ansluter till webbservern med den mottagna IP-adressen och hemsidan laddas ner till användarens dator. Alla steg är nödvändiga om det inte finns lagrad information om vilka zoner eller namnservrar som ansvarar för en angiven domän sedan tidigare. Figur 3.2 : Visualisering av en DNS-uppslagning från en användare. 3.5 Mellanlagring Mellanlagring används för att förhindra att DNS-uppslagningarna blir tidkrävande samt undvika onödig datatrafik över nätverket [8]. DNS-uppslag som lyckas når sällan rooten i DNS-trädet. Svaren på resolverns fråga lagras oftast i cacheminnet på namnservern längre ner i trädet. Exempelvis hos användarens Internetleverantör [9]. Utifrån tidigare underrubrik DNS-uppslagning har användaren redan efterfrågat IPadressen för domänen www.exempel.se där IP-adressen returnerades. Utifrån det exemplet har resolvern mellanlagrat informationen i cacheminnet som gavs från rootservern. Därmed finns det lagrat vilka namnservrar som är auktoritativa servrar inom.se-zonen. Frågan ställs direkt till en av.se-namnservrar och svaret returneras snabbare. Ett annat scenario kan uppstå då resolvern nyligen besvarat en fråga om ett annat domännamn som slutar på exampel.se, till exempel ftp.exempel.se. Då finns svaret från.se-zonens namnserver lagrat i cacheminnet om vilken auktoritativ server som 7

besvarade frågan tidigare och frågan kan ställas direkt till den auktoritativa servern ansvarig för exampel.se. Scenario tre kan uppstå då resolvern tidigare besvarat en fråga om www.exempel.se. Då finns svaret från den auktoritativa servern om domännamnet lagrat i cacheminnet och resolvern kan svara direkt viken IP-adress som motsvarar www.exempel.se. Hur länge denna information lagras beror på vilken värde zonen har ansatt för TTL (Time To Live) [8]. 3.6 Säkerhetsbrister Det vanligaste tillvägagångsättet för att hantera säkerhetshål i DNS är att uppdatera implementerad mjukvara vilket enbart skapar temporärt uppskov tills nästa säkerhetshot uppstår. Alla säkerhetshot i DNS varierar men dess egenskap att utnyttja DNS svagheter är lika [7]. Nedan följer beskrivning av de huvudsakliga säkerhetshoten. 3.6.1 Man-in-the-middle MITM (Man In The Middle) -attack är möjlig eftersom resolvern erhåller svar från DNS-servern och kan inte utföra någon äkthetsbevisning eller verifiering av integriteten för paket den tar emot. Den enda äkthetsbevisningen resolven kan utföra är kontrollera IP-adressen från DNS-servern, destination- samt källport och DNS-överförings-ID. En angripare kan enkelt matcha dessa parametrar genom manipulation och klienten kan inte göra mer än att tilltro paketen och ta emot. Således kan angriparen lösa berättigade frågor och svara med falsk information [10]. 3.6.1.1 Paketavlyssning Överföringen som sker med frågor och svar i DNS är osignerade och skickas med okrypterade UDP (User Datagram Protocol) -paket och en angripare kan enkelt avlyssna DNS-överföringen [3]. Genom att avlyssna DNS-frågan från resolvern kan angriparen generera ett svar tillbaka till resolvern innan den tilltänkta DNS-servern hinner svara. Angriparen kan modifiera svaret och resolvern har ingen säkerhetsmekanism som utför äkthetsbevisning av källan för att veta om svaret blivit manipulerat [10]. Säkerhetsmekanismer som TSIG (Transaction SIGnature) och IPSec är möjligt att implementera men belastningarna för varje DNS-överföring skulle öka vilket skapar instabilitet mellan de olika parterna, resolvern och DNS-servrarna. Implementeringen skulle heller inte skapa något förtroende eftersom de bara genererar hop-by-hop integritet och ingen end-to-end integritet mellan parterna [3]. En MITM-attack involverar en tredje part, angriparen genskjuter kommunikationen mellan de andra två parterna, servern och klienten vilket vanligtvis uppnås genom ARP (Address Resolution Protocol) -förgiftning inom en LAN (Local Area Network) miljö. Dataöverföringar använder MAC (Media Access Control) -adresser som opererar på datalänklagret av TCP (Transmission Control Protocol) /IP-stacken för att översätta IPadresser till MAC-adresser. Protokollet som används vid denna översättning är ARP. MAC-adressen krävs för att nätverksenheter ska kunna kommunicera med varandra. Dessa nätverksenheter måste kunna skicka och ta emot MAC-adresser [24]. ARP hanterar två olika typer av paket, ARP-förfrågningar och ARP-svar. Den nod som vill veta MAC-adressen till mottagarnoden broadcastar en APR-förfrågan ut över 8

nätverket. Mottagarnoden med den angivna IP-adressen besvarar frågan med sin MACadress genom ett ARP-svar i unicast. Noden som ställde ARP-förfrågan lagrar svaret i sitt lokala cacheminne (ARP-tabell) genom att para ihop IP-adressen och MACadressen i par om (IP, MAC) [25]. ARP-protokollet innehåller ingen autentiseringsmekanism vilket inte förhindrar en angripare från att skicka förfalskade ARP-svar, de förhindrar inte heller att vem som helst kan besvara ARP-förfrågningar. När en angripare omdirigerar trafiken till en annan dator inom samma LAN tillåts den att genomföra detta utan att någon autentisering sker. En ARP-spoofing attack sker när angriparen skickar ett förfalskat ARP-svar genom att låtsas ha IP-adressen som efterfrågas. Detta leder till att den förfrågande mellanlagrar fel adress i sin ARP-tabell och ständigt skickar data till angriparen utan att vara medveten om att det sker. DNS-cacheförgiftning är en konsekvens av MITM-attacker [24]. 3.6.1.2 Gissa överförings-id DNS använder till största del UDP-protokollet vid överföring. Det är enkelt för en angripare att generera paket som matchar UDP-protokollets parametrar. ID-fältet i DNS-huvudet är ett 16-bitars fält och serverns UDP-port associeras med DNS som har en välkänd port vilket kan vara en av 2 32 olika kombinationer. Spannet mellan olika kombinationer är inte tillräckligt stort för att undvika brute-force attacker. I praktiken kan klientens UDP-port och ID-numret förutses från tidigare överföringar och det är inte ovanligt att klientens port är av ett fixt värde med tanke på brandväggar och andra restriktioner. Därför kan spannet frekvent reduceras till 2 16 olika kombinationer. Eftersom denna attack är beroende av att förutse resolverns beteende lyckas den oftast. En korrekt gissning av överförings-id: et är inte tillräckligt för att injicera korrupt data. En kombination av kännedom eller gissning av frågetypen (QTYPE) och fråga angående domännamnet (QNAME) gör att resolvern har svårt att skilja på korrekt eller korrupt data. I de flesta avseenden likar denna attack en paketavlyssning. Denna attack är mer komplex än paketavlyssning eftersom attacken fungerar enbart då antagandena är korrekta, attacken är dock enklare eftersom angriparen inte behöver befinna sig på samma nätverk [3]. 3.6.2 Cacheförgiftning DNS använder cacheminnet för att effektivisera DNS-förfrågningar. DNS-protokollet stödjer inget effektivt sätt att uppdatera DNS-servrarnas cacheminne [10]. Därför kan en angripare utnyttja svagheten genom att förse den rekursiva resolvern med falsk information om domänens IP-adress. Uppgifterna lagras i resolverns cacheminne där TTL-värdet kan ansättas av angriparen. När användaren ställer en förfrågan om domänen kommer ett det felaktiga svaret skickas till användaren. Domänen med den felaktiga IP-adressen kan leda till en förfalskad hemsida där användarens ges fel information eller luras att ange känslig information [8]. De flesta namnbaserade attackerna kan delvis mildras genom långvariga kontroller av DNS-poster i relevans till originalförfrågan, dock räcker inte skyddet till gentemot Name-Chaining-attacker. Det finns flera olika varianter på denna attack men de som 9

involveras i alla är DNS-poster vars DNS-data (RDATA) innehåller ett DNS-namn, eller i vissa fall inte alls innehåller något DNS-namn utan direkt mappar till ett korrupt DNS-namn. Genom dessa DNS-poster kan angriparen injicera felaktiga adresser till användarens cacheminne och därmed omdirigera efter angriparens tycke [3]. Värsta exemplen av detta är DNS-posterna CNAME, NS och DNAME för att de kan omdirigera offrets DNS-frågor vilket angriparen väljer. DNS-poster som MX och SRV är inte lika farliga, men kan i princip också utlösa ytterligare uppslagningar som angriparen väljer. DNS-posterna A och AAAA använder inte DNS-namn i sina DNSdata (RDATA) men eftersom in-addr.arpa och IP6.arpa indexeras för DNS-kodning av IPv4 och IPv6 kan även dessa DNS-poster användas för Name-Chaining-attacker [3]. Generellt sett sker en attack på följande sätt [3]: 1. Offret ställer en DNS-förfrågan. 2. Angriparen injicerar ett svar exempelvis via paketavlyssning vilket ska leda till att användaren någon gång i processen skall ges fel information. 3. Angriparen svar innehåller en eller flera DNS-poster med DNS-namn i deras RDATA. Beroende på vilken typ av attack kan angriparen antingen injicera falsk data till användarens cacheminne eller omdirigera till en server angriparen väljer. En angripare som injicerar DNS-poster i användarens cacheminne kan alltid åstadkomma någon form av skada [3]. 3.6.3 DoS-attacker Liksom många andra nätverkstjänster är DNS såbar för DoS (Denial of Service) - attacker. DNS-servrar riskerar även att bli använda som DoS-förstärkare eftersom svarspaketen för DNS tenderar att vara större än paketen där DNS-förfrågan ställs [3]. En angripare kan förgifta en ARP-tabell för en användare på så sätt att varje paket användaren skickar skickas till angriparen istället för den tilltänkta destinationen. Då kan angriparen blockera kommunikationen för användaren [25]. DNS-servrar är inte särskilt utsatta för DoS-attacker så länge DNS-servern tilldelas tillräckligt med minne. En DNS-server kan snabbt svara på DNS-frågor om den är auktoritativ [26]. Den 21 oktober 2002 utsattes alla 13 root-servrar samtidigt för en DDoS (Distributed Denial of Service) -attack. Volymen av attacken var uppskattningsvis 50 till 100 Mbits/sek per root-server. Attacken resulterade att flera root-servrar blev otillgängliga från flera parter av det globala Internet, flera serverar var dock nåbara från samtliga övervakningsstationer under attacken. Det finns inga rapporter att slutanvändarna uppmärksammande några felmeddelanden. Eftersom DNS-protokollet är konstruerat för att klara viss nåbarhet bland namnservrarna kan det uppstått förseningar om ett antal sekunder vid namnuppslagningar. För ovanlighetens skull var denna attack riktat mot samtliga root-servrar, denna typ av attack brukar annars riktas mot en enskild rootserver. Systemet fungerade efter dess design och demonstrerade robusthet mot synkroniserade attacker mot alla root-servrar [27]. 10

3.6.4 Visualisering av sårbarheterna inom DNS Figur 3.3 visualiserar var i DNS-uppslagningen sårbarheterna finns [40]. Nedan förklaras de olika sårbarheterna. 1. MITM-attack och cache-förgiftning för lokala IP-adresser genom till exempel ARP- och DNS-spoofing i kapitel 6.2.1. 2. Samma som ovan. 3. Gissa överförings-id samt injicera felaktiga paket. 4. Samma som 1 och 2. 5. Gissa överförings-id samt injicera felaktiga paket. 6. Administratören kan tillhanda hålla en korrupt zonfil, antigen av misstag eller medvetet. 7. En felaktig zonfil kan returneras till användaren. Gissa överförings-id samt injicera felaktiga paket. 8. MITM-attack och Cache-förgiftning för lokala IP-adresser genom till exempel ARP- och DNS-spoofing i kapitel 6.2.1. Figur 3.3 : Visualisering av sårbarheterna inom DNS under DNS-uppslagning. 11

4. DNSSEC Under detta kapitel kommer vi att förklara hur DNSSEC är uppbyggt och hur tekniken fungerar. Vi kommer även att gå in på hur DNSSEC är tänkt att lösa säkerhetsbristerna i DNS och vilka återstående problem som finns i DNSSEC. 4.1 Varför DNSSEC DNS är en av de viktigaste bitarna i Internet och utan fungerande DNS: er fungerar inte Internet. Problemet med DNS är att det saknar implementering av säkerhet och kan på så sätt utsätta användarna för sårbarheter. Därför var en utveckling av säkerhetspaket nödvändigt för att säkerställa tillförlitligheten och utveckling av Internet. Detta säkerhetstillägg kallas DNSSEC och lägger till en krypterad signatur till DNS-data som skickas [11]. Ett av de största problemen med DNS var att de inte tänkte på säkerheten när de utvecklade DNS-protokollet. IETF uppmärksammande problemet med den bristande säkerheten i DNS och ordnade i november 1993 en sammankomst där huvudmålet var att ta fram en lösning till säkerhetsbristerna i DNS. Det dröjde fram till 1999 innan de publicerade RFC 2535, detta dokument beskriver DNSSEC [3] En av de största bristerna i DNS är att det ger en möjlighet för en angripare att lägga till en falsk DNS-server vilket gör att användarna som skriver in en adress i webbläsaren tror att de kommer till den riktiga sidan men i själva verket lotsas de till en helt annan sida som angriparen väljer, detta gör att användarna kan bli utsatta för nätfiske [11]. 4.2 Hur fungerar DNSSEC Det är framför allt tre säkerhetsbrister i DNS som DNSSEC är skapat för att åtgärda, dessa är ursprunglig autentisering, dataverifiering och verifiera denial-of-existence. Detta är tänkt att lösas genom att lägga till en digital krypterad signatur från svaren som skickas från DNS-servern [14]. Det är viktigt att kunna garantera att användaren kommer till den sidan som webbadressen anger. DNS kontrollerar aldrig om data som skickas kommer från den servern som den utger sig att vara ifrån. Så länge port och TXID fälten matchar med den efterfrågade adressen från användaren. För att lösa detta problem implementerar DNSSEC en PKI (Public Key Infrastrucure) som gör att en resolver kan få tillgång till en publik nyckel från en DNSSEC signerad zon och med hjälp av denna kan den kontrollera att signerad data kommer från rätt zon [13]. För att kunna garantera att data från DNS-svaren är äkta skapar varje zon två nycklar, en publik nyckel och en privat nyckel [12]. Den publika nyckeln sparas i en ny RR (Resource Record) som kallas DNSKEY och innehåller den binärkodade nyckeln som tillsammans med relevant information om nyckeln som vad det är för krypteringsalgoritm som har används [13]. Varje RRSet använder sig av den privata nyckeln för att skapa signaturer, dessa sparas i en RR som kallas RRSIG [13]. När sedan den svarar på en förfrågan skickar DNS tillbaka både RRSIG och RRSet som är associerad med data som ställdes i frågan. Resolvern måste har lärt sig DNSKEY: n från 12

den efterfrågade zonen och kan då verifiera att svarsdata är äkta och inte har blivit modifierad på vägen [12]. De två olika nycklarna som används för signering i zonerna kallas för ZSK (Zone Signing Key) och KSK (Key Signing Key) och de skapas av zonadministratörerna. Zonen signeras med ZSK och så blir ZSK signerad av KSK [12]. För att resolvern inte ska behöva tillhandahålla en publik nyckel för varje signerad zon och att varje zon inte ska behöva skicka sin publika nyckel till alla vid ändringar av sina nycklar då skapas chain-of-trust och detta görs med en DS (Delegation Signer) RR som delar upp zonerna i förälder- och barnzoner, så när en zon uppdaterar eller ändrar sin nyckel skickar barnzonen nyckeln till sin förälderzon. Detta gör att varje förälder kan signera sina barn och på så sätt garantera säkerheten i kedjan, detta gör även att resolvern inte behöver tillhandahålla de signerande nycklarna från varje zon utan bara från root-zonerna [16]. På detta sätt ska DNSSEC lösa problemet med ursprungautentisering för att garantera att data som kommer i DNS-svaret är äkta och kommer fram utan att de ska ha blivit störda på vägen. Men DNSSEC ska även kunna tillhandahålla funktioner som löser denial-of-existence detta görs genom att implementerar ytligare en RR, som heter NSEC, den listar alla namnservrar som ett företag har listat och vilket som är den nästa i listan [13]. Figur 4.1 visas hur NSEC fungerar, ett företag har tre olika namnservrar. a.namnserver.se pekar på b.namnserver.se och vidare så pekar b.namnserver.se på d.namnserver.se. Figur 4.1 : Visualisering av NSEC-uppslagning mellan olika namnservrar. Om en resolver efterfrågar c.namnserver.se försöker namnservern göra uppslaget men misslyckas eftersom det inte finns någon c.namnserver.se, istället hittar den a.namnserver.se och då skickar den tillbaka svaret a.namnserver.se på detta sätt NSEC d.namserver.se och sedan får resolver att förstå att det inte finns någon b.namnserver.se [16]. NSEC var den första versionen som skapades för att förutse denial-of-existence. Ett av problemen med NSEC är att den skickat svaren i klartext och gör att en angripare kan 13

få tillgång till information om företaget. För att förhindra detta utvecklades NSEC3 som är en hashad och krypterad variant av NSEC [12]. 4.3 Lösningar till DNS- säkerhetsbrister Paketavlyssning är ett problem i DNS, om DNSSEC är korrekt konfigurerad och används på rätt sätt kan det skapa en end-to-end integritetskontroll. Då kan verifiering att data som skickas från servern bli kontrollerad att den inte har blivit modifierad på vägen till klienten. DNSSEC har inget skydd mot ändring av pakethuvuden från DNS, för att kontrollera detta måste resolvern vara konfigurerad för just detta ändamål. Det gäller även för attacker där angriparen gissar överförings-id, där emot när resolvern kontrollerar signaturerna i DNS-svaren kan dessa attacker upptäckas [3]. Cacheförgiftning ska DNSSEC erbjuda ett bra skydd emot genom att med hjälp av resolvern kontrollera signaturen och kan på så sätt bestämma om data som skickas i DNS-svaren verkligen kommer från rätt avsändare [3]. 4.4 Säkerhetsbrister i DNSSEC Även om DNSSEC är ett säkerhetstillägg är det inte lösningen på alla problem. Ett av DNSSEC största problem är att det är ett väldigt komplext system som kräver stor skicklighet från zonadministratörerna för att utföra implementeringen av DNSSEC och den bristfälliga rapporteringen av fel som kan uppstå gör att felsökning i DNSSEC försvåras [3]. Med DNSSEC ökar arbetsbördan för resolvern eftersom varje paket med signaturer ska valideras, detta medför att tiden som en uppslagning tar kommer att öka och det kommer att ta längre tid att kunna ge svar tillbaka till klienten. Detta ökar risken för time-out. Användare med bristande tålamod som kanske ställer en ny fråga för att det tar för lång tid att få svar gör att bördan på resolvern kommer att öka. På grund av detta hjälper DNSSEC inte heller mot DoS-attacker utan gör problemet värre [3]. DNSSEC kan inte heller kontrollera att zonfiler är korrekta. Dessa kan ändras av en zonadministratör antingen medvetet eller omedvetet [20]. 4.5 DNSSEC validering för användare För användare som vill kontrollera om sidor de besöker använder sig av DNSSEC så är möjligheter för att göra detta automatisk väldigt dåligt. Användare som vill kontrollera sidor så kan man använda.se alternativt DNSCHECK där man får reda på om den sökta sidan använder sig av DNSSEC eller inte [42]. Om man vill ha ett alternativ som automatiskt kontrollerar om sidan som man besöker använder sig av DNSSEC så har Firefox ett tillägg till sin webbläsare som automatiskt validerar sidan som man besöker [43]. 14

5. DNSSEC i Sverige och världen Detta kapitel beskriver DNSSEC historia samt förklarar olika implementerings alternativ. 5.1 Historik Även om DNSSEC har funnits tillgänglig en länge tid har införandet av tekniken gått väldigt långsamt i världen. Trots detta är Sverige och den svenska toppdomänen.se en av de länderna som ligger långt fram med införandet och är ett föregångsland för resten av Internetvärlden. Sverige var det första land att signera sin root-zon och detta gjordes 2005. Januari 2007 lanserade.se tjänsten DNSSEC vilket gör att alla som har en domän under.se-domänen kan tillgå den förbättrade säkerhet som DNSSEC erbjuder [19]. Under 2007 när.se hade lanserat sin DNSSEC-tjänst började de även arbeta hårdare med att få domännamnsägarna att bli mer intresserade av DNSSEC och få dem att byta från DNS till DNSSEC. De började även göra en undersökning varje år där de undersöker hälsoläget i den Svenska.SE-zonen. I rapporten som släpptes 2007 gjordes det ingen kontroll av hur många domäner som använde sig av DNSSEC men det gjordes året därpå och detta visade att 2008 var det totalt 891 domäner i den svenska.se-zonen som hade infört DNSSEC men av dessa var det bara åtta kommuner och två statliga myndigheter som hade infört DNSSEC [21]. 2008 upptäckte forskaren Dan Kaminsky en bugg i DNS som gjorde att välden fick upp ögonen för DNSSEC och eftersom att.se då låg i framkant med införandet av DNSSEC så riktade väldens blickar mot Sverige. Kaminskybuggen är en form av cacheförgiftning. I Sverige fortsätter antalet domäner som använder sig av DNSSEC att öka. När rapporten 2007 kom var det totalt 891 domäner som hade DNSSEC nu har den siffran ökat till 2000, ökningen är kontinuerlig enligt.se men det går inte i samma takt som de hade hoppats på [22]. Denna ökning av antal domäner som ansluter sig till DNSSEC förväntas öka väldigt mycket under 2010 detta för att den 15 juli 2010 så signerades root-zonen och detta tror de ska leda till att fler länder får upp ögonen för fördelarna med DNSSEC [23]. I Figur 5.1 ses en karta över de kommuner som i dagsläget implementerat DNSSEC på sin domän. 15

Figur 5.1 : Karta med kommuner med DNSSEC [44]. 5.2 Checklista för implementation av DNSSEC För att installera DNSSEC på sin domän finns det en del steg som måste göras innan DNSSEC är redo och kan användas. Göra en DNS-uppsättning på önskad hårdvara och programvara som stödjer DNSSEC. Detta kan vara Microsoft Server 2008 R2, BIND (Berkeley Internet Name Domain) eller någon liknade. Aktivera DNSSEC för sin zon. Skapa nycklar som kommer att användas vid signering av zonen. Det kommer att behövas två stycken nycklar en KSK och en ZSK. Signera zonen. Publicera nyckeln till domänmansregistrator. Nu ska zonen vara signerad med DNSSEC och färdig för användning [18,31]. 16

5.3 Olika produkter för att installera DNSSEC Det finns idag olika alternativ som kan användas vid installation av DNSSEC och tillvägagångssättet vid signering av zonen. Ofta vill kommuner, företag och myndigheter behålla sin nuvarande DNS-infrastruktur utan att behöva installera en ny. Därför är det viktigt att det finns lösningar för alla typer av system [32]. 5.3.1 Microsoft Server 2008 R2 DNS Eftersom Windows Server 2003 bara tillhandahöll grundläggande stöd för DNSSEC var det många som hoppades att Windows Server 2008 R2 skulle innehålla bättre support för DNSSEC. Microsoft har utvecklat Windows Server 2008 R2 med fullständigt stöd för DNSSEC. Trots att Windows Server 2008 R2 har stöd för det mesta saknas det fortfarande stöd för NSEC3 och kan inte signera dynamisk uppbyggda zoner som AD (Active Directory) bygger kring [17,32]. 5.3.2 BIND BIND är den mest använda tekniken för DNS över Internet. BIND utvecklades under 1980-talet på University of California. Den klarar av det mesta som en DNS ska göra, den svarar på frågor som skickas till den och den gör det med de DNS-protokoll standarder som finns. BIND är kompatibelt med DNSSEC ifrån version 9. BIND är en fri programvara som vem som helst får använda, den går under en ICS-licens vilken gör att den är fri att använda, kopiera, modifiera och distribuera [34,35]. 5.2.3 OpenDNSSEC För att öka införandet av DNSSEC bestämde.se att utveckla ett alternativ som användare kunde använda för införande av DNSSEC. Denna lösning skulle göra det enklare att installera DNSSEC för webbhotell, Internetleverantörer och toppdomäner att införa DNSSEC. Syftet med OpenDNSSEC var att förenkla administrationen av DNSSEC, med hjälp av OpenDNSSEC ska många steg automatiseras. OpenDNSSEC kan bara användas för att införa DNSSEC, den har alltså ingen egen DNS utan det måste redan finnas installerat [36,37]. 17

6. Installation av DNS och DNSSEC i testmiljö Detta kapitel förklarar och visar vår testimplementering av DNS och DNSSEC. Tidigare nämnda säkerhetsbrister i DNS testas i form av praktiska angrepp och visar vad en implementering av DNSSEC skyddar mot. 6.1 Syfte Syftet är att skapa oss en bredare uppfattning om hur DNS och DNSSEC fungerar samt testa det olika säkerhetsbristerna. Syftet är också att undersöka hur komplex en testimplementering av DNSSEC är. En hypotes är att kommuner, myndigheter och företag inte installera DNSSEC eftersom en implementation är för komplex. 6.2 Planering Vi kommer installera DNS med operativsystemet Windows Server 2003 RS SP2 och använda grundinställningarna. DNSSEC installeras med Windows Server 2008 R2 eftersom det innehåller stöd för en installation av DNSSEC, en annan anledning är att Windows Server 2008 R2 är det senaste serveroperativsystemet från Microsoft [17]. Vi kommer att installera en DNS-server, därefter utsätta servern för attacker som är kända som säkerhetsbrister i DNS-protokollet. Därefter installerar vi DNSSEC på DNSservern och utsätter den för samma attacker och utvärderar resultaten. Installationen av DNSSEC kommer ske i olika steg enligt Microsoft egna checklista för applicering av DNSSEC [18]. 6.2.1 Faktorer Här specificeras de faktorer vi tar hänsyn till under experimentet och vilken effekt som behandlas. Behandling är den faktor vi kommer undersöka effekten av i experimentet [15]. Vi kommer undersöka skillnaden på DNS och DNSSEC genom att utsätta servern för attacker. Vi kommer även behandla hur komplex ett införande av DNSSEC är. Oberoende variabler är de faktorer som kan påverka experimentet [15]. Faktorer som kan påverka vårt experiment: Kommuner, myndigheter och företag behöver ytterligare resurser för att emigrera från DNS till DNSSEC vilket är tidskrävande och ökar komplexiteten. Experimentservrarna kommer inte vara lika belastad som en DNS-server för ett företag eller likande och datorresurserna kan variera. Beroende variabler är de faktorer vi mäter resultatet för experimentet [15]. Faktorer vi kommer mäta resultatet på: Hur en installation av DNS sker i Windows Server 2003 R2 SP2. Hur en installation av DNS och DNSSEC sker i Windows Server 2008 R2. Praktisk tillämpa attacker mot säkerhetsbristerna i DNS-protokollet. Hur komplext DNSSEC är att installera i Windows Server 2008 R2. 18

6.3 Installation av DNS Under experimentet utförde vi olika typer av attacker och därför upprättades en testmiljö för att inte skada någon DNS-server i drift. Figur 6.1 visualiserar vår uppsättning av DNS-serverar och klienter för att möjliggöra DNS-uppslag. Figur 6.1 : Testmiljöns infrastruktur för implementering av DNS. 19

Nod Datorspecifikation Programvaror DNS-server DNS-server Dell Latitude D620 1 Intel Core 2 1.66 GHz 2GB RAM IIS 6.0 192.168.1.43 DNS-server 2 Klient 1 Klient 2 Klient 3 Windows Server 2003 R2 Standard Dell OptiPlex 745 Intel Core 2 1.86 GHz 1 GB RAM Windows Server 2003 R2 Standard AMD Athlon X2 6000+ 3.01 GHz 6 GB RAM Windows 7 Packar Bell Easynote AMD Athlon X2 1.90 GHz 3 GB RAM Windows 7 Compaq Mini 311 1.6 GHz Intel Atom 2 GB RAM Windows 7 Angripare 1 VirtualBox 1024 MB RAM Bryggat nätverkskort Backtrack 4 R1 Angripare 2 VirtualBox 512 MB RAM Bryggat nätverkskort Backtrack 4 R1 192.168.2.2 (Forwarder) 192.168.1.43 192.168.1.43 192.168.2.3 192.168.2.6 Router 1 NETGEAR Wireless-N 150 Router WNR 1000 Router 2 Siemens Gigaset SE361 WLAN Tabell 6.1 : Visar egenskaper och inställningar för varje nod i infrastrukturen för implementering av DNS. 20

6.3.1 ARP och DNS-förgiftnings attack Mål Målet med attacken är att vilseleda Klient 2 till en förfalskad hemsida som angriparen administrerar utifrån testmiljön i figur 6.2. Klient 2 använder DNS-server 2 för DNSuppslag och angreppet görs mot DNS-server 2. Tillvägagångssätt Vi skapade en textfil (hosts.txt) som innehåller raden: 192.168.2.9 www.orsa.se Sedan körde vi följande kommandon: arpspoof i eth0 t 192.168.2.2 192.168.2.1 arpspoof i eth0 t 192.168.2.1 192.168.2.2 dnsspoof i eth0 f hosts.txt host 192.168.2.2 Första och andra kommandot används för att DNS-server 2 (192.168.2.2) skall tro att angriparen (192.168.2.9) är routern så all dess utgående trafik skickas till angriparen. Tredje kommandot avlyssnar all DNS-trafik från DNS-server 2 och alla DNS-frågor som involverar www.orsa.se kommer besvaras av angriparen enligt filen host.txt. Resultat Detta leder till när Klient 2 anger www.orsa.se i sin webbläsare kommer inte den förväntade hemsidan visas utan Angriparens hemsida laddas istället. Angriparen kan på så sätt visa fel information och införskaffa sig känslig information om användaren vid Klient 2. Klient 2 använder kommandot: dig @192.168.2.2 www.orsa.se Resultatet i figur 6.2 visar att den angripna DNS-servern (192.168.2.2) pekar på angriparens IP-adress när DNS-förfrågan om www.orsa.se ställs. Om Klient 2 istället använder kommandot: dig @192.168.1.43 www.orsa.se Figur 6.3 visar att den icke-angripna DNS-servern (192.168.1.43) pekar på den korrekta IP-adressen till www.orsa.se. Klient 3 och alla andra klienter som använder DNS-server 2 för DNS-uppslagningar är därmed också utsatta för attacken. Detta är en MITM-attack och DNS-server 2 pekar egentligen på rätt IP-adress till domänen www.orsa.se. Men eftersom angriparen avlyssnar DNS-server 2 DNS-förfrågningar kan den avläsa när en fråga ställs om www.orsa.se och då svarar den med dess felaktiga IP-adress till angriparen. I figur 3.3 placeras angriparen mellan ISP (Internet Service Provider) Resolver Server (DNS-server 2) där den avlyssnar frågorna (2) och besvarar dessa med sina egna paket (3) och användaren tolkar att svaren är korrekta utan att någon validering sker. 21