}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya Masarykova univerzita Fakulta informatiky Bezpečnostní analýza provozu DNS Diplomová práce Milan Čermák Brno, podzim 2013

2 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 Milan Čermák Vedoucí práce: RNDr. Jan Vykopal, Ph.D. ii

3 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

4 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

5 Obsah 1 Úvod Obsah práce Domain Name System Historie Doménová jména Implementace a struktura Protokol DNS Záznamy Formát zpráv DNS Security Extensions Software Správa serveru Nástroje pro práci s DNS Online dostupné nástroje Bezpečnost DNS Odmítnutí služby Změna konfigurace DNS Zneužití vyrovnávací paměti DNS Přesměrování provozu DNS Ostatní zranitelnosti Shrnutí Monitorování provozu DNS Ukládání dotazů na serveru DNS Zpřístupnění provozních záznamů DNS Zpracování uložených záznamů Monitorování paketů DNS Hloubková analýza paketů Analýza IP toků Shrnutí Anomálie provozu DNS Provozní anomálie Nadměrný provoz DNS Tunelování provozu Dotazy na neexistující záznamy Využívání DNS resolverů mimo lokální síť Bezpečnostní anomálie Cybersquatting Amplifikační útok Dotazy na neobvyklé typy záznamů Dotazování závadných domén Domény specifických vlastností Společné chování více zařízení Analýza provozu DNS v síti MU

6 5 Metody detekce anomálií provozu DNS Detekce využívání DNS resolverů mimo lokální síť Metoda využívající standardní IP toky Metoda využívající rozšířené IP toky Vyhodnocení nasazení Detekce návštěv vizuálně podobných domén Popis metody Implementace Vyhodnocení nasazení Detekce amplifikačního útoku Popis metody Implementace Vyhodnocení nasazení Detekce otevřených DNS resolverů Popis metody Implementace Vyhodnocení nasazení Detekce dotazů na závadné domény Popis metody Implementace Vyhodnocení nasazení Shrnutí Závěr A Obsah přiloženého DVD

7 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

8 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

9 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

10 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átory 1. 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 Generické domény. Národní domény mil edu... com net org us uk... pl cz sk mit google ieee amazon zona mail docs 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

11 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 V rámci České republiky jsou provozovány celkem 3 instance kořenových serverů (viz tabulka 2.1). Označení Operátor IPv4 adresa IPv6 adresa Umístění F Internet Systems :500:2f::f Praha, stejná instance Consortium, Inc. jako J J VeriSign, Inc :503:C27::2:30 Praha, stejná instance jako F L ICANN :500:3::42 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) Dotaz: pc1.zona.cz Odkaz na.cz cctld DNS Kořenový DNS Dotazovaný DNS (2) (3) Dotaz: pc1.zona.cz Odkaz na zona.cz DNS Dotaz: pc1.zona.cz Autoritativní odpověď cctld DNS Autoritativní DNS pro zona.cz Obrázek 2.2: Hierarchie DNS serverů při překladu adresy pc1.zona.cz. 7

12 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í Hierarchie DNS DNS Proxy (cache) (3) DNS resolver (cache) (4) DNS (5) kořenový server Počítač DNS (6) TLD server Prohlížeč (cache) (1) 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ž 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 spo- 8

13 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í 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 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. Obsahuje ovou adresu na správce domény. Jelikož je využíván pro jiné účely, je nahrazován tečkou (například admin@zona.cz 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

14 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 IN SOA ns1.zona.cz. admin.zona.cz. ( ; 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 IN NS ns1.zona.cz. zona.cz IN NS ns2.zona.cz. ; mail server Resource Records for the zone (domain) zona.cz IN MX 20 smtp1.zona.cz. zona.cz IN MX 30 smtp2.zona.cz. ; host RR ns1 IN A ns2 IN A smtp1 IN A smtp2 IN A pc1 IN A ; alias to zona.cz www IN CNAME zona.cz 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

15 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 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

16 2. Domain Name System 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 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 Zóna.: DS n550f30618be204e SIG 31088aa325d9c403 Klíč pro.: xd253c5f (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: y46ea4256ad4b6a zona.cz Zóna.zona.cz: A 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

17 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 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] 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

18 2. Domain Name System 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 dig 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 ANY +bufsize= dnssec # Získání PTR záznamu pro danou IP dig -x 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 support.microsoft.com/default.aspx?scid=kb;en-us; 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 nslookup -type=any zona.cz

19 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: muni.cz registrant: SB:LM9-RIPE_XX registrar: REG-GENREG registered: :00:00 changed: :30:53 expire: contact: SB:LM9-RIPE_XX org: Masaryk University address: UVT, Botanicka 68a address: Brno address: address: CZ ludek@ics.muni.cz nsset: NSS:MUNI-UVT:4 nserver: ns.muni.cz ( ) nserver: ns2.muni.cz ( ) 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: 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: 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

20 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 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

21 2. Domain Name System 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í ové 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 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

22 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. cctld DNS (2) (4) ID 96: Odkaz na zona.cz Dotaz bg89.zona.cz (5) Dotaz (6) Odpověď Útočník (1) Dotaz bg89.zona.cz (7) Dotaz Útočník (3)... ID 96: Odkaz na zona.cz ID 1: Odkaz na zona.cz DNS resolver (8) Odpověď 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

23 2. Domain Name System 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 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

24 2. Domain Name System 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

25 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 #57021 (zona.cz): query: zona.cz IN A +E ( ) client #56090 (ns1.zona.cz): query: ns1.zona.cz IN A +E ( ) client #49884 ( query: IN A +E ( ) client #52281 (zona.cz): query: zona.cz IN A + ( ) client #60675 (zona.cz): query: zona.cz IN AAAA + ( ) client #60094 (zona.cz): query: zona.cz IN MX + ( ) 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

26 3. Monitorování provozu DNS 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 až 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 d64 R Q [0085 A D NOERROR] A (4)zona(2)cz(0) Snd R Q [0085 A D 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

27 3. Monitorování provozu DNS 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

28 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 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

29 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 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

30 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

31 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 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 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

32 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í. Záznamy Upozornění 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 . 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.bro 1. 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

33 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 : #separator \x09 #set_separator, #empty_field (empty) #unset_field - #path dns_cybersquatting #open #fields response_time client_ip domain domain_ip #types time addr string addr is.mumi.cz 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ů 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

34 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 První verze, která podporovala pouze IPv4. Nyní zastaralé. 5 Jedna z nejrozšířenějších verzí. Podporuje pouze IPv4. 9 Standard IETF. Založená na šablonách. Podporuje IPv6, MPLS a IPv4. 10 (IPFIX) 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

35 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

36 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