Názory k článku Útok na DNS náhodnými dotazy
-
Buki (neregistrovaný)
Musim trochu zapropagovat :), nekomu by to mohlo pomoct:
http://blog.powerdns.com/2015/03/11/introducing-dnsdist-dns-abuse-and-dos-aware-query-distribution-for-optimal-performance/ -
Filip JirsákStříbrný podporovatelTo řešení S DNSSEC řeší podle mne jen okrajový případ, kdy útočník na DNS server domény druhého řádu útočí přes generované názvy 4. řádu. Předpokládám, že ale mnohem častější útoky, než
random.www.example.combudou přímo narandom.example.com, ne? A tam už DNSSEC nepomůže. Má smysl tu „díru“ zazáplatovat, ale asi to moc nepomůže… -
Ondřej CaletkaZlatý podporovatelŘeší to úplně stejně. konkrétně random.example.com je pokryto NSEC záznamem
example.com. IN NSEC www.example.com. …
Na tom, kolik teček v sobě dotaz má vůbec nezáleží, NSEC záznamy pokrývají v kruhu celou zónu. Umožňují každému vyčíst, které záznamy v zóně existují a tedy i to, že žádné jiné existovat nemohou.
Ostatně, to, že NSEC záznamy umožňují vylistovat všechna existující jména v zóně je některými vnímáno jako bezpečnostní riziko a je to zároveň důvod, proč byl vynalezen mnohem komplikovanější systém NSEC3 (a možná ještě bude NSEC4). I pro NSEC3 ale platí, že je jej možné použít k určení neexistujícího záznamu. V takovém případě to ale vyžaduje jisté výpočetní nároky na straně rekurzivního serveru, který musí dotazované jméno nejprve několikrát zahashovat a pak najít, zda leží v nějakém rozsahu pokrytém NSEC3 záznamy. -
Filip JirsákStříbrný podporovatel
V tomhle případě by ale rekurzivní server musel mít stažený seznam všech NSEC3 záznamů (případně celou zónu při použití NSEC). A pak nejprve podle těchto záznamů určit, zda doménové jméno existuje. To je podle mne mnohem náročnější, než se jenom podívat do cache a zjisti, že nic pod
www.example.comneexistuje. Nejspíš má smysl tenhle výpočet dělat až tehdy, pokud by rekurzivní server zjistil, že daná doména je pod útokem. Jenže pak zase hrozí, že autoritativní server zahltí požadavky na ty NSEC/NESC3 záznamy. -
Ondřej CaletkaZlatý podporovatel
Ano, náročnější to bezesporu je. Ale pokud jde o validující resolver, většinu věcí stejně dělá kvůli validaci už teď. Server nemusí mít nutně od začátku všechny NSEC/3 záznamy, ty se postupně naučí při odpovídání na několik prvních dotazů. Nejtěžší tak asi bude nějakým optimálním způsobem implementovat cache těchto záznamů, aby se v ní dalo rychle vyhledávat, zda hledané slovo je pokryté, nebo ne. S indexováním jen podle levého pole to asi nepůjde.
S NSEC3 se to zkomplikuje v tom, že server musí nejprve najít v cache nejdelší shodu na záznamu typu NSEC3PARAM, podle těchto parametrů dotazované jméno zahashovat a pak hledat, zda je dotazované heslo pokryté v cache. Tohle hashování ale není marné, stejně by ho musel provádět při DNSSEC validaci obdrženého NSEC3 záznamu.
-
Ondřej CaletkaZlatý podporovatel
Nikoli, pro autoritativní server je pravděpodobně stejně náročné odpovědět na dotaz na neexistující záznam návratovým kódem
NXDOMAINjako odpovědět na dotaz použitím žolíku.Problém je, že k expanzi žolíkového znaku dochází už na straně autoritativního serveru, takže rekurzivní resolver se nemá jak dozvědět*, že daný záznam je vytvořený z žolíku a musí tedy každou jednu instanci samostatně kešovat.
*) Ve skutečnosti se takovou informaci může dozvědět opět jen z DNSSEC podpisů.
-
j (neregistrovaný)
Ehm ... nebylo by pak jednodussi povolit verejne DNS transfer, a tim padem netreba zadny DNSsec? Jo aha, to by bylo moc jednoduchy ... a malo narocny na vykon ... on by totiz ten resolver pak mohl ziskat vsechny zaznamy jedinym dotazem. Takhle jich muze posilat i nekolik tisic, nez precte celou domenu ...
No nakonec se teda budem umet branit tomu, ze nekdo zneuzije verejne dostupne dns (pokud nas tedy pred tim bude hodlat branit prave jeho provozovatel, ktery k tomu ale nema zadny rozumny duvod) ... tak si trivialne napise trivialni script (protoze to nemusi byt ani zadna binarka) a ten spusti na stovkach tisic stroju.
A to sme u toho, ze drtiva vetsina domen DNSSEC nepouziva. Protoze z trivialni ulohy odpovedi na dotaz, dela vypocet atomovy bomby. Takze v primerene blizke budoucnosti prijde nekdo s trivialnim postupem, jak vykonostne slozit celej DNS strom.
-
ebik (neregistrovaný)
U autoritativního serveru to tak je. Nicméně problem vzniká na rekurzorech, ty by totiž mohly ošahávání domén zastavit, pokud mají potřebnou informaci. Protože jinak, jak již bylo zmíněno, mají povinnost odpověď z někoho vytřískat, což v případě přetíženého autoritativního serveru celou situaci zhoršuje.
A ano na to aby validující rekurzor odpověděl, musí validovat, a to není jednoduchá operace.
-
Filip JirsákStříbrný podporovatel
Popsané útoky neútočí na rekurzory, ale na autoritativní servery. Pokud se bude rekurzor zabývat validací odpovědi a nebude mít čas posílat hloupé dotazy na autoritativní server, je to pro autoritativní server výhra. A pokud se někdo pokouší zahltit rekurzor, je to "v pořádku" - rekurzor obvykle poskytuje své služby do "své" sítě, takže stačí, když si správce udělá ve "své" síti pořádek. Ano, tou sítí může být ISP, ale podle mne by se ISP měl starat o to, že z jeho sítě se někdo pokouší útočit - a v tomto případě má ISP výhodu, protože útok je veden na jeho server a tudíž se o něm hned dozví. Pokud někdo, např. Google, provozuje otevřené rekurzory, má to těžší - ale rozhodl se k tomu dobrovolně, tak snad ví, co dělá a jaká to má rizika.
-
it ide do prdele (neregistrovaný)
neviem ci som sam ale it ide do prdele. vyvoj zaspal v dobe kamennej.
dns je tomu jasnym prikladom.
Miesto toho aby sa domenova databaza zotriedila na X skupin podla logaritmu periodicity zmien a nasledne zotriedila abecedne a rozdelila na rozumne velke bloky po cca 100 KB. Nasledne pri zmene alokacie by master jednoducho notifikoval subscriberov ze blok 54as5d6 vyprsal a aktualizoval sa na 456sfd5.
"mirror" server by mal nacacheovanu tabulku prvych zaznamov v kazdom bloku a hashe blokov a tu by odposielal. nasledne client by dopytoval cele bloky. na co mirror by poslal bud obsah bloku alebo hash + obsah aktualizovaneho bloku.
naslnedne deploynut tisice mirror serverov a problem vyrieseny.
-
Filip JirsákStříbrný podporovatel
Takže bychom někde měli abecední seznam všech domén rozdělený po cca 100 kB blocích (protože by se samozřejmě všechny domény nacpaly do té skupiny s nejčastější obnovou - dát doménový název do jiné skupiny by přinášelo jen samé problémy). Celá tahle databáze by se nepřetržitě distribuovala na tisíce zrcadel. Zároveň by nezadržitelně rostla, jak by se do ní neustále přidávaly další a další záznamy - a hackeři by soutěžili, kdo dokáže doménové záznamy vytvářet rychleji a komu se jako prvnímu podaří celý ten systém zahltit. Také by vznikaly zajímavé chyby souběhu, kdy by někdo měl uložený nějaký blok, zjistil by, že pro zodpovězení dotazu potřebuje blok následující - jenže než by o něj požádal, došlo by k distribuci další verze databáze, všechny bloky by se samozřejmě posunuly, a on by musel s dotazováním začít znova (a stihnout to do té doby, než dojde k další distribuci nové verze).
V čem by to bylo lepší, než současný systém? Třeba na vyčerpání zdrojů pomocí dotazů na neexistující domény by ten systém byl náchylnější, než dnes, protože odpovědí na dotaz by nebyl krátký UDP paket o neexistenci záznamu, ale celý 100 kB blok.
-
Filip JirsákStříbrný podporovatel
V článku se řeší rekurzivní resolvery, Knot DNS je autoritativní server. CZ.NIC sice také píše rekurzivní resolver (který bohužel bude mít v názvu také Knot), ale ten je ještě ve vývoji („early development phase“).
-
wrigley (neregistrovaný)
Dekuji panu Caletkovi za clanek. Je to presne tak, jak pise. Pridam zkusenost od ISP. Ukoky tohoto typu zacaly nekdy v unoru 2014. Navic, cilove domeny, ktere jsou pro tento typ utoku pouzite, jsou IMHO zamerne registrovane pro tento ucel a jejich NS zamerne neodpovidaji, tj. cilem utoku jsou spise primo rekurzory. PowerDNS, ktery jsem mel tehdy nasazeny se stal v tehdejsi verzi nepouzitelny. Nejdriv dosly filedescriptory a pak i zdrojove porty pro dotazy. 20 tisic dotazu/s tohoto charakteru polozilo farmu se ctyrmi resolvery jako nic. A kdyz nemely problemy vlastni rekurzory, tak sitove prvky (fw) kolem, protoze musely drzet stavove informace k probihajicim dotazum a dochazela jim pamet. S Unboundem se tahle situace da pomerne dobre zvladnout popisovanym zavadenim prazdnych lokalnich zon, kde se posilame ne NX DOMAIN, ale REFUSED. Snaze se pak identifikuje, napr. v packet capture, kdo skodi. PowerDNS rekurzor prosel za posledni rok upravami za ucelem zvyseni odolnosti proti utokum, ale jeste jsem ho nezkousel, protoze zatim nema podporu DNSSEC.
-
wrigley (neregistrovaný)
Jeste pridam jeden zajimavy odkaz. Komunita kolem PowerDNS pripravila DNS balancer, ktery lze pouzit pri obrane proti temto utokum:
http://blog.powerdns.com/2015/03/11/introducing-dnsdist-dns-abuse-and-dos-aware-query-distribution-for-optimal-performance/ -
MP (neregistrovaný)
Chtel bych se zeptat, pokud dobre rozumim, tak jste meli rekurzory pdns na portu 53, z kterych jste to pripadne smerovali na autoritativni servery? Jak jste pak resili forward tech zon na autoritativni - nepredpokladam, ze jste rucne upravovali kazdy rekurzor v pripade, ze byla pridana/odebrana zona na autoritativnim serveru. Mam momentalne autoritativni servery nad databazi pred rekurzory prave kvuli te automaticke funkcnosti zon, ale pokud by existovala cesta, jak tu samou funkcnost zprovoznit i v rekurzorovym forwardu, tak me to dost zajima.
Diky -
wrigley (neregistrovaný)
Ty k utoku zneuzivane zony zavadime lokalne primo do rekurzoru pomoci unbound-control:
local-zone: 11hhaa.com. refuse
local-zone: 11kkpp.com. refuse
local-zone: 11nini.com. refuse
local-zone: 11wan.com. refuse
local-zone: 1212w.com. refuse
local-zone: 1234176.com. refuseTim se zamezi posilani dotazu do teto zony na jeji autoritativni NS a rovnou se to rejectne. Ale mozna jsem nepochopil, jak to myslite.
-
Kolemjdoucí (neregistrovaný)
"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." - to je holt tak když je někdo líný si zjistit jak se ten maximální počet otevřených souborů jedním procesem dá zvýšit, Google najde spoustu dokumentace jako například http://stackoverflow.com/questions/3734932/max-open-files-for-working-process
-
Sten (neregistrovaný)
Pro naslouchání máte 65 535 portů, na kterých můžete čekat příchozí spojení, (navíc pro každou IP adresu zvlášť, takže s více IP adresami tento limit lez zvýšit). Sestavená spojení ale takto omezena nejsou, protože kromě lokálního portu jsou ještě identifikována vzdálenou adresou a vzdáleným portem.
-
Ondřej CaletkaZlatý podporovatel
Nebyl líný, zjistil a nastavil, ale stejně nepomohlo. I při zvýšení limitu na 8000 se počet současně probíhajících rekurzivních dotazů zastavil pod hodnotou 4500 a server začal nahodile odmítat nové dotazy. Nemusí tedy nutně jít jen o limit počtu otevřených souborů, ale třeba i o to, jak BIND vnitřně funguje.
-
Kolemjdoucí (neregistrovaný)
Budiž, pak to není lenost ale jen trestuhodná nedůslednost - proč jste tedy ten limit 4500 v článku tak přímočaře svedl na limit počtu otevřených souborů jedním procesem? Měřil jste vůbec kolik měl proces nameserveru ve skutečnosti otevřených filedescriptorů? Hint: ls -1 /proc/<pid>/fd | wc -l
-
Ondřej CaletkaZlatý podporovatel
Máte pravdu, mohlo to být formulováno lépe, omlouvám se.
Faktem je, že při prostém zvýšení limitů v konfiguraci BINDA se logy začaly plnit zprávami o vyčerpaném počtu otevřených souborů. Po zvýšení limitu počtu otevřených souborů takové zprávy zmizely, podle logů k žádné chybě nedocházelo, nicméně BIND náhodně vracel SERVFAIL pro legitimní dotazy. Připadalo mi to příliš komplikované na vysvětlení v daném místě článku, proto jsem se uchýlil ke zkratce.
-
MilanJ (neregistrovaný)
Diky za clanek.
Podobnym utokum celime casto. Provozujeme Unbound a reseni jsme (pred mnoha mesici) nasli v blokovani problematickych dotazu pomoci iptables na nasich resolverech (anycast BGP po Evrope). Ackoliv by si nekdo mohl rict, ze L7 packet inspekce je prilis, funguje to perfektne (na novych kernelech).
Jinak v Unbound serveru tohle lze jednoduse sledovat pomoci unbound-control dump_requestlist |awk '{ print $4}'| rev | cut -d'.' -f -3 | rev | sort | uniq -c | sort -n
Milan
-
MilanJ (neregistrovaný)
Jen kratce:
iptables -I INPUT -m string --hex-string "|043133727903636f6d|" --algo bm --to 100 -j DROP -m comment --comment '13ry.com'Ten hex-string je jmeno problematicke domeny kodovane napr. pomoci :
#!/usr/bin/env pythonimport codecs
import sysif len(sys.argv) < 2:
sys.exit('Usage: %s human-string' % sys.argv[0])hexlify = codecs.getencoder('hex')
for label in sys.argv[1].split('.'):
sys.stdout.write(str("{0:0{1}x}".format(len(label),2)))
sys.stdout.write(hexlify(label)[0])sys.exit()
Snad to pomuze.
-
MilanJ (neregistrovaný)
Pro uzivatele Unbound resolveru - https://github.com/hdais/unbound-bloomfilter
