012345

}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky

Bezpečnostní analýza provozu DNS Diplomová práce

Milan Čermák

Brno, podzim 2013

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

V Brně dne 7. 1. 2014

Milan Čermák

Vedoucí práce: RNDr. Jan Vykopal, Ph.D. ii

Poděkování Na tomto místě bych rád poděkoval vedoucímu mé práce RNDr. Janu Vykopalovi, PhD. a konzultantovi Mgr. Tomáši Jirsíkovi za cenné rady při její tvorbě. Velké díky patří také kolegům z Ústavu výpočetní techniky Masarykovy univerzity, kteří byli ochotni kdykoliv pomoci. Taktéž děkuji rodičům a všem přátelům za jejich velkou podporu.

iii

Shrnutí Diplomová práce se zaměřuje na analýzu síťového provozu vytvářeného službou Domain Name System (DNS). K tomuto účelu jsou využity IP toky rozšířené o informace z provozu DNS. Práce se primárně soustředí na anomálie a útoky, které se mohou v tomto provozu vyskytnout. Popisuje jejich vlastnosti a možné dopady na celou síť. Pro vybrané anomálie jsou navrženy nové metody umožňující jejich detekci. Každá z těchto metod byla implementována v jazyce Perl a zkušebně nasazena v síti Masarykovy univerzity. Nasazení umožnilo úspěšně odhalit doposud obtížně detekovatelné síťové anomálie a útoky a přispět tak k lepšímu zabezpečení sítě Masarykovy univerzity.

Klíčová slova Domain Name System, DNS, detekce anomálií, síťové toky, IPFIX, fbitdump, síťová bezpečnost

iv

Obsah 1 2

3

4

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Obsah práce . . . . . . . . . . . . . . . . . . . . . Domain Name System . . . . . . . . . . . . . . . . 2.1 Historie . . . . . . . . . . . . . . . . . . . . . . . 2.2 Doménová jména . . . . . . . . . . . . . . . . . . 2.3 Implementace a struktura . . . . . . . . . . . . . 2.4 Protokol DNS . . . . . . . . . . . . . . . . . . . . 2.4.1 Záznamy . . . . . . . . . . . . . . . . . . 2.4.2 Formát zpráv . . . . . . . . . . . . . . . . 2.4.3 DNS Security Extensions . . . . . . . . . 2.5 Software . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Správa serveru . . . . . . . . . . . . . . . 2.5.2 Nástroje pro práci s DNS . . . . . . . . . 2.5.3 Online dostupné nástroje . . . . . . . . . 2.6 Bezpečnost DNS . . . . . . . . . . . . . . . . . . 2.6.1 Odmítnutí služby . . . . . . . . . . . . . . 2.6.2 Změna konfigurace DNS . . . . . . . . . . 2.6.3 Zneužití vyrovnávací paměti DNS . . . . 2.6.4 Přesměrování provozu DNS . . . . . . . . 2.6.5 Ostatní zranitelnosti . . . . . . . . . . . . 2.6.6 Shrnutí . . . . . . . . . . . . . . . . . . . Monitorování provozu DNS . . . . . . . . . . . . . 3.1 Ukládání dotazů na serveru DNS . . . . . . . . . 3.1.1 Zpřístupnění provozních záznamů DNS . . 3.1.2 Zpracování uložených záznamů . . . . . . 3.2 Monitorování paketů DNS . . . . . . . . . . . . . 3.2.1 Hloubková analýza paketů . . . . . . . . . 3.2.2 Analýza IP toků . . . . . . . . . . . . . . 3.3 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . Anomálie provozu DNS . . . . . . . . . . . . . . . 4.1 Provozní anomálie . . . . . . . . . . . . . . . . . 4.1.1 Nadměrný provoz DNS . . . . . . . . . . 4.1.2 Tunelování provozu . . . . . . . . . . . . . 4.1.3 Dotazy na neexistující záznamy . . . . . . 4.1.4 Využívání DNS resolverů mimo lokální síť 4.2 Bezpečnostní anomálie . . . . . . . . . . . . . . . 4.2.1 Cybersquatting . . . . . . . . . . . . . . . 4.2.2 Amplifikační útok . . . . . . . . . . . . . 4.2.3 Dotazy na neobvyklé typy záznamů . . . 4.2.4 Dotazování závadných domén . . . . . . . 4.2.5 Domény specifických vlastností . . . . . . 4.2.6 Společné chování více zařízení . . . . . . . 4.3 Analýza provozu DNS v síti MU . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 4 5 5 5 6 8 9 10 12 13 13 13 15 15 16 17 17 19 19 20 21 21 22 23 25 25 29 33 35 35 35 36 36 37 38 38 39 40 41 42 42 43 1

Metody detekce anomálií provozu DNS . . . . . . 5.1 Detekce využívání DNS resolverů mimo lokální síť 5.1.1 Metoda využívající standardní IP toky . . . 5.1.2 Metoda využívající rozšířené IP toky . . . . 5.1.3 Vyhodnocení nasazení . . . . . . . . . . . . 5.2 Detekce návštěv vizuálně podobných domén . . . . 5.2.1 Popis metody . . . . . . . . . . . . . . . . . 5.2.2 Implementace . . . . . . . . . . . . . . . . . 5.2.3 Vyhodnocení nasazení . . . . . . . . . . . . 5.3 Detekce amplifikačního útoku . . . . . . . . . . . . 5.3.1 Popis metody . . . . . . . . . . . . . . . . . 5.3.2 Implementace . . . . . . . . . . . . . . . . . 5.3.3 Vyhodnocení nasazení . . . . . . . . . . . . 5.4 Detekce otevřených DNS resolverů . . . . . . . . . 5.4.1 Popis metody . . . . . . . . . . . . . . . . . 5.4.2 Implementace . . . . . . . . . . . . . . . . . 5.4.3 Vyhodnocení nasazení . . . . . . . . . . . . 5.5 Detekce dotazů na závadné domény . . . . . . . . . 5.5.1 Popis metody . . . . . . . . . . . . . . . . . 5.5.2 Implementace . . . . . . . . . . . . . . . . . 5.5.3 Vyhodnocení nasazení . . . . . . . . . . . . 5.6 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . 6 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah přiloženého DVD . . . . . . . . . . . . . . . .

5

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

48 49 49 50 51 52 52 53 53 54 55 55 56 56 57 57 58 59 60 60 61 62 64 69

2

Kapitola 1

Úvod Používání jmen místo čísel je pro člověka mnohem přirozenější a jednodušší na zapamatování. Proto téměř hned po spuštění první internetové sítě bylo místo číselných adres vhodných pro strojové zpracování zavedeno právě jmenné pojmenování. Mechanismus pojmenování byl později transformován do systému hierarchických jmen známým pod termínem Domain Name System, zkráceně DNS. V současné době tvoří tento systém nedílnou součást internetu, kdy téměř každá služba a zařízení v síti má své jedinečné pojmenování a je pomocí tohoto pojmenování adresována. Díky širokému využívání doménových jmen je téměř každá komunikace v rámci internetu předcházena právě překladem jmen na síťovou adresu. Toho je možné s výhodou využít při bezpečnostním monitorování síťového provozu. Pro toto monitorování jsou dnes nejčastěji využívány nástroje založené buď na hloubkové analýze celého provozu nebo na analýze agregovaných záznamů o provozu na síti, tzv. IP toků. Zatímco hloubková analýza provozu je pro velké sítě časově a výkonově velmi náročná, agregované záznamy představují efektivní nástroj pro bezpečnostní monitoring sítě, byť za cenu sníženého množství informací. Standardní IP toky obsahují pouze síťové adresy a porty komunikujících stran doplněné o základní statistiky spojení. Jedna síťová adresa ovšem může mít přiřazeno více jmen rozlišujících poskytované služby. Na základě síťové adresy a portu ovšem nelze rozlišit, kterou službu klient využil. Právě pro tyto účely je vhodné rozšířit síťové toky o informace o dotazech na doménová jména, které předcházely samotnému spojení. Díky tomu je možné lépe identifikovat služby, které dané zařízení používá, při zachování výhod IP toků. Většina publikací o monitorování DNS se zaměřuje na analýzu provozu na serverech páteřní sítě nebo na detekci existence závadných domén. Tato diplomová práce je ovšem primárně zaměřena na lokální sítě většího rozsahu. Na rozdíl od páteřních a spojových sítí je v lokální síti možné mnohem lépe propojit dotazy DNS s konkrétním zařízením, které se dotazovalo. Kromě detekování závadných domén tak lze analyzovat i specifické chování konkrétního zařízení, které může naznačovat například jeho napadení škodlivým software. Diplomová práce se zabývá výzkumem možností využití informací z provozu DNS pro bezpečnostní analýzu obecného síťového provozu. Cílem práce tedy není navrhnout metody umožňující detekovat útoky na samotnou infrastrukturu DNS, ale spíše detekovat, pomocí zachyceného DNS provozu, jakékoliv neobvyklé chování zařízení v síti. K tomuto účelu jsou využity IP toky rozšířené o informace z DNS provozu, které jsou vhodné i pro monitorování větších sítí. Na základě analýzy dotazů na překlad jmen a odpovědí vytvářených v prostředí sítě Masarykovy univerzity jsou v diplomové práci navrženy nové univerzální metody detekce anomálií síťového provozu. Tyto metody umožňují rozšířit možnosti současných detekcí založených pouze na síťových tocích. Navržené metody byly implementovány v podobě detekčních skriptů, které byly úspěšně nasazeny v prostředí sítě Masarykovy univerzity. Díky nim se podařilo detekovat chybná nastavení zařízení v síti MU a další napadená zařízení, která nebyla stávajícími metodami detekovatelná. 3

1. Úvod

1.1

Obsah práce

Diplomová práce obsahuje celkem pět kapitol zabývajících se problematikou monitorování DNS provozu, od popisu základních vlastností DNS až po návrh a vyhodnocení nových detekčních metod. Druhá kapitola se konkrétněji zaměřuje na obecný popis protokolu DNS, doplněný o dostupná softwarová řešení a bezpečnostní hrozby týkajících se samotné infrastruktury a protokolu DNS. Třetí kapitola se věnuje problematice monitorování provozu DNS. Jsou představeny tři rozdílné přístupy, kterými lze provoz zachytávat a analyzovat. Pro každý z uvedených přístupů jsou popsány jeho výhody a nevýhody doplněné vhodným způsobem použití. Čtvrtá kapitola práce se již zaměřuje na popis konkrétních anomálií, které se mohou objevit v provozu DNS. Podle důvodu jejich vzniku a možných důsledků jsou tyto anomálie rozděleny na provozní a bezpečnostní. Závěr kapitoly je věnován analýze a anomáliím provozu DNS v síti Masarykovy univerzity. Předposlední kapitola je věnována jednotlivým detekčním metodám, které byly vytvořeny v rámci diplomové práce. U každé zmíněné metody je detailně popsán její princip a vytvořená implementace spolu s výsledky a zkušenostmi z nasazení v síti Masarykovy univerzity. Vytvořené implementace jsou obsaženy v příloze. Šestou kapitolu tvoří závěr práce shrnující významné výsledky dosažené během jejího řešení. Jsou zde také navrženy možná rozšíření vyvinutých metod spolu s dalšími možnostmi, jak lze dál využít informace z provozu DNS.

4

Kapitola 2

Domain Name System Kapitola je věnována vlastnostem protokolu DNS. Krátce se zabývá jeho historií od prvních standardů až po současný stav. Následně navazuje popis principu doménových jmen společně se strukturou a implementací současné infrastruktury DNS. Hlavní část této kapitoly je zaměřena na popis samotného protokolu DNS, kde jsou představeny základní typy doménových záznamů a vyměňovaných zpráv, doplněné o popis protokolu DNS Security Extensions. Popis protokolu je doplněn sekcí obsahující informace o dostupném softwarovém řešení jak pro správu samotného DNS serveru, tak komunikaci s ním. Celá kapitola je zakončena popisem bezpečnostních hrozeb týkajících se samotné infrastruktury a protokolu DNS.

2.1

Historie

Použití jména místo fyzické adresy není pouze záležitostí moderních sítí, ale bylo používáno už od sítě ARPANET, předchůdce dnešního internetu. Překlad jmen na adresu byl realizován pomocí souboru hosts, který musel být ručně vytvořen na každém zařízení v síti. Z důvodu sjednocení názvů byl následně vytvořen hlavní soubor umístěný v Stanford Research Institute a na všechny zapojené počítače byla distribuována jeho kopie. Přestože se soubor hosts již dnes nevyužívá, je stále zachován ve všech operačních systémech, kde je možné jej použít pro ruční nastavení adresy domény. Ve chvíli, kdy se síť začala rozšiřovat a přibývalo stále více zapojených strojů, přestávalo být možné řešit překlad slovního názvu pomocí jednoho hlavního souboru. Snahy zjednodušit a standardizovat přidělování slovních názvů vedly v roce 1983 k vytvoření standardů RFC 882 [34] a RFC 883 [35]. V nich Paul Mockapetris zavádí hierarchickou strukturu doménových jmen a představuje protokol, který k překladu jmen na adresu stroje využívá takzvaný jmenný server (name server). Místo hledání doménového jména v souboru hosts je zaslán dotaz jmennému serveru, který podle uloženého záznamu odpoví adresou stroje. Na základě těchto standardů byla v roce 1984 zveřejněna první implementace jmenného serveru. Jednalo se o práci studentů Kalifornské univerzity, kteří vytvořili software The Berkeley Internet Name Domain Server (BIND) [50], fungující pod operačním systémem Unix, později portovaném i na Windows NT. Jejich práce umožnila zbudovat infrastrukturu name serverů a zavést tak DNS protokol do praxe. Software BIND je stále vyvíjen a v současnosti je světově nejrozšířenější implementací jmenného serveru. V roce 1987 byl navržený protokol DNS aktualizován v RFC 1034 [32] a RFC 1035 [33], které tvoří základy v současné době používaného protokolu. Pro správu a přidělování doménových jmen byla následně určena organizace Internet Assigned Numbers Authority (IANA), od které tuto roli v roce 1998 přebrala organizace Internet Corporation for Assigned Names and Numbers (ICANN), která se stará o přidělování jmen dodnes.

2.2

Doménová jména

Standard RFC 882 [34] zavedl nové hierarchické (stromové) členění slovního názvu stroje, které je zachováno dodnes. Toto členění rozděluje název na domény prvního řádu (Top-Level Domains – TLD), domény druhého řádu (Second-Level Domains – SLD) a další libovolný počet nižších 5

2. Domain Name System domén vzájemně oddělených tečkou. V případě domény prvního řádu mluvíme ještě o rozdělení na generickou (gTLD) a národní doménu (ccTLD). Generická doména je využívána pro stejný typ subjektů, jakými jsou například vzdělávací instituce (doména .edu) nebo informační servery (doména .info). Oproti tomu národní domény jsou tvořeny dvoupísmennou zkratkou obvykle vycházející ze standardu ISO 3166 [14]. Kompletní seznam používaných domén prvního řádu je možné naleznout na stránkách organizace ICANN [13]. Doménou druhého řádu je označován uzel na druhé úrovni hierarchického stromu DNS. Spojením doménového jména prvního, druhého a nižších řádů, ve tvaru sld.tld, vzniká takzvané doménové jméno. Přidělování doménových jmen je řízeno systémem autority a delegování, který odpovídá hierarchické struktuře DNS. V rámci tohoto systému má každý uzel přidělenou autoritu (osobu nebo organizaci), která jej spravuje a může delegovat správu na další uzly, označené doménovým jménem nižšího řádu. Primární autoritou starající se o kořen hierarchického systému (označovaném v doménovém jméně tečkou, která se běžně neuvádí), je organizace IANA. Tato organizace má na starost také domény prvního řádu, kdy v případě generických domén deleguje přidělování na akreditované registrátory, kteří prodávají a zajišťují přidělování domén druhého řádu. U národních domén je jejich administrace delegována na jednotlivé státy, které si přidělování domén druhého řádu řídí sami. Ty obvykle využívají národní centrální organizaci (u nás například CZ.NIC) akreditující lokální registrátory1 . Spojením doménového jména s názvem zařízení (hostname) vzniká takzvané plně specifikované doménové jméno (Fully Qualified Domain Name – FQDN), které přesně určuje pozici zařízení v stromové struktuře DNS. Ukázka této stromové struktury se nachází na obrázku 2.1. Na příkladu smtp1.podzona1.zona.cz, je možné vidět, že administrace domény zona.cz je delegována podle jednotlivých organizačních jednotek. V tomto případě na podzóny 1 a 2, ve kterých se nachází jednotlivá zařízení připojená do sítě adresovatelná podle hostname, v uvedeném příkladě pod jménem smtp1. V současné době je možné se setkat také s hostname označujícím nejen jméno zařízení v síti, ale i jméno služby (například ftp.domena.cz nebo www.domena.cz). Generické domény

mil

edu mit

...

com

.

net

google mail

Národní domény

docs

org ieee

us

uk

...

pl

cz

sk

amazon

zona

books

podzona1 podzona2 smtp1

Obrázek 2.1: Příklad stromové hierarchie doménových jmen.

2.3

Implementace a struktura

Implementace DNS přesně kopíruje strukturu delegování doménových jmen, popsanou v předchozí sekci. Každý uzel stromové hierarchie je reprezentován jedním nebo více DNS servery, 1. Zajímavou výjimkou je souostroví Tokelau [52], které umožňuje registrovat domény druhého řádu zadarmo, bez nutnosti registrátora.

6

2. Domain Name System které zodpovídají za uzly, které jsou hierarchicky pod nimi [2]. Hlavní součástí celé struktury jsou takzvané kořenové servery (anglicky označovány jako root servers), nacházející se na začátku celé struktury a obsahující odkazy na servery obsluhující domény prvního řádu. Kdykoliv je nějaký DNS server dotazován na doménu, o které nemá žádné informace, dotazuje se jednoho z těchto kořenových serverů. V současné době je používáno 13 kořenových serverů, reprezentovaných velkým množstvím fyzických strojů (se stejnou IP adresou) rozprostřených v síti po celém světě. Každý běžný server DNS obsahuje seznam kořenových serverů, který je distribuován spolu s DNS softwarem. Všechny kořenové servery jsou přístupné pod doménou root-servers.net a jsou pojmenovány pomocí písmen od a.root-servers.net až po m.root-servers.net. Kompletní seznam kořenových serverů s jejich umístěním je možné naleznout na adrese http://www.root-servers.org. V rámci České republiky jsou provozovány celkem 3 instance kořenových serverů (viz tabulka 2.1). Označení F J

Operátor Internet Systems Consortium, Inc. VeriSign, Inc.

L

ICANN

IPv4 adresa 192.5.5.241

IPv6 adresa 2001:500:2f::f

192.58.128.30

2001:503:C27::2:30

199.7.83.42

2001:500:3::42

Umístění Praha, stejná instance jako J Praha, stejná instance jako F Praha, jiná lokalita jako F a J

Tabulka 2.1: Instance kořenových DNS serverů v České republice [1].

Hned pod kořenovými severy DNS se v hierarchické struktuře nachází takzvané TLD servery, které zodpovídají za jednotlivé domény prvního řádu. Servery jsou, v případě ccTLD, spravovány v rámci konkrétní země, nebo společností ICANN, v případě gTLD. Tyto servery obsahují odkazy na servery obsluhující domény druhého řádu, které taktéž mají určený vlastní server DNS. Celkově překlad jména postupně prochází přes všechny servery DNS struktury až k takzvanému autoritativnímu serveru, který zná přesnou adresu stroje v síti. Příkladem může být překlad jména pc1.zona.cz znázorněný na obrázku 2.2. V případě, že klientem dotazovaný DNS server nemá o dané doméně žádné informace, jako první kontaktuje kořenový server, který odpoví odkazem na ccTLD server. Dotazovaný server následně kontaktuje odkazovaný ccTLD server, který jej dál odkáže na server zodpovědný za doménu zona.cz. Tento server má již ve svých záznamech IP adresu stroje pc1 a odpovídá takzvanou autoritativní odpovědí, ve které sděluje konkrétní IP adresu stroje pro dotazovanou doménu.

(1)

(2) Dotazovaný DNS (3)

Dotaz: pc1.zona.cz Odkaz na .cz ccTLD DNS Dotaz: pc1.zona.cz Odkaz na zona.cz DNS Dotaz: pc1.zona.cz Autoritativní odpověď

Kořenový DNS ccTLD DNS Autoritativní DNS pro zona.cz

Obrázek 2.2: Hierarchie DNS serverů při překladu adresy pc1.zona.cz.

7

2. Domain Name System

2.4

Protokol DNS

Protokol DNS primárně obsahuje dvě části: dotaz a odpověď. Jelikož dotazující nezná přesnou adresu autoritativního serveru, musí být postupně dotazována celá hierarchická struktura. Dotazovat se takto na každou doménu je ale časově náročné a dochází k zbytečnému zatěžování serverů a kapacity sítě. Z toho důvodu celý systém DNS využívá tzv. cache neboli vyrovnávací paměť, kam ukládá obdržené odpovědi tak, aby se nemusely provádět další dotazy a byla vrácena přímo odpověď. Celý systém překladu domény zadané do webového prohlížeče typického domácího uživatele je znázorněn na obrázku 2.3. DSL modem/router

Poskytovatel připojení

DNS Proxy (cache) (3)

DNS resolver (cache) (4)

DNS (5) kořenový server DNS (6) TLD server

Počítač Prohlížeč (cache) (1)

Hierarchie DNS

Resolver (cache) (2)

DNS (7) server domény

Obrázek 2.3: Schéma DNS systému [2].

Pokud uživatel zadá do prohlížeče nějakou adresu, jako první je prohledána vyrovnávací paměť samotného prohlížeče (1), která může mít uloženou IP adresu domény [2]. V případě, že prohlížeč nemá uloženou žádnou informaci, volá systémovou knihovnu zvanou resolver (2). Ta jako první opět prohledá svoji dočasnou paměť a v případě, že záznam nemá uložen, vytváří DNS dotaz, který podle nastavení posílá buď lokálnímu serveru DNS (3), nebo serveru poskytovatele připojení (4). Lokální server DNS je využíván v sítích organizací, kde slouží jak k překladu jmen v lokální síti, tak k překladu doménových jmen (jako takzvaný cache server). Lokální cache DNS server slouží jako proxy komunikující s DNS serverem poskytovatele připojení. Dotazovaný server DNS může fungovat dvěma rozdílnými způsoby. Prvním z nich je takzvaný rekurzivní, kde dotaz probíhá tak, jak je znázorněn na obrázku 2.3. V tomto případě je v rámci odpovědi resolveru vrácena přímo IP adresa dotazovaného stroje a o překlad se stará dotazovaný server DNS, který postupně kontaktuje všechny servery hierarchické struktury. Druhým způsobem je nerekurzivní neboli iterativní překlad, kde dotazovaný server DNS odpoví odkazem na první server v rámci hierarchické struktury. Tento odkaz zpracovává resolver, který sám kontaktuje odkazovaný server DNS a projde dále zbytek hierarchické struktury. Resolver po získání IP adresy dotazované domény vrací prohlížeči tuto IP a ukládá získané informace do vyrovnávací paměti. Jelikož je zasíláno velké množství nezávislých dat, je k přenosu využíván primárně protokol UDP. Ten díky tomu, že není potřeba navazovat spojení jako v případě TCP, umožňuje větší rychlost samotného překladu. Nevýhodou komunikace přes UDP jsou možné chyby způsobení ztrátou nebo poškozením paketu. Velikost UDP paketu může být v případě IPv4 až 65 535 bytů (IPv6 dovoluje použití větších). Takto velké pakety ale obvykle neumí obsloužit další síťové prvky, jakými jsou například směrovače, což vede k jejich fragmentaci. Samotné DNS servery mají obvykle nastavenou maximální velikost odesílaného UDP paketu. Například Microsoft DNS server má jako základní hodnotu nastaveno 1280 bytů, software BIND má v základu nastaveno 4096 bytů. V případě, že je tato velikost překročena, server DNS zasílá informaci o překročení velikosti paketu a klient iniciuje TCP spojení. Druhým příkladem, kdy DNS využívá TCP spo8

2. Domain Name System jení, je přenos zónového souboru (při transferu zóny na jiný server DNS), kde jsou případné chyby přenosu nežádoucí. 2.4.1 Záznamy Základní složkou překladu DNS jsou zónové soubory (Zone Files), které jsou uloženy na autoritativním serveru dané domény. Tyto soubory slouží k popisu nebo překladu domény na jednotlivé charakteristiky, zařízení a služby, které doména obsahuje. Začátek zónového souboru obsahuje hodnoty $TTL a $ORIGIN. Proměnná $TTL (Time To Live) udává implicitní hodnotu pro všechny záznamy v zónovém souboru. Hodnota TTL je pak využívána při ukládání do vyrovnávací paměti, kde značí platnost záznamu v sekundách. Po jejím vypršení server záznam smaže a pokud je na něj opět dotazován, tak jej znova musí získat. Druhá hodnota $ORIGIN definuje název domény, pro kterou daný zónový soubor platí. Jednotlivé záznamy jsou rozděleny do takzvaných zdrojových záznamů (resource records – RR), na které se lze dotazovat a získat tak jednotlivé informace o doméně. Každý RR záznam obsahuje název domény, TTL záznamu, třídu (obvykle IN, značící internet), typ záznamu a samotnou hodnotu. V zónovém souboru se může nacházet velké množství typů záznamů, následující výčet uvádí pouze hlavní z nich [2]: ∙

SOA (Start Of Authority) – Záznam definující klíčové charakteristiky dané zóny nebo domény. V Zone File musí být uveden právě jednou a slouží jako jeho „hlavička“. Ze všech záznamů je tento nejkomplexnější a obsahuje nejvíce parametrů: –

name – Kořenové jméno zóny (například zona.cz.), často je nahrazeno znakem @, který slouží jako substituce za $ORIGIN.

–

ttl – Udává TTL pro daný SOA záznam. Pokud není nastaveno, použije se výchozí.

–

class – Třída záznamu, obvykle nastaveno na IN.

–

name-server – Udává název hlavního name serveru pro danou doménu.

–

e-mail – Obsahuje e-mailovou adresu na správce domény. Jelikož je znak @ využíván pro jiné účely, je nahrazován tečkou (například [email protected] se uvede jako admin.zona.cz.).

–

sn – Udává sériové číslo záznamu, které se navýší při každé jeho změně. Využívá se hlavně při sdílení zónového souboru s dalšími (sekundárními) DNS servery.

–

refresh – Hodnota v sekundách po jejímž uplynutí si sekundární DNS server kontroluje aktuálnost záznamu podle hodnoty sn.

–

retry – Definuje čas, po kterém má sekundární DNS server znovu dotazovat sn, v případě že nedostal odpověď.

–

expiry – Pokud sekundární DNS server nezíská sn a vyprší hodnota expiry, pak považuje záznam zóny za neplatný.

–

nx – Udává počet sekund, po kterých si má resolver držet informaci o neexistenci doménového záznamu.

∙

NS – Záznam obsahuje odkaz na jméno autoritativního serveru pro danou doménu. Udáváno je vždy jméno ve formátu FQDN, nikoliv IP adresa. V zónovém souboru se musí nacházet nejméně jeden NS záznam, obvykle jsou ale uváděny dva a více, sloužící jako záložní (sekundární) servery.

∙

MX – Tento typ záznamu uvádí název poštovního serveru pro danou doménu. Před tímto názvem je ještě uváděna priorita, což je číslo značící, který poštovní server se má použít 9

2. Domain Name System v případě, že jich je uvedeno více. Dotazující postupně prochází všechny zmíněné poštovní servery podle priority, dokud jej některý z nich neobslouží. ∙

A, AAAA – Jedná se o jeden z hlavních záznamů v zónovém souboru, obsahující IP adresy dotazovaného hosta. V případě záznamu A se jedná o IPv4 adresu a v případě AAAA o IPv6 adresu. U tohoto typu záznamu není obvykle uváděno celé doménové jméno (například stroj1.zona.cz), ale pouze jeho jméno v rámci domény (stroj1).

∙

CNAME – Tento záznam sloučí k přidělení aliasu jinému doménovému jménu. To je využíváno při rozsáhlých zónových souborech, kdy se na jedné IP adrese nachází více služeb. Není tak nutné upravovat každý záznam.

∙

PTR – Tento typ záznamů, obvykle označovaný jako reverzní, je využíván pro zpětný překlad IP adres na doménové jméno. Obvykle jsou uloženy v takzvaném reverzním zónovém souboru. Tyto záznamy jsou využívány pro dohledání původu dané IP adresy.

∙

TXT – Hodnota tohoto záznamu je libovolný textový řetězec, který je přiřazený danému jménu.

Následující příklad uvádí ukázku zónového souboru pro doménu zona.cz, obsahující některé zmíněné typy záznamů: ; fragment from example - does not use substitution $TTL 2d ; default TTL for zone $ORIGIN zona.cz. ; Start of Authority record defining the key characteristics @ IN SOA ns1.zona.cz. admin.zona.cz. ( 2003080800 ; sn = serial number 12h ; ref = refresh 15m ; ret = refresh retry 3w ; ex = expiry 2h ; nx = nxdomain ttl ) ; name servers Resource Records for the domain zona.cz. 18000 IN NS ns1.zona.cz. zona.cz. 18000 IN NS ns2.zona.cz. ; mail server Resource Records for the zone (domain) zona.cz. 28800 IN MX 20 smtp1.zona.cz. zona.cz. 28800 IN MX 30 smtp2.zona.cz. ; host RR ns1 IN A 192.168.254.2 ns2 IN A 192.168.254.3 smtp1 IN A 192.168.254.4 smtp2 IN A 192.168.254.5 pc1 IN A 192.168.254.6 ; alias www.zona.cz to zona.cz www IN CNAME zona.cz. 2.4.2 Formát zpráv Všechny zprávy, které jsou využívány v rámci DNS komunikace, sdílí stejný formát paketu rozdělený do pěti sekcí: hlavička (header), dotaz (question), odpověď (answer), autorita (authority) a dodatečné informace (additional) [33]. 10

2. Domain Name System ∙

Hlavička – Sekce s hlavičkou je v paketu vždy přítomna a slouží ke specifikaci, které ze zbylých sekcí a v jakém množství jsou dále obsaženy a zda se jedná o dotaz, odpověď nebo nějaký jiný požadavek. Struktura hlavičky je znázorněna na obrázku 2.4 a obsahuje následující informace [33, 2]: –

ID – Jednoznačný identifikátor, vytvořený resolverem tak, aby bylo možné jednoduše spárovat dotaz s odpovědí.

–

QR – Bit specifikující, zda paket je dotaz (hodnota 0) nebo odpověď (hodnota 1).

–

OPCODE – Slouží ke specifikaci druhu dotazu (standardní, inverzní nebo na status serveru).

–

AA – Informace, zda se jedná o autoritativní odpověď.

–

TC – Značí, zda zpráva byla z důvodu velikosti rozdělena do více menších zpráv.

–

RD – Určení, jestli má server (pokud to umožňuje) provádět rekurzivní překlad.

–

RA – Označuje, jestli server má povolen rekurzivní překlad.

–

Z – Rezervováno pro budoucí použití. Musí být nastaveno na hodnotu 0.

–

AD – Používaný u DNSSEC (viz sekce 2.4.3), kde značí, zda byla data autentizována.

–

CD – Opět používaný u DNSSEC. Pokud je nastaven, tak veškeré kryptografické úkony provádí dotazující se resolver.

–

RCODE – Kód odpovědi: 0 = bez chyby, 1 = chyba formátu, 2 = chyba serveru, 3 = chyba jména (doména neexistuje), 4 = server nepodporuje daný druh dotazu, 5 = operace zamítnuta, ...

–

QDCOUNT, ANSCOUNT, NSCOUNT, ARCOUNT – Počet záznamů v jednotlivých sekcích. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA|Z |AD|CD| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Obrázek 2.4: Formát hlavičky DNS zprávy [33].

∙

Dotaz – V této sekci se nachází samotný dotaz, složený z dále popsaných tří částí. V případě, že je dotazováno více domén naráz, jsou tyto domény rozděleny do jednotlivých po sobě jdoucích sekcí. –

QNAME – Část obsahující dotazovanou doménu. 11


∙

–

QTYPE – Specifikace jaký typ záznamu je požadován. V případě, že je dotazován typ ANY, jsou vráceny všechny záznamy týkající se dané domény.

–

QCLASS – Nastavení třídy dotazu. Obvykle nastaveno na IN, značící internet.

Odpověď, autorita a dodatečné informace – Zbylé sekce se skládají z proměnného počtu zdrojových záznamů, jejichž počet je definován v hlavičce. Záznam obsahuje všechny následující informace: –

NAME – Doménové jméno kterého se záznam týká.

–

TYPE – Typ zdrojového záznamu, specifikujícího význam dat v sekci RDATA.

–

CLASS – Specifikace třídy dat v sekci RDATA.

–

TTL – 32 bitové číslo, určující, jak dlouho má být daný záznam uchováván ve vyrovnávací paměti.

–

RDLENGTH – Délka položky RDATA.

–

RDATA – Popis záznamu ve formátu specifikovaném položkami TYPE a CLASS. V případě, že typ dotazu je A a třída IN, pak tato položka obsahuje IPv4 adresu.

2.4.3 DNS Security Extensions Služba DNS ve svém základu neposkytuje žádnou úroveň zabezpečení. Potencionálnímu útočníkovi se tak otvírají rozličné možnosti, jak tuto službu použít k nekalým účelům, například narušením komunikace a zfalšováním údajů. Tím, že útočník změní údaje o doménových jménech, ovlivní fungování dalších internetových služeb, které může tímto zásahem zneužít [58]. Útočník pak může například pomocí falešných webových stránek získávat hesla, přístupové kódy či údaje o platebních kartách, obcházet antispamovou kontrolu nebo podvrhnout zprávy a informace na webových stránkách. Přičemž uživatel nemusí vůbec poznat, že se nachází na podvržené stránce. Detailnější popis a další příklady útoků je možné naleznout v sekci 2.6. 199.7.83.42

Zóna .: DS n550f30618be204e SIG 31088aa325d9c403 Klíč pro .: xd253c5f92441741 (Private) yd6ea4256ad4b6a5 (Public)

= Lokální DNS

a.ns.nic.cz

Zóna .cz: DS f98ab356c89100bc SIG d2a5e5bde52361e5 Klíč pro .cz: m61ac25e5febf351 (Private) n550f30618be204e (Public)

Root: 199.7.83.42 y46ea4256ad4b6a

= zona.cz

Zóna .zona.cz: A 192.168.254.2 SIG 762bc9d63e02aab9 Klíč pro .zona.cz: cb987aaa39410bfe (Private) f98ab356c89100bc (Public)

Obrázek 2.5: Schéma řetězce klíčů DNSSEC (původní obrázek převzat z [58]). Jako řešení problému bezpečnosti DNS bylo v RFC 2535 [11] navrženo rozšíření DNS Security Extensions (DNSSEC), které k protokolu přidává kontrolu údajů pomocí asymetrické kryptografie. V případě používání DNSSEC si držitel domény musí vygenerovat dvojici klíčů, kde 12

2. Domain Name System soukromým klíčem podepíše údaje, které vkládá do souboru zóny [58]. Tento podpis je následně možné ověřit pomocí veřejného klíče publikovaného držitelem domény u nadřazené autority (registrátor TLD). Tato autorita má opět pro své záznamy vygenerovanou dvojici klíčů a veřejný klíč je publikovaný v kořenových serverech DNS. Je tak vytvořen řetězec, zajišťující, v případě ověření podpisů, důvěryhodnost obdržených záznamů. Na obrázku 2.5 je znázorněno schéma řetězce klíčů, zajišťující důvěryhodnost získaných dat. Jak je z popisu znát, vyšší bezpečnost s sebou přináší výrazně vyšší režii při práci s DNS a při samotném vytváření nových záznamů. Z tohoto důvodu není dodnes DNSSEC široce rozšířen, přestože ho již podporuje většina serverů DNS.

2.5

Software

Pro práci se systémem DNS existuje velké množství nástrojů, které umožňují jeho monitorování, správu a testování. V první části této sekce jsou představena dvě základní softwarová řešení pro správu DNS serveru. Následující druhá část popisuje používané nástroje pro diagnostiku a práci s DNS. 2.5.1 Správa serveru V současné době existuje velké množství implementací umožňujících provoz DNS serveru. Mezi nejrozšířenější z nich patří BIND, původně vytvořený na University of California v Berkeley. Dalším příkladem je pak Microsoft DNS, který nachází užití hlavně ve firemních sítích. BIND Software BIND patří mezi nejrozšířenější implementace DNS na internetu a na linuxových serverech tvoří téměř standard. Jelikož BIND byl také historicky první implementací DNS, slouží také jako referenční implementace DNS, se kterou je porovnáván veškerý další DNS software [2]. Díky své otevřenosti a rychlosti je využíván hlavně na serverech, které obsluhují kořenové a TLD domény. Většina poskytovatelů internetového připojení jej také používá a díky tomu, že je poskytován zdarma (BSD licence), je nasazován i ve firemních sítích. Samotný software spolu s dalšími informacemi je možné naleznout na webové stránce výrobce [9]. Microsoft DNS Společnost Microsoft je v současné době největším výrobcem desktopových operačních systému. Její zaměření však není pouze na desktopy, ale i na jejich jednoduchou správu, pomocí Windows Serveru. Windows Server je využíván primárně ve firemních a menších sítích, kde slouží pro obsluhu většiny síťových služeb (DHCP, FTP, web, ...). Mezi jednu z jeho funkcionalit patří také implementace serveru DNS. Oproti základní instalaci BIND nabízí řešení od společnosti Microsoft jednoduché a uživatelsky přívětivé rozhraní, které je jednoduše konfigurovatelné, viz obrázek 2.6. Bližší informace s návody je možné naleznout na adrese společnosti Microsoft [31]. Knot DNS V České republice je organizací CZ.NIC vyvíjen další příklad softwaru pro servery DNS. Software Knot DNS je primárně určený pro autoritativní servery, kde jsou kladeny velké nároky na výpočetní rychlost. Důvodem jeho vývoje je snaha rozšířit opensourcové implementace vhodné pro TLD servery, za účelem zvýšení bezpečnosti, stability a odolnosti infrastruktury DNS. Bližší informace je možné naleznout na domovské stránce projektu [59]. 2.5.2 Nástroje pro práci s DNS Jelikož je systém DNS vcelku komplikovaný, je někdy obtížné nalézt chybu, která může vzniknout lokálně nebo kdekoliv při získávání odpovědi. Následující programy slouží pro různé formy dotazování a práci s DNS servery a k získávání informací o doméně a IP adresách v ní. 13


Obrázek 2.6: Vytvoření nového záznamu pro doménu zona.cz v Microsoft DNS

dig Program dig, je součástí softwarového řešení BIND a slouží k dotazování serverů DNS. Program se ovládá z příkazové řádky a poskytuje široké možnosti nastavení dotazu. Implementace je volně dostupná jak pro MS Windows, tak pro unixové systémy, kde je rozšířenější. Program umožňuje nastavit téměř všechny možné parametry dotazu, od dotazované domény, typ dotazu až po nastavení požadované velikosti UDP paketu. Kompletní dokumentaci programu je možné naleznou na jeho manuálové stránce. Následující volání programu představuje základní příkazy programu: # Získání IPv4 adresy stroje pc1.zona.cz od DNS serveru # na adrese 10.10.10.1 dig pc1.zona.cz @10.10.10.1 A # Výpis všech informaci platných pro doménové jméno zona.cz # s nastavením maximální velikosti UDP paketu a vynucením DNSSEC dig zona.cz @10.10.10.1 ANY +bufsize=65535 +dnssec # Získání PTR záznamu pro danou IP dig -x 192.168.254.2 @10.10.10.1 nslookup Program byl vytvořen jako odlehčená verze programu dig. Tento nástroj nenabízí tak široké možnosti nastavení, ale díky své jednoduchosti a univerzálnosti je rozšířen v operačních systémech MS Windows. Program je možné ovládat buď interaktivně, zadáváním příkazu nebo přes parametry v příkazové řádce. Návod na jeho použití je možné naleznout na adrese http:// support.microsoft.com/default.aspx?scid=kb;en-us;200525. Ukázka základních příkazů programu: # Výpis MX záznamů pro doménové jméno zona.cz nslookup -type=MX zona.cz # Výpis všech informaci pro doménu zona.cz od serveru 10.10.10.1 nslookup -type=any zona.cz 10.10.10.1 14

2. Domain Name System host Jedná se o jednoduchý unixový nástroj pro překlad doménového jména na adresu a naopak s velmi základními možnostmi nastavení. Ukázka volání: # Získání IP adresy stroje pc1.zona.cz host pc1.zona.cz whois Nástroj whois slouží k vyhledávání v databázi, ukládající informace o majitelích internetových domén. Z výpisu je možné získat informace o vlastníkovi, kontaktech, kam lze hlásit možné zneužití a podobné. Zkrácená ukázka whois záznamu pro doménu muni.cz: domain: registrant: registrar: registered: changed: expire:

muni.cz SB:LM9-RIPE_XX REG-GENREG 25.08.1995 02:00:00 22.11.2010 14:30:53 27.10.2014

contact: org: address: address: address: address: e-mail:

SB:LM9-RIPE_XX Masaryk University UVT, Botanicka 68a Brno 602 00 CZ [email protected]

nsset: nserver: nserver:

NSS:MUNI-UVT:4 ns.muni.cz (147.251.4.33) ns2.muni.cz (147.251.6.10)

2.5.3 Online dostupné nástroje Kromě již zmíněných nástrojů použitelných z příkazové řádky existují i jejich webové obdoby. Tato řešení mají výhodu ve chvílích, kdy je potřeba vyzkoušet nastavení DNS serveru z prostředí mimo lokální síť. Následující výčet uvádí pouze některé z velkého množství dostupných nástrojů: DNSstuff Stránky nabízí nástroje pro vyhledání záznamů o doméně a spoustu dalších nástrojů, které se zaměřují na všechny služby internetu. Domovská stránka: http://www.dnsstuff. com/tools. Dig web interface Jak již z názvu napovídá, jedná se o stránky umožňující spustit vzdáleně program dig a analyzovat nastavení serveru DNS z venkovní sítě. Domovská stránka: http: //digwebinterface.com/. Open resolver test Stránky věnující se různým oblastem problematiky DNS. Online například nabízí nástroj, k ověření, zda je server DNS nastavený tak, aby odpovídal a vyhodnocoval dotazy (na jiné domény, než ve které se nachází) z venkovní sítě. Domovská stránka: http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl/.

2.6

Bezpečnost DNS

Infrastruktura DNS je dnes nedílnou součástí internetu a počítačových sítí. Servery obsluhují velké množství klientů a určují, na jakou IP adresu se dané doménové jméno přeloží. Z pohledu 15

2. Domain Name System potencionálního útočníka tak DNS představuje ideální cíl útoku, kdy může přesměrovat uživatele na jinou IP adresu nebo znemožnit překlad jmen a ztížit přístup na internetové služby. Správné nastavení a zabezpečení infrastruktury DNS tak dnes hraje velmi důležitou roli. Následující sekce jsou věnovány příkladům možných zranitelností, následkům jejich zneužití a možnostem obrany, jak ze strany uživatele tak ze strany správce DNS.

2.6.1 Odmítnutí služby Útok typu odmítnutí služby (Denial of Service, dále DoS) představuje jeden z útoků, na který je náchylná většina internetových služeb. DoS je technika útoku, kdy je stroj v síti zahlcen, případně překonfigurován tak, že nedokáže obsloužit legitimní požadavky jeho uživatelů. V případě DNS serveru uživatel neobdrží odpovědi a není tak schopný přeložit doménové jméno na IP adresu. Pokud je odstaven některý autoritativní server, je výrazně omezen přístup k službám zóny, kterou obsluhuje. Jestliže je naopak napaden některý DNS resolver, není užívání internetu nijak výrazně ovlivněno neboť v rámci nastavení zařízení v síti, bývá nastaven ještě druhý, záložní server DNS. Pokud se ale útočníkovi podaří takto odstavit více serverů DNS, je uživatelům výrazně zkomplikováno užívání všech síťových služeb. Útočníci často využívají takzvané distribuované formy útoku (DDoS), kdy je daný provoz generován na více strojích zároveň a je tak dosaženo většího zahlcení. Příkladem takto rozsáhlého útoku a jeho dopadu je masivní DDoS útok na Estonsko v roce 2007 [51]. V rámci tohoto útoky bylo cíleno nejen na webové stránky vládních organizací, ale i na samotnou infrastrukturu sítě a převážně na hlavní DNS servery. Obyvatelé Estonska tak měli téměř 14 dní výrazně omezený přístup na Internet. Možností jak způsobit odmítnutí služby má útočník hned několik. Obecně je lze rozdělit na dva způsoby: zahlcení provozu nebo napadení samotného stroje. V případě zahlcení je útočníkem vygenerován objemný provoz, buď TCP SYN paketů, které způsobí zaplnění TCP/IP zásobníku, nebo velkých UDP paketů. V případě útoku pomocí TCP SYN paketů není možné navázat se strojem TCP spojení, které je využíváno například pro přenos zónových souborů mezi servery. V případě UDP paketů je výrazně přetížena linka, kterou je server připojen, což způsobí zahazování legitimních dotazů, které se tak nedostanou k serveru DNS. V případě, že je server DNS využíván také pro jiné typy služeb, například web, může útočník zahltit i tyto služby, například komplikovanými dotazy na databázi. Výsledkem pak je výrazné omezení výpočetního výkonu potřebného k překladu doménových jmen. Druhou možností, jakou útočník může způsobit odmítnutí služby, je napadení samotného serveru DNS. Výsledkem je například vynucené vypnutí nebo restart, případně změna konfigurace tak, že server přestane obsluhovat DNS dotazy. Útočníci mohou využít zranitelnost přetečení zásobníku v operačním systému nebo jakémkoliv nainstalovaném software, což jim umožní spuštění příkazu nebo nahrání škodlivého software. Útočník tak získá přístup k systému serveru a může způsobit jeho odstavení, případně i kompletní smazání. Další možností je zaslání špatně formátovaného paketu, který software neumí zpracovat a dojde k jeho pádu (viz například zranitelnost serveru NSD [48]). Během opravy je následně DNS server nedostupný a dotazy nejsou obsluhovány. Obrana před útoky typu odmítnutí služby je obecně komplikovaná a vyžaduje navýšení kapacit přípojných linek a výpočetního výkonu zařízení. V případě DNS je ovšem řešení částečně jednodušší, neboť aby byl útok úspěšný, musí útočník odstavit více serverů najednou. Jako nejvhodnější řešení je tedy použití více záložních DNS severů. Takovéto servery mohou být adresovány pomocí anycast adresy, díky čemuž uživatel nemusí ani vědět o těchto zálohách. Tento mechanismus je využíván například všemi kořenovými DNS servery. Dále je také vhodné udržovat software serveru DNS aktualizovaný, aby nebylo možné využít jeho známé zranitelnosti. Z pohledu uživatele je možné v případě, že nejsou obsluhovány jeho DNS dotazy, využít některý z veřejných serverů DNS např. OpenDNS [38] nebo Google [17]. 16

2. Domain Name System 2.6.2 Změna konfigurace DNS Útok, při kterém útočník změní konfiguraci serveru DNS, představuje velké riziko, neboť odhalení takovéto změny je často velmi obtížné. Pro změnu konfigurace potřebuje útočník získat přístup k samotnému serveru DNS. Tento přístup lze získat obvykle pomocí chyb v instalovaném software, díky kterým může útočník nainstalovat škodlivý software, případě získat vzdálený přístup s administrátorskými právy. S takto získanými právy již útočník může měnit konfiguraci zónových souborů nebo samotné nastavení serveru DNS. V případě přístupu k zónovému souboru získává útočník kompletní moc nad doménou, spadající pod daný zónový soubor. Je tak možné vymazat všechny záznamy pro danou doménu, díky čemuž uživatelé nebudou moci přistoupit na danou doménu. Druhou možností je přesměrování domény na jinou IP adresu. Pod touto adresou může být například webová stránka obsahující pohoršující materiály, které mohou poškodit dobré jméno vlastníka domény. Druhým důvodem změny IP je přesměrování domény na falešnou stránku, která slouží pro sběr přihlašovacích údajů a dalších informací zákazníků služeb dané domény. Změnu IP adresy v MX záznamu je také možné využít k přesměrování e-mailové komunikace na stroje útočníka. Jestliže útočník získá administrátorský přístup k serveru DNS, může kromě zónových souborů měnit i jeho nastavení. Taková změna nastavení je často využívána například pro tzv. amplifikační útoky (viz sekce 4.2.2). Útočník server nastaví tak, aby umožňoval překlad rekurzivních dotazů i pro klienty mimo lokální síť. Díky tomu bude možné tento server využít k amplifikačním útokům pomocí podvržených IP adres. Další z možností je povolení přenosu zónových souborů na jakýkoliv server. Díky tomu útočník získá přehled o všech strojích a službách, které pod danou doménu spadají. Tuto znalost může útočník využít k dalším, již cíleným útokům. Aby útočník nezískal přístup k serveru, je potřeba udržovat software serveru DNS aktuální a zajistit bezpečnost pomocí antivirových řešení, firewallů a dalších bezpečnostních nástrojů. Mělo by taky platit, že služba DNS by měla být provozována na samostatném serveru, který neobsluhuje žádné další služby, potencionálně zneužitelné k průniku. Z pohledu uživatele je velmi obtížné útok přesměrování domény detekovat. V případě změny IP adresy se uživateli v prohlížeči ukazuje správná doména, tudíž není možné jednoduše poznat, že se nachází například na podvržené stránce. První možností jak potencionální útok detekovat je využití protokolu DNSSEC, který na základě nesprávného podpisu upozorní uživatele. Z hlediska poskytovatele je nutné, aby podpisy byly generovány mimo server DNS, což nemusí být vždy dodrženo. Jedinou obranou je tedy využití autentizace webových služeb pomocí SSL certifikátů. Pokud je uživatel na podvržené stránce, prohlížeč by jej měl informovat, že certifikát serveru je neplatný. Tato obrana je ale možná pouze u služeb majících svůj certifikát. V případě že spojení není autentizováno, nemá uživatel žádnou možnost obrany. 2.6.3 Zneužití vyrovnávací paměti DNS Vyrovnávací paměť DNS je široce využívána v infrastruktuře DNS. Díky ní je možné urychlit překlad jmen, jelikož není nutné dotazovat se autoritativního DNS serveru, pokud je ve vyrovnávací paměti uložena aktuální odpověď. Problém ale tvoří použití protokolu UDP, který umožňuje podvrhnutí odpovědí. Jelikož není v rámci UDP přenosu ustanoveno žádné spojení, může útočník, pokud zná cílový port, zdrojovou IP adresu a DNS ID dotazu, vytvořit vlastní upravený paket odpovědi. Díky použití vyrovnávací paměti DNS je tato odpověď uložena a pokud se další klient dotazuje na danou doménu, je mu vrácena tato podvržená odpověď. Lze tak úspěšně přesměrovat všechny klienty využívající daný DNS cache resolver. Obecně lze rozlišit dva druhy útoků na vyrovnávací paměť serveru DNS. Prvním z nich je případ, kdy se útočník vloží do komunikace mezi resolverem a dotazovaným serverem. V případě, že útočník dokáže doručit odpověď dříve jak DNS server, bude tato odpověď brána jako správná a následně uložena. Podmínkou je, že odpověď útočníka, musí mít nastavený stejný cílový port, 17

2. Domain Name System zdrojovou IP adresu a identifikační číslo dotaz (dále ID) tak, aby tato odpověď byla brána jako legitimní. Aby útočníkova falešná odpověď byla doručena dříve než správná odpověď serveru DNS, má útočník více možností. První z nich je zajistit, aby se dotaz nedostal k serveru DNS jeho odstavením, případně přesměrováním dotazu. Další možností je vyčkávat na dotaz a spoléhat na to, že odpověď dorazí dříve. Třetí možností je generování velkého množství odpovědí s různými porty a ID dotazu a spoléhání se na to, že za určitý čas bude, díky narozeninovému paradoxu, kombinace správná. Druhý způsob útoku na vyrovnávací paměť DNS serveru představil Kaminsky [25]. V tomto případě útočník nečeká, až se DNS resolver bude dotazovat na danou doménu, ale vynutí takový dotaz sám. Schéma tohoto útoku je uvedeno na následujícím obrázku 2.7. V případě, že chce útočník přesměrovat například doménu zona.cz, vytváří specifické dotazy na domény třetího řádu, u kterých je pravděpodobné, že je server DNS nemá uloženy v lokální paměti. Příkladem je doména bg89.zona.cz, která pro doménu druhého řádu neexistuje a DNS resolver ji tak velmi pravděpodobně nemá uloženou. Dotaz na tuto doménu tedy způsobí, že se server DNS začne dotazovat na doménu druhého řádu. Útočník spolu s dotazy na domény třetího řádu generuje podvrhnuté odpovědi s IP adresou serveru DNS registrátora domény. Tyto odpovědi obsahují vždy různý port a ID. Díky velkému množství dotazů je vysoce pravděpodobné, že jednou se útočníkovi podaří danou kombinaci ID a portu „trefit“, a do vyrovnávací paměti resolveru tak bude uložena podvržená informace. Tato chyba využívala vlastnosti nedostatečné náhodnosti portů a ID dotazů, díky čemuž se pravděpodobnost vygenerování správné odpovědi výrazně zvyšovala.

(4

) ID

19 96: 2.1 O 68 dka ) .25 z n Do 4.2 a taz zo na bg .cz 89 .zo na .cz

ccTLD DNS

(1)

Útočník

(3)

(2

) (5

Dotaz bg89.zona.cz

...

ID 96: Odkaz na zona.cz 6.6.6.6 ID 1: Odkaz na zona.cz 6.6.6.6

w taz Do d ) O (6

zo w.

.cz

na

w

Útočník 6.6.6.6

6 .6.

.6 ď6

vě

po

(7) Dotaz www.zona.cz (8)

DNS resolver

Odpověď 6.6.6.6

Oběť

Obrázek 2.7: Schématické znázornění Kaminskeho útoku.

Správci serverů DNS mají několik možností obrany před útokem zacíleným na vyrovnávací paměť resolveru. První z nich je zavedení protokolu DNSSEC, díky čemuž bude každá odpověď autentizována, a každá nesprávná odpověď zahozena. V případě, že není možné zavést podporu DNSSEC, je důležité mít aktualizovaný DNS software. Po zveřejnění Kaminskyho útoku byly vydány aktualizace softwaru serverů DNS, které opravují náhodnost generování zdrojového portu a ID dotazu. Uživatel má při tomto typu útoku opět dvě hlavní možnosti obrany. První tvoří použití protokolu DNSSEC, druhou je opět validace SSL certifikátů. Jak ale zmiňuje Kaminsky, použití SSL certifikátů uživateli nemusí dávat plnou jistotu. 18

2. Domain Name System 2.6.4 Přesměrování provozu DNS Přesměrování provozu DNS na jiný server je velmi podobné útokům zneužívajícím vyrovnávací paměť. Rozdílem je, že nejsou upraveny pouze některé domény, ale celý provoz je přesměrován na útočníkův server DNS. Díky tomuto přesměrování vidí veškeré dotazy, které klienti vytváří. Může také změnit odpověď na jakýkoliv dotaz a přesměrovat tak uživatele na podvodný web. V tomto případě útoku je možné způsob jeho provedení rozčlenit na tři způsoby. Prvním je vytvoření falešného serveru DNS v lokální síti a přesměrování provozu na tento falešný server. K samotnému přesměrování může útočník využít buď podvržení odpovědi ARP, případně DHCP, kdy v DHCP odpovědi nastaví jako server DNS svůj falešný server. Tento způsob útoku ale vyžaduje přímý přístup do lokální sítě, který pro útočníka může být komplikovaný. Druhým způsobem je napadnutí zařízení samotného klienta, kdy je na zařízení nainstalován škodlivý software. Tento škodlivý software po své instalaci může buď upravit soubor hosts a přesměrovat definované domény nebo může změnit nastavení primárního serveru DNS. Změnou nastavení serveru DNS získá útočník plnou moc nad DNS dotazy klienta na které může vracet jakékoliv odpovědi. Příkladem takovéhoto útoku byl široce rozšířený škodlivý software DNSChanger [37]. Třetím způsobem je napadení síťových zařízení, například směrovače a podobné, které umožní přesměrovat provoz DNS na útočníkův DNS server. Tento typ útoku se příliš netýká správců samotných serverů DNS, ale spíše správců lokální sítě. Aby útočník nemohl v rámci lokální sítě spustit vlastní server DNS, je třeba lokální síť zabezpečit například pomocí systému odhalení průniku (IDS) a omezit přístup k lokální síti. Z pohledu klientů je velmi důležité mít aktualizovaný software spolu s antivirovým řešením. Vhodné je také kontrolovat platnost a přítomnost SSL certifikátů, při vstupu na webové stránky.

2.6.5 Ostatní zranitelnosti Kromě zmíněných útoků existují ještě další zranitelnosti a nebezpečí, které nelze do žádné z výše uvedených kategorií zařadit. Prvním příkladem takovéto zranitelnosti je prozrazování příliš mnoho informací o vnitřní infrastruktuře v rámci doménových záznamů. Takovou informací může být např. uvedené jméno verze software serveru uložené v TXT záznamu domény. Kromě TXT záznamů může útočník využít také dotazu ANY, který může prozradit všechny služby provozované pod danou doménou. Na základě těchto informací může útočník lépe zacílit svůj útok na konkrétní služby a být úspěšnější. Druhým příkladem je útok přes registrátora domény. Útočník v tomto případě může napadnout samotný server DNS registrátora. Tyto servery ale obvykle bývají aktualizovány a dobře zabezpečeny. Vhodnou možností je tedy napadení webové aplikace registrátora. Útočník může využít zranitelnost samotného webu a získat tak přístup k databázi a dalším souborům, které mu umožní změnit IP adresu přidělenou dané doméně. Případně se může pokusit získat přihlašovací údaje vlastníka domény, ať už jejich hádáním nebo pomocí metod sociálního inženýrství. V tomto případě je na vlastníkovi domény, aby byl obezřetný při sdělování přihlašovacích údajů a vybral si bezpečného registrátora, který má dostatečně zabezpečené svoje služby. Další potencionální riziko představuje využívání veřejných serverů DNS. Tomuto problému se věnuje ve své práci Alonso [3], který diskutuje problém používání OpenDNS. Servery projektu OpenDNS jsou v současné době velmi široce používány a v prostředí decentralizovaného Internetu vytváří velmi rozsáhlý centrální prvek spravovaný jednou společností. Taková společnost tak může účinně blokovat dotazy na domény, které jsou podle jejího měřítka nějak závadné. Problémem je, že uživatel nemá pod kontrolou, které domény jsou zablokovány. Riziko představuje zmíněné měřítko, kdy je třeba určit, zda je daná doména závadná či nikoliv. Příkladem může být doména thepiratebay, kterou se americké úřady snažili zablokovat, přestože nebyla přímo závadná. 19

2. Domain Name System 2.6.6 Shrnutí Poslední zmíněné riziko představuje spíše zajímavou možnost zneužití infrastruktury DNS. Útoky, které byly zmíněny dříve ovšem představují velmi závažnou hrozbu, se kterou je potřeba při používání DNS počítat. Většinu zmíněných hrozeb je možné eliminovat využitím protokolu DNSSEC. Tento protokol ovšem stále není široce nastaven a používán, což usnadňuje potencionálním útočníkům práci. Následující kapitoly práce se již nezabývají zmíněnými zranitelnostmi DNS, ale představují různé analytické metody využívající provoz DNS k odhalení síťových anomálií. Tyto anomálie se mohou týkat jak samotného DNS (například velký objem dotazů), tak i provozu vyvolaném přítomností škodlivého software v síti.

20

Kapitola 3

Monitorování provozu DNS Kapitola se věnuje problematice pasivního monitorování provozu DNS. Jsou představeny dva rozdílné přístupy, kterými lze provoz zachytávat a analyzovat. U každého přístupu jsou uvedeny jeho výhody a nevýhody, spolu s nástroji, které daný přístup reprezentují. Prvním uvedeným přístupem je sběr a analýza provozních záznamů ze samotných serverů DNS, jehož nevýhodou je hlavně možnost analyzování pouze části provozu. Druhý uvedený přístup je založen na monitorování paketů. Tato část je rozdělena na dvě podsekce podle způsobu práce s pakety. Jako první je uveden princip hloubkové analýzy paketů, kdy jsou analyzovány pakety i s jejich obsahem. Druhý způsob představuje analýza IP toků, kdy jsou údaje z paketů agregovány. Celá kapitola je zakončena krátkým shrnutím, které přehledně porovnává jednotlivé přístupy.

3.1

Ukládání dotazů na serveru DNS

První z metod umožňujících monitorování provozu DNS je sběr provozních záznamů (logů) přímo na serveru DNS. V případě menších organizací, kde se nachází pouze jednotky DNS serverů je tato metoda nejjednodušší na správu a také nejlevnější. Pro rozlehlé sítě s větším počtem nezávislých serverů DNS ovšem není příliš vhodná, neboť je obtížné získávat a zpracovávat provozní záznamy ze všech serverů DNS v síti. Provozní záznamy jsou obvykle textové dokumenty obsahující informace o činnosti a běhu jednotlivých programů, které dané záznamy vytváří. Tyto záznamy slouží pro zpětnou analýzu chování programu, která umožní lépe určit okolnosti vedoucí k nějaké jeho chybě. Kromě různých informací o samotném programu, mohou provozní záznamy obsahovat i data, kdo a kdy daný program používal, s kým program navázal kontakt a v případě serveru například jaká adresa kladla jaký dotaz. Obvykle programy umožňují vytvářet provozní záznamy různých detailů podle toho, jak jsou dále zpracovávány. Následující výpis ukazuje příklad provozních záznamů serveru DNS vytvořených při dotazech na doménu zona.cz: client client client client client client

127.0.0.1#57021 127.0.0.1#56090 127.0.0.1#49884 127.0.0.1#52281 127.0.0.1#60675 127.0.0.1#60094

(zona.cz): query: zona.cz IN A +E (127.0.0.1) (ns1.zona.cz): query: ns1.zona.cz IN A +E (127.0.0.1) (www.zona.cz): query: www.zona.cz IN A +E (127.0.0.1) (zona.cz): query: zona.cz IN A + (127.0.0.1) (zona.cz): query: zona.cz IN AAAA + (127.0.0.1) (zona.cz): query: zona.cz IN MX + (127.0.0.1)

Kromě programů vytváří provozní záznamy i samotný operační systém. Aby nebylo vytvářeno příliš mnoho souborů s provozními záznamy jednotlivých aplikací, byl zaveden obecný standard, tzv. Syslog protokol, definovaný v RFC 5424 [16]. Tento protokol umožňuje sbírat záznamy jednotlivých programů a ukládat je na jednotné místo v rámci celého systému nebo i sítě, kdy jsou dat přeposílána na jedno zařízení v síti. Nashromážděná data je možné následně analyzovat, vzájemně korelovat a získat tak přehled o chování zařízení v síti. 21

3. Monitorování provozu DNS 3.1.1 Zpřístupnění provozních záznamů DNS Přestože software serverů DNS umožňuje ukládání dotazů a odpovědí, není tato funkcionalita v základním nastavení povolena. Je tedy na každém administrátorovi, zda monitorování DNS dotazů povolí. V případě softwaru BIND v linuxových operačních systémech lze povolit ukládání provozních záznamů dvěma způsoby. Prvním z nich je jednoduchý příkaz rndc querylog, kterým se ukládání záznamů jak zapíná, tak i vypíná. Příkaz způsobí, že jsou veškeré příchozí dotazy DNS ukládány ve formátu Syslog v souboru /var/log/messages nebo v případě systému Debian v /var/log/syslog. Tento příkaz je ovšem vhodný spíš pro jednorázové spuštění a prohlédnutí provozního záznamu, místo pravidelného sledování. Pro dlouhodobé ukládání se využívá nastavení konfiguračního souboru /etc/bind/named.conf, viz sekce 6.2.9 až 6.2.10 oficiální dokumentace BIND [8].

Obrázek 3.1: Povolení ukládání logů pro Microsoft DNS.

V případě Micorosft DNS serveru je situace obdobná a ukládání provozních záznamů je v základu vypnuté. Ukládání záznamů DNS je ale možné povolit v nastavení role serveru DNS, viz obrázek 3.1. V případě, že není nastavený žádný výstupní soubor, jsou záznamy ukládány do souboru C:\windows\system32\dns\dns.log. Jak je vidět z obrázku 3.1, administrátor má široké možnosti nastavení ohledně toho, co bude ukládáno za informace. V případě ponechání nezaškrtnuté možnosti Details výstup obsahuje podobné informace jako v předcházející ukázce logu vytvořené na BIND serveru: Rcv 147.251.4.33 Snd 192.168.0.109

1d64 R Q [0085 A D 0002 R Q [0085 A D

NOERROR] A (4)zona(2)cz(0) NOERROR] A (4)zona(2)cz(0)

Pokud je ovšem zaškrtnuta možnost Details je ukládán téměř celý paket v textové podobě včetně všech sekcí a přepínačů. Tento formát ale zabírá mnohem více místa. Obecně lze tedy říci, že pro všechny provozní záznamy je třeba zvážit požadovanou úroveň detailu na základě účelu, za jakým jsou provozní záznamy sbírány. 22

3. Monitorování provozu DNS 3.1.2 Zpracování uložených záznamů Získané záznamy je možné zpracovávat různými způsoby podle toho, za jakým účelem jsou shromažďovány. V případě, že administrátor potřebuje pouze zjistit zda server DNS funguje správně, není potřeba žádné strojové zpracování. Obvykle je dostačující jednoduše prohlédnout v jakémkoliv textovém editoru získané provozní záznamy a najít případné chybové záznamy. Pokročilejší metodou je využití programu, který dokáže zpracovat záznamy a zobrazit potencionálně zajímavé informace. Jedním ze zajímavých nástrojů zpracovávající uložené DNS záznamy je volně dostupný program WinDNSLogAnalyser [61] pro operační systémy Windows. Tento program uživateli dokáže poskytnout statistiky například o nejvíce dotazovaných doménách, typech záznamů nebo IP adresách tazatelů. Všechny informace jsou také znázorněny pomocí přehledných grafů. Ukázka výstupu programu je znázorněna na obrázku 3.2. Nevýhodou programu je, že neumožňuje vyhledávání v analyzovaných datech, přesto dokáže velmi rychle poskytnout základní přehled o provozu DNS.

Obrázek 3.2: Uživatelské rozhraní programu WinDNSLogAnalyser.

Dalším z nástrojů, který využívá získané provozní záznamy je program dnsgraph [44], dostupný pro linuxové operační systémy. Program zpracovává uložené DNS záznamy a vytváří přehledné statistiky neúspěšných překladů, rekurzivních dotazů nebo například dotazů na neexistující domény. Na obrázku 3.3 se nachází ukázka statistiky chyb překladu, ve které je velmi lehce vidět nárůst chyb překladu okolo času 16:00. Tento nárůst značí pravděpodobnou chybu v nastavení buď klientů nebo samotného serveru DNS. Takovéto statistiky mohou administrátorům serveru výrazně pomoci při analýze provozu DNS a lze jimi jednoduše odhalit případné chyby. Předchozí programy pro analýzu provozních záznamů DNS jsou využitelné spíše pro odhalování případných chyb v nastavení než pro jakýkoliv bezpečnostní monitoring. Pro tyto účely se spíše hodí využití centrálního úložiště provozních záznamů z různých služeb v síti. Nad tímto úložištěm je možné spustit nástroje, které umí zpracovávat jednotlivé záznamy, vyhledávat v nich a vzájemně korelovat jednotlivá data. Výsledkem může být například upozornění na závadné domény nebo velké množství dotazů na neexistující domény, značící potencionální přítomnost škodlivého software, viz kapitola 4. Nástroje umožňující zpracování provozních záznamů pro bezpečnostní monitoring jsou obvykle označovány zkratkou SIEM (Security Information and Event Management). 23

3. Monitorování provozu DNS

Obrázek 3.3: Ukázka statistiky generované programem dnsgraph [44].

Jako příklad SIEM nástrojů může sloužit aplikace Splunk [23] dostupná pro většinu operačních systémů. Tato aplikace umožňuje efektivní vyhledávání a korelaci velkého množství sesbíraných provozních záznamů. Výhodou je velká univerzálnost neboť program je schopný zpracovat jakýkoliv typ záznamu. Popis jak zprovoznit zpracování provozních záznamů DNS generovaných Microsoft DNS serverem je možné naleznout v článku Trevora Hawthorna [19]. Zmíněný článek popisuje i napojení externího seznamu závadných domén a možnost jejich vyhledávání v DNS dotazech. Díky tomu tento nástroj může být využitý i pro detekci zařízení napadených potencionálně škodlivým softwarem. Kromě pokročilého vyhledávání nabízí Splunk i vytváření statistik a přehledných grafů. Na obrázku 3.4 je znázorněn příklad statistiky popisující seznam a počet dotazovaných domén v čase (pro lepší viditelnost je použito logaritmické měřítko). Díky tomu je možné sledovat na které domény se klient dožadoval a zda se dotazuje pravidelně. V uvedeném příkladě je zvýrazněna opakovaně dotazovaná doména www.facebook.com.

Obrázek 3.4: Ukázka generované statistiky dotazovaných domén v programu Splunk.

Z příkladu uvedených programů vyplývá, že provozní záznamy DNS jsou velmi zajímavým a obsáhlým zdrojem informací. Jejich nevýhodou je časová náročnost zpracování v případě, že je třeba analyzovat velké množství záznamů. Proto je metoda analýzy záznamů DNS vhodná 24

3. Monitorování provozu DNS spíše pro sítě s menším počtem klientů a serverů DNS. V tomto prostředí poskytuje dostatek informací, které mohou být použity jak k odhalení potencionálních chyb v nastavení, tak pro bezpečnostní monitoring.

3.2

Monitorování paketů DNS

Monitorování provozu DNS přímo na síti nabízí velmi efektivní alternativu pro ukládání provozních záznamů na straně serveru DNS. Není potřeba pro každý server v síti nastavovat ukládání záznamů a řešit jejich export, ale stačí na vhodných místech v síti umístit zařízení, která budou monitorovat provoz a z něj získávat potřebná data. Další výhodou je, že při analýze provozu v síti jsou zachyceny i dotazy mířící na servery DNS mimo lokální síť, které při sběru provozních záznamů není možné jakkoliv získat. Samotné monitorování a sbírání dat z provozu je možné provádět buď na síťových rozhraních jednotlivých zařízení v síti nebo pomocí takzvané síťové sondy. Sondou je v tomto případě myšleno zařízení sloužící primárně pro sběr a analýzu nebo export získaných dat, obvykle připojené přes rozbočovač (TAP) nebo port aktivního prvku provádějící zrcadlení provozu. 3.2.1 Hloubková analýza paketů K zachycenému provozu je možné přistupovat dvěma způsoby. První z těchto způsobů představuje tzv. hloubková analýza paketů, kdy je analyzován celý paket. Kromě hlaviček paketu je analyzován i jeho obsah, který v případě DNS obsahuje dotazované doménové záznamy, všechny odpovědi a další data definovaná protokolem DNS. Následující nástroje představují rozdílné přístupy, jak lze provádět hloubkovou analýzu paketů. Každý z uvedených přístupů poskytuje jiné údaje o DNS. V závislosti na tom, za jakým účelem jsou data z DNS provozu shromažďována, je tedy třeba vybrat vhodný nástroj. tcpdump/Wireshark Nejjednodušší přístup pro analýzu síťových dat představuje program tcpdump [30]. Tento program umožňuje zachytávat veškerý provoz (nikoliv pouze DNS) na síťových rozhranních a případně jej exportovat do předem definovaných formátů, které lze následně ručně nebo strojově analyzovat. Následující příkaz uvádí příklad spuštění programu tcpdump na síťovém rozhraní eth0 tak, aby vypisoval obsah příchozích nebo odchozích paketů z portu 53 (DNS), na standardní výstup: tcpdump -i eth0 -vvv -s 0 -n port 53 Výpis na standardní výstup není ovšem příliš efektivní a ani vhodný pro analýzu provozu. Z toho důvodu existují různé skripty a nástroje schopné syntakticky analyzovat daný výstup tak, aby bylo možné jej ukládat a následně dál analyzovat. Příkladem takovéhoto použití je jednoduchý skript od Jona Taie [49], vypisující údaje o DNS spojeních. Druhou možností, místo výpisu na standardní výstup, je ukládání celých paketů a jejich následná analýza pomocí jiného nástroje. Tato metoda s sebou ovšem přináší velkou náročnost na velikost úložného prostoru. Přesto pokud monitorovaná síť obsahuje menší množství klientů, je i tato metoda možná. Nejrozšířenějším programem schopným analyzovat uložené pakety je nástroj Wireshark. Ten umožňuje jak analýzu a procházení uložených paketů, tak i jejich přímé zachytávání. Program nabízí rozčlenění paketů do jednotlivých sekcí tak, aby byl dobře čitelný jejich obsah. Tato funkcionalita je dobře vidět na obrázku 3.5, kde se nachází ukázka vygenerovaného výstupu odpovědi pro doménu muni.cz. Výhodou je, že v zobrazených paketech je možné také vyhledávat a filtrovat pouze informace, které jsou relevantní pro analýzu. 25

3. Monitorování provozu DNS

Obrázek 3.5: Ukázka zobrazení paketu odpovědi DNS v programu Wireshark.

Z důvodu vysokých nároků na úložný prostor není metoda analýzy celých paketů příliš vhodná pro dlouhodobé sledování větších sítí. Nástroje typu tcpdump, případně wireshark, jsou vhodnější spíše pro ruční analýzu provozu a hledání konkrétních chyb služeb v síti. Druhým důvodem jejich použití je zachycení a dohledaní konkrétních údajů ze specifického paketu. V případě provozu DNS tak lze například dohledávat všechny odpovědi, které byly vráceny při dotazu na specifickou doménu. Pro tyto účely je vhodnější použít nástroje zmíněné dále. Tyto nástroje zachycený paket neukládají celý, ale vybírají pouze podstatné informace. Tyto informace následně ukládají ve formátu, který umožní jejich rychlou analýzu. Nástroje typu tcpdump/wireshark, jsou vhodnější spíše pro ruční analýzu dat a dohledání konkrétního údaje. DNS Statistic Collector Pro dlouhodobé sledování provozu DNS je místo ukládání celých paketů vhodné extrahovat a ukládat pouze relevantní informace, díky čemuž se výrazně sníží objem ukládaných dat. Prvním příkladem nástrojů extrahujících informace z obsahu paketů je DNS Statistic Collector [12] (dále jen DSC), zaměřený na analýzu provozu DNS. Nástroj slouží pro vytváření statistik o DNS provozu podobně jako dříve popsaný nástroj dnsgraph, není tedy vhodný pro analýzu dotazovaných domén a jiné vyhledávání. DSC se skládá ze dvou částí: kolektoru, který slouží pro sběr a extrakci DNS dat, a prezentační části vytvářející statistiky a přehledné grafy. Pomocí knihovny libpcap [30] kolektor sleduje všechny pakety DNS procházející síťovým rozhraním. Je možné jej nasadit jak na samotném serveru DNS, tak v jakémkoliv zařízení nacházejícím se v síti. Kolektor podle nastavení v konfiguračním souboru ukládá extrahovaná data do XML souboru, který je možné přímo analyzovat nebo přeposílat na společné úložiště spolu s daty z jiných kolektorů v síti. Prezentační část DSC z důvodu rychlejšího zpracování transformuje XML soubory do textového souboru rozdělujícím jednotlivá data novým řádkem. Takto upravená data jsou následně 26

3. Monitorování provozu DNS zpracována CGI skriptem, který se stará o výpočet všech statistik a hlavně prezentaci ve webovém rozhraní. Vypočítané statistiky jsou prezentovány ve formě grafů, které znázorňují například podíl dotazů rozdělených podle jejich typu, populární TLD domény, podíl chyb pro jednotlivé klienty nebo velikost dotazů. Jelikož je DSC již starší nástroj a není příliš vyvíjen, nabízí sdružení CZ.NIC jeho rozšíření DSCng [57]. Toto rozšíření již využívá export dat do databáze, místo textového souboru, díky čemuž je urychleno jejich zpracování. Hlavní změnou je ale prezentační část postavená na technologiích HTML5 a JavaScript. Toto řešení nabízí vyšší interakci a zvyšuje tak možnost podrobnější analýzy. Následující obrázek 3.6 zobrazuje statistiku typu dotazů za týden, vygenerovanou v online ukázce nástroje na adrese https://devpub.labs.nic.cz/dscng/.

Obrázek 3.6: Statistika typu dotazů generovaná programem DSCng [57].

DSC a jeho novější varianta DSCng nabízí zajímavé a přehledné statistiky o provozu DNS, které jsou vhodné spíše pro administrátory serverů DNS a správce sítě, než pro bezpečnostní monitoring. Přesto i z těchto dat lze odhalit například amplifikační útok využívající některý z serverů DNS v síti, viz sekce 4.2.2. Nevýhodou je, že nejsou ukládány dotazované domény a získané odpovědi, které jsou dále využitelné pro bezpečnostní monitoring.

The Bro Network Security Monitor The Bro Network Security Monitor (dále jen Bro) [39] je druhým příkladem nástrojů schopných extrahovat potřebné informace ze síťového provozu. Kromě DNS jako v předchozím případě, se zaměřuje na celkový provoz, díky čemuž se stává velmi univerzálním nástrojem. Jedná se o pokročilý pasivní systém detekce průniků (IDS), do kterého je možné implementovat vlastní detekční metody založené na hloubkové analýze paketů. Program kromě možnosti psát vlastní detekční metody obsahuje i velké množství předinstalovaných metod. Velkou výhodou programu je zpracování v reálném čase, díky čemuž jsou generovány upozornění na anomálie a bezpečnostní hrozby bezprostředně po jejich výskytu. Architektura Bro se skládá celkově ze tří částí znázorněných na obrázku 3.7. První je síťová část využívající knihovnu libpcap, která slouží k získávání a filtrování paketů přicházejících ze síťového rozhraní. Toto rozhraní je obvykle připojeno do sítě přes TAP, díky čemuž je Bro 27

3. Monitorování provozu DNS nedetekovatelné útočníkem a přitom má přístup k veškerému provozu na lince. Tato část vytváří proud filtrovaných paketů, který předává druhé vyšší části. Příchozí proud filtrovaných paketů zpracovává druhá část (Event Engine) generující jednotlivé události. Tato část prochází jednotlivé příchozí pakety a podle jejich obsahu vytváří události, které odpovídají jednotlivým vlastnostem paketu. Jako příklad může sloužit událost dns_A_reply. Tato událost je vyvolána ve chvíli, kdy Bro zaznamená příchozí DNS odpověď typu A. Vyvolané události obsahují informace o obsahu paketu. Kromě atributů specifických pro každou službu, obsahuje každá událost i atribut connection. Tento atribut v sobě obsahuje základní informace o spojení, například jeho začátek, trvání , komunikující strany nebo historii. Atribut connection obsahuje také jednoznačný identifikátor spojení, který je možné využít k propojení všech událostí vygenerovaných během spojení. Upozornění

Záznamy

Interpreter skriptů Události

Generátor událostí Pakety

Síť Obrázek 3.7: Architektura nástroje Bro [43].

Poslední částí Bro je interpreter jednotlivých skriptů (Policy Script Interpreter). Tato část se stará o překlad a zpracování jednotlivých skriptů využívaných pro detekci anomálií nebo bezpečnostních hrozeb v síti. Tyto skripty zpracovávají jednotlivé události, vzájemně je korelují a vyhodnocují. Výsledek je pak možné ukládat do jednotlivých logů a upozornit zodpovědné osoby například přes e-mail. Seznam všech událostí, které je možné využít pro detekci, je možné naleznout v oficiální dokumentaci programu [42]. Jednotlivé detekční skripty je možné rozdělit do dvou kategorií. První jsou skripty, které uživatel doplní a vytvoří sám, druhou představují již zabudované detekční skripty. Tyto zabudované skripty generují takzvané Notices vyvolávané při detekování podezřelé události. Příklad takovéhoto upozornění je DNS::External_Name upozorňující na cizí domény odkazující na lokální adresu. Tyto upozornění jsou generovány vždy a je pouze na administrátorovi, zda a jakým způsobem je zpracuje (například uloží do logu). Skripty využívané v rámci Bro mají definovanou vlastní syntax, pro co možná nejrychlejší zpracování. Příklad skriptu využívajícího události dns_A_reply a dns_AAA_reply je možné naleznout v příloze pod názvem dns_visually_similar.bro1 . Tento skript byl vytvořen v rámci diplomové práce pro vyzkoušení vývoje skriptů v nástroji Bro. Skript slouží pro analýzu dotazů DNS a sledování, zda nebyly dotazovány domény, které jsou vizuálně podobné definovaným. Tento typ detekce vede k odhalení potencionálního phishingového útoku využívaného ke sběru přihlašovacích hesel uživatelů. Útočník v tomto případě využívá vizuální podobnost domén,

1. Příloha: detekcni_skripty/Bro/dns_cybersquatting.bro

28

3. Monitorování provozu DNS které si oběť nemusí všimnout. Následující výpis představuje ukázku vygenerovaného logu po navštívení adresy is.mumi.cz ze stroje s IP adresou 10.0.2.15: #separator \x09 #set_separator , #empty_field (empty) #unset_field #path dns_cybersquatting #open 2013-11-04-09-36-23 #fields response_time client_ip domain #types time addr string addr 1383554182.944603 10.0.2.15 is.mumi.cz

domain_ip 147.251.17.5

Detekční nástroj Bro nabízí široké možnosti pro analýzu provozu v síti, přičemž není zaměřen pouze pro analýzu DNS jako dříve uvedené programy. Díky tomu je možné navázat data z provozu DNS na ostatní informace ze sítě a zpřesnit tak detekční metody. Příkladem může být ověření, zda uživatel dotazovanou doménu opravdu navštívil. Mezi hlavní výhody Bro patří také možnost rychlého vývoje vlastních detekčních metod založených na hloubkové analýze paketů. Díky tomu je možné rychle zareagovat na nové hrozby a zabezpečit tak vlastní síť. Další výhodou, která tento nástroj odlišuje od ostatních metod, je zpracovávání v reálném čase. Díky tomu není třeba vyčkávat na vygenerovaní exportu dat a je možné zareagovat na jakoukoliv událost ve chvíli kdy se v síti objeví. Mezi hlavní nevýhody tohoto řešení patří vysoká výpočetní náročnost způsobená tím, že pro jeden paket může být vyvoláno i několik druhů událostí. Tuto nevýhodu je ale možné částečně eliminovat omezením generovaných událostí pouze na ty, které jsou dále zpracovávány detekčními skripty. Problémem také je, že provoz není žádným způsobem ukládán, díky čemuž jej nelze zpětně analyzovat. Řešením by mohlo být ukládání celých paketů, což ale klade nemalé kapacitní nároky na úložné prostory. Další z nevýhod je nedostatečná dokumentace, hlavně v případě popisu samotného jazyka Bro, která znesnadňuje vývoj uživatelských skriptů. 3.2.2 Analýza IP toků Mezi nejrozšířenější metody sledování provozu v síti patří technologie NetFlow založená na bázi IP toků. Tok je definován jako sekvence paketů se shodnou pěticí údajů: zdrojová a cílová adresa, zdrojový a cílový port a číslo protokolu [26]. Každý tok je také doplněn časovou značkou jeho začátku a konce. Dále jsou zaznamenávány další informace o toku, jakými jsou například počet přenesených paketů, bytů, IP protokol, typ služby nebo TCP příznaky. Takto získané statistiky o toku poskytují dostatečné informace o síťovém provozu a chování uživatelů v síti. Mezi hlavní výhody NetFlow patří agregovaný pohled na dění v síti. Zachycené pakety nejsou ukládány celé, ale jsou z nich extrahovány pouze podstatné informace, které jsou následně agregovány do jednoho toku. Oproti dříve zmíněné analýze obsahu paketů pomocí programu Bro, NetFlow nabízí méně detailní pohled. Díky agregaci tak není možné provádět některé typy úloh nad síťovými daty. Tato nevýhoda je ovšem vyvážena nižšími požadavky na výpočetní výkon a úložné prostory. Pomocí NetFlow je tedy možné analyzovat i rozsáhlé sítě s velkým objemem provozu, jakou je například síť Masarykovy univerzity. Kompletní informace o síťovém spojení, jsou odesílány do databáze toků až po jeho ukončení. Příkladem ukončení toku je u protokolu TCP ukončení spojení pomocí paketu s příznakem FIN. Tento princip ale nelze použít u protokolu UDP, nebo u příliš dlouhých spojeních, kde je obtížné rozhodnout, zda se stále jedná o aktivní spojení. Z tohoto důvodu byl v rámci technologie NetFlow zaveden export dat založený na tzv. aktivním a neaktivním časovém limitu. U dlouhotrvajících spojení je využíván aktivní časový limit, který po definovaném časovém intervalu ukončí monitorování spojení a exportuje jej do databáze toků. Další data v poslaná rámci spojení 29

3. Monitorování provozu DNS vytváří opět nový tok. Díky tomuto řešení jsou uvolňovány prostředky monitorovacího zařízení. Druhou výhodou je možnost analýzy takovýchto dat, bez nutnosti čekání na konec spojení. Neaktivní časový limit označuje délku intervalu od posledního paketu v rámci spojení. Pokud je tento interval překročen, je jako v případě aktivního limitu tok ukončen, přičemž případný další paket je zařazen do nového toku. Tabulka 3.1 popisuje nejrozšířenější verze NetFlow. Hlavní je verze 5, která je v současné době stále nejrozšířenější, přestože neumožňuje monitorování provozu IPv6 [26]. S touto podporou přichází až následující verze 6, která je ovšem využívána minimálně. Tato verze navíc zavádí možnost specifikace exportovaných dat pomocí takzvaných šablon, díky čemuž lze upřesnit jaké další informace budou v síťovém toku uvedeny. Aktuální NetFlow verze 9 byla uznána i jako standard RFC 3954 [6] organizací IETF. Na tuto verzi v roce 2008 navázal otevřený standard NetFlow verze 10 [7, 45], obvykle označován jako IPFIX (IP Flow Information Export). IPFIX nejen díky své otevřenosti představuje univerzální standard pro export informací o síťových tocích. Přesto v současné době není IPFIX ještě příliš rozšířen. Mezi hlavní verze, které se dnes používají tedy patří NetFlow verze 5 a 9. Verze

Komentář

1 5 9 10 (IPFIX)

První verze, která podporovala pouze IPv4. Nyní zastaralé. Jedna z nejrozšířenějších verzí. Podporuje pouze IPv4. Standard IETF. Založená na šablonách. Podporuje IPv6, MPLS a IPv4. Standard IETF vycházející z NetFlow v9 s několika rozšířeními.

Tabulka 3.1: Hlavní používané verze NetFlow [26]. Pro sběr NetFlow/IPFIX dat je možné využít různá zařízení od odlišných výrobců. Jako základní zdroj dat je možné využít některá síťová zařízení typu přepínač nebo směrovač, podporující export IP toků. Tato zařízení ovšem nejsou primárně určena pro sběr tohoto typu informací a proto mohou být některá získaná data nepřesná [20]. Pro sběr dat je tedy lepší využít specializované programy a zařízení, obvykle označované jako síťová sonda. Pokud přenosová rychlost monitorované sítě dosahuje maximálně jednotek gigabitů za sekundu, je možné využít softwarové řešení pro sběr dat. Výhodou jsou nižší pořizovací náklady a možnost nasazení na jakémkoliv, dostatečně výkonném, zařízení v síti. V případě, že síť dosahuje vyšších přenosových rychlostí, je třeba využít hardwarové sondy, které již umožňují zpracování dat v sítích s rychlostí 10 Gb/s a vyšších. Získané síťové toky je možné analyzovat buď na samotném zařízení, kde byly získány nebo je možné využít tzv. kolektoru. Tím je myšleno zařízení v síti, na které jsou zasílány toky ze všech zařízení v síti. Všechny toky jsou zde dále zpracovány a uloženy. Nad uloženými toky je pak možné vyhledávat různé anomálie pomocí programů schopných tyto data analyzovat. Díky tomu, že jsou uloženy toky ze všech zařízení na jednom místě, je lze vzájemně korelovat a zpřesnit detekční metody. Velmi důležitou roli v tom, jaká data budou k dispozici, hraje rozmístění jednotlivých síťových sond v rámci infrastruktury sítě. Například sonda na přípojném místě k Internetu, bude monitorovat všechen příchozí a odchozí provoz ze sítě, avšak komunikace mezi jednotlivými podsítěmi zůstane nadále skryta [26]. Je tedy potřeba shromažďovat data i z vnitřní sítě, pomocí vhodného rozmístění síťových sond, jak je schematicky znázorněno na obrázku 3.8. Export síťových toků s informacemi z paketů DNS Výraznou výhodou nových verzí NetFlow/IPFIX je využití šablon, specifikujících formát exportovaných dat. Díky tomu je možné rozšířit standardní IP tok i o informace z provozu DNS. 30

3. Monitorování provozu DNS Aby tyto informace byly přidány k tokům, je potřeba rozšířit exportér síťové sondy tak, aby byl schopný zpracovávat i provoz DNS, jelikož standardní exportér DNS data nezpracovává. V této diplomové práci byl využit zásuvný modul pro exportér vyvíjený Michalem Kováčikem na Vysokém učení technickém v Brně. Tento modul v současné době podporuje export následujících dat: ∙

Ans – počet odpovědí v sekci Answers,

∙

RCode – kód odpovědi (obvykle označující případné chyby překladu),

∙

ID – jednoznačný identifikátor pro párování dotazu s odpovědí,

∙

Name – dotazovaná doména,

∙

QType – typ dotazovaného záznamu,

∙

Class – třída dotazovaného záznamu,

∙

RR TTL – platnost záznamu,

∙

RLen – velikost dat odpovědi,

∙

RData – data odpovědi (v případě více odpovědí je uvedena pouze jedna),

∙

PSize – požadovaná minimální velikost paketu,

∙

DNSSEC – informace, zda je použit DNSSEC.

Lokální síť

Síťová sonda

Zdrojová a cílová IP adresa Zdrojový a cílový port Protokol Doba komunikace Počet paketů Počet bytů Ostatní

Síťová sonda

Kolektor síťových toků

Obrázek 3.8: Schéma zapojení prvků pro analýzu síťových toků.

Analýza toků s informacemi z provozu DNS Analýzy dat je možné provádět pomocí jakéhokoliv analytického programu schopného zpracovávat data ve formátu NetFlow/IPFIX. Pro analýzu standardních NetFlow je možné využít nástroj nfdump [18]. V diplomové práci byl také využit v současné době vyvíjený program fbitdump [53]. Tento program umožňuje zpracovávat IP toky ve formátu IPFIX uložené v databázi FastBit [56], do které byly uloženy v rámci zpracování na kolektoru. Program nabízí jednoduchý výpis toků, 31

3. Monitorování provozu DNS vytváření statistik a agregování toků, přičemž lze omezit analyzovaná data pomocí filtru. Následující ukázka předvádí některé základní příkazy nástroje fbitdump: # Základní výpis DNS paketů: fbitdump -R <složka s toky> -o dns4 # Výpis informací o šabloně pro vybraná data fbitdump -R <složka s toky> -T # Příklad použití filtru s omezením pouze na domény obsahující řetězec muni fbitdump -R <složka s toky> "%dnsname == ’%muni%’ -o dns4 # Výpis IP adresy a dotazované domény s omezením na DNSSEC fbitdump -R <složka s toky> "%dnsdo == 1" -o "fmt:%srcip4|%dnsname" S výstupy nástrojů schopných analyzovat NetFlow/IPFIX data je možné pracovat dvěma rozličnými způsoby. Prvních z nich je generování přehledných grafů, reprezentujících historii a aktuální stav provozu na síti. Příkladem takového grafu je obrázek 3.9. Z takto vygenerovaných grafů je možné pro administrátora sítě jednoduše rozpoznat nestandardní chování. Nestandardním chováním je v tomto případě myšlena jakákoliv odchylka od běžného, očekávaného stavu. Na uvedeném příkladě by tedy administrátorovi neměl uniknout velký nárůst velikosti paketů označený v pravé části obrázku.

Obrázek 3.9: Graf zobrazující statistiku velikostí paketů v provozu DNS. Vygenerované grafy poskytují administrátorovi pouze informace, že je v síti nějaké nestandardní chování. Aby bylo možné rozhodnout, zda se jedná o bezpečnostní incident nebo o běžné chování, je potřeba využít druhý způsob práce s NetFlow/IPFIX daty. Tímto způsobem je přímá analýza jednotlivých toků, umožňující zjistit, kterých strojů (IP adres) se daná anomálie týká, jaké chování jí předcházelo a lze také získat podrobnější informace o tocích označených anomálií. Na základě těchto informací je následně administrátor schopný rozhodnout o povaze anomálie. Ruční kontrola anomálií ovšem není nutná vždy a velmi často je možné ji nahradit automatizovaným zpracováním. Pro tyto účely jsou používány programy schopné pracovat s nástroji pro analýzu toků ve formátu NetFlow/IPFIX. Tyto programy jsou v pravidelných intervalech spouštěny nad získanými toky, obvykle na straně kolektoru. Programy se zaměřují na specifické chování, provázející různé anomálie značící bezpečnostní rizika. Příkladem je detekce skenování 32

3. Monitorování provozu DNS sítě, které se vyznačuje přístupem na mnoho IP adres z jediné IP adresy. Pokročilejším detekčním mechanismem je například detekce slovníkových útoků na službu SSH, kdy jsou sledovány délky a objemy opakujících se toků. Výhodou analýzy IP toků je možnost vzájemné korelace jednotlivých detekčních metod. Takovouto korelaci je možné využít například při odhalování botnetů v síti. Botnety se vyznačují specifickým chováním, jakým je instalace na zařízení oběti, kontaktování kontrolního centra a následné plnění povelů. Jednotlivé prvky chování je možné brát jako běžné chování zařízení, až jejich vzájemné propojení dokáže odhalit přítomnost nakaženého zařízení. Hlavní nevýhodou technologie NetFlow/IPFIX oproti nástrojům zaměřených na hloubkovou analýzu paketů, je nemožnost implementace některých detekčních metod, jelikož není možné využít všechny informace ze síťového provozu. Přesto využití technologie NetFlow/IPFIX je vhodnou metodou pro monitorování provozu DNS. Oproti dříve uvedeným metodám nejsou kladeny příliš vysoké nároky na výpočetní výkon, ani na úložnou kapacitu. Díky tomu je možné využití této technologie i na rozsáhlých sítích s vysokým objemem provozu. Oproti monitoringu pomocí dříve popsanému nástroji Bro, jsou data o provozu navíc ukládána, díky čemuž je možné se k nim kdykoliv vrátit a provést další analýzu. Takto uložená data je současně možné použít jako důkaz při případném dokazování. Další z výhod je možnost vytváření statistik o provozu na síti. To umožňuje administrátorům odhalovat i případné chybné nastavení, tak jako v případě DSC.

3.3

Shrnutí

Tabulka 3.2 uvádí porovnání jednotlivých přístupů pro monitorování provozu DNS. V prvním sloupci je uvedeno za jaký čas je možné získat a analyzovat záznamy z provozu. V případě, že data nejsou poskytována v reálném čase, je uveden čas, který je doporučován pro optimální provoz. Zatímco u nástroje DSC je možné nastavit téměř jakýkoliv čas, u analýzy síťových toků nelze daný interval příliš zkrátit, neboť by se ztrácely výhody agregování toků. Analyzovaná data

Dostupnost dat

Požadavky na výkon

Nároky na úložnou kapacitu

Náročnost dalšího zpracování

Provozní záznamy

okamžitě

vysoké

střední

střední

Těla paketů · tcpdump/Wireshark · DSC · Bro IP toky

okamžitě 5 minut okamžitě 5 minut

střední nízké vysoké střední

vysoké nízké žádné střední

vysoká nelze střední nízká

Tabulka 3.2: Porovnání přístupů pro monitorování provozu DNS. Třetí sloupec uvádí porovnání jednotlivých přístupů v závislosti na výpočetní náročnost při analýze většího objemu provozu, odpovídajícího rozsáhlým sítím. Nejvíce náročným přístupem je generování událostí ze síťového provozu pomocí nástroje Bro. Pro každý paket může být vyvoláno několik rozdílných událostí, které je nutné vyhodnotit, což v případě vyššího objemu provozu může být časově a výkonově náročné. Další sloupec se zaměřuje na objem ukládaných dat. Jediným nástrojem neukládajícím data je Bro, které umožňuje pouze případné ukládání specifických provozních záznamů. Pokud ovšem nejsou vytvářeny, nelze zachycený provoz zpětně analyzovat, což může způsobovat problémy při dohledávání dodatečných informací o provozu. Z uvedených nástrojů, které ukládají záznamy o provozu tudíž vychází nejlépe nástroj DSC, který ukládá pouze relevantní informace pro tvorbu statistik. 33

3. Monitorování provozu DNS Náročnost dalšího zpracování má velký význam v případě, že je třeba vyvíjet nové detekční metody. Kromě nástroje DSC, který neposkytuje žádnou možnost dodatečné analýzy dat, je možné pro všechny přístupy vyvíjet programy, které využívají získaná data. Pro vývoj nových metod jsou ovšem primárně určeny nástroje analyzující síťové toky a nástroj Bro. Přestože je nástroj Bro určen pro vývoj nových metod, neobsahuje příliš dobrou dokumentaci. Problém také tvoří omezení pouze na události a funkce, které jsou v Bro implementované. Do budoucna ale Bro představuje velmi zajímavou cestu k monitorování síťového provozu a to nejen DNS. V případě nástrojů analyzujících IP toky, je náročnost dalšího zpracování označena jako nízká. Základ metod totiž tvoří filtry pro analýzy toků, přičemž samotný výstup již lze jednoduše zpracovat pomocí jakéhokoliv skriptovacího jazyku. Obecně lze říci, že analýza síťových toků představuje vhodné řešení pro monitorování provozu v rozsáhlých sítích, byť za cenu opoždění detekce o přibližně 5 minut, podle nastavení. Zachycená data jsou průběžně ukládána, díky čemuž je možné se k nim kdykoliv vrátit, přičemž výpočetní a paměťové nároky nejsou vysoké i v případě velkého množství dat.

34

Kapitola 4

Anomálie provozu DNS Kapitola se zaměřuje na popis konkrétních anomálií, které se mohou objevit v provozu DNS, doplněné výsledky analýzy provozu v síti Masarykovy univerzity. Anomálie jsou rozděleny do dvou sekcí na provozní a bezpečnostní, podle důvodu jejich vzniku a možných následků. Mezi provozní anomálie spadá primárně chování, které se výrazně odlišuje od očekávaného chování provozu DNS. Provozní anomálie obvykle souvisí se špatným nastavením zařízení v síti nebo jsou způsobeny jejich specifickým chováním. Toto chování může být způsobeno jak z legitimních důvodů, tak jej může vyvolat útok na dané zařízení. Rozlišení je ovšem často obtížné a je potřeba provést další hlubší analýzu zjištěné anomálie. Naopak bezpečnostní anomálie již plně souvisí s ohrožením zařízení a uživatelů v síti.

4.1

Provozní anomálie

Pod pojem provozní anomálie spadá provoz DNS, který vybočuje od normálního předpokládaného chování. Takovéto neobvyklé chování může být způsobeno špatným nastavením zařízení v síti nebo využitím protokolu DNS k jiným účelům, než je překlad doménových jmen. Na rozdíl od bezpečnostních anomálií, nepředstavují provozní anomálie přímé bezpečnostní riziko. Přesto je potřeba s nimi počítat při bezpečnostním monitoringu, neboť mohou výrazně ovlivnit jeho úspěšnost. 4.1.1 Nadměrný provoz DNS Prvním příkladem provozních anomálií je situace, kdy zařízení v síti začnou generovat výrazně velké množství dotazů nebo odpovědí. Takovéto chování je obvykle způsobeno špatnou konfigurací, případně nějakou chybou zařízení. Nadměrný provoz lze nejlépe detekovat pomocí pravidelného vytváření statistik o celkovém provozu DNS. V takovéto statistice se provozní anomálie vyznačují výrazně rozdílnými hodnotami od normálního provozu. Tyto statistiky mohou být zaměřeny například na klienty s nejvíce dotazy, počet dotazů na specifickou doménu, nejvíce dotazované servery nebo nejčastěji dotazované domény. Schonewille [46] ve svém výzkumu identifikoval, že mezi nejpřínosnější statistiky patří statistika dotazovaných domén spolu s klienty, kteří dané domény dotazují. Jakákoliv odchylka v těchto statistikách tak obvykle dobře označuje různé provozní anomálie. Další příklad provozní anomálie, během které je vytvářeno velké množství dotazů, identifikoval ve své práci Zdrnja [60]. Ve své práci zjistil, že v rámci sítě Aucklandské univerzity je vytvářeno velké množství dotazů typu A antispamovými řešeními, nikoliv klienty prohlížejícími si web. Antispamová řešení využívají tzv. blacklisty v reálném čase (RBL – Realtime Blacklist). Pro dotazování nad těmito seznamy je využívána technologie DNS, kdy antispamové řešení vytváří dotaz na doménu, ze které zpráva přišla. RBL DNS následně zasílá odpověď v závislosti na tom, zda daná doména je blokována či nikoliv. Díky velkému množství takto vytvářených dotazů se podařilo z provozu DNS identifikovat vlnu spamu, který byl zasílán na adresy Aucklandské univerzity. Posledním příkladem vytváření velkého množství provozu jsou klienti s internetovým prohlížečem Chrome. Tento prohlížeč poskytuje, v případě že uživatel zadává text do adresního řádku, 35

4. Anomálie provozu DNS nápovědu ve formě známých nebo příbuzných domén. Pro potřeby urychlení následného zobrazení webové stránky se prohlížeč na hlavní z těchto nabídnutých domén dotazuje serveru DNS. Díky tomu nemusí s překladem vyčkávat, až uživatel opravdu napíše celou adresu, ale může stránku načítat už částečně dopředu. V případě detekčních metod zaměřených na bezpečnostní anomálie je potřeba s tímto faktem počítat. Uživatel totiž dotazovanou doménu nemusí nakonec vůbec navštívit, což by mohlo vést k falešným poplachům. 4.1.2 Tunelování provozu Tunelování síťového provozu je technika, kdy pro přenos jednoho síťového spojení je využito jiné síťové spojení. V případě DNS se tak může jednat například o komunikaci pomocí doménového jména a odpovědi, přes které je možné navázat spojení a přenášet jakákoliv data. Příkladem této techniky je již zmíněná technologie RBL, kdy je přes DNS spojení pokládán dotaz, zda je daná doména nebo IP adresa z bezpečnostních důvodů blokována. V rámci odpovědi je zasílána buď předem definovaná IP adresa nebo návratový kód značící odpovědi ANO/NE. Kromě RBL tuto techniku využívá i například nástroj na mapování IP adres na odpovídající autonomní systém vytvořený Team Cymru [24]. Důvodem pro používání takovéhoto tunelování je velká rychlost odpovědi a snadná konfigurace samotného dotazovacího nástroje. Tunelování provozu pomocí DNS není ovšem využíváno pouze pro účely dotazování nad vzdálenou databází. Tunelování využívají také další nástroje mezi které patří i škodlivý software. Tyto nástroje využívají toho, že provoz DNS je obvykle na firewallech povolen, což umožňuje komunikaci i v sítích s omezenými možnostmi komunikace. Jako příklad takovéto komunikace je možné uvést následující dotaz a odpověď: Dotaz na záznam TXT: ksvsuaacaakaaaaaaeaaaagsaqaabkhvhlyxjffm2flyodieaeaaaaa3aaaab4 f.3g2hqcaaiaaaqaoxfldmypzy5ayfbbbnbxwmvxltfxckbb7y.a.j.e5.sk Odpověď: ABAHKgACABQAAAAAAAAA0gQAAAAAAAAAAAAAAAAAAAIAAABAAAAAiJ/JwgEAAQD nJZdSAAAAAAAAAAA+AQMDwCoFAZrghMErfUo1fRmGVV6Dg1+a433SYRGtFezbXA QazbhSn3JshYtDY+4= Z uvedené ukázky je zřejmé, že se nejedná o žádné existující doménové jméno a DNS je tedy využito k tunelování. V tomto případě se jedná o přenos dat v kódování Base64. Problematice tunelování DNS provozu se krátce věnuje ve své práci Stoner [47], který navrhl detekovat tunelování na základě počtu unikátních znaků v doménovém jméně. Z předchozí ukázky je zřejmé, že pokud jsou data zakódována, obsahují velké množství různých unikátních znaků. Zatímco pokud je dotazována reálná doména, její jméno obsahuje výrazně méně unikátních znaků (například www.muni.cz). Přestože je možné částečně odhalit tunelovaný provoz, problémem stále zůstává rozlišení, zda se jedná o nezávadné tunelování nebo tunelování, které využívá škodlivý software k zamaskování své činnosti. 4.1.3 Dotazy na neexistující záznamy Časté dotazy na neexistující domény jsou další formou provozní anomálie DNS. Takovéto dotazy vznikají převážně v případech, kdy webová stránka, případně nějaký program, obsahují odkaz na doménu, která za dobu existence takového odkazu již zanikla. Druhou možností je špatné napsání doménového jména v adresním řádku webového prohlížeče. Kromě těchto příkladů je možné se s těmito dotazy setkat také v případě škodlivého software snažícího se kontaktovat doménu řídícího centra, která byla zrušena z důvodu její závadnosti. Velké množství dotazů na neexistující domény často také označuje špatně nakonfigurovaný stroj, který špatně vytváří dotazy na doménová jména. Příkladem může být dotaz na doménu 36

4. Anomálie provozu DNS ftp.zona.cz.zona.cz. Z dotazu je zřejmé, že klient se nacházel v doméně zona.cz a jeho resolver tuto doménu přidával k jeho dotazům. Díky tomu, že dotazy nejsou korektně zpracovány, vznikají takovéto nesmyslné dotazy. Další příklad anomálie, kdy jsou dotazovány neexistující domény, představil ve své práci Oberheide [36]. Ten se zaměřil na analýzu provozu DNS v tzv. darknet podsíti, která obsahuje IP adresy síťových pastí (honeypotů). Během svého výzkumu zjistil, že útočníci často dotazují reverzní záznamy příslušející IP adresám daného honeypotu. Útočníci si tak ověřují zda se na dané IP adrese nachází reálný stroj. V případě, že se útočníkům vrátí informace o neexistujícím záznamu, přesměrují se na jinou IP adresu. Útočník si tímto způsobem také zjišťuje o jaký stroj s jakou službou se jedná. V případě reverzního záznamu vedoucím na ftp.zona.cz například útočník zjistí, že na dané IP adresa běží FTP server. Díky této informaci je tak možné lépe zacílit další útok. Skenování strojů v síti pomocí DNS se potvrdilo i v případě Masarykovy univerzity. Například během 28. listopadu 2013 bylo provedeno celkem 865 dotazů na IP adresy příslušející honeypotům. Z hlediska útočníka je takovéto skenování velmi výhodné, neboť se nemusí dotazovat sám, ale využívá k tomu jakýkoliv veřejný server DNS. Díky tomu není odhalena jeho IP adresa a útočníkova totožnost je skryta. 4.1.4 Využívání DNS resolverů mimo lokální síť Další příklad provozních anomálií tvoří využívání DNS resolverů mimo lokální síť. V lokálních sítích je obvyklé, že obsahují lokální server DNS, který je nastaven jako primární DNS server pomocí protokolu DHCP. Tento server obvykle funguje ve dvou režimech, prvním je překlad lokálních doménových jmen (tj. jména, která jsou přeložitelná pouze v rámci lokální sítě) a druhým fungování jako DNS proxy. Výhodou takového řešení je, že překlad jmen probíhá výrazně rychleji díky ukládání výsledků do dočasné paměti. Kromě rychlosti může mít používání externích DNS resolverů vliv i na dostupnost služeb v lokální síti. Tyto služby jsou obvykle pojmenovány v rámci lokální domény, která nemusí být servery mimo lokální síť obsluhovaná. Uživatelé tedy neobdrží korektní IP adresu a služba pro ně bude „nedostupná“. Další problém představuje možný odposlech provozu DNS. Jestliže je využíván lokální DNS resolver, jsou všechny dotazy mimo lokální síť vytvářeny tímto serverem a není možné dohledat zařízení, které se ve skutečnosti dotazuje. Při použití externího DNS resolveru je ovšem možné, v případě že není použito zařízení pro překlad síťových adres (NAT), spojit dotazy s konkrétním zařízením a lépe tak sledovat jeho chování. Místo nastavení lokálního DNS resolveru se administrátoři (hlavně větších sítí) často uchylují k nastavení některého ze známých veřejných DNS resolverů. To se děje buď z důvodu, že si nepamatují, jakou IP adresu má lokální DNS resolver nebo se spletou při nastavování IP adresy. Druhým důvodem, proč je nastavován jiný než lokální DNS resolver jsou často důvody ochrany. Klient může záměrně používat veřejný server s nastaveným DNSSEC nebo server, který poskytuje pokročilou ochranu s blacklistem závadných domén1 . Posledním příkladem, kdy je používán DNS resolver mimo lokální síť, jsou zařízení s pevně nastaveným DNS přinesená uživateli z jejich domovů. Detekovaná anomálie vyžívání DNS resolverů mimo lokální síť obvykle pro administrátory označuje chybně nakonfigurované zařízení v síti. Může se jednat například o překlep při zadávání IP adresy DNS resolveru. Nastavená IP adresa obvykle neoznačuje zařízení s veřejným DNS resolverem a zařízení tak zbytečně vyčkává na vypršení časového limitu, než se začne dotazovat sekundárního serveru DNS. Tato anomálie ovšem může označovat i bezpečnostní riziko v případě používání neznámého, případě podezřelého externího DNS resolveru (server bez doménového jména nebo s lokalitou v jiné zemi). Takovéto chování může svědčit o napadení klienta nějakým 1. Příkladem takového serveru je Comodo Secure DNS: http://www.comodo.com/secure-dns/

37

4. Anomálie provozu DNS druhem škodlivého software, který se snaží přesměrovat DNS dotazy na útočníkův server DNS, viz sekce 2.6.4. Z hlediska monitorování provozu DNS je potřeba s touto provozní anomálií počítat, neboť při monitorování pouze lokálních serverů DNS nemusí být zachyceny všechny dotazy. Z toho důvodu není úplně dostatečné sledování dotazů pouze na lokálním serveru pomocí provozních záznamů, ale je třeba monitorovat i provoz na hranici sítě.

4.2

Bezpečnostní anomálie

Oproti provozním anomáliím představují bezpečnostní anomálie významné riziko. Do kategorie bezpečnostních anomálií spadá primárně zneužití služeb DNS k útokům a provoz vyvolaný činností rozličného škodlivého softwaru. Tyto anomálie představují hlavní důvody, proč by měl být provoz DNS v rámci sítě monitorován. Díky monitoringu lze včas zamezit útokům, případně detekovat přítomnost škodlivého software před tím, než budou napáchány větší škody. 4.2.1 Cybersquatting Pojem cybersquatting označuje obecně zaregistrování a užívání takového doménového jména, které může být zaměnitelné s jiným. Hlavním důvodem je odprodej dané domény, případě její zneužití k sběru přihlašovacích a jiných údajů klientů služby dané domény. Cybersquatter obvykle spoléhá na to, že pojmenování, které zvolil, je lehce zaměnitelné s oficiální doménou případně, že daná organizace bude chtít jeho zaregistrované pojmenování používat. Termín cybersquatting slouží k obecnému pojmenování všech forem tvoření vhodných domén tak, aby bylo možné je zneužít. Následující výčet představuje základní způsoby tvoření cybersqauttingových domén: ∙

Registrace domén prvního řádu – Pokud si organizace zaregistruje například doménu spolecnost.cz, cybersquatter okamžitě zaregistruje další domény prvního řádu (splecnost.com, spolecnost.sk, ...).

∙

Doplnění oficiálního jména – V tomto případě cybersquatter vytvoří domény, které ve svém názvu obsahují oficiální název domény, na kterou cílí. Příkladem takovýchto domén jsou dobraspolecnost.cz, spolecnostmobile.cz, ...

∙

Zneužití vypršení platnosti registrace – Jestliže majitel domény včas nezaplatí za prodloužení registrace oficiální domény, cybersquatter si ji zaregistruje na sebe. Díky tomu k ní tedy majitel ztratí kompletně přístup.

∙

Typosquatting – Cybersquatter si v tomto případě registruje domény, které vznikají překlepem při psaní oficiální domény (např. sspolecnost.cz nebo solecnost.cz, ...).

∙

Vytvoření vizuálně podobné domény – Registrovaná doména obsahuje znaky, jednoduše vizuálně zaměnitelné se znaky jinými. Doména spo1ecnost.cz tak může být lehce zaměnitelná s doménou spolecnost.cz.

Ze zmíněných způsobů je nejvíce nebezpečným pro vlastníka oficiální domény její zaregistrování po vypršení platnosti její registrace. Útočník tak získá nejen samotné doménové jméno, ale získá i například přístup k e-mailům, posílaným na danou doménu na základě MX záznamu. Kromě toho může také sbírat přihlašovací údaje případně jakékoliv další soukromé údaje dané služby. To už pro organizaci představuje výrazné bezpečnostní riziko. Z toho důvodu je třeba důsledně kontrolovat a prodlužovat platnost registrace domény, pokud je využívána. V případě sledování sítě je dobré se zaměřit na detekci typosquattingových a vizuálně podobných domén. Tyto domény bývají obvykle spojovány s podvodnými e-maily, kdy uživateli přijde například informace o vypršení platnosti jeho e-mailové adresy s odkazem na prodloužení, kde 38

4. Anomálie provozu DNS uživatel musí zadat přihlašovací údaje. Doména je obvykle zvolena záměrně tak, aby uživatel na první pohled nepoznal, že se nejedná o oficiální webové stránky. 4.2.2 Amplifikační útok Amplifikační útok je jedním z nejvíce útočníky používaných útoků zneužívajících infrastrukturu DNS. Jedná se o formu DDoS útoku, jehož cílem je zahlcení přenosové linky oběti. Díky tomu touto linkou neprochází žádná data a nejsou obsluhovány požadavky regulérních klientů. Často se stává, že takovéto zahlcení nedovedou zpracovat síťové prvky, jako je směrovač nebo i firewall, které pak následně přestávají fungovat. K zahlcení síťové kapacity oběti je potřeba velké množství vygenerovaného provozu, které obvykle není schopen útočník samostatně vygenerovat. Jelikož DNS funguje primárně nad protokolem UDP, útočníkovi umožňuje podvrhnout zdrojovou IP adresu odkazující na oběť, protože není vytvářeno žádné spojení. Útočník tedy může generovat dotazy na DNS se změněnou IP adresou, přičemž odpověď je zaslána oběti. Tento postup je pro útočníka výhodný, neboť při překladu dotazu na odpověď dochází k zesílení neboli amplifikaci. Zesílení označuje stav, kdy je paket dotazu malý, zatímco paket odpovědi je mnohokrát větší, jak je schématicky znázorněno na obrázku 4.1. Útočník tak může generovat více menších paketů, které následně k oběti dorazí výrazně zvětšeny, díky čemuž zahltí přenosovou linku oběti.

DNS

Útočník

Odpověď: 204.46.43.28 ... Cílová IP: 192.168.254.6 Velikost: 4015 B

Dotaz: fkfkfkfa.com ANY Zdrojová IP: 192.168.254.6 Velikost: 72 B

Oběť 192.168.254.6

DNS

DNS

Obrázek 4.1: Schéma amplifikačního útoku. Hlavním cílem útočníka je vytvořit takový dotaz, který vyvolá co největší odpověď. K tomu jsou nejvhodnější dotazy typu ANY, které vrací všechny záznamy příslušející dané doméně. Výsledná odpověď je tedy výrazně větší oproti menšímu dotazu. Dříve útočníci využívali domény organizací, které vracely spoustu záznamů. S příchodem protokolu DNSSEC útočníci začali zneužívat toho, že při jeho použití jsou k záznamům vkládány ještě jejich digitální podpisy, což výsledný paket zvětší téměř dvakrát. Tento postup ale obvykle nevyužije maximální velikost paketu, kterou je možné zaplnit. Z toho důvodu si útočníci v poslední době začali vytvářet vlastní domény naplněné záznamy tak, aby vracely co největší možné odpovědi, viz ukázka výstupu dotazu na obrázku 4.2. Příkladem takovýchto domén je v současné době stále aktivní doména fkfkfkfa.com, případně již korektně fungující domény pkts.asia, bitstress.com2 . fkfkfkfa.com. fkfkfkfa.com. fkfkfkfa.com. fkfkfkfa.com.

86378 86378 86378 86378

IN IN IN IN

A A A A

204.46.43.113 204.46.43.114 204.46.43.115 204.46.43.116

Obrázek 4.2: Ukázka části výstupu dotazy typu ANY pro doménu fkfkfkfa.com. 2. Další domény používané k amplifikaci je možné naleznout na http://dnsamplificationattacks.blogspot.cz

39

4. Anomálie provozu DNS Aby útočník mohl provést amplifikační útok, potřebuje nalézt vhodný server DNS, který obslouží jeho požadavky. Potřebuje tedy server schopný provádět rekurzivní překlad pro dotazy přicházející od útočníka. Servery v lokální síti mají, ve správném nastavení umožněny rekurzivního překlady pouze pro dotazy z lokální sítě. V případě serverů poskytovatelů internetových služeb je ve správné konfiguraci nastavena metoda omezení počtu dotazů na jednoho klienta tak, aby se zabránilo amplifikačním útokům. Pokud některé z těchto pravidel, ať už pro lokální servery nebo servery poskytovatelů, není dodrženo, může útočník využít server k zesílení. Kromě používání legitimních serverů DNS využívají útočníci také zařízení napadená škodlivým software, který zprovozní na daném stroji veřejný DNS resolver. Útočník tak nemusí vyhledávat a zkoušet servery DNS, které mu umožní reverzní dotazy. Důležitou roli při amplifikačním útoku hraje maximální velikost UDP paketu. V případě, že objem dat přesáhne definovanou velikost paketu, server zašle pouze část odpovědi. Následně je na klientovi, aby navázal TCP spojení, během kterého se již přenese její zbytek. Útočník tedy musí využít pouze maximální velikost UDP paketu, neboť ve chvíli kdy ji přesáhne, je výsledná odpověď v UDP paketu výrazně zkrácena. Obvyklou hodnotou maximální velikosti UDP paketu je 4096 B. Uměle vytvořené domény často bývají naplněny tak, aby se této hodnotě co nejvíce přiblížily. Pokud útočník získá administrátorský přístup k serveru Microsoft DNS, může v registrech zařízení nastavit maximální velikost až 16 384 B, což umožní zvětšení UDP paketu až 200krát. Tento postup ale není příliš používán, neboť je třeba získat přístup k serveru. Amplifikační útoky využívající DNS jsou velmi rozšířenou formou DDoS útoků. Mezi nejznámější útoky lze zařadit útok z roku 2013 na servery společnosti Spamhaus [41]. Tento útok bývá označován jako největší útok v historii Internetu. Útok trval téměř celý den a během špičky bylo dosaženo objemu až 300 Gb dat za sekundu. Amplifikační útoky je možné zaznamenat i v České republice. Příkladem je krátký listopadový útok na společnost ACTIVE 24 [10].

4.2.3 Dotazy na neobvyklé typy záznamů Mezi další bezpečnostní anomálie patří časté dotazování na neobvyklé typy záznamů. V rámci běžného provozu jsou nejvíce dotazovány záznamy typu A, AAAA a PTR. Tyto záznamy slouží pro běžný převod jména na IP adresu a opačně. V případě, že výrazně vzroste počet dotazů na jiné typy záznamů, může to znamenat obvykle přítomnost škodlivého software v síti. Kromě zmíněných typů záznamů jsou běžně využívány i další jako jsou MX pro e-mailové služby, TXT nebo třeba NS. Počet dotazů na tyto typy záznamů ovšem není příliš výrazný. Proto lze jakékoliv výrazně zvýšení počtu dotazů považovat za bezpečnostní anomálii, která by měla být dále prošetřena. Příkladem chování značícího nakažené zařízení je nárůst dotazů typu MX. Tyto záznamy jsou dotazovány při odesílání e-mailů z SMTP serveru na jiný s cílem zjistit, pod jakou IP adresou je na dané doméně provozován e-mailový server. Pro SMTP servery je toto běžné chování. Pokud ovšem začne takovéto dotazy pokládat jiné zařízení v síti, jedná se pravděpodobně o škodlivý software snažící se rozesílat nevyžádanou poštu (SPAM). Takové rozesílání je charakteristické tím, že je zasíláno velké množství e-mailů na velké množství různých domén. Díky tomu výrazně naroste počet pokládaných dotazů. Kromě dotazu typu MX identifikoval Schonewille [46] ve své práci také podezřelý nárůst dotazů typu AXFR. Tyto dotazy slouží k přenosu zónových souborů mezi samotnými servery. Dochází tak k replikaci DNS, aby záložní server měl stejná data jako server primární. V základním nastavení je přeposílání zónových souborů zakázáno, případně je umožněno pouze serverům s předem definovanými IP adresami. Administrátoři ovšem někdy toto nastavení změní, čímž umožní přenos zónového souboru i mimo lokální síť. V případě, že se útočník dokáže dostat k takovému souboru, získá detailní přehled o všech zařízeních a službách, které spadají pod danou 40

4. Anomálie provozu DNS doménu. Zaznamenání tohoto typu dotazu může označovat útočníka snažícího se proniknout do sítě. 4.2.4 Dotazování závadných domén Mezi další možnosti, jak monitorování DNS může přispět k odhalení nakaženého zařízení je sledování dotazů na závadné domény. Pod pojmem závadná doména je myšlena doména obsahující služby, které využívá škodlivý software, ať už ke svému šíření nebo řízení. Tyto domény mohou označovat jak webové stránky obsahující závadný kód, tak i další služby, jakými je například IRC chat a podobné, používané k ovládání nainstalovaného škodlivého softwaru. Částečně do této kategorie spadají i cybersquattingové domény popsané dříve. V případě, že existuje seznam závadných domén, je možné sledovat dotazy klientů a na základě takovéhoto seznamu určit, zda je klient potencionálně nakažen škodlivým softwarem. Možný je také opačný přístup, kdy existuje seznam povolených domén. Takový seznam může být například databáze nejčastěji dotazovaných domén3 , u kterých lze předpokládat, že budou nezávadné. Z hlediska bezpečnostního monitoringu hrají DNS záznamy velkou roli při detailnější analýze chování klienta. Jak již bylo zmíněno v sekci 3.2.2, záznamy o síťových tocích obsahují pouze informace ze 3. a 4. síťové vrstvy referenčního ISO OSI modelu. Jedna IP adresa ovšem může poskytovat více služeb (například webhosting), případně se za ní může skrývat více zařízení. V případě webhostingu tak není možné určit, kterou konkrétní stránku uživatel navštívil. V případě monitorování DNS je možné rozšířit znalost IP adresy i o dotazovanou doménu. Díky tomu lze například rozlišit, zda oběť navštívila phishingové stránky nebo legitimní stránky provozované na stejném serveru. Tabulka 4.1 obsahuje příklady potencionálně závadných domén, které byly dotazovány stroji ze sítě Masarykovy univerzity. K těmto doménám je doplněn údaj, v kolika seznamech se nacházela doména při její analýze službou VirusTotal [55], fungující jako agregátor databází závadných domén. Doména getthefilenow.info cybeitrapp.info www.tns-counter.ru st.cloins.com www.softosystem.com

Databáze Fortinet, Malwarebytes hpHosts, Websense ThreatSeeker, malwares.com URL checker Dr.Web, Fortinet, Malwarebytes hpHosts, Websense ThreatSeeker, malwares.com URL checker Comodo Site Inspector, WOT, Webutation BitDefender, Sophos, WOT, Webutation ADMINUSLabs, AutoShun, Dr.Web, Emsisoft, G-Data, Malwarebytes hpHosts, Sophos

Tabulka 4.1: Příklady potencionálně závadných domény z dotazů klientů MU (tabulka je doplněna o informace ve kterých databázích je doména označena jako závadná). Informace z provozu DNS tedy umožňují lépe prozkoumat chování napadeného stroje. Například je možné prozkoumat, které domény stroj navštívil před napadením a odhalit tak zdroj, ze kterého byl škodlivý software potencionálně rozšířen. Tuto znalost lze následně použít k zablokování zdroje šíření, případně reportování provozovateli služby. Kromě analýzy dotazů před napadením je možné analyzovat i dotazy prováděné po napadení. Většina škodlivého software se po proniknutí do systému snaží kontaktovat svá řídící centra, která jim umožní stažení dodatečných souborů, případě předají povely. Podle odhalené závadné domény je možné také vyhledat ta zařízení, která se dotazovala na danou doménu a určit další možné nakažené stroje v síti. Mezi hlavní nevýhody monitorování dotazů na závadné domény ovšem patří nadměrný počet takovýchto dotazů. V případě velkých sítí, jakými je například Masarykovy univerzita, není 3. Mezi největší takový seznam patří databáze společnosti Alexa dostupná na http://www.alexa.com/topsites.

41

4. Anomálie provozu DNS možné analyzovat veškeré dotazy, které klienti v síti vytváří. Sledování všech dotazů a vyhledávání závadných domén je tedy spíše vhodné pro menší sítě, kde tato metoda může poskytnout výrazné navýšení bezpečnosti. V případě velkých sítí se nabízí pouze možnost identifikace dalších nakažených zařízení, tak jak bylo zmíněno v předchozím odstavci. 4.2.5 Domény specifických vlastností Pod pojmem domény specifických vlastností jsou myšleny domény, které se jakýmkoliv způsobem odlišují od klasických, normálně používaných domén. Příkladem takovéto odlišnosti je hodnota atributu TTL určujícího, jak dlouho má být udržován záznam ve vyrovnávací paměti resolveru. Podle RFC 1912 je typické nastavení pro platnost záznamu 1 až 5 dní tak, aby nedocházelo k přetěžování DNS a linek. Toto nastavení se ovšem týká záznamů, které jsou stálé a téměř neměnné. V případě, že pod danou doménou je provozována služba, která musí být schopná vypořádat se s větší zátěží, bývá pod jednu doménu přiděleno více IP adres. Když se klient dotazuje na takovou doménu, kontaktuje první ze seznamu vrácených IP adres. V případě, že se dotazuje znovu, pořadí IP adres v záznamu se změní. Díky tomu dochází k vyvažování zátěže jednotlivých serverů. Stejný princip ovšem využívají i domény, na kterých se nachází řídící centra škodlivého software nebo například phishingové weby. Tento druh domén je obvykle označován pojmem fast-flux. Fast-flux domény se oproti standardním doménám liší velkým množstvím IP adres přiřazeným jednotlivým záznamům. Tyto IP adresy obvykle představují infikované stroje nic netušících obětí, kde je provozován web případně nějaké řídící centrum. Z důvodu, že tyto IP adresy nemají zajištěnou konektivitu (vypnutí zařízení, odhalení škodlivého software), nachází se jich v záznamu velké množství. V rámci domény tak dochází k častým změnám IP adres, které jsou realizovány pomocí velmi nízké hodnoty TTL. Snížení TTL na minimum zajistí, že pokaždé když se škodlivý software zeptá na danou doménu, získá IP adresu, která je velice pravděpodobně stále funkční. Nízkou hodnotou TTL a velkým počtem IP adres v záznamu je tedy možné odhalit potencionální fast-flux domény. Principu takovéto detekce se věnují ve svých pracích například Villamarín-Salomón [54], Perdisci [40] nebo Bilge [4]. Kromě specifické hodnoty TTL je možné využít i dalších vlastností k rozlišení fast-flux domén. Příkladem je analýza IP adres, které jsou pro danou domény vráceny v odpovědi. V případě, že je vraceno více IP adres měly by všechny spadat pod stejného správce. Tuto vlastnost je možné určit podle čísla autonomního systému (ASN), které má daná IP adresa přiřazené. Pokud IP adresy dotazované domény spadají pod jiné autonomní systémy, může to označovat doménu odkazující na nakažená zařízení. Škodlivý software je také obvykle rozšířen po celém světě. Kromě čísla ASN je tedy možné využít ještě geolokaci a sledovat, zda se dané IP adresy nachází na stejném místě. V případě velkých služeb jako je například Google může ale zmíněná metoda vyvolat nesprávná upozornění. Kromě zmíněných atributů odpovědi, do specifických vlastností patří i název samotné domény. V obvyklých případech jsou domény tvořeny slovy, případně slovními spojeními. Tato vlastnost ovšem nemusí platit pro domény generované automaticky různým škodlivým softwarem, případně domény dotazované při tunelování provozu, viz sekce 4.1.2. V tomto případě jsou domény obvykle tvořeny různými znaky, které nedávají běžnému člověku smysl. Detekci takovýchto domén se zabývá ve své práci Marchal [29]. Který představil matematické metody schopné analyzovat jednotlivé celky jména domény a označit doménu za podezřelou. 4.2.6 Společné chování více zařízení Mezi bezpečnostní anomálie spadá i detekování stejného chování více strojů v síti ve stejný čas. Tato anomálie může značit pouze náhodu, pokud je ovšem chování dlouhodoběji stejné, může se jednat o stroje napadené stejným škodlivým softwarem. Pravděpodobně se jedná o botnet 42

4. Anomálie provozu DNS plnící jednotlivé příkazy. Tyto příkazy přichází obvykle z řídícího centra ve stejný čas na všechna napadená zařízení. V případě, že se jedná o povel k útoku, zařízení začnou podnikat stejné kroky, které je možné následně dále detekovat. Kromě zvýšeného provozu a komunikací se stejnými IP adresami je možné vysledovat i dotazy na stejné domény. Z pohledu detekce takovéhoto chování je vhodné analyzovat spíše samotné dotazy DNS, místo korelace celého provozu. Zprávy DNS představují pouze část celkového provozu a je tak možné nad nimi provádět analýzu rychleji. Problematice detekce botnetů pomocí stejného chování se věnuje Choi [5]. Ten identifikoval 5 situací, během kterých botnet vykazuje DNS aktivitu: ∙

Dotaz na doménu řídícího centra a získání IP adresy.

∙

Dotaz na neexistující doménu řídícího centra. V tomto případě se jedná o doménu, která byla zrušena z důvodu její závadnosti.

∙

Opětovný dotaz na doménu řídícího centra v případě, že daná IP adresa přestane komunikovat (dojde k přesměrování řídícího centra).

∙

Vytváření dotazů při přemisťování samotného řídícího centra.

∙

Provádění útoků jakými jsou např. DDoS amplifikační útok nebo rozesílání spamu.

Většina z těchto situací sama o sobě není rozlišitelná od normálního provozu v síti. Pokud ovšem stejná situace nastane na více strojích v přibližně stejný čas, je možné takovéto chování rozlišit od ostatního provozu. Z pohledu možné detekce tohoto chování je nevýhodou, že zařízení v síti musí být nakaženy stejným druhem škodlivého softwaru. Tato anomálie tedy nastává spíše ve větších sítích s velkým množstvím zařízení. V případě malých sítí lze takto detekovat pouze škodlivý software, který se úspěšně rozšířil přes lokální síť nebo e-maily a nainstaloval se tak na více strojů. Výhodou je, že v případě analýzy na velkých sítích lze pomocí této anomálie odhalit i dosud neznámé druhy botnetů.

4.3

Analýza provozu DNS v síti MU

V síti Masarykovy univerzity je pro bezpečnostní monitoring využívána technologie IP toků popsaná v sekci 3.2.2. V současné době je podporován export informací z provozu DNS pouze z jedné síťové sondy na hranici sítě. Data tedy neobsahují informace z vnitřních podsítí a nejsou tak viditelné dotazy obsluhované lokálními servery DNS. Do budoucna je ovšem plánováno rozšířit sledování DNS i do podsítí tak, aby bylo možné analyzovat co největší množství provozu. Typ síťových toků Základní Rozšířené o data DNS

Počet paketů (tis.) 18 170 18 138 Δ 31

Počet MB 1 439 1 436 Δ2

Počet toků (tis.) 18 144 18 136 Δ7

Tabulka 4.2: Porovnání detekcí DNS provozu pro 11. 12. 2013. Detekce DNS přináší výrazné rozšíření informací o provozu na síti, než které doposud nabízelo standardní NetFlow. Díky záznamům o provozu DNS je možné přesně rozlišit skutečný DNS provoz od veškerého provozu spojeného se síťovými porty využívanými protokolem DNS. Tento fakt je znázorněn v tabulce 4.2 obsahující statistiku odchozího provozu. Statistiky prvního řádku tabulky jsou založeny pouze na filtrování cílového portu 53, UDP i TCP provozu, zatímco druhý řádek již obsahuje pouze statistiky z toků nesoucích protokol DNS. Odlišnost těchto dvou přístupů je velmi dobře vidět pomocí rozdílu jednotlivých statistik. V případě analýzy pouze standardních NetFlow by bylo přibližně sedm tisíc toků mylně považováno za provoz DNS. Ve 43

4. Anomálie provozu DNS skutečnosti se jedná pouze o využití portu 53 jinou aplikací, která se například pokouší obejít možná pravidla firewallu. Dotazované typy záznamů Díky přesnému rozlišení a získání dodatečných informací o provozu DNS je možné získat další statistiky, které velmi dobře vytváří základní přehled o dění v síti. Příkladem takového přehledu je statistika nejčastěji dotazovaných typů záznamů uvedená na obrázku 4.3. Na prvních místech se vyskytují očekávávané záznamy typu A a AAAA. Oproti předpokladu se ovšem na třetí místě, namísto reverzních dotazů, nachází dotazy typu DS související s využíváním protokolu DNSSEC. Je tedy zřejmé, že protokol DNSSEC je v rámci sítě Masarykovy univerzity široce používán. Při konkrétním zaměření se na využívání protokolu DNSSEC vychází, že byl požadován v přibližně 77 % všech odchozích dotazů. Tyto dotazy jsou převážně vytvářeny servery DNS Masarykovy univerzity, které mají použití protokolu DNSSEC nastaveno.

DS; 1191 SRV; 9

SPF; 62

DNSKEY; 67

AAAA; 4346

MX; 96

TXT; 264

A; 11414

PTR; 582 SOA; 14 NS; 62 Obrázek 4.3: Statistika nejčastěji dotazovaných typů záznamů, podle počtu toků (tis.), ze dne 11. 12. 2013.

Návratové kódy odpovědí DNS Další vhodnou statistiku popisující aktuální dění v síti představuje tabulka 4.3 obsahující návratové kódy odpovědí DNS. Tato statistika může velmi dobře sloužit správcům při hledání chybných nastavení DNS. Z uvedených dat vyplývá, že přibližně 90 % odpovědí bylo zodpovězeno bez jakýchkoliv potíží. Kódy NXDOMAIN, REFUSED a SERVFAIL odpovídají překlepům a dalších chybám, které se v dotazech mohou vyskytnout. Jejich množství je ovšem pro velkou síť, jakou je síť Masarykovy univerzity, očekávávané a nijak nevybočuje z předpokládaného chování. Odpovědí (tis.) 8243 480 176 154 17 3

Podíl 90,7 % 5,3 % 1,9 % 1,7 % 0,2 % 0,0 %

Návratový kód NOERROR NXDOMAIN REFUSED SERVFAIL NOTIMPL FORMERR

Tabulka 4.3: Statistika návratových kódů DNS odpovědí pro síť MU ze dne 11. 12. 2013.

44

4. Anomálie provozu DNS Dotazované domény Spolu se souhrnnými informacemi o provozu DNS je velmi zajímavým zdrojem dat i statistika dotazovaných domén. Kromě odhalení výrazně často dotazovaných neobvyklých domén, může tato statistika sloužit i jako zdroj dat pro analýzu chování uživatelů v síti. Tabulka 4.4 zobrazuje 20 nejčastěji dotazovaných domén v síti MU, v porovnání se seznamem nejčastěji dotazovaných domén (v rámci České republiky) vytvářeným organizací Alexa. Nejčastěji dotazované domény v síti MU jsou rozděleny na dva sloupce, kde první představuje domény z celé sítě MU. Druhý sloupec obsahuje pouze dotazy z podsítí eduroam, vpn a jednotlivých kolejí, kde se obvykle nachází zařízení samotných uživatelů a data tak nejsou „zkreslena“ dotazy generovanými servery a jinými specifickými zařízeními. Zajímavým výsledkem je, že po přidání podsítě vpn k eduroam a podsítím kolejí nedošlo kromě jednoho záznamu žádné změně nejvíce dotazovaných domén. Ze statistiky nejčastěji dotazovaných domén vyplývá, že v případě celé sítě je nejčastěji dotazovaná platforma doručování dat (Content Delivery Network) organizace Akamai. Jsou zde také velmi dobře vidět dotazy vytvářené antispamovými řešeními e-mailových serverů, konkrétně dotazované domény spamhaus.org a spamcop.net. Výraznou anomálii představují reverzní dotazy na doménu 50.84.81.194.in-addr.arpa. IP adresa 194.81.84.50 patří do rozsahu Institute of Cancer Research v Anglii. Může se tak pravděpodobně jednat o špatně nastavený server MU sloužící pro zpracování medicínských dat, který nějakým způsobem komunikuje se zmíněnou IP adresou a pokouší se ověřit její totožnost. Pořadí 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.

Celá síť MU akamai.net google.com akamaiedge.net akadns.net vk.me akamaihd.net amazonaws.com idnes.cz gstatic.com spamhaus.org facebook.com 194.in-addr.arpa sme.sk twitter.com spamcop.net seznam.cz microsoft.com muni.cz edgesuite.net cloudfront.net

Podsíť rozsahů eduroam a kolejí MU google.com youtube.com akamaihd.net facebook.com muni.cz ubuntu.com gstatic.com microsoft.com googleusercontent.com sme.sk twitter.com wikipedia.org fbcdn.net apple.com msftncsi.com root-servers.net seznam.cz idnes.cz google-analytics.com doubleclick.net

Alexa pro ČR google.cz facebook.com seznam.cz google.com youtube.com novinky.cz idnes.cz super.cz wikipedia.org centrum.cz heureka.cz aukro.cz szn.cz alza.cz csfd.cz sport.cz zbozi.cz blesk.cz uloz.to neobux.com

Tabulka 4.4: Porovnání nejvíce dotazovaných domén z 11. 12. 2013. se seznamem organizace Alexa. V případě nejvíce dotazovaných domén z podsítí eduroam, vpn a kolejí MU uvedených v tabulce 4.4 již výsledek odpovídá běžnému chování uživatelů webových služeb. V případě porovnání těchto výsledků s výsledky publikovanými organizací Alexa je zajímavé, že v rámci sítě MU je využívána anglická adresa služeb Google, přičemž organizace Alexa na první místo řadí její českou verzi a anglickou až na čtvrté místo. Ve statistice domén v rámci podsítí MU jsou přítomny 45

4. Anomálie provozu DNS také domény ubuntu.com a apple.com, které jsou dotazovány samotným operačním systémem, například pro získání aktualizací, a nejsou obsaženy ve statistice organizace Alexa. Neexistující domény Kromě statistiky všech dotazovaných domén v rámci sítě je vhodným zdrojem dat i analýza domén, na které v rámci odpovědi byla vrácena informace, že neexistují. Tabulka 4.5 ukazuje statistiku takovýchto domén. Počet dotazů 3084 2666 2661 1115 1066 1066 520 514 512 444 444

Podíl 2,7 % 2,4 % 2,4 % 1,0 % 0,9 % 0,9 % 0,5 % 0,5 % 0,5 % 0,4 % 0,4 %

Doména 36.4.251.147.bl.spamcop.net 36.4.251.147.sa-accredit.habeas.com 36.4.251.147.sa-trusted.bondedsender.org 96.49.251.147.bl.spamcop.net 96.49.251.147.sa-trusted.bondedsender.org 96.49.251.147.sa-accredit.habeas.com muni.cz.multi.uribl.com muni.cz.dbl.spamhaus.org 36.4.251.147.cbl.abuseat.org beruĹĄka.mifa beruĹĄka.eduroam.muni.cz

Tabulka 4.5: Statistika dotazů na neexistující domény. Z uvedené statistiky je možné velmi dobře vidět dotazy na různé RBL, které vrací informaci, že daná IP adresa není závadná. Údajem, který by neměl uniknout potencionálním administrátorům, je dotazovaní na doménu obsahující slovo beruĹĄka. V tomto případě se pravděpodobně jedná o jméno počítače, které obsahuje diakritiku. Tuto diakritiku ovšem použitý resolver nezvládl správně zpracovat, což vedlo k takovéto deformaci. Diakritika v současné době v rámci doménových jmen není povolena. Z toho důvodu takovéto nastavení jména počítače může způsobovat problémy, například při vzdáleném připojování. Dotazované externí servery DNS Se statistikou nejčastěji dotazovaných domén velmi souvisí statistika ohledně nejčastěji dotazovaných externích serverů DNS uvedená v tabulce 4.6. Tabulka obsahuje servery DNS, které jsou dotazovány jak samotnými klienty, tak resolvery v síti Masarykovy univerzity. Tato statistika by podle očekávání měla na prvních místech obsahovat servery obsluhující domény prvního řádu. Následně po těchto serverech by měly být uvedeny servery DNS náležící nejvíce používaným internetovým službám. V uvedené statistice ovšem nejvíce vyniká IP adresa 8.8.8.8 směřující na veřejný DNS resolver provozovaný společností Google. Tento server není používán pouze pro překlad doménových jmen náležícím službám Google, ale slouží primárně jako DNS resolver. Z uvedené statistiky tedy jednoznačně vyplývá, že tento server je nastaven jako primární pro velké množství zařízení v síti MU, což může výrazně snižovat rychlost překladu doménových jmen. Dané nastavení také představuje potencionální bezpečnostní riziko, neboť dotazy na doménová jména jsou zpracovávány mimo síť MU. Z následné analýzy bylo zjištěno, že tento server DNS měly jako primární nastaveny některé směrovače páteřní infrastruktury sítě MU. Správci sítě byly na tuto skutečnost upozorněni a na na základě tohoto upozornění byly směrovače přenastaveny na použití lokálního DNS serveru Masarykovy univerzity. Kromě vysoké pozice serveru DNS společnosti Google, je dalším zajímavým záznamem ve statistice IP adresa 193.108.88.129. Tato adresa nemá přiřazený reverzní DNS záznam, což může 46

4. Anomálie provozu DNS znamenat podvodný server DNS. Podle záznamu whois databáze se ovšem jedná o server organizace Akamai, která na této IP adresa pravděpodobně obsluhuje dotazy pro své služby. Počet dotazů (tis.) 3434 867 342 231 207 176 175 166 106 101

IP adresa 8.8.8.8 192.33.14.30 216.239.36.10 77.75.73.77 193.108.88.129 194.0.12.1 193.29.206.1 195.113.192.209 194.79.55.77 213.199.180.53

Doménové jméno google-public-dns-a.google.com b.gtld-servers.net ns3.google.com ns.seznam.cz – a.ns.nic.cz d.ns.nic.cz ns.nemho.cz ns2.mafra.cz ns3.msft.net

Tabulka 4.6: Nejvíce dotazované externí servery DNS ze dne 11. 12. 2013.

Dotazy na lokální servery DNS z venkovní sítě V případě, že je v síti přítomný server DNS, který obsluhuje i dotazy z jiných sítí než lokálních, je vhodné vytvářet statistiky i o tomto provozu. V případě sítě Masarykovy univerzity se jedná například o servery DNS, které poskytují překlad doménových jmen pro střední školy zapojené v síti CESNET. Díky statistice o počtu dotazů na jednotlivé domény byl v rámci řešení diplomové práce identifikován špatně nastavený DNS server jiné univerzity v Brně. Tento server se vyznačoval specifickým chováním, kdy vytvářel příliš mnoho stejných dotazů na DNS server Masarykovy univerzity, viz tabulka 4.7 nejvýraznějších hodnot. Doba trvání (sek.) 23 808 16 200 50

Počet paketů 1065 422 226

Počet bytů 77 745 30 806 17 402

Doména 53.218.220.162.in-addr.arpa 17.159.175.203.in-addr.arpa 241.240.52.179.114.in-addr.arpa

Tabulka 4.7: Dotazy špatně nastaveného serveru DNS. Správce serveru, vytvářejícího takovéto množství dotazů, byl na tento fakt upozorněn. Během následné analýzy odhalil, že velký počet PTR dotazů byl vytvářen DNS cachovacím serverem, který měl nastaven v resolveru samotného serveru právě DNS server Masarykovy univerzity. Když se serveru na dotaz vrátila odpověď SERVFAIL, dotazoval se dál serverů DNS, které měl uvedené v nastavení. Právě toto chování způsobilo velký počet reverzních dotazů na IP adresy, které se v síti Masarykovy univerzity nenachází, díky čemuž na tyto dotazy nebyla vracena odpověď. Server DNS dané univerzity se tak zbytečně dotazoval nesprávného serveru, což prodlužovalo dobu překladu reverzního dotazu.

47

Kapitola 5

Metody detekce anomálií provozu DNS Kapitola se věnuje vyvinutým detekčním metodám sloužícím pro detekci vybraných anomálií. Tyto anomálie byly vybrány na základě jejich dopadu na bezpečnost sítě a jejich potencionálním užitku. V kapitole jsou obsaženy metody detekce využívání externích DNS resolverů, návštěv vizuálně podobných domén, amplifikačních útoků a s nimi související metoda detekce otevřených DNS resolverů. Dále je představen koncept detekce dotazování závadných domén spojených s činností škodlivého software. Pro každou z metod je uveden její základní princip spolu s popisem její implementace pro síť Masarykovy univerzity. Tyto implementace jsou součástí přílohy diplomové práce. Skripty využívající rozšířené IP toky jsou souhrnně zařazeny do balíku DNSAnomDet. Vyvinuté detekční metody a jejich implementace jsou v závěru kapitoly vzájemně porovnány. Každá z uvedených metod je doplněna vyhodnocením jejího nasazení v síti Masarykovy univerzity. Architektura zapojení jednotlivých prvků detekci anomálií v síti MU je znázorněna na obrázku 5.1. Síťová sonda schopná exportovat i DNS data je nasazena pouze na hranici sítě MU, což má vliv na implementaci a následné vyhodnocení detekčních metod. Některé výsledky z detekovaných anomálií, během nasazení detekčních metod, byly nahlášeny odpovědným administrátorům, díky čemuž bylo opraveno chybné nastavení serverů DNS a dalších zařízení v síti MU. Síťová sonda Zásuvný modul DNS

NetFlow/IPFIX

Reportovací systém

IPFIX/NetFlow kolektor Výsledky detekcí Detekční skripty

Pomocná data

Databáze

Obrázek 5.1: Architektura pro detekci anomálií v provozu DNS.

V rámci detekčních skriptů využívajících nástroj fbitdump jsou využívány atributy filtru, které nejsou plně standardizovány. Tabulka 5.1 stručně vysvětluje význam jednotlivých atributů tak, aby bylo možné v případě jiné implementace nástroje pro analýzu IPFIX dat využít atributy se stejným významem. 48

5. Metody detekce anomálií provozu DNS Atribut %srcip4 %dstip4 %srcport %dstport %ts %pkt %dnsname %dnsqtype %dnsrdata %dnsrlen %dnsrcode %dnspsize %dnsdo

Význam Zdrojová IPv4 adresa Cílová IPv4 adresa Zdrojový port Cílový port Čas začátku toku Počet paketů v rámci toku Doménové jméno Typ dotazovaného záznamu Obsah odpovědi DNS Délka položky %dnsrdata Návratový kód odpovědi DNS Maximální definovaná velikost UDP paketu DNS Informace, zda je vyžadováno použití DNSSEC

Tabulka 5.1: Používané atributy filtru nástroje fbitdump.

5.1

Detekce využívání DNS resolverů mimo lokální síť

Detekce využívání externích DNS resolverů slouží primárně k upozornění správců na možné problémy s nastavením DNS. Primární snahou je zavést používání lokálních serverů DNS tak, aby nebyl provoz náležící lokální síti zbytečně rozšířen i mimo tuto síť. Hlavní problematikou detekce je rozlišení serverů DNS od ostatních zařízení v síti. Ideální nastavení představuje stav, kdy se externích serverů DNS dotazuje pouze lokální DNS resolver, který překládá dotazy jednotlivých klientů. Pokud ovšem existuje v síti i klient využívající externí DNS resolver, tak vykazuje podobné chování. V případě menších sítí je možné tento problém vyřešit pomocí seznamu lokálních serverů DNS a upozorňovat pouze na IP adresy, které nespadají do tohoto seznamu. Pro servery DNS ve větších sítích ovšem takovýto seznam nemusí existovat, a není tedy možné provádět takto zjednodušenou detekci. V rámci řešení diplomové práce byly vytvořeny dvě rozdílné metody pro detekci využívání externích DNS resolverů. První řeší danou problematiku nad standardními IP toky. Druhá metoda již využívá IP toky rozšířené o data z provozu DNS. Velmi názorně tak představuje, jak toto rozšíření dokáže zpřesnit a zefektivnit detekci používání externích DNS resolverů.

5.1.1 Metoda využívající standardní IP toky Jak již bylo zmíněno primárním problémem detekce externích DNS resolverů je rozlišení legitimních serverů DNS od ostatních zařízení. Metoda analyzující standardními IP toky využívá faktu, že servery DNS dotazují více externích serverů DNS, zatímco ostatní zařízení obvykle dotazují pouze jeden server DNS, který mají uvedený v nastavení. Pro zjištění klientů využívajících pouze jeden server DNS je využita sekvence příkazů, jejíž základ tvoří filtr pro program nfdump sloužícím pro dotazování nad IP toky ve formátu NetFlow: nfdump -M -R . "proto UDP and dst port 53 and src net and not dst net " -q -A srcip,dstip -o "fmt:%sa|%da|%fl|%ts" Pomocí tohoto příkazu jsou vybrány pouze toky obsahující komunikaci s externím serverem DNS. Výběr je proveden pomocí omezení na lokální síť a cílový port 53 využívaný pro DNS komunikaci. Vyfiltrované toky jsou následně agregovány podle skupin zdrojová-cílová IP adresa, 49

5. Metody detekce anomálií provozu DNS díky čemuž nedochází ke zbytečné duplikaci dat. Z tohoto výstupu je následně třeba odstranit opakující se záznamy například pomocí následující sekvence linuxových příkazů: | sort -n -t "." -k 1,1 -k 2,2 -k 3,3 -k 4,4 | uniq -u -w 17 Jelikož jsou analyzována standardní NetFlow data, nelze vyloučit, že IP toky obsahují tunelování provozu nebo se pod jednou IP adresou střídá více zařízení. Nejsou také odhaleni klienti, kteří využívají i sekundární server DNS. V obdrženém výsledku se tedy nachází i nesprávné záznamy, které je třeba eliminovat. K tomuto účelu je nejvýhodnější použít databázi, kam se výsledná data nahrají, a bude možné s nimi dále pracovat. Aby bylo vyloučeno detekování nesprávných výsledků, je třeba z databáze vybírat takové komunikace, které odpovídají reálnému používání serveru DNS. V případě analýzy např. jednou za měsíc je vhodné vybrat pouze ty klienty, kteří komunikovali se serverem DNS minimálně během 13 dnů s průměrným počtem 20 dotazů. Tyto hodnoty vychází z analýzy získaných záznamů, přičemž hranice je nastavena tak, aby bylo odhaleno co nejvíce zařízení s minimálním počtem nesprávných upozornění. Implementace Implementace metody je rozdělena do dvou skriptů. Skript DNS_external_analyser zajišťuje analýzu dat z jednoho dne a nahrání výsledků do databáze. Databáze obsahuje pouze jednu tabulku obsahující časové značky, počet toků, IP adresy klientů a serverů. Pro usnadnění reportování a následné analýzy je k oběma IP adresám doplněno také jejich doménové jméno. O vyhodnocení dat z databáze a hlášení výsledků se následně stará skript DNS_external_reporter. Skript hlásí pouze pro zařízení v síti MU se statickou IP adresou. Jsou tedy vynechány rozsahy podsíti kolejí, eduroam a vpn. V rámci hlášení výsledků jsou zvýrazněny pravděpodobné překlepy v nastavení serveru DNS. Jako překlep je brána cílová IP adresa, která se od IP adresy lokální sítě liší v jedné číslici. V případě Masarykovy univerzity (rozsah 147.251.0.0/16) se může jednat například o překlep 148.251.4.33. Tato detekce je pro správce velmi užitečná neboť odhaluje špatně nastavený server DNS, což způsobuje prodlužování doby překladu čekáním na vypršení intervalu a využití sekundárního serveru DNS. 5.1.2 Metoda využívající rozšířené IP toky Při použití rozšířených IP toků je možné zvolit jiný přístup k rozlišení serveru DNS od ostatních zařízení. Tímto přístupem je detekce navštívení dotazované domény. Server DNS totiž slouží pouze k překladu doménových jmen, přičemž získanou IP adresu již navštěvuje klient sám. Naopak, pokud klient dotazuje externí DNS resolver, dotazovanou doménu také navštíví (kromě případů zmíněných v sekci 4.1.1). Detekční metoda je rozdělena do dvou fází. V první fázi jsou z rozšířených IP toků vybrány všechny IP adresy dotazující server DNS mimo definovanou lokální síť. K tomu je využit následující filtr pro nástroj fbitdump: fbitdump -R "%srcip4 == and %dstip4 != and %dstport == 53 and exists %dnsname" -A%srcip4 -q -o "fmt:%srcip4|" Získané IP adresy jsou agregovány, aby nedocházelo ke zbytečným duplicitám. V druhé fázi je třeba provést ověření, zda se jedná o klienta či server. K tomu metoda využívá výpis prvních N dotazovaných domén, které v rámci odpovědi vrací IP adresu. Pokud je nastavena pouze detekce první domény, metoda může, v případě že klient se na IP adresu pouze dotázal bez navštívení, mylně označit IP adresu za DNS server. To ovšem nemusí vadit, neboť při další analýze v jiný 50

5. Metody detekce anomálií provozu DNS čas, již může klient jinou dotazovanou doménu navštívit, a bude tak správně detekován. Pokud je ovšem potřeba detekovat všechny klienty během jedné analýzy, je třeba volit hodnotu N vyšší. Příkaz pro výběr dotazovaných domén pro specifickou IP adresu uvádí následující příklad: fbitdump -R <složka s IFIX daty> "%dstip4 == and %srcip4 != and %srcport == 53 and exists %dnsname and %dnsrlen == 4" -n -q -o "fmt:%ts|%dnsrdata|%srcip4" Samotná detekce návštěvy domény využívá hodnotu IP adresy z paketu odpovědi. V rámci IP toků je dohledáno zda zdrojová IP adresa navázala spojení s IP adresou náležící doméně do dvou sekund od položení dotazu na doménu. Dvě sekundy představují optimální limit, za který klient navštíví danou IP adresu i v případě nějakého zpoždění. Pokud návštěva není detekována, je takto vyzkoušena další doména, až do N-tého pokusu. Jestliže žádná doména nebyla navštívena, je zdrojová IP označena za server DNS a není dále reportována. Následující příklad uvádí příkaz pro detekci navštívení domény: fbitdump -R <složka s IPFIX daty> "%ts > <čas dotazu> and %ts < <čas dotazu + 2 sekundy> and %srcip4 == and %dstip4 == and %dstport != 53" -q -n 1 Implementace Metoda využívající rozšířené IP toky je implementována skriptem DNSAnomDet_external_dns. Oproti předchozí metodě tento skript poskytuje výsledky hned po jeho spuštění. Není tedy třeba vyčkávat několik dnů, aby bylo možné získat správné výsledky. V případě provádění analýzy každou hodinu, je dostatečné nastavit hodnotu N na 1, jelikož je velká pravděpodobnost, že při některém ze spuštění bude zařízení využívající externí DNS odhaleno. 5.1.3 Vyhodnocení nasazení Skript analyzující standardní IP toky byl nasazen v síti Masarykovy univerzity v červnu 2013. Výstup primárně slouží jako informace pro správce podsítí, přičemž není vyžadována žádná akce a slouží spíše jako doporučení pro změnu nastavení. Obrázek 5.2 ukazuje graf počtu detekovaných použití externích DNS resolverů v jednotlivých měsících, kde jsou zahrnuty pouze statické IP adresy zařízení v síti MU. Z grafu je zřejmé, že po prvním hlášení byly opraveny téměř všechny překlepy a byla opravena přibližně čtvrtina reportovaných použití externích serverů DNS. Z grafu je také zřejmé, že v každém měsíci se objevilo minimálně jedno nové hlášení o překlepu v nastavení DNS serveru. Skriptem DNS_external_reporter bylo za měsíce červen až listopad nahlášeno celkově 172 zařízení, která měla nastavený externí DNS resolver. Zajímavostí je, že z tohoto počtu celkem 147 používalo server společnosti Google (IP adresa 8.8.8.8). To je způsobeno pravděpodobně jednoduchostí IP adresy, která se snadno zapamatuje. Někteří správci volí tuto IP v případech, kdy si nejsou jistí adresou některého z DNS serverů používaných v síti Masarykovy univerzity. Kromě tohoto veřejného serveru se dále objevují servery projektu OpenDNS a DNS servery sítě CESNET. Podezřelým příkladem bylo detekované použití DNS serveru 214.251.28.2, který nemá přidělené žádné doménové jméno. Může se tak jednat o podvržený server DNS nastavený škodlivým softwarem, sloužící k přesměrování specifických dotazů oběti. Velmi zajímavý výsledek také představují detekce překlepů v nastavení DNS serverů. Díky překlepu byly např. zasílány DNS dotazy jednoho zařízení v síti Masarykovy univerzity na stroj 147.241.8.10 (vpn8-10.atec.army.mil) patřící do americké vojenské sítě. Oproti detekci postavené pouze na analýze standardních IP toků poskytuje skript využívající rozšířené toky výrazně přesnější detekci s eliminací falešných reportů. Skript je také možné 51

Počet serverů

5. Metody detekce anomálií provozu DNS 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10 5 0 Červen

Červenec

Srpen

Počet externích serverů DNS

Září

Říjen

Listopad

Počet překlepů

Obrázek 5.2: Počet klientů využívajících externí DNS resolver v jednotlivých měsících roku 2013.

použít na libovolné časové okno, díky čemuž lze detekovat použití externího DNS téměř hned po přijmutí IP toků na straně kolektoru. Nevýhodu představuje analýza delšího časového okna. V případě potřeby hlášení pouze jednou za měsíc je vhodné spouštět skript v menších pravidelných intervalech a výsledek ukládat do databáze, ze které bude následně vytvářen report pro správce. Porovnání základních vlastností obou skriptů je znázorněno v tabulce 5.2. Pro porovnání jsou využita data za tři dny, kdy v případě skriptu DNS_external_reporter je vyžadována komunikace minimálně během dvou dnů v průměrném počtu minimálně 20 dotazů. Tři dny představují minimální počet dní, kdy lze alespoň částečně vyloučit nesprávné detekce. Uvedený počet nesprávných upozornění je založen na ruční analýze podezřelých výsledků. Z tabulky jasně vyplývá, že použití rozšířených IP toků poskytuje velmi přesnou detekci, ovšem za cenu větší výpočetní náročnosti. Detekční skript DNS_external_* DNSAnomDet_external_dns

Detekovaných zařízení 88 228

Nesprávná upozornění 25 0

Doba běhu ∼ 6 min ∼ 144 min

Tabulka 5.2: Porovnání základních vlastností skriptů pro detekci používání externích DNS resolverů v síti MU ve dnech 2. 1. 2014 až 4. 1. 2014.

5.2

Detekce návštěv vizuálně podobných domén

Pojem cybersquatting pod sebou skrývá velké množství druhů zneužití domény. V rámci diplomové práce byla vytvořena metoda zaměřující se na detekci domén, které zneužívají vizuální podobnost. Tyto domény kromě neškodných informací mohou obsahovat také podvodné stránky sloužící primárně pro sběr přihlašovacích a dalších údajů uživatelů originální domény. Obzvláště velké riziko představuje zvětšený výskyt dotazů na takovéto domény. Tento jev odpovídá šíření phishingových e-mailů, které útočník hromadně zaslal uživatelům v síti. 5.2.1 Popis metody Metoda detekce vizuálně podobných domén je založena na procházení všech dotazovaných domén. Z důvodu, aby nebyla vyvolávána nesprávná upozornění, jsou analyzovány pouze odpovědi 52

5. Metody detekce anomálií provozu DNS DNS. Díky tomu je zajištěno, že dotazovaná doména má přiřazenou funkční IP adresu, pod kterou je dostupný nějaký obsah (web nebo jiná síťová služba). Následující příkaz uvádí volání nástroje fbitdump, při dohledání pouze jedné domény a všech jejich poddomén: fbitdump -R <složka s IPFIX daty> "%srcport == 53 and %dstip4 == and (%dnsname == ’%.<domena>’ or %dnsname == ’<domena>’)" -q -o "fmt:%ts|%dnsname|%dnsrdata" Samotná detekce potencionálně nebezpečných domén je založena na porovnání domén v IP tocích s předem vygenerovaným seznamem domén. Pro vygenerovaní co největšího počtu vizuálně podobných domén je využito celkem tří metod transformace originální domény. První transformací je zdvojení písmen dané domény, další transformaci představuje nahrazení jednotlivých písmen vizuálně podobnými, přičemž je změněno vždy jen jedno písmeno domény. Nakonec jsou k vygenerovaným názvům doplněny předem definované domény prvního řádu. Výsledek pro doménu muni je například následující: mmuni.cz, mmuni.com, muuni.cz, muuni.com, munni.cz, munni.com, munii.cz, munii.com, nuni.cz, nuni.com, runi.cz, runi.com, mvni.cz, mvni.com, muhi.cz, muhi.com, mumi.cz, mumi.com, muri.cz, muri.com, munj.cz, munj.com, munl.cz, munl.com, mun1.cz, mun1.cz V případě, že jsou využity IP toky zachycené pouze na hranici sítě, se jako dotazující IP adresy často vyskytují DNS servery lokální sítě místo samotných klientů. Z těchto informací tedy není možné zjistit klienta, který se na danou doménu dotazoval, a upozornit jej, že se potencionálně stal obětí phishingu. Aby bylo možné určit i klienta, který se na danou doménu dotazoval, lze využit podobný princip jako v případě metody detekce používání externích serverů DNS. Z odpovědi zjistit čas jejího přijmutí a IP adresu na kterou daná doména odkazuje. Následně vybrat z IP toků ty klienty, kteří navštívili danou doménu do dvou sekund od zaznamenání odpovědi. Metodu dohledávání klientů je možné použít pouze pro domény, které nejsou dotazovány příliš mnoho klienty najednou. V opačném případě dochází k ukládání odpovědi do dočasné paměti, a dotaz tak není propagován mimo lokální síť, čímž jej není možné zachytit na hranici sítě. V případě detekce vizuálně podobných domén se ovšem nedá předpokládat tak vysoká návštěvnost. Metoda dohledání klientů dokazuje, že pro určité úlohy není nutné sbírat data i z vnitřní sítě, ale stačí pouze údaje z hranice sítě. 5.2.2 Implementace Popsaná metoda byla implementována ve skriptu DNSAnomDet_visually_similar. Generování vizuálně podobných domén je založeno na Mamchenkově skriptu [28] pro detekci typosquattingových domén. Během testovacího nasazení byl skript nastaven na detekování návštěv domén, které jsou vizuálně podobné doménám muni, facebook a google. Ke každé vygenerované mutaci byly následně přidány domény prvního řádu: .cz a .com. 5.2.3 Vyhodnocení nasazení Skript pro detekci dotazování podezřelých domén byl nasazen v síti Masarykovy univerzity v říjnu 2013, přičemž do prosince bylo detekováno 78 případů návštěv domén, které odpovídaly některé ze skriptem vygenerovaných. Výsledek nasazení je znázorněn pomocí statistiky detekovaných domén na obrázku 5.3. Na první pohled velmi vyniká doména gooogle.com, jejíž návštěva byla detekována v 53 případech. Z názvu domény je zřejmé, že se jedná o překlep v psaní do53

5. Metody detekce anomálií provozu DNS ménového jména, přičemž takto velké číslo je pravděpodobně způsobeno širokým používáním služby Google. 2

2

1 googlle.cz

12

googlle.com

www.ggoogle.com 3

www.gooogle.com faacebook.com

1

53

3

googlee.com

1

ezdroje.mmuni.com ggoogle.com gooogle.com

Obrázek 5.3: Počet detekovaných vizuálně podobných domén.

Velkou nevýhodou nasazení skriptu je nutnost ruční kontroly obsahu domén. Tento proces nelze efektivně automatizovat, neboť je velmi obtížné odhadnout, zda je daná doména nějakým způsobem škodlivá. Některé z detekovaných domén odkazují na legitimní doménu (například gooogle.com). Vlastník originální domény si tak zajišťuje, aby nebylo možné podobnou doménu zneužít. Naprosto opačný příklad tvoří doména googlle.com. Po zadání domény do prohlížeče byl uživatel přesměrován na adresu http://globalpromotions.glideshomes.com/home.html, kde mu byl zobrazen dotazník podle toho, jaký prohlížeč aktuálně používá. Po vyplnění byla uživateli nabídnuta možnost zaregistrovat se a vyhrát iPhone 5S, přičemž cena registrace byla 99 Kč/týden. Kromě toho byl celý dotazník generován pomocí JavaScriptu, který antivirová řešení označila jako závadný. Další skupinu typu domén tvoří domény, které využívají překlepu uživatelů, přičemž vydělávají na zobrazovaných reklamách. Příkladem je i doména mmuni.com, přičemž jakákoliv doména třetího řádu je přesměrována na obsah domény druhého řádu. Vizuální podoba s originální doménou je velmi malá, přesto je vhodné i takovýmto doménám věnovat pozornost, neboť může být zneužita proti uživatelům síťových služeb Masarykovy univerzity, kteří se přepíšou při psaní originální domény. Během nasazení skriptu nebyly odhaleny žádné domény, které by využívaly přímé vizuální podobnosti. Veškeré detekované domény obsahovaly zdvojené písmeno, což odpovídá překlepům v jejich psaní. Z výsledků tedy vyplývá, že se během sledovaného období neobjevila žádná phishingová kampaň, která by cílila na zmatení uživatelů. Veškeré zachycené domény tak vznikly pravděpodobně pouhým přepsáním se uživatelů, nikoliv úmyslným navedením na závadnou doménu.

5.3

Detekce amplifikačního útoku

Amplifikační útok zneužívající infrastrukturu DNS je jedním z nejrozšířenějších typů DDoS útoků. Pokud je jakékoliv zařízení v síti cílem útoků, je tento fakt velmi snadno rozpoznatelný z nárůstu objemu provozu v základních statistikách IP toků. Opačný problém ovšem tvoří detekování resolverů v lokální síti, které jsou zneužity k amplifikaci. Jelikož útočník využívá takovýchto strojů více, nemusí být nárůst provozu na jednom zařízení rozlišitelný od běžného chování. 54

5. Metody detekce anomálií provozu DNS Detekcí amplifikačního útoku na základě základních NetFlow dat se např. zabývá ve své práci Huistra [21]. Informace ze základních IP toků ovšem nemusí být schopny odhalit každý pokus o využití infrastruktury DNS k amplifikačnímu útoku. Velký potenciál pro detekci ovšem nabízí rozšířené IP toky využívané v rámci diplomové práce. Díky informacím, jako je dotazovaná doména nebo typ dotazu, lze přesněji určit opakující se dotazy a výrazně tak snížit hranici pro detekci amplifikačního útoku. 5.3.1 Popis metody Pro detekci stavu, kdy se stroje v lokální síti podílí na amplifikačním útoku, byla vytvořena metoda postavená na informacích z rozšířených IP toků. Ze studia dostupné literatury vyplynulo, že útočníci obvykle dotazují známé domény, které vrací velký počet záznamů. Mezi takovéto domény patří například icann.org. K ještě většímu zesílení je využit protokol DNSSEC, který výrazně navýší velikost paketu díky přidávání informací o podpisu. Kromě toho z literatury vyplynulo, že útočníci specifikují maximální velikost UDP paketu, což umožní vygenerovat větší odpověď (základní nastavení v případě Microsoft DNS je 1280 bajtů). V první fázi vývoje detekčního mechanismu tedy byly využity tyto poznatky k vytvoření následujícího filtru pro nástroj fbitdump: fbitdump -R "%dstip4 != and %srcip4 == and %srcport == 53 and %dnspsize > 4096 and %dnsdo == 1" -A%srcip4,%dstip4 Z výsledků analýzy dat pomocí zmíněného filtru vyplynul fakt, že útočníci velmi často využívají vlastní vygenerované domény, které jsou plně naplněny záznamy. Útočníci tedy v tomto případě již nepotřebují vynucovat použití protokolu DNSSEC. Co se týče specifikace maximální velikosti UDP paketu, ze zachycených útoků bylo zjištěno, že útočníci používají primárně tři nastavení: 9000 bajtů, 4096 bajtů nebo nenastavují žádnou velikost. Aby tedy byly zachyceny všechny útoky, není možné tento atribut obsáhnout ve filtru. Na základě zmíněné analýzy byla upravena detekční metoda tak, aby dokázala odhalit co největší množství útoků. Samotná detekce funguje na základě jednoduchého filtru, který agreguje toky podle zdrojové IP adresy spolu s doménovým jménem, přičemž jsou sledovány pouze DNS odpovědi na dotaz typu ANY, viz následující filtr: fbitdump -R "%dstip4 != and %srcip4 == and %srcport == 53 and %dnsqtype == 255" -A%srcip4,%dnsname -o "fmt:%ts|%pkt|%srcip4|%dnsname|" -m%pktDESC Rozhodnutí, zda se jedná o amplifikační útok, je možné provést na základě počtu odeslaných paketů. Přičemž jako vhodná hranice se jeví počet 200 stejných paketů za hodinu. Hranice je takto stanovena z důvodu, že se mohou objevit legitimní dotazy na specifické domény náležící do lokální sítě v počtu až desítek paketů. Hranice je stále dostatečné nízká neboť amplifikační útoky jsou charakteristické výrazně větším množstvím paketů. Stejný filtr s prohozenými parametry zdrojové a cílové adresy, je možné využít i pro detekci použití amplifikačního útoku na některý ze strojů lokální sítě. 5.3.2 Implementace Navržená metoda byla implementována ve skriptu DNSAnomDet_amplification. Kromě detekce zařízení podílejícího se na amplifikačním útoku, skript umožňuje i detekci pokusů o útok. Tyto pokusy jsou vytvářeny na zařízení v síti, které nemají povolené DNS nebo nefungují jako otevřený 55

5. Metody detekce anomálií provozu DNS DNS resolver. Aby skript zbytečně neanalyzoval zařízení, která vytvořila pouze malé množství odpovědí, je ve skriptu možné stanovit minimální hranici objemu provozu. 5.3.3 Vyhodnocení nasazení Skript DNSAnomDet_amplification byl nasazen v síti Masarykovy univerzity v říjnu 2013, přičemž do konce listopadu zachytil 10 úspěšných, různě dlouho trvajících, amplifikačních útoků zneužívajících zařízení v síti MU. Vlastnosti těchto útoků jsou shrnuty v tabulce 5.3, přičemž uvedená doba trvání je spíše orientační neboť většina útoků neprobíhala souvisle. Největším detekovaným útokem, byl útok, který začal 22. října a trval sedm dní. Velmi zajímavým specifikem tohoto útoku je, že nebyl směrován pouze na jednu IP adresu oběti, ale bylo zasíláno malé množství paketů směrovaných v odpovědi na více IP adres. Celkově byly zaslány odpovědi na 11 438 různých IP adres, přičemž celkový počet paketů byl 5 132 327. Průměrně tedy vychází, že na jednu IP adresu bylo zasláno 449 paketů. Útočník tak pravděpodobně spíše testoval možnosti svého nástroje, namísto cíleného útoku. Doba trvání útoku (hodiny) 1 1 1 1 5 1 167 2 8 3

Doména bitstress.com fkfkfkfa.com pkts.asia irlwinning.com aa.10781.info pkts.asia pkts.asia isc.org isc.org reanimator.in

Počet odpovědí 3 941 54 133 64 292 13 190 276 748 8 112 5 132 327 8 241 10 493 5 279

Počet resolverů 1 1 1 1 1 1 4 1 1 3

Vyžadování DNSSEC Ne Ne Ne Ne Ne Ne Ne Ne Ano Ne

Velikost paketu 9 000 9 000 9 000 9 000 9 000 9 000 9 000 Nenastaveno 4 096 Nenastaveno

Tabulka 5.3: Vlastnosti detekovaných amplifikačních útoků. Téměř každý den byl ovšem zaznamenán neúspěšný pokus o amplifikační útok, kdy se útočník pokoušel využít již opravená zařízení, případně úplně jiná zařízení nepodporující reverzní překlad. Výsledkem je, že se tyto útoky neprojevují v standardních IP tocích jako odchylka, jelikož běžný stav obsahuje tyto útoky. Z detekovaných výsledků je také zřejmý posun k využívání uměle vytvořených domén namísto původních již existujících. Kromě domény isc.org jsou všechny domény obsažené v tabulce uměle vytvořené a naplněné záznamy tak, aby umožnily generovat co největší paket odpovědi. Mezi hlavní přínos skriptu DNSAnomDet_amplification patří zpřesnění detekce útoku. Na rozdíl od detekce založené na objemu přenesených dat z IP toků, umožňuje skript díky znalosti dotazované domény a typu dotazu odhalit i méně výrazné útoky, které mohou splývat s normálním provozem DNS. Problém ovšem stále tvoří útoky, kdy útočník využívá velké množství strojů po celém světě, díky čemuž mu stačí generovat menší provoz, který není jednoduše rozlišitelný od normálního provozu.

5.4

Detekce otevřených DNS resolverů

Metoda pro detekci amplifikačních útoků nedokáže odhalit méně výrazné útoky, byť poskytuje výrazně lepší zjemnění detekční hranice v porovnání s metodami založenými pouze na standardních IP tocích. Druhou výraznou nevýhodou této metody je, že detekce dokáže odhalit špatně nakonfigurovaná zařízení až ve chvíli, kdy začnou být zapojována do amplifikačního útoku. Na 56

5. Metody detekce anomálií provozu DNS amplifikační útok je ovšem možné se dívat i z druhé strany, kterou tvoří samotná zařízení podílející se na útoku. U těchto zařízení si útočník obvykle nejdříve ověří, zda fungují správně a překládají dotazy. Detekci právě těchto testů řeší další metoda vytvořená v rámci diplomové práce. V současné době je možné pro účely detekce otevřených DNS resolverů využít reporty generované projektem Open Resolver Scanning Project [15]. Tento projekt funguje tak, že dokola prochází všechny IPv4 adresy a zkouší, zda odpovídají na portu 53 (DNS) na dotaz dnsscan.shadowserver.org typu A. V případě, že je zaznamenána odpověď, je tato informace hlášena správcům jednotlivých sítí, pokud o tyto data projeví zájem. Nevýhodou tohoto řešení je, že nemusí odhalit zařízení včas před tím, než je zneužito k amplifikačnímu útoku. Jedná se také o externí projekt, který může být kdykoliv ukončen. Není tedy jistota zajištění výsledků i do budoucna. 5.4.1 Popis metody Základem metody detekující otevřené DNS resolvery je znalost domén, které jsou obsluhovány servery DNS z lokální sítě. Odpovědné servery DNS musí být schopny překládat dotazy na tyto domény i pro zařízení mimo lokální síť. Ovšem rekurzivní dotazy na jiné domény by měly být zamítnuty. V případě malých sítí se jedná obvykle o jednotky domén. U velkých sítí ale může být těchto domén výrazně více. Jakmile jakékoliv zařízení v síti odpoví na dotaz neobsahující některou z domén lokální sítě, je možné s jistotou označit toto zařízení za otevřený DNS resolver. Pro detekci takovýchto odpovědí slouží následující příkaz pro nástroj fbitdump. fbitdump -R "%dstip4 != and %srcip4 == and %srcport == 53 and %dnsname != ’%<doména>’ and %dnsname != ’%<doména>’ and %dnsname == ’%.%’ and %dnsrcode == 0" -q -A%srcip4,%dnsname -o "fmt:%srcip4|%dnsname|" Uvedený příkaz vybírá pouze ty odpovědi, na které bylo odpovězeno s návratovým kódem NOERROR. Ostatní návratové kódy obvykle označují, že DNS server daný dotaz odmítá přeložit. V příkazu je možné definovat jakékoliv množství domén náležejících do lokální sítě, vždy ve formátu and %dnsname != ’%<doména>’. 5.4.2 Implementace Největším problémem, při vývoji skriptu implementujícím tuto metodu, byla unikátnost sítě Masarykovy univerzity, která se z pohledu infrastruktury DNS výrazně odlišuje od běžných sítí jiných organizací. V síti MU je registrováno velké množství domén, nikoliv pouze doména muni.cz. Problém tvoří souhrnný seznam těchto domén, který v současné době neexistuje. Hlavní součástí skriptu je tedy funkce ověřující, zda daná doména náleží síti MU či nikoliv tak, aby odpovědi na ni nebyly zahrnuty ve filtru detekujícím otevřené DNS resolvery. K rozhodnutí zda doména náleží síti MU, je využit nástroj dig (viz sekce 2.5), pomocí kterého je vytvořen dotaz typu ANY na testovanou doménu. Pokud doména náleží síti MU, je v ní uveden některý z jmenných serverů Masarykovy univerzity. Ve výsledku je tedy testována přítomnost řetězce muni.cz. Pokud některý záznam tuto doménu obsahuje, je vložen do whitelistu a do filtru, aby nebyl dále vybírán. Jelikož pod síť MU spadá velké množství domén, byla pro jejich ukládání zvolena databáze která umožňuje jednoduché a rychlé zapisování a čtení. Druhým specifikem sítě Masarykovy univerzity je zajišťování DNS resolverů pro své zákazníky, konkrétně střední školy. Tyto resolvery umožňují reverzní překlad i definovaným podsítím středních škol. Z hlediska detekční metody se mohou jevit jako otevřené resolvery a vyvolávat nesprávná upozornění. V rámci skriptu je seznam těchto serverů vložen do databáze a white57

5. Metody detekce anomálií provozu DNS listován. Je ovšem potřeba jednou za nějaký čas zkontrolovat, že i tyto servery jsou nastaveny správně. K této kontrole lze použít například nástroj Dig web interface zmíněný v sekci 2.5.3. Během vytváření skriptu představovaly další problém zachycené domény obsahující velká písmena (např. iS.MUni.cZ), které zbytečně navyšovaly počet domén ve filtru. Jelikož nástroj fbitdump neumožňuje převést domény na malá písmena, bylo nutné v rámci skriptu implementovat funkci, která přidává parametr %dnsnamel, označující doménové jména s malými písmeny. Skript tedy vytváří sloupec s takto upravenými doménami v databází IPFIX sám. 5.4.3 Vyhodnocení nasazení Skript DNSAnomDet_open_resolvers byl nasazen v síti Masarykovy univerzity v říjnu 2013. Od této doby do začátku prosince 2013 bylo detekováno celkem 207 otevřených resolverů. 188 z těchto detekovaných resolverů tvoří IP adresy z rozsahů, jakou jsou eduroam nebo vpn, kde jsou připojeným zařízením automaticky přidělovány IP adresy. Počet zařízení, na kterých běží otevřený resolver může být tak ve skutečnosti výrazně menší, neboť jedno zařízení se může skrývat pod více IP adresami. Zbylých 19 detekovaných resolverů tvoří statická zařízení s pevnou IP adresou. Jak již bylo zmíněno, v síti Masarykovy univerzity je v současné době využívána detekce externím nástrojem v rámci Open Resolver Scanning Project. Obrázek 5.4 znázorňuje porovnání detekovaných zařízení hlášených tímto nástrojem s detekovanými zařízeními pomocí nasazeného skriptu. Z obrázku je velmi dobře vidět, že nástroj DNSAnomDet_open_resolvers odhalil o 131 zařízení více jak externí nástroj. Externí nástroj ovšem dokázal odhalit 11 zařízení, která nasazený skript nezaznamenal. To může být způsobeno buď výpadky sondy exportující IP toky nebo mohly být tyto odpovědi vedeny druhým přípojným bodem Masarykovy univerzity, z něhož nejsou exportovány IP toky do vývojového kolektoru. V případě shody detekce oběma nástroji, byly skriptem DNSAnomDet_open_resolvers detekovány i dotazy vytvářené v rámci detekce externího nástroje.

76 Shoda

+ 11

131 DNSAnomDet_open_resolvers

Open Resolver Scanning Project

Obrázek 5.4: Porovnání výsledků detekce nástroji DNSAnomDet_open_resolvers a Open Resolver Scanning Project.

Kromě dotazů, kterými si útočník zkouší správnou funkčnost zařízení, byly skriptem zaznamenány i všechny amplifikační útoky uvedené v tabulce 5.3. Mimo tyto útoky byly zachyceny ještě další dva tzv. „pomalé“ útoky, viz tabulka 5.4. Detekce otevřených resolverů je tedy velmi dobrým nástrojem i pro detekci samotných amplifikačních útoků, neboť umožňuje snížit hranici na úplné minimum a již po první zachycené odpovědi je možné hlásit anomálii odpovědným správcům. Doba trvání útoku (hodiny) 1 2

Doména isc.org isc.org

Počet odpovědí 138 828

Počet resolverů 1 1

Vyžadování DNSSEC Ano Ne

Velikost paketu 4096 Nenastaveno

Tabulka 5.4: Vlastnosti nízkofrekvenčních amplifikačních útoků. 58

5. Metody detekce anomálií provozu DNS Nasazený skript kromě detekce samotných otevřených DNS resolverů umožnil také analýzu domén, které byly na daných strojích překládány. Na obrázku 5.5 je znázorněna statistika nejčastěji překládaných domén podle počtu odpovědí s tím, že jsou vybrány pouze ty s více jak 200 odpověďmi. Z uvedeného grafu je zřejmé, že detekované otevřené DNS resolvery neslouží pouze pro amplifikační útoky, ale jsou využívány i k jiným účelům. Příkladem může být doména facebook.com, kdy na některé otevřené resolvery byl zjevně přesměrován překlad různých doménových jmen pro nic netušící oběť mimo síť MU. Je tedy velmi pravděpodobné, že pro určité domény byly vraceny jiné než originální IP adresy.

1 450

3 182 7 201

4 591

1 170

873 600

1 442

340 261

pkts.asia isc.org

259

reanimator.in

orcart.facebook.com

238

db3msgr6010810.gateway.messenger.live.com graph.facebook.com

android.clients.google.com s.gateway.messenger.live.com mtalk.google.com

171 228

api.facebook.com api-read.facebook.com

275 626

gld.push.samsungosp.com

dnsscan.shadowserver.org 34403.0.4.4.20703.rst3.r.skype.net

Obrázek 5.5: Nejčastěji překládané domény na otevřených resolverech v síti MU během října až prosince 2013.

Kromě zmíněných dotazovaných domén bylo zachyceno i skenování společnosti Neustar [22]. Jednou z nabízených služeb této společnosti je pravidelná kontrola podvrhnutí DNS záznamů. Kontrola probíhá tak, že jsou automaticky dotazovány otevřené DNS resolvery na domény patřící zákazníkům společnosti. V případě, že je na odpověď vrácena jiná IP adresa než má být, je zákazník na tento faktu upozorněn a jsou podniknuty kroky, aby nebylo možné takovýto záznam dále zneužít. Ze zachycených odpovědí je možné určit i zákazníky této společnosti, jakými jsou například FMC Technologies nebo Boeing.

5.5

Detekce dotazů na závadné domény

Dotazované domény mohou prozradit o jakémkoliv zařízení v síti velmi mnoho. V rámci bezpečnostního monitoringu je nejužitečnějším údajem informace, zda dotazovaná doména vede na závadnou službu. Tuto službu může představovat podvodný web, web šířící škodlivý software nebo třeba řídící centrum škodlivého softwaru. Problémem ovšem je, že nelze monitorovat veškerý provoz DNS, neboť jeho analýza by byla velmi časové náročná z důvodu velkého množství dat. Z toho důvodu je potřeba analyzovaná data určitým způsobem omezit. Možnou formou omezení je zaměření se pouze na domény dotazované po startu zařízení. Kromě vytváření dotazů samotným operačním systémem jsou generovány také dotazy aplikací, které se automaticky spouští hned po startu. Až po těchto aplikacích se začínají teprve objevovat domény související s prohlížením webu. Většina škodlivého softwaru je obvykle automaticky spuštěna se startem zařízení, přičemž se okamžitě po spuštění snaží kontaktovat své řídící centrum. Toto řídící centrum slouží například pro stažení dalšího škodlivého softwaru nebo pro 59

5. Metody detekce anomálií provozu DNS předávání příkazů v případě botnetu. Díky tomuto chování je možné odhalit škodlivý software pouze z dotazů vytvořených po startu zařízení a není tak nutné analyzovat veškerý další provoz. 5.5.1 Popis metody Rozpoznání startu zařízení ze záznamů IP toků je velmi obtížné neboť neexistuje žádný identifikátor startu zařízení. Při řešení diplomové práce byl ovšem zjištěn specifický DNS dotaz používaný operačními systémy Windows pro testování, zda mají dostupný server DNS. Dotaz na doménu dns.msftncsi.com je vytvářen pouze jednou po připojení zařízení do sítě, případně při výpadcích serveru DNS. Detekcí tohoto dotazu lze odhalit potencionální start zařízení, přičemž se mohou objevit i nesprávné detekce díky dotazům vytvořeným již během spojení. Tyto detekce ovšem nepředstavují výrazný problém, neboť hlavní přínos tvoří výrazné omezení množství prohledávaných domén v IPFIX datech. Důležitou součástí detekce je rozlišení, zda se na zmíněnou doménu dotazuje klient nebo server DNS. Během analýzy síťových dat bylo zjištěno, že některé servery DNS směřují dotazy na tuto doménou pouze na specifické IP adresy spadající pod doménu ns<čislo>.msft.net. Odfiltrováním těchto adres je tak možné vyloučit tyto DNS servery z výsledku. Výsledný filtr nástroje fbitdump pro detekci času startu zařízení vypadá následovně: fbitdump -R <složka s IPFIX daty> "%dnsname == ’dns.msftncsi.com’ and %dnsqtype == 1 and %srcport != 53 and %dstport == 53 and %dstip4 != 65.55.37.62 and %dstip4 != 64.4.59.173 and %dstip4 != 213.199.180.53 and %dstip4 != 207.46.75.254 and %dstip4 != 65.55.226.140 and exists %srcip4" -m%srcip4 -o "fmt:%ts|%srcip4" Další odfiltrování serverů DNS je potřeba provést až na základě výsledku zmíněného příkazu, pomocí omezení počtu dotazů za dané časové okno. Jestliže se jedná o server DNS, vytváří velké množství dotazů na doménu dns.msftncsi.com, což neodpovídá chování běžného klienta. Po odfiltrování těchto serverů je následně pro každý detekovaný start dané IP adresy vypsáno prvních N dotazovaných doménových jmen. Pokud je zvolena větší hodnota N, je analyzováno více domén a vzrůstá tak pravděpodobnost odhalení závadné domény. Nevýhodou je vyšší časová náročnost. Z analyzovaných domén je vhodné odstranit reverzní dotazy na služby Windows, případně lokální domény, u kterých se dá předpokládat, že budou bezpečné. Následující příkaz je příkladem vyhledání dotazovaných domén pro jedno zařízení: fbitdump -R "%ts > <čas detekce startu> and %srcip4 == and %dnsname != ’%.connectify’ and %dnsname != ’%.localnetwork’ and %dnsname != ’%.windowsupdate.com’ and %dnsname == ’%.%’ and %dnsname != ’%.in-addr.arpa’ and %srcport != 53 and %dstport == 53 and %dnsname != ’%msftncsi.com’ and %dnsname != ’%microsoft.com’ and %dnsname != ’%’" -m -c -A%ts,%dnsname -o "fmt:%ts|%dnsname|" Získané domény je následně možné porovnat s jakýmkoliv seznamem závadných domén. Velkou výhodou této metody je, že analýza celkového provoz DNS je omezena pouze na N zkoumaných domén. Díky tomu je možné tuto metodu použít i v prostředí velkých sítí s vysokým objemem provozu DNS. 5.5.2 Implementace Navržená metoda byla implementována ve skriptu DNSAnomDet_after_start. Tento skript k rozpoznání závadných domén využívá externí službu VirusTotal [55], kde je možné přes jednoduché 60

5. Metody detekce anomálií provozu DNS rozhraní zadat podezřelé domény a získat seznam databází, kde je daná doména hlášena jako závadná. Aby ovšem nebyla tato služba příliš zahlcována dotazy, jsou detekované domény porovnány ještě se seznamem 1 000 000 celosvětově nejčastěji navštěvovaných domén, vytvářeným společností Alexa1 . Nevýhodou tohoto řešení je, že v listu jsou uvedeny pouze domény druhého řádu, což může způsobovat nepřesnosti při detekci. Během testování byly porovnávány všechny domény ze seznamu nejčastěji navštěvovaných domén. Některé domény, hlavně na konci listu, ovšem mohou být také závadné, jen široce navštěvované. Podle počtu zařízení v síti je tedy potřeba, při reálném nasazení, rozumně vyvážit počet porovnávaných domén tak, aby nebyla příliš vytěžována služba VirusTotal. V rámci tohoto vyvážení je také potřeba stanovit vhodnou hranici, kolik domén po startu zařízení bude detekováno. 5.5.3 Vyhodnocení nasazení Skript DNSAnomDet_after_start analyzující dotazované domény po startu zařízení byl nasazen v síti Masarykovy univerzity v listopadu 2013. Skript bylo možné v současné době použít pouze na IP tocích zachycených sondou na hranici sítě MU, což znemožnilo detekovat start všech zařízení v síti. Skript tedy analyzoval pouze dotazy klientů, kteří používají externí DNS resolver, díky čemuž jsou v IPFIX datech zaznamenány jejich dotazy. Přesto bylo do konce prosince 2013 detekováno celkově 29 IP adres zařízení, pravděpodobně obsahujících škodlivý software. Všechny tyto IP adresy spadají do rozsahu dynamických IP adres a adres zařízení na kolejích MU. Jelikož se jedná o dynamické adresy, skutečný počet detekovaných zařízení může být nižší. Jako závadné domény byly skriptem označeny ty, které byly nahlášeny v minimálně čtyřech databázích agregovaných službou VirusTotal. Tento limit je stanoven z důvodu, že mezi databázemi se nachází i reputační databáze, které mohou obsahovat nesprávná ohodnocení domény. V tabulce 5.5 jsou uvedeny detekované domény spolu s údajem v kolika seznamech byly nalezeny. Doména www.tns-counter.ru telemetry.tanzuki.net www.tinydm.com cybermindtool.info st.cloins.com fget-career.com filemagnet.info advombat.ru

Počet databází 4 5 5 4 4 5 4 4

Doména getthefilenow.info habble.ru cybeitrapp.info check.frogupdate.com static.tanzuki.net www.general-files.biz ad.tanzuki.net www.softosystem.com

Počet databází 4 6 5 4 4 4 4 7

Tabulka 5.5: Seznam závadných domén detekovaných v síti MU během listopadu až prosince 2013. Ze seznamu detekovaných domén se podařilo v případě jednoho klienta odhalit i o jakou nákazu se jednalo. Díky analýze společnosti Sophos [27] bylo možné určit, že dané zařízení s největší pravděpodobností obsahovalo virus Troj/Mdrop-FGJ. Tento fakt ukazuje, že kromě detekce nakažení je možné odhalit i konkrétní škodlivý software, který se na daném zařízení nachází. Další objevenou zajímavostí je, že jeden klient byl detekován také nástrojem pro detekci otevřených DNS resolverů. Lze tedy usuzovat, že instalovaný virus slouží také ke spuštění DNS resolveru pro potřeby amplifikačních a jiných útoků. Kromě závadných domén byly skriptem DNSAnomDet_after_start ukládány i domény, které se nacházely v seznamu společnosti Alexa spolu s jejich pozicí v tomto seznamu. Nejčastěji dotazované domén po startu zařízení jsou uvedeny na obrázku 5.6, přičemž číslo v závorce znázorňuje počet detekcí. Domény jsou seřazeny po směru hodinových ručiček podle pořadí 1. Seznam je dostupný na adrese http://www.alexa.com/topsites.

61

5. Metody detekce anomálií provozu DNS v seznamu společnosti Alexa. Kromě porovnání se seznamem společnosti Alexa mohou být tato data i zajímavým zdrojem informací pro analýzu chování běžných uživatelů a jejich zařízení v síti a také mohou prozradit jaký je na zařízeních nainstalovaný software. Z analyzovaných dat například vyplynulo, že byla vícekrát dotazována doména avast.com jak eset.com, z čehož lze usoudit že antivirové řešení Avast je více rozšířeno u uživatelů v síti MU, kteří využívají externí server DNS. unibo.it (127) eset.com (130)

ytimg.com (147)

verisign.com (183) hotmail.com (153)

google-analytics.com gemius.pl (421)

(171) google.com (1254)

teamviewer.com (97) ubuntu.com (126) opera.com (110) gstatic.com (417) avast.com (261) outlook.com (119)

facebook.com (1717)

google.sk (195)

fbcdn.net (293) youtube.com (293)

seznam.cz (185)

live.com (248)

google.cz (577)

twitter.com (159)

skype.com (241)

bing.com (236) dropbox.com (178) adobe.com (98)

fbstatica.akamaihd.net (494)

googleusercontent.com (116)

msn.com (164)

akamaihd.net (809)

Obrázek 5.6: Nejvíce dotazované domény po startu zařízení.

5.6

Shrnutí

Tabulka 5.6 obsahuje shrnutí vlastností implementovaných detekčních skriptů a výsledků jejich nasazení. Druhý sloupec obsahuje výpočetní náročnost, přičemž se čas v případě nástroje DNS_external_* vztahuje jako jediný na data posbíraná během tří dnů. Tento údaj odpovídá minimálnímu doporučovanému množství analyzovaných dat tak, aby bylo zabráněno velkému množství nesprávných upozornění. Časy ostatních skriptů odpovídají analýze dat z jedné hodiny provozu. Metoda DNS_external_* DNSAnomDet_external_dns DNSAnomDet_visually_similar DNSAnomDet_amplification DNSAnomDet_open_resolvers DNSAnomDet_after_start

Časová náročnost ∼ 6 min ∼ 2 min < 0.5 min < 0.5 min < 0.5 min < 0.5 min

Využití databáze Ano Ne Ne Ne Ano Ne

Detekcí za listopad 2013 67 Nenasazeno 36 2 120 8

Typ IP toků Standardní Rozšířené Rozšířené Rozšířené Rozšířené Rozšířené

Tabulka 5.6: Shrnutí implementovaných metod. 62

5. Metody detekce anomálií provozu DNS Třetí sloupec tabulky označuje, zda skript potřebuje ke svému fungování databázi. V případě skriptu DNSAnomDet_open_resolvers není nutné využít databázi a je možné, při přepsání implementace, využít například zápis do souboru, jelikož uložená data není třeba dále analyzovat. Hlavním výsledkem implementovaných detekčních metod je počet detekovaných anomálií. Tyto anomálie dříve nebyly ze standardních IP toků detekovatelné. Nasazení detekčních skriptů tedy pomohlo zvýšit bezpečnost sítě Masarykovy univerzity a odhalit špatně nakonfigurovaná zařízení.

63

Kapitola 6

Závěr Diplomová práce se zaměřuje na analýzu anomálií v síťovém provozu vytvářeném službou Domain Name System (DNS). Nejprve se věnuje samotnému protokolu DNS, jeho vlastnostem a bezpečnostním hrozbám. Dále se již zabývá možnostmi monitorování provozu, přičemž jsou představeny tři rozdílné přístupy, kterými lze provoz DNS monitorovat. Z jejich vzájemného porovnání vyplývá, že pro monitoring rozsáhlé sítě (např. velikosti Masarykovy univerzity) je nejvýhodnější využít technologii síťových toků rozšířených o informace z provozu DNS. V současné době používaný exportér síťových toků tak byl rozšířen zásuvným modulem vyvíjeným na Vysokém učení technickém v Brně schopným exportovat data z provozu DNS ve formátu IPFIX. Dále se práce zaměřuje na popis jednotlivých anomálií, které se mohou vyskytnout v provozu DNS. Pro lepší přehlednost jsou tyto anomálie rozčleněny do dvou sekcí, na provozní a bezpečnostní. Na základě znalosti těchto anomálií byla v síti Masarykovy univerzity provedena analýza zachyceného provozu. Kromě zajímavých statistik popisujících chování zařízení a uživatelů v síti, bylo pomocí této analýzy odhaleno špatné nastavení prvků infrastruktury sítě. Tyto prvky využívaly pro překlad jmen externí server DNS namísto serveru v lokální síti, což způsobovalo zbytečné zpoždění překladu a představovalo i potencionální bezpečnostní riziko. Hlavní výsledek práce představují nové metody detekce vybraných anomálií provozu DNS využívající rozšířené síťové toky. Mezi detekované anomálie byly vybrány ty, které představují potencionální bezpečnostní riziko. Navržené metody byly implementovány v jazyce Perl a nasazeny v síti Masarykovy univerzity, kde umožnily odhalit útoky a anomálie, které dříve nebylo možné jednoduše detekovat. Příkladem je detekce využívání externích DNS resolverů, která byla implementována jak nad standardními, tak nad rozšířenými IP toky. Díky informacím z provozu DNS bylo možné původní metodu, s velkým množstvím nesprávných upozornění, výrazně zjednodušit a hlavně zpřesnit. Kromě nových detekčních metod jsem během řešení diplomové práce přispěl také k vývoji nástroje fbitdump, kdy byly veškeré nalezené chyby nahlášeny jeho vývojářům. V případě zásuvného modulu pro exportér IP toků jsem předal jeho tvůrci podněty a nápady, které byly následně implementovány, což umožnilo ještě lépe analyzovat zachycený provoz DNS. Během vývoje detekčních metod jsem také odhalil špatně nastavený server DNS jiné univerzity, jehož správce byl na tento fakt upozorněn. Výsledkem bylo napravení chyby a zrychlení překladu dotazů kladených na daný server. Výsledky diplomové práce dokládají, že je výhodné k nástrojům bezpečnostního monitoringu doplnit i analýzu provozu DNS. Lze tak odhalit chyby, anomálie či případně útoky, které jinak nejsou jednoduše detekovatelné. Sledování provozu DNS představuje také zajímavý základ pro vývoj nových detekčních metod síťových anomálií. Příkladem je navržený koncept detekce startu zařízení, jelikož chování zařízení po startu je výrazně odlišné od běžného. Další zajímavý směr vývoje může představovat analýza zařízení nakažených škodlivým software. Dotazy DNS vytvořené těmito zařízeními mohou odhalit nové doposud neznámé škodlivé domény nebo mohou sloužit také k dohledání dalších zařízení v síti nakažených stejným škodlivým softwarem.

64

Literatura [1] Root Server Technical Operations Assn [online], 2013. stránka: http://www.root-servers.org/.

[cit. 2013-09-23]. Domovská

[2] Ron Aitchison. Pro DNS and BIND 10. Apress, Berkely, CA, USA, 2011. ISBN 978-14302-3048-9. [3] Francisco Alonso. Cyber warfare with DNSbotnets. Hakin9 IT Security Magazine, 5(7), 2010. ISSN 1733-7186. [4] Leyla Bilge, Engin Kirda, Christopher Kruegel, Marco Balduzzi. EXPOSURE: Finding Malicious Domains Using Passive DNS Analysis. NDSS 2011, 18th Annual Network and Distributed System Security Symposium, San Diego, United States, 2011. The Internet Society. [5] Hyunsang Choi, Hanwoo Lee, Heejo Lee, Hyogon Kim. Botnet Detection by Monitoring Group Activities in DNS Traffic. Computer and Information Technology, 2007. CIT 2007. 7th IEEE International Conference on, s. 715–720, 2007. [6] B. Claise. Cisco Systems Netflow Services Export Version 9. RFC 3954 (Informational), 2004. Dostupné z: http://www.ietf.org/rfc/rfc3954.txt. [7] B. Claise. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. RFC 5101 (Proposed Standard), 2008. Dostupné z: http://www.ietf.org/rfc/rfc5101.txt. Obsoleted by RFC 7011. [8] Internet Software Consortium. BIND 9 Administrator Reference Manual [online]. Redwood City, California, USA, 2013. [cit. 2013-10-22]. Dostupné z: http://ftp.isc.org/isc/bind 9/cur/9.9/doc/arm/Bv9ARM.pdf. [9] Internet Systems Consortium. The most widely used name server software: BIND [online], 2013. [cit. 2013-10-08]. Domovská stránka: http://www.isc.org/downloads/bind/. [10] CSIRT.CZ. V ČR byl opět zaznamenán DDoS útok ze sítě RETN [online], 2013. [cit. 201309-16]. Dostupné z: http://csirt.cz/page/1785/v-cr-byl-opet-zaznamenan-ddos-uto k-ze-site-retn/. [11] D. Eastlake. Domain Name System Security Extensions. RFC 2535 (Proposed Standard), 1999. Dostupné z: http://www.ietf.org/rfc/rfc2535.txt. [12] The Measurement Factory. DSC: A DNS Statistics Collector [online], 2013. [cit. 2013-11-03]. Domovská stránka: http://dns.measurement-factory.com/tools/dsc/. [13] Internet Corporation for Assigned Names, Numbers. List of Top-Level Domains [online], 2013. [cit. 2013-09-16]. Dostupné z: http://www.icann.org/en/resources/registries/ tlds. 65

6. Závěr [14] International Organization for Standardization. Codes for the representation of names of countries and their subdivisions [online]. Technical report, Geneva, Switzerland, 2013. [cit. 2013-09-16]. Dostupné z: http://www.iso.org/iso/home/standards/country_codes /country_names_and_code_elements.htm. [15] The Shadowserver Foundation. Open Resolver Scanning Project [online], 2013. [cit. 201312-11]. Domovská stránka: https://dnsscan.shadowserver.org. [16] R. Gerhards. The Syslog Protocol. RFC 5424 (Proposed Standard), 2009. Dostupné z: http://www.ietf.org/rfc/rfc5424.txt. [17] Google. Public DNS [online], 2013. [cit. 2013-12-28]. Dostupné z: https://developers.go ogle.com/speed/public-dns/. [18] Peter Haag. NFDUMP, 2013. [cit. 2013-12-27]. Domovská stránka: http://nfdump.sourc eforge.net/. [19] Trevor Hawthorn. Analyzing DNS Logs Using Splunk [online], 2012. [cit. 2013-10-29]. Dostupné z: http://stratumsecurity.com/2012/07/03/splunk-security/. [20] Rick Hofstede, Idilio Drago, Anna Sperotto, Ramin Sadre, Aiko Pras. Measurement Artifacts in Netflow Data. Proceedings of the 14th International Conference on Passive and Active Measurement, PAM’13, s. 1–10, Berlin, Heidelberg, 2013. Springer-Verlag. ISBN 978-3-642-36515-7. [21] David Huistra. Detecting Reflection Attacks in DNS Flows. 19th Twente Student Conference on IT, volume 19. University of Twente, 2013. [22] Neustar Inc. Neustar NeuSentry – The New Layer in Network Security [online], 2011. [cit. 2013-12-11]. Domovská stránka: http://www.neusentry.biz/. [23] Splunk Inc. Splunk: Operational Intelligence, Log Management, Application Management, Enterprise Security and Compliance [online], 2013. [cit. 2013-09-16]. Domovská stránka: http://www.splunk.com/. [24] Team Cymru Inc. IP to ASN Mapping [online], 2013. [cit. 2013-12-01]. Dostupné z: http:// www.team-cymru.org/Services/ip-to-asn.html#dns. [25] Dan Kaminsky. Black Ops 2008: It’s The End Of The Cache As We Know It [online], 2008. [cit. 2013-11-26]. Dostupné z: http://s3.amazonaws.com/dmk/DMK_BO2K8.ppt. [26] Vojtěch Krmíček, Pavel Minařík, Pavel Piskač, Michal Trunečka, Jan Vykopal. Katalog hrozeb, 2012. Technická zpráva. Ústav výpočetní techniky, Masarykova univerzita. 2012. [27] Sophos Ltd. Troj/Mdrop-FGJ [online], 2013. [cit. 2014-01-06]. Dostupné z: http://www.sophos.com/en-us/threat-center/threat-analyses/viruses-and-spy ware/Troj~Mdrop-FGJ/detailed-analysis.aspx. [28] Leonid Mamchenkov. Typosquatting hack [online], 2006. [cit. 2013-12-10]. Dostupné z: http://mamchenkov.net/wordpress/2006/11/15/typosquatting-hack. [29] S. Marchal, J. Francois, R. State, T. Engel. Semantic based DNS forensics. Information Forensics and Security (WIFS), 2012 IEEE International Workshop on, s. 91–96, 2012. [30] Luis Martin Garcia. TCPDUMP/LIBPCAP public repository [online], 2010. [cit. 2013-1112]. Domovská stránka: http://www.tcpdump.org/. 66

6. Závěr [31] Microsoft. DNS server [online], 2013. [cit. 2013-10-22]. Dostupné z: http://technet.mic rosoft.com/en-us/windowsserver/dd448607.aspx. [32] Paul V. Mockapetris. Domain names - concepts and facilities. RFC 1034, 1983. Dostupné z: http://www.ietf.org/rfc/rfc1034.txt. [33] Paul V. Mockapetris. Domain names - implementation and specification. RFC 1035, 1983. Dostupné z: http://www.ietf.org/rfc/rfc1035.txt. [34] Paul V. Mockapetris. Domain names: Concepts and facilities. RFC 882, 1983. Dostupné z: http://www.ietf.org/rfc/rfc882.txt. [35] Paul V. Mockapetris. Domain names: Implementation specification. RFC 883, 1983. Dostupné z: http://www.ietf.org/rfc/rfc883.txt. [36] John Oberheide, Manish Karir, Z. Morley Mao. Characterizing dark dns behavior. In Fourth GI International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA ’07), 2007. [37] Federal Bureau of Investigation. Operation Ghost Click: International Cyber Ring That Infected Millions of Computers Dismantled [online], 2011. [cit. 2013-11-26]. Dostupné z: http://www.fbi.gov/news/stories/2011/november/malware_110911. [38] OpenDNS. Internet Security or DNS Service for your Business or Home - OpenDNS [online], 2013. [cit. 2013-11-19]. Domovská stránka: http://www.opendns.com/. [39] Vern Paxson. Bro: a system for detecting network intruders in real-time. Proceedings of the 7th conference on USENIX Security Symposium - Volume 7, SSYM’98, s. 3–3, Berkeley, CA, USA, 1998. USENIX Association. [40] Roberto Perdisci, Igino Corona, Giorgio Giacinto. Early Detection of Malicious Flux Networks via Large-Scale Passive DNS Traffic Analysis. Dependable and Secure Computing, IEEE Transactions on, 9(5):714–726, 2012. ISSN 1545-5971. [41] Matthew Prince. The DDoS That Almost Broke the Internet [online], 2013. [cit. 2013-1205]. Dostupné z: http://blog.cloudflare.com/the-ddos-that-almost-broke-the-inte rnet. [42] The Bro Project. Bro 2.1 documentation: base/event.bif.bro [online], 2013. [cit. 2013-11-04]. Dostupné z: http://www.bro.org/sphinx/scripts/base/event.bif.html. [43] The Bro Project. The Bro Network Security Monitor [online], 2013. [cit. 2013-11-04]. Dostupné z: http://www.bro.org/documentation/overview.html. [44] Jicheng Qu, Przemyslaw Sztoch. dnsgraph [online], 2013. [cit. 2013-10-29]. Domovská stránka: http://sourceforge.net/projects/dnsgraph/. [45] J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. Information Model for IP Flow Information Export. RFC 5102 (Proposed Standard), 2008. Dostupné z: http://www.ietf .org/rfc/rfc5102.txt. Obsoleted by RFC 7012, updated by RFC 6313. [46] Antoine Schonewille, Dirk-Jan van Helmond. The Domain Name Service as an IDS, 2006. R Research Annual [47] Ed Stoner. Finding Malicious Activity in Bulk DNS Data. 2009 CERT○ Report, 2010.

67

6. Závěr [48] Ondřej Surý. Závažná vzdálená zranitelnost v DNS serveru NSD [online], 2012. [cit. 2013-1119]. Dostupné z: http://blog.nic.cz/2012/07/19/zavazna-vzdalena-zranitelnost-vdns-serveru-nsd-3/. [49] Jon Tai. parse-tcpdump-udp-port-53.php [skript online], 2013. [cit. 2013-10-30]. Dostupné z: https://gist.github.com/jtai/1368338. [50] Douglas B. Terry, Mark Painter, David W. Riggle, Songnian Zhou. The Berkeley Internet Name Domain Server. Technical Report UCB/CSD-84-182, EECS Department, University of California, Berkeley, 1984. Dostupné z: http://www.eecs.berkeley.edu/Pubs/TechRp ts/1984/5957.html. [51] Eneken Tikk, Kadri Kaska, Liis Vihul. International cyber incidents: legal considerations. Cooperative Cyber Defence of Excellence (CCD COE), Tallinn, Estonia, 2010. ISBN 9789949-9040-0-6. [52] Dot TK. .tk free domains for all [online], 2013. [cit. 2013-09-16]. Domovská stránka: http:// www.dot.tk/. [53] Petr Velan. Processing of a Flexible Network Traffic Flow Information. Diplomová práce, Masarykova univerzita, Fakulta informatiky, 2012. Dostupné z: http://is.muni.cz/th/25 5519/fi_m/. [54] Ricardo Villamarin-Salomon, José Carlos Brustoloni. Identifying Botnets Using Anomaly Detection Techniques Applied to DNS Traffic. Consumer Communications and Networking Conference, 2008. CCNC 2008. 5th IEEE, s. 476–481, 2008. [55] VirusTotal. VirusTotal - Free Online Virus, Malware and URL Scanner [online], 2013. [cit. 2013-12-05]. Domovská stránka: https://www.virustotal.com/#url. [56] Kesheng John Wu. FastBit: An Efficient Compressed Bitmap Index Technology [online], 2013. [cit. 2013-11-11]. Domovská stránka: https://sdm.lbl.gov/fastbit/. [57] CZ.NIC z. s. p. o. DSCng [online], 2013. [cit. 2013-11-03]. Domovská stránka: http://ww w.dscng.cz/. [58] CZ.NIC z. s. p. o. Jak funguje DNSSEC [online], 2013. [cit. 2013-10-22]. Dostupné z: http://www.nic.cz/page/444/jak-funguje-dnssec/. [59] CZ.NIC z. s. p. o. Knot dns, 2013. [cit. 2013-10-08]. Domovská stránka: https://www.kno t-dns.cz/. [60] Bojan Zdrnja, Nevil Brownlee, Duane Wessels. Passive Monitoring of DNS Anomalies. Proceedings of the 4th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, DIMVA ’07, s. 129–139, Berlin, Heidelberg, 2007. SpringerVerlag. ISBN 978-3-540-73613-4. [61] ZedLan. WinDNSLogAnalyser [online], 2010. [cit. 2013-10-29]. Domovská stránka: http:// www.zedlan.com/win_dns_log_analyser.php.

68

Příloha A

Obsah přiloženého DVD ∙

/text_prace/ – složka obsahující elektronickou verzi diplomové práce,

∙

/detekcni_skripty/ –

./Bro/dns_visually_similar.bro – příklad Bro skriptu pro detekci vizuálně podobných domén,

–

./IPFIX/DNSAnomDet-1.0.tar.gz – instalační balík detekčních skriptů DNSAnomDet,

–

./IPFIX/DNSAnomDet-1.0/ – složka obsahující rozbalenou verzi balíku detekčních skriptů DNSAnomDet,

–

./NetFlow/ – složka obsahující skript pro detekci použití externích DNS využívající standardní IP toky.

69

012345

Recommend Documents