Överbelastningsattacker genom öppna reläer

(1)

Författare:

Göran G

USTAFSSON

(gg222bn) Sebastian L

UNDBERG

(sl222mz) Handledare: Jacob L

INDEHOFF

Examinator: Marcus W

^ILHELMSSON

Termin: VT2014

Ämne: Datavetenskap Nivå: G1E

Examensarbete inom datavetenskap

Överbelastningsattacker genom

öppna reläer

(2)

Abstrakt

Detta arbete behandlar en specifik typ av överbelastningsattack som blir allt mer populär.

Dessa attacker utförs genom öppna reläer med syftet att få ut en avsevärt mycket högre effekt än den som annars är uppnåbar. Granskning av attacker utförda genom tjänsterna DNS och NTP har utförts med syftet att ge en klar bild av hur allvarligt hotet är och även klargöra hur en systemadministratör kan säkra tjänsterna för att skydda både sina egna och andras resurser. Resultaten av undersökningar visar att en attack utförd genom en DNS-tjänst ger under optimala förhållanden en amplifikationsfaktor av “102.4” och en attack genom en NTP-tjänst ger under optimala förhållanden en amplifikationsfaktor av

“229.16”. Resultaten visar även att problemet kan lösas helt eller delvis genom att be- gränsa tillåtna nätverk eller stänga av rekursion i DNS och kommandon i NTP.

Nyckelord:

DoS, DDoS, Överbelastningsattack, Amplifikationsattack, DNS, NTP

Abstract

This work concerns a specific type of Denial of Service attack which is becoming in- creasingly popular. These attacks are carried out through open relays with the purpose of getting a significantly higher effect than otherwise achievable. Examination of attacks carried out through the services DNS and NTP have been conducted with the purpose of providing a clear picture of how serious the threat is and also clarify how a system admin- istrator can secure the services to protect both their own and others resources. The results of our studies show that an attack performed through a DNS service gives under optimal conditions a amplification factor of “102.4” and an attack through a NTP service gives under optimal conditions a amplification factor of “229.16”. The results also show that the problem can be solved in whole or in part by limiting the allowed network or disable recursion in DNS and commands in NTP.

Keywords:

DoS, DDoS, Amplification attack, DNS, NTP

(3)

1 Introduktion

Under de senaste åren har det blivit mer och mer vanligt att se nyheter om utförda attacker riktade mot specifika företag och organisationer [1, 2]. Det handlar oftast om attacker av typen som går under benämningen Distributed Denial of Service (DDoS) vilket innebär att en attack utförs från flera olika håll med syftet att överbelasta en tjänst för att den inte längre ska kunna uppfylla sitt syfte, till exempel att en webbsida inte längre ska vara nårbar av vanliga besökare [3].

Denial of Service syftar på det specifika resultat som är önskvärt i en attack och inte ett specifikt tillvägagångssätt [3] vilket gör att ämnet ständigt kan förändras. En attack som utförs idag är därför inte nödvändigtvis samma form av attack som utfördes igår. Ämnet är aktuellt och diskussion om både gammal och framförallt ny metodik krävs för effektiv motverkan av problemet.

1.1 Problemformulering

Det problem som kommer undersökas är en specifik form av DDoS-attack som till synes blir mer och mer populär [4]. Den unika formen av DDoS-attack som studien kommer fokusera på handlar om attacker som utförs genom det som kallas för öppna reläer, kort sagt attacker som använder sig av öppna nätverkstjänster på Internet för att få en högre effekt (amplifikationsfaktor) än en mer traditionell DDoS-attack kan åstadkomma [5]. Vid en traditionell DDoS-attack är kostnaden av en attack direkt relaterad till effekten medan en attack utförd genom öppna reläer har en låg kostnad och hög effekt, ett kommando på några bytes kan resultera i ett svar i storleken av flera kilobyte) [6].

Diskussion om bekämpning av problemet är ytterst viktig eftersom effekten av en stor attack som nyttjar den här metoden kan negativt påverka stora delar av Internet [7] och som resultat få allvarliga konsekvenser för samhället. Nyligen har det utförts attacker vars trafikmängd har stigit upp till 400Gbit/s [8] vilket är tillräckligt stor skala för att överbelasta många länkar som Internet består av. I dagsläget finns det tiotals miljoner av öppna reläer [9] som kan användas för attacker och aktiv motverkan behövs nu.

1.2 Syfte och frågeställning

Statistiska undersökningar av attacker som utförs genom specifikt DNS- och NTP-tjänster planeras att utföras i en laborationsmiljö för att få fram siffror på hur hög amplifikationsfaktor som kan uppnås under optimala förhållanden. Syftet med undersökningen är främst för att få en klar bild av hur allvarligt hotet är. Genom att jämföra resultaten av testerna med en mer traditionell överbelastningsattack kan flera viktiga slutsatser dras. Bland annat hur mycket högre trafik en DDoS-attack genom öppna reläer kan åstadkomma jämfört med en traditionell attack, alternativt hur många gånger färre maskiner krävs det för att uppnå samma mängd trafik. Om en attack är 10 gånger mer effektiv kan 10 gånger färre maskiner användas för att uppnå samma effekt.

Utöver undersökning av effekten som kan uppnås under en attack kommer fokus att läggas även på de olika sätt den här typen av attacker kan motverkas. Frågan som ska besvaras är vad kan en systemadministratör göra för att effektivt skydda sina egna och eventuellt även andras resurser, alltså administratören av en nätverkstjänst som potentiellt kan användas

(5)

som relä vid ett angrepp. För att besvara frågan kommer undersökning av diverse tekniska lösningar att genomföras. Ett exempel kan vara hur en systemadministratör säkrar mjukvaran som tillhandahåller tjänsterna DNS och NTP.

Syfte och frågeställning kan summeras på följande sätt:

• Få fram en teoretisk estimering av problemets storlek baserat på resultat av tester.

• Upptäcka tekniska lösningar som kan användas för att motverka en attack. Specifikt motverkan vid nätverkstjänsten som agerar som mellanhand, inte hur ett potentiellt offer kan skydda sig mot ett angrepp.

1.3 Avgränsning

Det valda ämnet är en liten del av ett väldigt brett problemområde. Fokus kommer enbart att läggas på frågor relaterat till specifikt öppna reläer. De nätverkstjänsterna som kommer att undersökas är DNS och NTP. Dessa tjänster har valts eftersom de ofta nämns i nyhetsartiklar om attacker utförda genom öppna reläer. På grund utav den sträva tidsramen som finns kommer fokus inte att läggas på annat än vad en systemadministratör av en tjänst kan göra för att motverka problemet eftersom det då blir alldeles för stort arbete.

1.4 Målgrupp

Den målgrupp som det här arbetet riktar sig mot är allra främst systemadministratörer och nätverksadministratörer eller personer med likvärdig kunskap inom ämnet. Arbetet kommer därför att anpassas utefter detta och inte gå in djupare än nödvändigt på diverse saker som den tilltänkta målgruppen bör ha kunskap utav.

Själva undersökningen av hotet kan vara av intresse för många olika parter medan de delar i arbetet som fokuserar på motverkan av en attack enbart kommer att vara av värde för en person vars arbetsuppgift är systemadministratör.

(6)

2 Teoretisk bakgrund

Följande information ger en kortfattad beskrivning av de olika tekniska termer, protokoll, program etc som läsaren behöver ha grundläggande kunskap om för att kunna ta åt sig av informationen som framkommer under senare delar av arbetet.

2.1 Denial of Service

Denial of Service (förkortas DoS) är en form av attack som saboterar nätverk, system eller tjänster [10]. Syftet är att neka åtkomst till dessa för legitima användare och det kan utföras med olika metoder. En DoS-attack kan exempelvis åstadkommas genom att fysiskt skada ett system, att man raderar eller korrumperar information, eller översväm- mar tjänster med illasinnad nätverkstrafik [3]. Attacker utförs vanligtvis genom att köra ett simpelt program som skapar trafik som är menat att överbelasta en tjänst eller ett helt nätverk. Eftersom det är relativt enkelt att utföra DoS-attacker används dessa ofta för att neka användare åtkomst till diverse tjänster [10].

2.2 Distributed Denial of Service

Distributed Denial of Service (förkortas DDoS) beskriver attacker som används för att överbelasta nätverk, system eller tjänster genom att skicka illasinnad trafik från flera källor samtidigt [10]. DDoS-attacker använder sig av liknande metoder som en vanlig DoS- attack gör fast i en större skala. En DDoS-attack använder vanligtvis tiotusentals klienter för att överbelasta ett gemensamt mål [11]. Klienterna som används vid utförandet av DDoS-attacker är med i ett så kallat botnät (ett nätverk av enheter) som tillsammans utför en attack då externa kommandon mottages [12]. Klienter som är en del av ett botnät brukar beskrivas som en “zombie” eller en “bot”.

2.3 Öppna reläer

Öppna reläer är en benämning för tjänster som lever upp till två kriterier; tjänsten ska vara tillgänglig för alla och inte vara begränsad till vissa parter (öppen) och tjänsten ska kunna agera som mellanhand (relä). Ett bra exempel på en öppen relä kan vara en e-posttjänst som alla kan använda för att vidarebefodra e-post till en annan destination [13].

2.4 User Datagram Protocol

User Datagram Protocol (förkortas UDP) är ett transportprotokoll som används för att skapa förbindelselösa anslutningar mellan datorer anslutna i ett nätverk. En förbindelselös anslutning innebär att kommunikationen sker utan verifiering av att alla paket anländer och utan verifiering av att ordningsföljden på paket är densamma vid både mottagning och sändning. Det gör därför protokollet opålitligt vid överföring av data och skall und- vikas att användas när integritet är viktigt. Protokollet används för kommunikation där hastigheten är viktig och då tappade paket eller paket som anländer i fel ordningsföljd kan hanteras utan allt för höga negativa konsekvenser. [14]

(7)

2.5 Domain Name System

Domain Name System (förkortas DNS) är en tjänst vars huvudsakliga syfte är att hantera översättning mellan domännamn och IP-adresser för att göra adressering vid kommunikation mellan olika enheter över ett nätverk mer användarvänlig. I ett nätverk urskiljs olika enheter med hjälp av IP-adresser och DNS används för att binda domännamn till IP-adresser. Då ett domännamn anges vid adressering sker ett så kallat namnuppslag, en förfrågan om IP-adressen som gäller för det specifika domännamnet skickas till en DNS-tjänst och ett svar förväntas komma tillbaka. [13]

En viktig funktion som finns med i DNS-standarden kallas för rekursion. Funktionen gör att en DNS-tjänst kan utföra en förfrågan åt en DNS-klient, till exempel kan en användare fråga DNS-tjänst A om information som finns på DNS-tjänst B utan att själv ställa DNS- förfrågan direkt till DNS-tjänst B [15].

2.6 Extension Mechanisms for DNS

Extension Mechanisms for DNS (förkortas EDNS) är en utökning av DNS-standarden som bland annat möjliggör användandet av paket upp till storleken 4096 bytes istället för den traditionella storleken på 512 bytes. Överskrids gränserna skickas den DNS- relaterade trafiken genom TCP-protokollet istället för UDP-protokollet. [16]

2.7 Berkeley Internet Name Domain

Berkeley Internet Name Domain (förkortas BIND) är en den vanligaste DNS-tjänsten som används idag. Mjukvaran utvecklades från början som ett examinationsprojekt vid University of California i Berkeley, USA någon gång under 1980-talet [17]. Det utvecklas och underhålls numera av organisationen Internet Systems Consortium som är dedikerad till att främja utvecklingen av infrastrukturen bakom Internet [18].

2.8 Domain Information Groper

Domain Information Groper (förkortas dig) är ett verktyg som används för att ställa olika typer av frågor om domännamn i syfte att få svar från en DNS-tjänst. Programmet ut- för DNS-förfrågningar utifrån anvisning och presenterar svaret som eventuellt anländer från en DNS-tjänst. Programmets breda flexibilitet gör det till ett kraftfullt verktyg vid felsökning av DNS-relaterade problem. [19]

2.9 Network Time Protocol

Network Time Protocol (förkortas NTP) är ett nätverksprotokoll som hanterar tidssynkro- niseringen av datorer över ett nätverk. Denna synkronisering sker mellan enheter som är antingen en primär server, sekundär server eller klient. [20]

Med hjälp av “stratum” så identifieras antalet av hopp mellan enheter och en eller flera auktorativa tidskällor. NTP undviker att synkronisera sig om servern inte uppfyller två krav. Först måste servern själv vara synkroniserad och sedan jämför NTP även tiden

(8)

som rapporteras från flera källor. Källan som har lägst avstånd (“stratum”) används för synkroniseringen förutsatt att den rapporterad tiden inte skiljer sig märkvärt från de andra tidskällorna. NTP använder sig av UDP-protokollet på port 123 som både källa och destination vid synkronisering av tid. [21]

2.10 Network Time Protocol Daemon

Network Time Protocol Daemon (förkortas NTPD) är ett program som sköter synkronisering av systemklockan mot externa NTP-tidsservrar eller mot en lokal hårdvarubaserad klocka ansluten direkt till servern. NTPD kan köras i olika former av lägen, exempelvis klient-server relation och broadcast. [22]

I NTPD version 4.2.6 och tidigare fanns det ett kommando kallat för “monlist” som numera är borttaget på grund utav att det har utnyttjas vid attacker. Syftet med kommandot är att presentera en lista på de 600st senaste anslutna klienterna till NTP-tjänsten. [23]

2.11 Brandväggar

Brandväggar används för att skydda viktiga resurser som är anslutna till ett nätverk genom att begränsa inkommande och utgående nätverkstrafik. Detta görs vanligtvis med en fy- sisk så kallad “end-point”-brandvägg som placeras mellan olika nätverk eller med en mjukvarubaserad brandvägg lokalt på en dator. [24]

Brandväggar brukar delas in i tre olika generationer för att beskriva dess funktionalitet.

Första generationens branvägg (även kallad för “stateless firewall”) kontrollerar trafiken baserad på dess källa, destination, protokoll och port. Andra generationens brandvägg (även kallad för “stateful firewall”) utökar föregående med att även hantera sessioner. Den tredje generationens brandvägg (även kallad “application-layer firewall”) kan kontrollera nätverkstrafik baserad på ett pakets innehåll. [25]

2.12 Netfilter / IPTables

Netfilter är en del av kärnan i operativsystemet Linux vars syfte är att filtrera inkommande och utgående nätverkstrafik efter specifika regler [26]. Det är det underliggande systemet för den brandvägg som används i dagens Linux-system. IPTables är namnet på det verktyg som används för att administrera reglerna som Netfilter-systemet följer [27]. Netfilter är en så kallad mjukvarubaserad brandvägg.

2.13 Ubuntu Linux

Ubuntu är en populär Linux-distribution som är baserad på Linux-distributionen Debian GNU/Linux. Utvecklingen av distributionen sker i det öppna men är ledd av företaget Canonical. Det finns två olika varianter av Ubuntu. Ubuntu Desktop som är till för att användas på skrivbordet och Ubuntu Server som är till för att används på servermaskiner.

All kod släpps under licensen GNU General Public License eller någon annan likvärdig licens. [28]

(9)

2.14 Wireshark

Wireshark är ett program med ett grafiskt användargränssnitt som används för att anal- ysera nätverkstrafik. I realtid kan programmet fånga upp och processera den trafik som passerar ett specifikt nätverksgränssnitt som användaren väljer att avlyssna. Wireshark kan användas på ett antal olika operativsystem som exempelvis Windows, OS X och Linux. Programmet är licensierad under GNU General Public License version 2 och är fritt att använda av allmänheten. [29]

2.15 Attack genom DNS-relä

Ett sätt att utföra en attack genom en öppen relä är att utnyttja DNS-tjänster. Det finns flera anledningar till att tjänsten är ett attraktivt val vid en attack, bland annat för att det är en vanligt förekommande tjänst vars standardbetende går att utnyttja. Mer specifikt är det en kombination av att inkommande förfrågor som normalt sätt accepteras från alla olika nätverk och den funktionalitet som kallas för rekursion [30, 15]. Tack vare rekursion behöver en angripare inte använda den informationen som finns på den specifika DNS-tjänsten som kontaktas utan det räcker att ange namnet på en annan domänzon som angriparen vet innehåller mycket information.

För att kunna utföra en attack krävs följande saker:

1. Tillgång till en DNS-tjänst som har rekursion igång och inte är begränsad till specifika nätverk (att alla kan använda tjänsten oavsett källan).

2. Namnet på en domänzon som innehåller mycket information (många poster och framförallt poster med stora fält). Till exempel en domänzon som har flera NS-, TXT- och RSSIG-poster som sammanlagt blir stor.

3. Båda tjänsterna bör ha stöd för det som kallas för EDNS (Extension Mechanisms for DNS) eftersom det tillåter 8 gånger större DNS-svar, den maximala storleken blir 4096 bytes istället för 512 bytes.

4. Ingen övervakning och validering av avsändaradresser i paket som anländer hos närmsta internetleverantören. Attacken förlitar sig helt på att det är möjligt att fabricera avsändaradressen inuti paket.

Trafikflödet vid en attack genom en DNS-tjänst kan ses i figur 1.

(10)

Figur 1: Trafikflödet vid en DNS-attack.

En attack genom en DNS-tjänst går till på följande sätt:

1. Angriparen ställer en DNS-förfrågan (begär all information om zonen som maskinen “DNS-tjänst” tar hand om) mot den öppna relän på maskinen “DNS-relä”. Det här sker med förfalskad avsändaradress.

2. Maskinen “DNS-relä” vidarebefodrar DNS-förfråga till maskinen “DNS-tjänst” och väntar på ett svar.

3. Maskinen “DNS-tjänst” svarar på DNS-förfrågan som maskinen “DNS-relä” har ställt.

4. Maskinen “DNS-relä” tar emot svaret som innehåller information om domänzo- nen och det vidarebefodras till den avsändaradressen som användes under steg 1 (adressen leder till offret).

Angriparen har nu ställt en liten DNS-förfrågan till en öppen relä och gjort att ett stort DNS-svar anländer hos offret. [31]

2.16 Attack genom NTP-relä

Ett alternativt sätt att utföra en attack genom en öppen relä är att utnyttja NTP-tjänster.

Vid en attack utnyttjar man specifikt en funktionalitet kallad för “monlist” som potentiellt ger ut ett stort svar till en liten NTP-förfrågan [23].

För att kunna utföra en attack krävs följande saker:

1. Tillgång till en NTP-tjänst som inte är begränsad till specifika nätverk (att alla kan använda tjänsten oavsett källan).

2. NTP-tjänsten i fråga måste tillåta kommandot “monlist”. Om kommandot är till- gängligt eller inte beror på vilken version av NTPD som används och på den kon- figurationsfilen som följer med vid installation eller om tjänsten i fråga har blivit säkrad efter installation.

(11)

3. NTP-tjänsten i fråga behöver ha en fylld lista på tidigare anslutna klienter. För högst effekt ska listan innehålla 600st IP-adresser som är maxgränsen.

4. Ingen övervakning och validering av avsändaradresser i paket som anländer hos närmsta internetleverantören. Attacken förlitar sig helt på att det är möjligt att fab- rica avsändaradressen inuti paket.

Trafikflödet vid en attack genom en NTP-tjänst kan ses i figur 2.

Figur 2: Trafikflödet vid en NTP-attack.

En attack genom en NTP-tjänst går till på följande sätt:

1. Angriparen ställer en NTP-förfrågan (kommandot “monlist”) till NTP-tjänsten på maskinen “NTP-relä”. Det här sker med förfalskad avsändaradress.

2. Maskinen “NTP-relä” tar emot kommandot och skickar svaret till den avsändaradressen som användes under steg 1 (adressen leder till offret).

Angriparen har nu ställt en liten NTP-förfrågan till en öppen relä och gjort att ett stort NTP-svar anländer hos offret. [23]

(12)

3 Metod

För att uppnå ett verklighetstroget resultat som identifierar hotbilden öppna reläer utgör utförs diverse kvalitativa tester under en kontrollerad laborationsmiljö i syfte att beräkna den möjliga amplifikationfaktorn som kan åstadkommas. Tjänsterna DNS och NTP granskas också för att upptäcka lösningar som kan implementeras för att motverka att tjänsterna an- vänds vid utförandet av överbelastningsattacker med amplifikationseffekt.

3.1 Laborationsmiljö

Vid utförandet av samtliga tester användes en virtuell laborationsmiljö i programmet VMware Fusion 6 Professional. Miljön består av fyra virtualiserade maskiner som en- samma sitter på ett gemensamt virtuellt nätverk. Se figur 3.

Figur 3: Logisk topologi av nätverket.

Samtliga virtuella maskiner körde operativsystemet Ubuntu Desktop 12.04 LTS och var anpassade för olika syften. Maskinen “Angripare” användes för initiering av attacker, maskinen “Server 1” användes som DNS-tjänst som agerar relä och NTP-tjänst, maskinen “Server 2” användes som DNS-tjänst för en stor domänzon och maskinen “Offer”

användes för avlyssning av nätverkstrafik.

Under genomförande av attacker och vid inspektion av nätverkspaket under resultat kan maskinerna enbart urskiljas genom de olika IP-adresserna, se tabell 1. Samtliga maskiner sitter på ett /22-nätverk och använder därför nätmasken “255.255.252.0”.

Tabell 1: IP-adresser som användes på nätverket.

Maskin IP-adress Angripare 192.168.0.10 Server 1 192.168.0.20 Server 2 192.168.0.21 Offer 192.168.0.30

Maskinerna använder flera olika program för att uppfylla sitt syfte. Se tabell 2.

(13)

Tabell 2: Mjukvara som användes på varje maskin.

Maskin Mjukvara Angripare iptables v1.4.12

DiG 9.8.1-P1 ntpdc 4.2.6p3 Server 1 BIND 9.8.1-P1

ntpd 4.2.6p3 Server 2 BIND 9.8.1-P1 Offer wireshark 1.6.7

Allt som har betydelse för laborationsmiljön, genomförandet och resultaten är specifi- cerat ovanför. Vid skapandet av virtuella maskiner och installationen av operativsyste- men användes standardval, utöver installation av mjukvaran i tabell 2 och konfiguration av tjänsterna har inget övrigt förändrats.

3.2 Genomförande

Testerna som utförs i den virtualiserade miljön analyseras med programmet Wireshark.

Samtliga tester upprepas fem gånger för att försäkra att de olika resultaten är konsekventa och pålitliga.

För att identifiera de olika amplifikationsfaktorerna som kan uppnås med hjälp av tjän- sterna DNS och NTP inspekteras trafiken som uppstår under attacker. Storleken på in- nehållet i de paket som är relaterade till förfrågan och svar undersöks.

Teoretisk undersökning av de funktioner som utnyttjas vid attacker har utförts vid för- beredning av arbetet och den insamlade informationen kommer nu att testas i praktiken för att identifiera de tekniska lösningar som kan användas för att motverka en attack.

Genomförandet består av flera olika steg som är uppdelade under enskilda rubriker.

3.2.1 Förberedelse av tjänster

Innan testerna kan utföras förbereds DNS-tjänsterna och NTP-tjänsten. Förberedelsen består av minimal konfiguration samt att tjänsterna fylls med information. Ena DNS- tjänsten ska hantera en domänzon vars information är exakt 4096 bytes stor och NTP- tjänsten ska ha en full lista av tidigare anslutna klienter (“monlist”).

DNS-tjänsten på maskinen “Server 1” ska vidarebefodra DNS-förfrågningar den ej själv kan svara på till maskinen “Server 2”. För att konfigurera programvaran BIND efter behov läggs följande information till i filen “/etc/bind/named.conf.local”:

forwarders { 192.168.0.21;

};

Utöver ovanstående förändring kommenteras texten “dnssec-validation auto;” bort genom att lägga till “//” framför.

(14)

DNS-tjänsten på maskinen “Server 2” ska hantera det påhittade domännamnet “example.dns”. För att konfigurera programvaran BIND efter behov läggs följande information till i filen “/etc/bind/named.conf.local”:

zone "example.dns" { type master;

file "/etc/bind/db.example.dns";

};

Filen “/etc/bind/db.example.dns” innehåller den domänzoninformation som har skapats specifikt för testerna. Se bilaga 1 för mer information.

NTP-tjänsten förbereds med konfiguration för att tillåta externa kommandon. Den stan- dardkonfigurationsfil som följer med vid installationen av programvaran NTPD under Ubuntu tillåter det inte och därför modifieras inställningarna. För att konfigurera programvaran NTPD behöver följande förändringar ske i filen “/etc/ntp.conf”:

Före justering.

restrict -4 default kod notrap nomodify nopeer noquery Efter justering.

restrict -4 default kod notrap nomodify nopeer

För att fylla listan med tidigare anslutna klienter i NTP-tjänsten användes följande kommandon för att automatiskt byta IP-adress och ansluta till NTP-tjänsten med en NTP- klient.

for (( x=0; x<=2; x++ )); do for (( i=54; i<=254; i++ )); do

echo "192.168.$x.$i"

sudo ifconfig eth0 192.168.$x.$i/22 ntpdate -q -t 0 192.168.0.20

done done

Efter ovanstående steg genomförts är alla tjänsterna rätt konfigurerade och fyllda med den information som krävs för att de planerade testerna ska vara möjliga att genomföra.

3.2.2 Attack genom DNS-relä

En attack genom en DNS-tjänst utförs genom att ställa en specifik DNS-förfrågan i kombination med en fabricerad avsändaradress. För att fabricera avsändaradressen på utgående trafik utnyttjas systemets inbyggda brandvägg och för att ställa DNS-förfrågor användes programvaran “dig”. Genomförandet sker på följande sätt:

Steg 1. IPTables användes för att få brandväggen Netfilter att justera informationen som står i avsändarfältet på alla utåtgående nätverkspaket.

iptables -t nat -A POSTROUTING -o eth0 -j SNAT \ --to-source 192.168.0.30

Steg 2. Programmet “dig” användes för att ställa en DNS-förfrågan om all information om domänzonen “example.dns” till den specifika maskinen som kör DNS-tjänsten.

(15)

dig ANY example.dns @192.168.0.20 +edns=0 +bufsize=4096

Steg 3 (valfritt). Samma DNS-förfråga kan ställas inuti en oändlig loop. Detta utförs inte under testerna men det kan användas vid ett riktigt angrepp.

while true; do

dig ANY example.dns @192.168.0.20 +edns=0 +bufsize=4096 \ +time=0

done

Det ovanstående är alla steg som behöver utföras för att få ett svar från DNS-tjänsten att anlända hos offret.

3.2.3 Säkring av DNS-tjänst

När det gäller säkring av en DNS-tjänst granskades två specifika funktioner. Begränsning av vilka nätverk det får ske anslutningar till tjänsten ifrån och avstängning av funktionen rekursion. All konfiguration sker inuti filen “/etc/bind/named.conf.options” på maskinen

“Server 1”.

För att begränsa nätverken användes en inställning vid namnet “allow-query”. Följande är ett exempel som begränsar dem tillåta nätverken till enbart “127.0/16” (lokal kommunikation) och “192.168.0/22”:

allow-query { 192.168.0/22; 127.0/16; };

För att stänga av funktionen rekursion användes en inställning vid namnet “recursion”.

Avstängning av funktionen specificeras på följande sätt:

recursion no;

För att testa säkringen av DNS-tjänsten utförs samma attack som under del 3.2.2 en gång till. Eftersom en del av säkringen av DNS-tjänsten var begränsning av tillåtna nätverk kommer angreppet numera att ske från en maskin som ligger utanför det tillåtna nätverket

“192.168.0/22” för att testet ska bli korrekt.

3.2.4 Attack genom NTP-relä

En attack genom en NTP-tjänst utförs genom att skicka kommandot “monlist” till en NTP-tjänst i kombination med en fabricerad avsändaradress. För att fabricera avsän- daradressen på utgående trafik utnyttjas systemets inbyggda brandvägg och för att ställa en NTP-förfrågan användes programvaran ntpdc. Genomförandet sker följande sätt:

Steg 1. IPTables användes för att få brandväggen Netfilter att justera informationen som står i avsändarfältet på alla utåtgående nätverkspaket.

iptables -t nat -A POSTROUTING -o eth0 -j SNAT \ --to-source 192.168.0.30

Steg 2. Programmet ntpdc användes för att skicka kommandot “monlist” till den specifika maskinen som kör NTP-tjänsten.

ntpdc -n -c monlist 192.168.0.20

(16)

Steg 3 (valfritt). Samma NTP-förfråga kan ställas inuti en oändlig loop. Detta utförs inte under testerna men det kan användas vid ett riktigt angrepp.

while true; do

ntpdc -n -c monlist 192.168.0.20 done

Det ovanstående är alla steg som behöver utföras för att få ett svar från NTP-tjänsten att anlända hos offret.

3.2.5 Säkring av NTP-tjänst

När det gäller säkring av en NTP-tjänst granskades två specifika funktioner. Begränsning av vilka nätverk det får ske anslutningar till tjänsten ifrån och avstängning av kommandon.

All konfiguration sker inuti filen “/etc/ntp.conf”.

För att begränsa nätverken användes en inställning vid namnet “restrict”. Följande är ett exempel som begränsar dem tillåta nätverken till enbart “127.0/16” (lokal kommunikation) och “192.168.0/22”:

restrict -4 default ignore

restrict 192.168.0.0 mask 255.255.252.0 restrict 127.0.0.0 mask 255.255.0.0

För att stänga av kommandon användes åter igen en inställning vid namnet “restrict”.

Avstängning av kommandon i kombination med befintlig nätverksbegränsning kan specificeras på följande sätt:

restrict 192.168.0.0 mask 255.255.252.0 noquery

Avstängning av kommandon utan kombination med befintlig nätverksbegränsning kan specificeras på följande sätt:

restrict -4 default noquery

För att testa säkringen av NTP-tjänsten utförs samma attack som under del 3.2.4 en gång till. Eftersom en del av säkringen av NTP-tjänsten var begränsning av tillåtna nätverk kommer angreppet numera att ske från en maskin som ligger utanför det tillåtna nätverket

“192.168.0/22” för att testet ska bli korrekt.

3.3 Metoddiskussion

En virtuell laborationsmiljö valdes inte enbart eftersom det är enkelt att hantera utan även för att undvika oförutsägbara problem som kan påverka undersökningen. Det är fram- förallt ett gemensamt och slutet virtuellt nätverk som är önskvärt. Som en extra försäkring av att samtliga resultat är korrekta utförs varje test fem gånger. Tester utförs flera gånger för att utesluta att tillfälliga fel har uppstått och för att se om resultaten verkligen är konsekventa.

Vid tidig granskning av tjänsterna identifierades funktionerna som utnyttjas vid med- verkan i överbelastningsattacker för att förstå både hur en attack genomförs och hur en attack eventuellt kan motverkas. Ett sätt som en attack eventuellt kunde motverkas var genom blockering i brandväggar, dock upptäcktes ingen användbar konfiguration som

(17)

kunde implementeras för att skydda tjänsterna mot icke legitima förfrågningar. Trafik som uppstår vid en attack går inte att särskilja från legitim trafik och därför går det inte att använda en brandvägg för att motverka att en tjänst används vid utförandet av en attack.

(18)

4 Resultat

Under den här delen presenteras resultaten av de attacker som utfördes genom både en DNS- och NTP-tjänst. Resultaten baserar sig helt på den informationen som samlades in genom programmet Wireshark under händelseförloppen.

Resultaten som eftersökes är den amplifikationsfaktorn som var tjänst ger samt resultaten av säkringen av var tjänst. För att få fram amplifikationsfaktorn undersöktes storleken på både förfrågan och svaret för att sedan ta reda på hur många gånger större svaret är jämfört med förfrågan. För att få fram resultaten av säkringen sker en jämförelse av resultat från en attack utförd både före och efter säkring.

4.1 Attack genom DNS-relä

För att underlätta sökandet efter rätt information i programmet Wireshark appliceras ett filter som begränsar vilka paket som ska visas. Paketen som visas har antingen IP- adressen “192.168.0.20” (server) eller “192.168.0.30” (offer) som källa och samtliga paket är relaterade till DNS-protokollet. Filtret specificeras på följande sätt:

(ip.dst==192.168.0.20 || ip.dst==192.168.0.30) && dns

Det första paketet som undersöks måste uppfylla följande kriterier: IP-adressen “192.168.0.30”

(offer) som avsändare och “192.168.0.20” (server) som destination samt innehåller en DNS-förfrågan som begär all information om domänzonen “example.dns”. Det finns enbart ett paket som uppfyller kraven. Se figur 4.

Figur 4: Paket som innehåller DNS-förfrågan.

Efter rätt paket lokaliserats inspekteras detta närmare för att få fram storleken på DNS- förfrågan. Storleken på UDP-paketet är 48 bytes och eftersom UDP har en header på en fast storlek av 8 bytes [14] visar det sig att den underliggande DNS-förfrågan har storleken 40 bytes. Se figur 5.

Figur 5: Inspektion av paket som innehåller DNS-förfrågan.

Det andra paketet som undersöks måste uppfylla följande kriterier: IP-adressen “192.168.0.20”

(server) som avsändare och “192.168.0.30” (offer) som destination samt innehåller svaret på den DNS-förfrågan som tidigare ställts. Det finns enbart ett paket som uppfyller kraven. Se figur 6.

(19)

Figur 6: Paket som innehåller DNS-svaret.

Efter rätt paket lokaliserats inspekteras detta närmare för att få fram storleken på DNS- svaret. Storleken på UDP-paketet är 4104 bytes och eftersom UDP har en header på en fast storlek av 8 bytes [14] visar det sig att det underliggande DNS-svaret är av storleken 4096 bytes. Eftersom storleken på svaret är högt har paketet fördelats i flera mindre paket under transporten och därför måste fliken “Reassembled IPv4” användas vid inspektion under Wireshark. Se figur 7.

Figur 7: Inspektion av paket som innehåller DNS-svaret.

Summering av den insamlade informationen kan ses i tabell 3.

Tabell 3: DNS-trafikens storlek.

Typ Storlek

Förfrågan 40 bytes Svar 4096 bytes

Då storleken på DNS-förfrågan och DNS-svaret är känt kan en beräkning utföras för att få fram den amplifikationsfaktorn som DNS-tjänsten ger. Se formel 1.

4096/40 = 102.4 (1)

Amplifikationsfaktorn som uppstår genom att utnyttja en DNS-tjänst är under optimala förhållanden 102.4. DNS-svaret är 102.4 gånger större än DNS-förfrågan.

4.2 Attack genom NTP-relä

För att få fram paketet som innehåller NTP-förfrågan appliceras ett filter i Wireshark som begränsar vilka paket som ska visas. Paketen som visas har IP-adressen “192.168.0.30”

(offer) som källa och “192.168.0.20” (server) som destination samt att alla paket är relaterade till NTP-protokollet. Filtret specificeras på följande sätt:

(20)

ip.src==192.168.0.30 && ip.dst==192.168.0.20 && ntp

Det första paketet som undersöks måste uppfylla följande kriterier: IP-adressen “192.168.0.30”

(offer) som avsändare och “192.168.0.20” (server) som destination samt innehåller en NTP-förfrågan som innehåller kommandot “monlist”. Det finns enbart ett paket som uppfyller kraven. Se figur 8.

Figur 8: Paket som innehåller NTP-förfrågan.

Efter rätt paket lokaliserats inspekteras detta närmare för att få fram storleken på NTP- förfrågan. Storleken på UDP-paketet är 200 bytes och eftersom UDP har en header på en fast storlek av 8 bytes [14] visar det sig att den underliggande NTP-förfrågan är av storleken 192 bytes. Se figur 9.

Figur 9: Inspektion av paket som innehåller NTP-förfrågan.

För att få fram paketen som innehåller NTP-svaret appliceras ett filter i Wireshark som begränsar vilka paket som ska visas. Paketen som visas har IP-adressen “192.168.0.20”

(server) som källa och “192.168.0.30” (offer) som destination samt att alla paket är relaterade till NTP-protokollet men inte ICMP-protokollet. Offret skickar ut ICMP-paket som inte är relevanta för undersökningen. Filtret specificeras på följande sätt:

ip.src==192.168.0.20 && ip.dst==192.168.0.30 && ntp && !icmp Manuell inspektion av den paketlistan som finns efter ovanstående filter har applicerats visar att NTP-svaret är fördelat i 100st paket. Det är ytterst viktigt att inga icke relevanta paket finns med i paketlistan eftersom det då ger fel resultat. Se figur 10.

Figur 10: Flera paket som innehåller NTP-svaret.

Efter rätt paket lokaliserats inspekterades en summering av alla dem paket som fanns i den filtrerade paketlistan för att få fram storleken på NTP-svaret. Summeringen visar att NTP-svaret består av 100st paket som tillsammans är 48200 bytes stort. Varje paket består av flera lager med information som används vid transport och dess storlek måste beräknas

(21)

bort för att få fram den slutgiltiga korrekta storleken, det är enbart innehållet i varje paket som är intressant. Se figur 11.

Figur 11: Summering av alla paket som innehåller NTP-svaret.

För att få fram storleken på den överliggande informationen som ska räknas bort per paket inspekteras ett av paketen närmare. Den totala storleken av hela paketet är 482 bytes. Storleken på UDP-paketet är 448 bytes och eftersom UDP har en header på en fast storlek av 8 bytes [14] visar det sig att den underliggande NTP-förfrågan är av storleken 440 bytes. Se figur 12.

Figur 12: Inspektion av ett av flera paket som innehåller NTP-svaret.

Summering av den insamlade informationen kan ses i tabell 4.

Tabell 4: Paketets uppdelning.

Del Storlek

Hela paketet 482 bytes NTP-delen 440 bytes

Då storleken på hela paketet och NTP-svaret är känt kan en beräkning utföras för att få fram hur mycket som ska räknas bort per paket. Se formel 2.

482 − 440 = 42 (2)

Då antalet paket, den totala storleken av alla paket och storleken som ska räknas bort per paket är känt kan en beräkning utföras för att få fram det slutgiltiga och korrekta värdet för hela NTP-svaret. Se formel 3.

(22)

48200 − (100 ∗ 42) = 44000 (3) Summering av den insamlade informationen kan ses i tabell 5.

Tabell 5: NTP-trafikens storlek.

Typ Storlek

Förfrågan 192 bytes Svar 44000 bytes

Då storleken på NTP-förfrågan och NTP-svaret är känt kan en beräkning utföras för att få fram den amplifikationsfaktorn som NTP-tjänsten ger. Se formel 4, observera att svaret är avrundat neråt.

44000/192 = 229.16 (4)

Amplifikationsfaktorn som uppstår genom att utnyttja en NTP-tjänst är under optimala förhållanden 229.16. NTP-svaret är 229.16 gånger större än NTP-förfrågan.

4.3 Säkring av tjänsterna

För att få fram resultatet av säkringen av både DNS-tjänsten och NTP-tjänsten måste en jämförelse av attacker utförda både före och efter säkring ske. Nedanför finns resultatet av den jämförelsen.

Vid genomförandet av ytterligare en attack genom en DNS-tjänst blev resultatet inte samma som under del 4.1. DNS-tjänsten på maskinen “Server 1” svarar inte längre på DNS-förfrågan utan DNS-tjänsten svarar istället med ett nekande. En attack går inte län- gre att genomföra under laborationsmiljön. Se figur 13.

Figur 13: Nekande av DNS-förfrågan efter säkring.

Vid genomförandet av ytterligare en attack genom en NTP-tjänst blev resultatet inte samma som under del 4.2. NTP-tjänsten svarar inte längre på NTP-förfrågan. En attack går inte längre att genomföra under laborationsmiljön.

Attackerna motverkas inte tack vare den begränsning av tillåtna nätverk som har konfig- urerats i tjänsterna eftersom förfrågorna ser ut att komma inifrån det tillåtna nätverket

“192.168.0/22”. Se figur 13, nekandet skickas till den påstådda källan av förfrågan.

(23)

5 Diskussion

Samtliga utförda attacker var enkla att genomföra. En stor anledning till detta är att stan- dardfunktionalitet i tjänsterna utnyttjas, tjänsterna användes helt enkelt på det sättet det är tänkt att användas och det görs med vanligt förekommande verktyg. Förfrågorna till tjän- sterna må vara ställda för illegitimt syfte men oavsett agerar tjänsterna helt korrekt.

Det resultat som framgår av undersökningen av en attack utförd genom en DNS-tjänst visar att trafiken som skickas ut från angriparens maskin kan multipliceras med över 100 gånger om det går igenom en helt öppen DNS-tjänst. Hur stor amplifikationsfaktor som kan uppnås beror på hur stor domänzon som kan hittas. Eftersom funktionen rekursion gör att det räcker med att bara hitta en enda stor domänzon är det enkelt att få fram en någorlunda hög amplifikationsfaktor även utanför en laborationsmiljö.

Det resultat som framgår av undersökningen av en attack utförd genom en NTP-tjänst visar att trafiken som skickas ut från angriparens maskin kan multipliceras med över 225 gånger om det går igenom en helt öppen NTP-tjänst. Hur stor amplifikationsfaktor som kan uppnås beror på hur många klienter som tidigare har anslutits till tjänsten. Efter- som listan på tidigare anslutna klienter inte rensas periodiskt blir listan snabbt full på en väl besökt NTP-tjänst vilket gör det enkelt att få fram en hög amplifikationsfaktor även utanför en laborationsmiljö.

Resultaten av attacker genomförda efter att säkringen av båda tjänsterna genomförts visar bland annat att begränsning av tillåtna nätverk enbart löser problemet då offret inte befinner sig inom det tillåtna nätverket. Anledningen till detta är att förfrågan ser ut att komma ifrån offret och inte angriparen.

Avstängning av rekursion i en DNS-tjänst löste problemet i laborationsmiljön men en attack kan rent teoretiskt utföras även utan att utnyttja rekursion. Utan rekursion måste den öppna DNS-tjänsten även hantera en stor domänzon eftersom den då inte kan begära information om en domänzon som befinner sig på en annan DNS-tjänst. I praktiken blir det besvärligt att hitta en DNS-tjänst som inte bara är öppen utan även också hanterar en stor domänzon, urvalet av lämpliga DNS-tjänster begränsas ytterligare.

Avstängning av kommandon i en NTP-tjänst löste problemet helt i laborationsmiljön. Då kommandon nekas går det inte längre att få fram ett stort svar från NTP-tjänsten. Kom- mandot “monlist” togs bort i version 4.2.7 av NTPD och därför behöver ingen säkring längre ske under förutsättningen att det är möjligt att köra en ny version av NTPD.

Det uppskattas finnas mellan 28 och 32 miljoner öppna DNS-tjänster [9] och eftersom det även finns en databas över öppna NTP-tjänster [32] är förmodligen även den siffran tillräckligt hög för att väcka oro. Kunskapen om hur enkelt en attack genomförs i kombination med de miljontals öppna tjänsterna som är redo att utnyttjas vid en attack gör att det mardrömsscenario som målats upp i diverse nyhetsartiklar inte är helt orealistiskt.

Det är inte orimligt att anta att det bara är en tidsfråga innan nya rekordbrytande attacker genomförs på Internet.

5.1 Slutsats

Resultatet av en attack utförd genom en DNS-tjänst visar att amplifikationsfaktorn som tjänsten ger under optimala förhållanden är “102.4”.

(24)

Resultatet av en attack utförd genom en NTP-tjänst visar att amplifikationsfaktorn som tjänsten ger under optimala förhållanden är “229.16”.

Det finns tekniska lösningar som en systemadministratör kan implementera för att motverka problemet. Begränsning av tillåtna nätverk kan konfigureras i båda tjänsterna och det löser problemet under förutsättningen att offret inte sitter på det tillåtna nätverket. Avstängning av funktionen rekursion i en DNS-tjänst försvårar utnyttjandet avsevärt. Avstängning av kommandon i en NTP-tjänst eller uppdatering till senaste versionen av ntpd löser problemet helt.

5.2 Fortsatt forskning

Undersökningen har varit begränsad till två specifika tjänster som är vanligt förekom- mande i attacker av denna typ. Dessa tjänster är dock inte nödvändigtvis de enda som går att utnyttja. Undersökning av övriga tjänster som eventuellt går att utnyttja kan vara intressant och hjälpa till att upptäcka framtida attackmetoder i ett tidigt skede.

Det kan också vara intressant att undersöka om vad andra parter kan göra för att motverka problemet. Exempelvis om en internetleverantör kan stoppa attacker helt genom att omöjliggöra fabricering av avsändaradresser och om en sådan begränsning kan användas för att motverka även andra vanligt förekommande problem på Internet idag.

(25)

Referenser

[1] Okänd. (2013, 4) Varning för nya superattacker på nätet - dn.se. Dagens Nyheter AB. [Online]. Tillgänglig: http://www.dn.se/ekonomi/varning-for-nya- superattacker-pa-natet/ [Kontrollerad: 2014-04-10]

[2] T. Brewster. (2014, 2) Flooding the web: The internet’s epic attack amplification problem | technology | theguardian.com. Guardian News. [Online]. Tillgäng- lig: http://www.theguardian.com/technology/2014/feb/24/flooding-the-web-attack- amplification [Kontrollerad: 2014-04-10]

[3] M. Handley. (2006, 11) Rfc 4732 - internet denial-of-service con- siderations. The Internet Engineering Task Force. [Online]. Tillgänglig:

http://tools.ietf.org/html/rfc4732 [Kontrollerad: 2014-04-16]

[4] M. Prince. (2013, 3) The ddos that almost broke the internet | cloudflare blog.

CloudFlare. [Online]. Tillgänglig: http://blog.cloudflare.com/the-ddos-that-almost- broke-the-internet [Kontrollerad: 2014-04-10]

[5] Okänd. (2013, 3) Dns amplification attacks | us-cert. United States Com- puter Emergency Readiness Team. [Online]. Tillgänglig: https://www.us- cert.gov/ncas/alerts/TA13-088A [Kontrollerad: 2014-04-10]

[6] J. Graham-Cumming. (2014, 1) Understanding and mitigating ntp- based ddos attacks | cloudflare blog. CloudFlare. [Online]. Till- gänglig: http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos- attacks [Kontrollerad: 2014-04-10]

[7] P. Bright. (2013, 4) Can a ddos break the internet? sure. . . just not all of it | ars technica. Ars Technica. [Online]. Tillgäng- lig: http://arstechnica.com/security/2013/04/can-a-ddos-break-the-internet-sure- just-not-all-of-it/ [Kontrollerad: 2014-04-10]

[8] S. Gallagher. (2014, 2) Biggest ddos ever aimed at cloudflare’s content delivery network | ars technica. Ars Technica. [Online].

Tillgänglig: http://arstechnica.com/security/2014/02/biggest-ddos-ever-aimed-at- cloudflares-content-delivery-network/ [Kontrollerad: 2014-04-10]

[9] Okänd. (2013, 10) Open resolver project. Open Resolver Project. [Online].

Tillgänglig: http://openresolverproject.org/ [Kontrollerad: 2014-04-10]

[10] B. Vachon and R. Graziani, Accessing the WAN CCNA: Exploration Companion Guide. Cisco Press, 2012, pp. 212–217.

[11] L. D. Paulson. (2006, 4) Hackers strengthen malicious botnets by shrinking them.

[Online]. Tillgänglig: http://www.computer.org/csdl/mags/co/2006/04/r4017.pdf [Kontrollerad: 2014-05-20]

[12] J. Livingood. (2012, 3) Rfc 6561 - recommendations for the remediation of bots in isp networks. The Internet Engineering Task Force. [Online]. Tillgänglig:

[13] Okänd. Open relay servers. [Online]. Tillgänglig: http://www.spamcop.net/fom- serve/cache/272.html [Kontrollerad: 2014-05-20]

(26)

[14] J. Postel. (1980, 8) Rfc 768 - user datagram protocol. The Internet Engineering Task Force. [Online]. Tillgänglig: http://tools.ietf.org/html/rfc768 [Kontrollerad:

2014-04-24]

[15] P. Mockapetris. (1987, 11) Rfc 1034 - domain names - concepts and facilities. The Internet Engineering Task Force. [Online]. Tillgänglig:

[16] J. Damas and M. Graff. (2013, 4) Rfc 6891 - extension mechanisms for dns (edns(0)). The Internet Engineering Task Force. [Online]. Tillgänglig:

[17] Okänd. Bind | internet systems consortium. [Online]. Tillgänglig:

https://www.isc.org/downloads/bind/ [Kontrollerad: 2014-05-21]

[18] ——. Mission | internet systems consortium. [Online]. Tillgänglig:

https://www.isc.org/mission/ [Kontrollerad: 2014-05-21]

[19] ——. (2014, 4) dig. Internet Systems Consortium. [Online]. Tillgänglig:

ftp://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.dig.html [Kontrollerad: 2014-04-25]

[20] D. Mills. (2010, 6) Rfc 5905 - network time protocol version 4: Protocol and algorithms specification. The Internet Engineering Task Force. [Online].

Tillgänglig: http://tools.ietf.org/html/rfc5905 [Kontrollerad: 2014-04-16]

[21] “Network time protocol: Best practices white paper,” White Paper, Cisco, 11 2008.

[22] Okänd. (2012, 11) ntpd - network time protocol (ntp) daemon. ntpd. [Online].

Tillgänglig: http://www.eecis.udel.edu/ mills/ntp/html/ntpd.html [Kontrollerad:

2014-04-24]

[23] ——. (2013, 12) Hackers spend christmas break launching large scale ntp-reflection attacks | symantec connect community. Symantec. [Online]. Till- gänglig: http://www.symantec.com/connect/blogs/hackers-spend-christmas-break- launching-large-scale-ntp-reflection-attacks [Kontrollerad: 2014-04-10]

[24] T. Northrup. Firewalls. Microsoft. [Online]. Tillgänglig:

http://technet.microsoft.com/en-us/library/cc700820.aspx [Kontrollerad: 2014-04- 24]

[25] M. Goodrich and R. Tamassia, Introduction to Computer Security. Pearson Addison-Wesley, 2011, ch. Network Security II, pp. 287–291.

[26] Okänd. (2014) The netfilter.org project. netfilter. [Online]. Tillgänglig:

http://www.netfilter.org/ [Kontrollerad: 2014-04-25]

[27] ——. (2013, 5) Man page of iptables. Wireshark Foundation. [Online]. Tillgänglig:

http://ipset.netfilter.org/iptables.man.html [Kontrollerad: 2014-04-25]

[28] ——. 1.1. what is ubuntu? [Online]. Tillgänglig:

https://help.ubuntu.com/14.04/installation-guide/i386/ch01s01.html [Kontrollerad:

2014-05-21]

[29] ——. (2014, 4) Wireshark · frequently asked questions. Wireshark Foundation.

[Online]. Tillgänglig: http://www.wireshark.org/faq.html [Kontrollerad: 2014-04- 25]

(27)

[30] P. Mockapetris. (1987, 11) Rfc 1035 - domain names - implementation and specification. The Internet Engineering Task Force. [Online]. Tillgänglig:

[31] M. Prince. (2012, 9) How to launch a 65gbps ddos, and how to stop one | cloudflare blog. CloudFlare. [Online]. Tillgänglig: http://blog.cloudflare.com/65gbps-ddos- no-problem [Kontrollerad: 2014-04-10]

[32] Okänd. (2014) Open ntp project. OpenNTPProject. [Online]. Tillgänglig:

http://openntpproject.org/ [Kontrollerad: 2014-04-10]

(28)

A Bilaga 1

$TTL 604800

@ IN SOA ns1.example.dns. admin.example.dns. ( 1 ; Serial

10800 ; Refresh 10800 ; Retry 2419200 ; Expire

604800 ) ; Negative Cache TTL

@ IN NS ns1.example.dns.

ns1 IN A 192.168.0.21

@ IN TXT "PrKuPV9OV39vzFhE9SdKTVUWep8WU68wunkTs1tVPOzeCAJnULtmx2saV urNV5Bf5BseyreRBZO3zGStFmuakmJvBYXnsSw4BcwtIKycu9rKZ8HjYTUrmoEj2sVI n70MpxyHC0srbDKhXlNEHLAttddVd34Ncw6oAFoUTTB2yYWUzNLz9iwDFb7pLUNvHNZ QIglb4qDtnneGQn17FM2OmRYy2BlbFbT2U3ubdxLmrPf9L7hvUQ2vfq7nH3DvRSG"

@ IN TXT "1n4VYvuyQpGv9hxELtXHVh4s7rJWW8IEh2UMJYdmLH8rTP2udkRGRbMEY KEdybtBlZkpb0bTmyHugUHbf8hwpPtftbtM03iWVwPZzlCs23W8O9ZcuH2t1qTUg6TM FMCJlSMIgl6JmzXhFE8GPPLL6xf6SpaXzB7GSZe1uy4PFLCQOqltYm76pCmZbTwcMya LnCaYGfhab2JL922HUFJXo2Y5TAB5s5xhU0pgQXk9L22P2NARkv33uocQEdAm3lh"

@ IN TXT "swHJpGVIgVzO7YEr82FREVRmPz8IfilSgeP96EZ8up3jVau5DEaFFaDzQ K57Lqq8mLit0VcA6j77LTijutf29CjlwbVC1JJtpBbJH1SXZvalZgHyJfCWkEuuDTnc Flx84hmKzNthOsseFEK7IRYaQX7eEP89mJPFhmd2g2C2FszJ9Toq4gyTAY5jN9SVKJR RjQIKDQPrmsSYUzB4pU1NQ1bV5mIG6s1mKvdmHWiw9x7gTf39YJVSq7vRhLaTWGq"

@ IN TXT "QPMw7lV590uTmYF4S4mFvwKgo0drHbakg4buF6N8MpXmGkFPuB9NaLfko XrCJip2doqkA4sUUbNUYTNCrmRfh9iBBlQQUXr1WVqeUb4iJemH89jnCZPDS6tE1pVg Coh6zYqWenyJQDficbXlvqABtu3yIKYWbSf21viNtALkvgLKPYRLwcJeZ93csrdXYab rZDZFDkbkWQg88Dgc3QfJFYS9N7PGZuBOFDFrkowSEtVZ1VJhcCbWkSZMVpqAjbe"

@ IN TXT "wvj3XIlxMJZVe1GjvUm9puYWnqOhnGZAwdicaS1vvvHWiBxR2i2bfPlLN ahVsPzZ9uhtpjvTYIQinMnUupQfjlYCl6gOKhHrZJT01dNF2VcO0fI3JMF5G3O0iL6H qkTAAhhSNs9C3HIrsUfWNY2ILYmUxMcuu37Z8x2oIis25Ll78qyYGhRm9cC9FhDEZac 7FgdZAnatooJBYcypJYxmN882tLPjTTfZroEHHTSkKhikKS3Akxa9x1ve0xj1g1J"

@ IN TXT "wgbNNQIJ0oZE3NRL8u0d9CMiW4OD2PTQdwPleR2FcJc2sdLIKESYOpis5 X83bnaoCvKNGtbTWm8Dxwu4toGQ9fINR1Oqc70OnjDQofVaWQj7ZW3HRnJUJfQhXHnY t4sOkbNWtOVoPgRy5n8VPPfVhP4kPdVTmffzxnaceys1ZItW3kQnA1xqN2Clpy4jvEH jtonR9PH2GcxopHwJuA6ypvV460DAFPWF1anLLm8SiOTAwteaJAdWOMaN6F53U8Y"

@ IN TXT "PeNWUzFfSbpLverZNLipcUGa9Po3ITRxGsIP67mRpE8N4o4USbwQvMB4z LYJasZa7CUSPDmWoQRb2RZD5sqZ0OQ6pC0CN6XIGVmbErWv7Gr74VQIH4I9aZ4gbXY6 TqX2vxHlTPNsNeyz4SRpv8dYFBRsOVpRhPkhS1n7mubPhVxOethcp5aYJX0M7d7zLsE sRq1HSXX2tWo0ADkp7oRze0d8eiAh93UCXowKNrx92efv1s8O7nOTCIcrwgXABbT"

@ IN TXT "xSr78jbOpgxyEfB70RUj0gruibvvBeKMacGJMVLz7hyUEdMeZ6TGYl8pH MvRcb3hYhQ3fBza9JQdclkgHSnSwJ8j66KWzfjr6PAhZTO22sDkEZ6E9yIJYWhgpogv 1yAjyOIO9GzVTveF3qyGp4ryjWkyO3azFSDjrBdFoTr93THlKAhmii3fGjVOH0n2TQb A8rxj3N5iAfQXy2AeNuRMtw6PCsAHUZyjFK5hawkQE8mKr51TVevwfMXJSkmCKUD"

(29)

@ IN TXT "8HdjsiA0hpxw4fquoF7k8aThma3tUpdpeSlR3ZAgxlZg7aXv4aBqMYv5O 8Ay96As8hzL4iaynXUIOpNbwxbpFKycrZWhU3ZrN21ZOrwgA5L2qiJpqtG2K97LhTvI ZQEYngPVdNI87CJ9rBGkG9JAJ0woRoUftVQ4vflOnP3VsUDWHKOJPpCvk6eBZX0Y8Gw XaADzxTCrOMzTif40KfXOL6BAgk5zPVhq2o1q2rWWj6HWYUGbZ5SAFqznPBSDFLQ"

@ IN TXT "xTbYiU9sXdpIiBGaSqxrmEkd7ZCF4c4lY76zSS0nJQCXbCN55gzyhGxhy 80V98lL4BcKrU8QLjyMITCiouY4XjmQLgCadyX5KxQuhFQuxODHXqgGdSVrCkF3lofj e3j8SGhAdoaNj69DoChjI8duV76RXkXVl9Ql0DOQQYG6qa24pGxwFTezCnTW7pstY7d d6C6JG3XeNLiIpP4RbZUhKwlKP4PlJrUmGr344z7RazlnFz2BZPkDZpT8ehcNpiJ"

@ IN TXT "bvpHThEQUcdtT41KQgengUs7ICJV7ZEwoS7GcyyYsxxM2rLBpT6D27kFE c0XciQc0dqo5Gde9jJ4LSYVYb87NWrCdgJswG701DLiNw1ptjeBI2bZbAaIvix813zm PiFG7yj9UemiEpAjshTiwTtARMZE4iO0gQyknrHdo7I6ATtjMgK6C59pLMm8MXJLU1G L4Nfotd13nFBSSxxNwkRkKMeC86bYntbJVMfDlWPDD6d5iLlINfIoReu4nG8Xz1I"

@ IN TXT "NKkmTHWoonD9tK2haEI20j2o0fmev1EWpElJ6l79NZz3tKbKywgj8If4q PjbGzjuKEQxhBvl53XZdbcZmr5oY98GaF7ZyQ2DsT6zRxG9vUD7o2vpzhgCQpkaPLIc 7pMXWURYAKhPN1r9avPMXttvI3GO0nJMhRXDnFoBt6kQOkDXeil7hxyiVpW8ZhVdExQ TLlkNrfxusG2TGOCKlRGmbiLkKWMjUfCk3qDBT4cBGMcQ4jKSRMIQHJ1vmJ1St5n"

@ IN TXT "kGdHgoJ2FBeZSQ8sJhlFZGUsSaddSLpW2sm7Hinwe2YZjztHKFCSfTRif qofoDmcYmG2u2rSJB45NzVDAlpgQiGzF2QEPURORld3TvBkyJkwk1w47qUkYJoUa0fK yBED5UUwOVkBuBdShO3eCBkEaQ4enDaqt5oW5ZkjwBIxrtq4D72KrG7tK8Grl1YMDrq 4WeyUzREUHO9O3tlQDVBmDikGVuiFUG9zwT9F430v79rKBBLTRZun2dFpqyUFsIe"

@ IN TXT "Fba7sszg3UDa7MdDB1n3LlvFn2llOG6goo7U4RG7TUyYsRR6HLMJTKKRM VA0mjVe0XreQWmlpYyXKcmq8UT8kcCt7cgQvkv1ALWsdxHmBEX9dilmdxgyJpNdwpzo JdBQ2LYA4tGTQXjMijhuWdweZAC7ztKEbSAbwonFquQVNj2GW9BUBOnVJmS5U6ylzoS G42C2pxBbrGOFpSU2g7H4ndrA55vm0aAlv7Z8ZRma1TGnOPXeoWeINGlzPLVuEf8"

@ IN TXT "8qqt3wzbdSaXYJpCTNORtErQoYDQ5GA6wrKU8VoAFa13ByvkrtDGuh4le bzMrErStbadBK5icDAyuWXIIVeCO0IZMS6mhUmE8TqzwwZ4WilSXWEV0003loyBstZp kIdF5KLvsGiRNRLUBb1nRDnpgRkMQq5j95y8YC1y2eUAk7pnvnLtvBUsvDbpt7zyS15 dAITC8Lt3A9m4DV9NHblmUeXP6"