V únoru 2014 se ve velké míře začal objevovat nový fenomén, zneužívající nejen otevřené rekurzivní servery. Cílem takového útoku je přetížení autoritativních serverů pro určitou doménu. Útočník postupuje tak, že vygeneruje dotazy složením z náhodného řetězce doplněného o existující doménové jméno oběti, například iree0foh.www.example.com. Náhodný řetězec se přitom pro každý dotaz mění.
Takovéto dotazy potom útočník rozešle rekurzivním serverům v internetu; to lze udělat buď z nějakého serveru, ideálně v síti, která nefiltruje podvržené zdrojové adresy, nebo může použít botnet. V prvním případě útok probíhá přes otevřené rekurzivní servery, v druhém případě to však není nutné a je možné použít DNS resolvery z nastavení hostitelského systému dané instance botnetu.
Protože je téměř jisté, že na takový dotaz nebude v cache rekurzivního resolveru připravena odpověď, je resolver donucen dotázat se přímo autoritativního serveru. Není-li autoritativní server dostatečně výkonný a připojený dostatečně silnou linkou, neustojí takový nápor dotazů z resolverů celého světa.
Seriál vznikl za přispění Národního CSIRT týmu České republiky CSIRT.CZ, který provozuje sdružení CZ.NIC, správce české národní domény. CSIRT.CZ je bezpečnostní tým pro koordinaci řešení bezpečnostních incidentů v počítačových sítích provozovaných v České republice. Cílem jeho členů je pomáhat provozovatelům internetových sítí v České republice zřizovat jejich vlastní bezpečnostní týmy a bezpečnostní infrastrukturu, řešit bezpečnostní incidenty a tím zlepšovat bezpečnost jejich sítí i globálního internetu. Více informací na www.csirt.cz.
Zpětný rozptyl na resolvery
Dalo by se říct, že přetížením autoritativních serverů, případně linky k nim, je dílo dokonáno. Z pohledu oběti to tak zajisté platí – internetové služby poskytované na doménách oběti jsou nedostupné. Přesně v tu chvíli ale nastane druhá, útočníkem zřejmě ne zcela plánovaná fáze útoku.
Zahlcený autoritativní server/linka začne na dotazy rekurzivních serverů odpovídat s velkou ztrátovostí. Protože úkolem rekurzivního resolveru je vyvinout veškeré úsilí k získání odpovědi pro klienta, bude se pokoušet opakovat dotaz víckrát a vyzkouší i všechny servery cílové domény. Tím se tedy rekurzivní resolver v dobré víře stává zesilovačem útoku, který na jeden zdrojový paket od útočníka vygeneruje několik paketů ke všem autoritativním serverům oběti. Takto násobený počet paketů skomírající autoritativní servery zaručeně dorazí.
Ale to pořád není všechno. Důsledkem zahlceného autoritativního serveru se rekurzivnímu serveru nakonec nepovede odpověď získat a po nějaké době, typicky 30 sekund, vrátí klientovi odpověď s návratovým kódem SERVFAIL. Prostředky rekurzivních resolverů jsou ale omezené. Nejpoužívanější server BIND má například výchozí limit na 1000 současně probíhajících rekurzivních dotazů. Je-li překročen, jsou další dotazy ihned odmítány s návratovým kódem SERVFAIL. Jestliže je zahlcen rekurzivními dotazy, kde (ne-)vyřízení každého trvá třicet sekund, dá se triviálně vypočítat, že k odepření služby takového serveru stačí zásobovat jej podobnými dotazy tempem pouhých 33 dotazů za sekundu. Tahle fáze útoku tedy tak trochu připomíná webový útok slowloris.
Obzvláště pikantní je pak situace pro tradiční poskytovatele internetového připojení, dosud přidělující rezidentním zákazníkům veřejné IPv4 adresy. Domácnosti jsou totiž přeplněny velmi levnými a často nepříliš kvalitními domácími routery. Ty kromě zranitelností jako rom-0 často obsahují také špatně nastavený DNS forwarder, který poslouchá i na WAN rozhraní a přeposílá dotazy rekurzivním serverům poskytovatele. Ty se pak stanou úzkým hrdlem, do kterého se valí tisíce nesmyslných dotazů odražených od domácích routerů zákazníků.
Jednoduchá protiopatření neexistují
Vystupujeme-li v našem příběhu v roli provozovatele autoritativních serverů, které se dostaly pod útok, asi nemáme jinou možnost, než přidat na robustnosti a kapacitě. Tradiční rate-limiting nepomůže, protože každý dotaz je unikátní a dotazy se nesnaží vylákat velké zesílení, jak bylo dříve obvyklé. Protože provoz agregovaný z celého světa v jednom místě může snadno přetížit nejen koncový server, ale i nejbližší síťovou infrastrukturu, je asi jedinou realistickou možností zprovoznění anycastu, který rozprostře provoz po celém světě. Takové anycastové cloudy jsou nabízeny i jako služba, některé dokonce i zdarma.
Horší situace je u provozovatelů rekurzivních serverů. Jsou-li dosud provozovány jako otevřené a takové otevření není k jejich účelu nezbytné, je uzavření rekurzivní funkce prvním logickým krokem. Zdá se totiž, že výše popsaná varianta botnet je prozatím výrazně méně obvyklá oproti variantě server. Dalším krokem, který se nabízí, je zvýšení limitu současně probíhajících rekurzivních dotazů u serveru BIND. K tomu slouží volba recursive-clients. Tohle řešení ale bez rizika také není, s každým rekurzivním dotazem BIND jednak spotřebuje asi 20 kB paměti, hlavně ale otevře jeden file descriptor. Počet otevřených souborů jedním procesem je ale také omezený, takže limit počtu rekurzivních dotazů není možné zvýšit na víc než přibližně 4500.
Další možností je zablokování domén obětí definicí prázdné autoritativní zóny. Tím se zabrání dalšímu útočení na servery oběti a také výrazně klesne počet současně probíhajících rekurzí. Na druhou stranu, daná doména je pro všechny uživatele daného rekurzivního serveru nefunkční. Doménová jména, na která se útočí se navíc velmi rychle mění a je tedy potřeba zablokovávat stále nová a nová a ta stará včas z blokování vyřadit. Postup je možné částečně zautomatizovat, kdy se v pravidelných intervalech zeptáme příkazem rndc
recursing na právě probíhající rekurze a v nich najdeme ty domény, které se často opakují a jejichž rekurze trvá příliš dlouho. Jen je třeba dát pozor na domény jako in-addr.arpa, které by mohly být omylem také zablokovány.
Je-li naší roli v celém příběhu role internetového poskytovatele, jehož zákazníci mají doma děravé routery odrážející DNS dotazy z internetu, asi by bylo nejlepším řešením buď donutit zákazníka k nápravě, nebo síť přeorganizovat tak, aby bylo možné takovéto problémové zákazníky umístit za firewall. Ani jedno řešení však obvykle není jednoduše proveditelné, ať už z důvodů právních, nebo třeba proto, že síť tvoří plochou strukturu, kde není snadné zákazníky rozdělovat do kategorií a selektivně filtrovat jejich provoz.
Problém přetíženého rekurzivního serveru může pomoci vyřešit také použití alternativy. Například Unbound zvládá mnohem vyšší množství současně probíhajících rekurzivních dotazů bez odpírání služby legitimním klientům.
DNSSEC by mohl pomoci
Zamyslíme-li se nad způsobem, jakým tento útok funguje, zjistíme že využívá skuliny v návrhu jinak agresivně kešovaného protokolu DNS. Autoritativní server může rekurzivnímu v odpovědi na dotaz sdělit, že dotazované jméno existuje nebo ne a v obou případech přidá i informaci o tom, jak dlouho si má rekurzivní server odpověď pamatovat (pro neexistující záznamy se použije hodnota z pole minimum záznamu SOA dané zóny). Odpověď autoritativního serveru ale vždy přísluší k dotazovanému jménu, protokol neumožňuje, aby server sdělil například: „ iree0foh.www.example.com neexistuje, a neexistuje ani nic jiného v podstromu www.example.com, tuto informaci si zapamatuj 1 hodinu.“
Zajímavé ale je, že přesně takováto funkce byla před lety zavedena coby NSEC/ NSEC3 záznamy pro DNSSEC. Jejich původní účel je umožnit serveru podepsaně popřít existenci dotazovaného záznamu i v případě, kdy server nemůže generovat podpisy v reálném čase. Jejich vedlejším efektem je, že přesně vymezují lexikální prostor mezi existujícími DNS záznamy v dané zóně. Představme si například, že DNSSEC podepsaná doména example.com obsahuje záznamy:
example.com. IN A 192.0.2.1
example.com. IN NSEC www.example.com. …
www.example.com. IN A 192.0.2.2
www.example.com. IN NSEC example.com. … Validující DNS resolver během prvních několika dotazů naplní svou paměť oběma NSEC záznamy, a po dobu jejich života si může být jistý, že v doméně example.com neexistuje jiná subdoména než www.example.com . Může tedy s klidným svědomím všechny další nesmyslné dotazy odbavovat lokálně, aniž by se pro každý z nich znovu doptával autoritativních serverů.
Takové řešení bohužel zatím není implementováno ani v BINDu, ani v Unboundu, představuje ale jednu z mála cest, jak problém náhodných jmen systematicky řešit. Aby fungovalo, je třeba zavést DNSSEC jak na straně oběti, tak i na straně provozovatele rekurzivního serveru.
Nezbývá, než přidat na výkonu
Ačkoliv se útok v této specifické podobě, někdy též nazývaný jako DNS Water Torture, začal objevovat teprve v roce 2014, jeho princip rozhodně nový není. Úplně stejným způsobem jsou už léta − byť nejčastěji neúmyslně − týrány kořenové DNS servery dotazy pro neexistující domény prvního řádu. S nadsázkou se tedy dá říct, že hlavním úkolem obrovské distribuované architektury kořenových DNS serverů je poskytovat velmi rychle informace o tom, které domény prvního řádu neexistují.
Kořenová zóna je však specifická, přinejmenším tím, že její obsah je veřejně dostupný. To umožňuje velkým operátorům zprovoznit vlastní zrcadlo a globální infrastrukturu ušetřit. Tato praxe nyní prochází standardizací v IETF.
ČLÁNKY DO MAILU