Examensarbete
Henric Telling och Anders Gunnarsson 2010-11-29
Ämne: Datalogi
Nivå: Kandidatexamen inom datalogi Kurskod: 2DV00E
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
i
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,
ii
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,
iii
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.
iv 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
v
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
vi
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
1
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].
2
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 .SE-zonen. 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
3
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].
4
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].
5
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
6
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 DNS-uppslagning 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
IP-adress 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 domäner är delegerade till
zonen. Root-servern svarar med en hänvisning till auktoritativservrarna för .SE-zonen.
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
7
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 IP-adressen för domänen www.exempel.se där IP-IP-adressen returnerades. Utifrån det exemplet har resolvern mellanlagrat informationen i cacheminnet som gavs från root-servern. 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.
8
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) /stacken för att översätta IP-adresser till MAC-IP-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].
9
nätverket. Mottagarnoden med den angivna IP-adressen besvarar frågan med sin MAC-adress 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 MAC-adressen 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 232 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 216 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].
10
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. posterna A och AAAA använder inte namn i sina DNS-data (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].
11
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.
12
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].
13
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 barn-zonen 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].
14
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].
15
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].
16
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.
17
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
18
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 protokollet. Därefter installerar vi DNSSEC på DNS-servern 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.
19
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.
20
Nod Datorspecifikation Programvaror DNS-server
DNS-server 1
Dell Latitude D620 Intel Core 2 1.66 GHz 2GB RAM
Windows Server 2003 R2 Standard
IIS 6.0 192.168.1.43 DNS-server 2 Dell OptiPlex 745 Intel Core 2 1.86 GHz 1 GB RAM
Windows Server 2003 R2 Standard
192.168.2.2 (Forwarder) 192.168.1.43 Klient 1 AMD Athlon X2 6000+ 3.01 GHz
6 GB RAM Windows 7
192.168.1.43 Klient 2 Packar Bell Easynote
AMD Athlon X2 1.90 GHz 3 GB RAM
Windows 7
192.168.2.3
Klient 3 Compaq Mini 311 1.6 GHz Intel Atom 2 GB RAM Windows 7 192.168.2.6 Angripare 1 VirtualBox 1024 MB RAM Bryggat nätverkskort Backtrack 4 R1 Angripare 2 VirtualBox 512 MB RAM Bryggat nätverkskort Backtrack 4 R1
Router 1 NETGEAR Wireless-N 150 Router WNR 1000
Router 2 Siemens Gigaset SE361 WLAN
21
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 server 2 för DNS-uppslag 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
22 ; <<>> DiG 9.3.2 <<>> @192.168.2.2 www.orsa.se ; (1 server found)
;; global options: printcmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1317
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION:
;www.orsa.se. IN A
;; ANSWER SECTION:
www.orsa.se. 60 IN A 192.168.2.9
;; Query time: 1 msec
;; SERVER: 192.168.2.2#53(192.168.2.2) ;; WHEN: Mon Oct 04 16:13:33 2010 ;; MSG SIZE rcvd: 45
Figur 6.2 : Resultat av angripen DNS-server med dig-kommando.
; <<>> DiG 9.3.2 <<>> @192.168.1.43 www.orsa.se ; (1 server found)
;; global options: printcmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 351
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION:
;www.orsa.se. IN A
;; ANSWER SECTION:
www.orsa.se. 85376 IN CNAME plaza.daladatorer.se.
plaza.daladatorer.se. 549 IN A 62.101.37.56
;; Query time: 3 msec
;; SERVER: 192.168.1.43#53(192.168.1.43) ;; WHEN: Mon Oct 04 15:28:40 2010 ;; MSG SIZE rcvd: 77
23
6.3.2 DNS-cache förgiftningsattack Mål
Målet med attacken är att förgifta DNS-server 1 DNS-cache så att den och dess användare får korrupta DNS-uppslagningar.
Tillvägagångssätt
Vi började med att använda ett webbaserat verktyg som används för att kontrollera sårbarheten hos den DNS-server som används [29]. Figur 6.4 visar resultatet av detta test för DNS-server 1 och ger oss informationen om att vi skall använda port 1046 under vår attack. Figur 6.4 visar alltså det som diskuterats tidigare, att DNS enbart använder ett fåtal portar och att överförings-ID: et enkelt kan beräknas.
Vi använde oss av programmet Metasploit på angriparens dator för att utföra attacken. De parametrar vi satte var att domännamnet vi skulle kapa var www.mora.se (HOSTNAME), nya adressen skulle vara 74.125.39.104 (NEWADDR) vilket är www.google.se, servern att angripa var 192.168.1.43 (RHOST) och porten att använda var 1043 (SRCPORT). Figur 6.5 visar de ansatta parametrarna i Metasploit.
När parametrarna var satta körde vi igång programmet med kommandot run vilket sätter igång attacken genom att angriparen skickar förfalskade DNS-förfrågningar till DNS-server 1. Figur 6.6 visar resultatet av attacken, det krävdes 29750 förfrågningar och 651000 svar innan DNS-servers 1 DNS-cache var förgiftad.
24
Figur 6.5 : Ansatta parametrar i Metasploit inför attack.
25
Resultat
Attacken resulterar i att DNS-server 1 mellanlagrar en korrupt adress till www.mora.se. Eftersom DNS-cache: en används för snabbare DNS-uppslag utnyttjas den korrupta adressen tills dess TTL har passerat och DNS-server 1 samt alla dess användare svaras med en korrupt adress. Både 192.168.1.1 och 192.168.2.1 nätverket påverkas av denna förgiftning efter som DNS-server 1 används för DNS-uppslagning av samtliga underliggande datorer.
Figur 6.7 visar med hjälp av kommandot nslookup att klient 1 besvaras med ett korrupt svar från DNS-server 1. Figur 6.8 visar med hjälp av kommandot dig att klient 2 besvaras med ett korrupt svar från DNS-server 2.
C:\Users\Henric>nslookup www.mora.se Server: UnKnown Address: 192.168.1.43 Icke-auktoritärt svar: Namn: www.mora.se Address: 74.125.39.104
Figur 6.7 : Korrupt svar från DNS-server 1 med nslookup.
; <<>> DiG 9.3.2 <<>> www.mora.se ;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 816
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION:
;www.mora.se. IN A
;; ANSWER SECTION:
www.mora.se. 21101 IN A
74.125.39.104 ;; Query time: 2 msec
;; SERVER: 192.168.2.2#53(192.168.2.2) ;; WHEN: Fri Oct 08 23:04:59 2010 ;; MSG SIZE rcvd: 45
26
6.3.3 DoS-attack Mål
Målet med attacken är att överbelasta DNS-server 1 så dess resurser inte kan användas av varken sig själv eller dess användare.
Tillvägagångssätt
Vi använde programmet Ettercap för att utföra vår DoS-attack. Först scannade vi efter klienter på nätverket för finna möjliga mål, vi väljer att angripa router 1 och DNS-server 1. Därefter scannar Ettercap vilka portar som är sårbara för denna attack, resultatet visade att portarna 53, 80, 135, 139 och 445 kunde utnyttjas för en attack. Angripare 1 startar en DoS-attack genom Ettercap och anger måldators IP-adress samt en förfalskad IP-adress inom nätverket, exempelvis 192.168.1.88 vilket används för att DNS-server 1 skall uppfatta denna IP-adress som korrekt och därför tillsätta alla sina resurser att besvara dess frågor till en adress som alltså inte finns.
Resultat
Denna attack resulterade i att varken DNS-server 1 eller dess underliggande användere kunde nå Internet. På så sätt kan ingen av datorerna i nätverken 192.168.1.1 eller 192.168.2.2 ställa några DNS-förfrågningar.
6.3.4 Intrång i Windows Server 2003 Mål
Målet med attacken är att komma åt zonfilen som är lagrad i vår server för att sedan göra så att den pekar på en helt annan IP-adress.
Tillvägagångssätt
Även till denna attack använder vi programmet Metasploit med hjälp av detta utnyttjar vi en sårbarhet som orsakar en buffer owerflow i NetApi32. Från angriparens dator försöker vi att få tillgång till filerna i DNS-server 2 för att på så sätt kunna ändra i dennes zonfiler och göra så att den skickar förfrågningar till andra IP-adresser istället för den korrekta.
Det första som ska göras är att köra en scanner mot datorn som görs med kommandot
NMAP på följande sätt.
nmap 192.168.2.2
NMAP är en portskanner som används i detta fall för att ta reda på information om
datorn som ska attackeras. Därefter används Metaspolit i kommandoläge. Där väljs exploiten ms08_067_netapi med kommandot.
Use windows/smb/ms08_067_netapi
Efter detta så sätter vi payloaden med följande kommando.
set payload generic/shell_bind_tcp
Vi ska nu ställa in vilken server vi vill utföra attacken emot med kommandot.
set RHOST 192.168.2.2
27
exploit
Nu får vi fram lite information om servern som vi ska utföra attacken emot. Metasploit lyckas inte automatiskt finna operativsystemet som vi vill attackera så det får vi specificera själva.
show targets
Vi får nu upp en fullständig lista över de olika operativsystemen med olika språkpacksalternativ. Vårt system är ett Windows Server 2003 med engelskt språkpack så vi väljer den i listan.
set target 10
Och sedan kör vi attacken igen med kommandot.
rexpolit
När denna sedan har kört färdig så får vi tillgång till servern.
Resultat
Attacken lyckas och vi får kontroll över DNS-server 2. På angriparens dator visas nu ett kommandofönster och för att kontrollera att det fungerar som det är tänkt så skapar vi en mapp på skrivbordet och granskar vi servern ses att mappen ligger där. Nu navigerar vi oss in till zonfilerna som ligger i Windows/System32/dns på DNS-server 2. Dessa filer ha vi nu full kontroll över och kan ändra dem som vi vill. Men eftersom att vi har full kontroll över datorn så kan vi även utnyttja läget till att göra mer förstörelse på servern. Det var förhållandevis lätt att utföra attacken eftersom att det fanns många guider för hur de skulle utföras. Men detta är en standardinstallation av Windows Server 2003 så vi använde oss inte av några tilläggsprogram för att förhindra intrång i servern Microsoft släppte även en säkerhetsuppdatering som förhindrade att denna attack skulle gå att genomföra på ett uppdaterat system.
6.5 Installation av DNSSEC
28
Nod Datorspecifikation Programvaror DNS-server
DNS-server 1
Dell Latitude D620 Intel Core 2 1.66 GHz 2GB RAM
Windows Server 2008 R2 Standard
IIS 7 192.168.1.43 DNS-server 2 Dell OptiPlex 745 Intel Core 2 1.86 GHz 1 GB RAM
Windows Server 2008 R2 Standard
192.168.2.2 (Trusted A) 192.168.1.43 Klient 1 AMD Athlon X2 6000+ 3.01 GHz
6 GB RAM Windows 7
192.168.1.43 Klient 2 Packar Bell Easynote
AMD Athlon X2 1.90 GHz 3 GB RAM
Windows 7
192.168.2.3
Klient 3 Compaq Mini 311 1.6 GHz 2 GB RAM Windows 7 192.168.2.6 Angripare 1 VirtualBox 1024 MB RAM Bryggat nätverkskort Backtrack 4 R1 Angripare 2 VirtualBox 512 MB RAM Bryggat nätverkskort Backtrack 4 R1
Router 1 NETGEAR Wireless-N 150 Router WNR 1000
Router 2 Siemens Gigaset SE361 WLAN
Tabell 6.2 : Visar egenskaper och inställningar för varje nod i infrastrukturen för implementering av DNSSEC.
Vi äger ingen registrerad .SE-domän därför skapade vi en testmiljö med DNSSEC där DNS-server 1 och 2 signerar dess zoner och DNS-server 2 erhåller DNS-server 1 som en tillförlitlig enhet för att skapa chain-of-trust relation däremellan. Kapitel 5.1 beskriver en checklista hur införandet stegvis appliceras för en registrerad domän, vi utförde det fyra första stegen och använde Microsofts handbok för införande av DNSSEC [30]. För validering av de besökta domänerna användes ett tillägg i webbläsaren Firefox [33].
29
Figur 6.9 : Domänen www.lab är säkrad med DNSSEC och visar en godkänd validering.
; <<>> DiG 9.3.2 <<>> @192.168.2.2 www.lab +dnssec ; (1 server found)
;; global options: printcmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 353
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000 ;; QUESTION SECTION: ;www.lab. IN A ;; ANSWER SECTION: www.lab. 3571 IN A 192.168.1.43 www.lab. 3571 IN RRSIG A 5 2 3600 20101119100133 20101020100133 60172 lab. Sq0KfcWZ9txhe5EcEpOTP1SwP8qBLv9nN1pWudQ5yVLv/0eA9YomJwWX nFADyXDP1uJwPDmMsu8BnBWztfNDtg==
;; Query time: 1 msec
;; SERVER: 192.168.2.2#53(192.168.2.2) ;; WHEN: Wed Oct 20 14:42:20 2010 ;; MSG SIZE rcvd: 151
Figur 6.10 : Säkert DNS-svar innehållande RRIG för domänen www.lab.
6.5.1 ARP och DNS-förgiftningsattack
30
Figur 6.11 : Domänen www.lab är säkrad med DNSSEC och visar därför att sidan är korrupt.
6.5.2 DNS-cache förgiftningsattack
Denna attack fungerade inte under vår testmiljö. Windows Server 2008 R2 innehåller säkerhetsförbättringar gentemot Windows Server 2003, som till exempel Socket Pool och Cache Locking vilket försvårar attacken, figur 6.4 och 6.12 visar skillnaden mellan resultaten för Windows Server 2003 och 2008. Tidigare använda webbaserade verktyget för kontrollering av sårbarheterna på namnservern användes och resultatet visas i figur 6.12. Resultaten visar en förbättring av säkerheten och fler resurser krävs för att angripa DNS-servern utan DNSSEC. För att en angripare skall tillgå fler resurser kan ett botnet användas, dock kommer DNSSEC motverka en förfalskad hemsida precis som attacken ovan visar.
Figur 6.12 : Resultat av porttest för DNS-server 1.
6.5.3 DoS-attack
31
6.5.4 Intrång i Windows Server 2008
Vi försöker genomföra samma attack som vi lyckades med på Windows Server 2003 men då inte denna sårbarhet finns i Windows Server 2008 fungerar det inte och vi lyckas inte att få tillgång till filerna på datorn. Det finns säkert andra öppningar i systemet som en angripare skulle kunna använda.
32
7. Resultat
Under detta kapitel kommer vi att redovisa de resultat som vi har fått fram genom våra intervjuer. Vi kommer också även att redovisa statistik om hur användningen av DNSSEC har utvecklas i Sverige under de senaste två åren.
7.1 Intervjuer
Vår första tanke var att intervjua kommunerna i Kronoberg för att få en överblick för deras resonemang kring DNS och införande av DNSSEC. Då ingen kommun i Kronoberg implementerat DNSSEC på sin domän och för att vi även ville intervjua kommuner med DNSSEC valde vi att utöka vårt intervjuområde. Vi har kontaktat kommuner via mail till intressanta intervjuobjekt, de som svarade och ville ställa upp bokade vi telefon- eller besökstid för intervju. De som inte svarade på utskicket kontaktade vi via telefon för att försöka boka en intervju. Det är även två kommuner som har valt att inte ställa upp på en intervju.
Vi har intervjuat sex kommuner, tre kommuner som infört DNSSEC, två kommuner som inte infört DNSSEC och en kommun som påbörjat arbetet med att införa DNSSEC.
7.1.1 Intervjuresultat
Kommunerna vi intervjuat hanterar sin DNS på olika sätt, några har hand om sina egna servrar och bara köpt domännamnet medan andra hyr tjänsten av externa företag.
Av de kommuner som har hand om sina egna servrar har valt olika system och sätt för att upprätta sina DNS: er. De operativsystem som framför allt används är Windows Server 2003 och 2008 och då använder de sig av Windows DNS men det är även en kommun som använder Linux och BIND och en kommun som har allt uppsatt i en virtuell Linuxmaskin på ett Windows operativsystem.
Det är liknade beslutfattare i alla kommunerna då IT-chefen eller IT-samordnaren tillsammans med sina tekniker beslutar om en implementation. Det är dock inte många av de tillfrågade kommunerna som har egen kompetens och då hyrde in en konsult som införde DNSSEC. Alla kommuner som vi har pratat med känner till DNSSEC och vet vad den skyddar mot.
Av de kommuner som vi har intervjuat är det bara en som har stött på problem med införandet av DNSSEC och det är Gävle kommun som även var första kommunen och troligtvis den första domänen som signerades med DNSSEC. Problemet var att vissa användare inte kunde komma åt sidan efter att gavle.se hade blivit signerad. Detta berodde på att Internetkunder som hade Telia och Tele2 som Internetleverantör körde med BIND 9.4.1 på sina namnservrar och denna version av BIND hade en bugg så att den satte AD-biten i DNS-protokollet fel och detta gjorde att för vissa hemmanvändarna fungerade inte DNS-trafiken via deras routrar [38]. Förutom denna incident har ingen av kommunerna uppmärksammat några problem med implementeringen av DNSSEC.
Tidsperioden kommunerna haft DNSSEC installerat varierar från ett par månader upp till några år.
33
utan att de har märkt det. Det är ingen av kommunerna som har tänkt eller diskuterat över riskerna som finns kvar med DNSSEC.
De kommuner som ännu inte infört DNSSEC för diskussioner om att införa det men tycker att dagens tillgängliga tekniker som finns för införande inte passar på deras DNS-infrastruktur. De kommuner som har infört DNSSEC är det ofta att någon person med kunskap som påpekat fördelarna med DNSSEC. Det är många kommuner runt Gävleborgs län som infört DNSSEC och de har fått hjälp av samma person, Torbjörn Eklöv som själv säger att han leder med 8-7 mot övriga Sverige.
Kostnaden för att införa DNSSEC varierar men det är inga stora kostnader det handlar om utan oftast en engångskostnad på några tusen samt en liten kostnad för drift och underhåll. De kommuner som har valt att låta andra företag ha hand om deras DNS är kostnaden bara ett par hundralappar i månaden beroende på vad för webbhotell som används och hur många domäner som används.
På frågan om varför det är så få kommuner som valt att införa DNSSEC är svaren relativt eniga. De flesta tror att det är brist på kunskap som gör att kommunerna inte väljer att införa DNSSEC. Även att DNSSEC beskrivs som väldigt komplext kan avgöra. Några tror även att en av anledningen till att det är så lågt intresse kan vara att det inte är en prioriterad fråga. Många kommuner tycker att deras DNS fungerar bra och kännar inte av några problem.
7.2 Statistik
Statistiken hämtad från IIS visar att antalet registrerade DNSSEC-domäner ständigt ökar med tiden. Statistiken visar även att tillväxten verkligen har tagit fart under 2010. I dagsläget finns det dubbelt så många registrerade DNSSEC-domäner jämfört med 2009 än så länge [39]. Figurerna 7.1, 7.2 och 7.3 visar diagram över tillväxten för DNSSEC i Sverige och att den ständigt ökar med tiden.
Figur 7.1 : Visar antalet registrerade DNSSEC-domäner under de senaste 90 dagarna. 3650 3700 3750 3800 3850 3900 3950 4000 4050 4100 4150 4200
34
Figur 7.2 : Visar antalet registrerade DNSSEC-domäner vid de 15 senaste månaderna.
Figur 7.3 : Visar antalet registrerade DNSSEC-domäner vid årsskiftet samt dagsläget. 0 500 1000 1500 2000 2500 3000 3500 4000 4500
DNSSEC-domäner vid månadsslut
0 500 1000 1500 2000 2500 3000 3500 4000 4500 2009 2010
