Názory k článku
Zabezpečte svůj DNS server

Ondreji, dekuji Vam za opet perfektni clanek!

Také děkuji. Více podobných článku na rootu!

Děkuji. Mám rád články, které popisují a řeší problémy z reality. Dobře napsané, ještě jednou díky.

Par tehcnickych:

1) toto prevazne nepali majitele/provo­zovatele onoho DNS ale cil utoku
2) problem (a zcela zasadni) je ten, ze pokud uz z nejakeho duvodu provozuju verejny DNS, tak taky musim pocitat s tim, ze IPv4 a ... NAT => z jedne IP mi zcela legalne muzou chodit tisice dotazu, protoze za tou jednou IP muzou byt stovky stroju.
3) neni od veci zduraznit, ze DNSSEC tomu nejen nepomuze, ale velmi zasadne zhorsuje stav prave tim, ze nasobne vice zvetsi odpovedi pripojenim klicu.
4) k filtrovani asi toliko, ze mam dlouhodobe vyzkouseno, ze drtiva vetsina provideru nefiltruje ani privatni rozsahy (uplne klidne doputuje paket s odesilatelem na 192.168...)

V podstatě souhlasím se všemi body.

Jen k bodu 2: Stejně si dovoluji tvrdit, že rozdíl mezi běžným provozem (byť od NATovaných klientů) a DoS útokem je řádový. Navíc málokdo provozuje skutečně veřejný DNS server v tom smyslu, že by k jeho používání zval celou veřejnost. Mnohem častěji jde o neveřejnou DNS službu například pro klienty/zaměstnance společnosti, která pouze není nijak zabezpečena a je jí možno používat odkudkoli. V takovém případě taky NAT nehraje roli.

Stejně tak v případě autoritativních serverů nehraje NAT roli, za jedním NATem budou maximálně jednotky rekurzivních resolverů.

Verejny server provozuje kazdy, kdo na nem ma svou domenu. To bude drtiva vetsina. Serveru urcenych pro klienty zase tolik nebude - spousta "ISP" odkazuje na verejne dostupne servery (trebas googlu ...).

Viz druhý odstavec předchozího komentáře. V případě autoritativního serveru nehraje NAT žádnou podstatnou roli, za stejným NATem budou maximálně jednotky rekurzivních resolverů, ty navíc mají cache, takže nechodí na autoritativní server s každým požadavkem.

Ad 1) pálí to i provozovatele DNS, neb to může vytížit linku (zrovna minulý týden se mi up/down prohnalo pár GB a rodina si stěžovala, jak je ten internet pomalý...). Ještě, že nemám FUP.

Psal ze ze prevazne - neni totiz treba (a ani to neni ucel) zahltit DNS server jako takovy. Staci na nej posilat desitky dotazu. A samo, posilat ty desikty dotazu na par desitek / stovek DNS serveru = velmi slusnej DOS na cilovou IP. Tusim ze pri pouziti DNSSEC dojte az k padesatinasobnymu zvetseni objemu dat. Tudiz pokud rekneme vygeneruju na jeden DNS server 10kbit a ten odesila 0,5Mbit, tak to pro ten srv neni nic ceho by si vsimnul (predpokladam ze drtiva vetsina serveru bude mit pripojeni alespon v jednotkach Mbit jen pro sebe), ale ja muzu na jedne pidilince x 100 (=1Mbit odchozicho trafficu) vygenerovat DOS 50Mbit jen pomoci smesnych 100 DNS serveru. A to si dovolim tvrdit, ze ani 10x vetsi traffic by pro vetsinu DSN serveru nebyl zasadni problem. Takze by mi technicky stacilo 10 DNS serveru na linkach 10Mbit+, aby admini tech DNSek nic neresili.

A voiala, staci mi libovolna kavarna a vygeneruju DOS, kterej slozi vpodstate cokoli.

> A voiala, staci mi libovolna kavarna a vygeneruju DOS, kterej slozi vpodstate cokoli.

Neslozi, ale muze zahltit linku. Vzhledem k nestavovosti UDP server paket proste zahodi, protoze ho neocekava. Nedojde ani k zadnemu bobtnani tabulek jako u SYN floodu.

Takze jak se to zda me, s tim zahlcenim linky to taky neni tak zhave. Jestlize prodpokladam, ze server A odbavi tok X tak, ze si ho ani nevsimne, a mam takovych serveru 10, tezko predpokladat, ze tok X*10 zahlti linku serveru B.

Takze imho utok musi jit bud proti stroji s radove slabsim pripojenim (ADSL apod.), nebo musim mit radove vic zesilovacu nez deset.

ad 2) - tomu se dá vyhnout tím, že mezi rekurzivní klienty a DNS server se prostě NAT nedá (bude se normálně routovat, bez NATu). No a nerekurzivních klientů nikdy nebude hodně (v případě že server vůbec má být pro nějaké domény autoritativní), od toho je v DNS zabudovaný princip cache (s konfigurovatelným TTL).

Vubec nepotrebujete rekurzivni DNS, staci vam libovolne DNS, pokud mate DNS pro svou domenu, tak to DNS tak nejak chte nechte MUSI klientum odpovidat. A pokud na nem mate DNSSEC, tim lip. Rekurze stim nema nic spolecneho.

Fígl je v tom, že na nerekurzivní dotazy pro mé domény se sice odpovídat MUSÍ, ale pouze na rozumně malý počet dotazů za nějaký čas z každé IP adresy (NAT tady žádný zásadní vliv mít nebude) a nadbytečné dotazy mohu bezpečně ignorovat, protože slušně se chovající resolver používá cache (s mnou určeným TTL) a neslušně se chovající resolver mě nezajímá.

Jiste, takze pokud vas web (napriklad) bude navstevovat spousta kliantu z nejake NATovane site, tak je vyfuckujete, protoze z ty IP prichazi moc dotazu. Ano, jiste tam mohou mit cache, ale taky nemusi. Nehlede na to, ze ti klienti se mohou ptat naprimo - kazdy pekne zvlast, a kazdy si samo odpoved pamatuje, takze se chova naprosto slusne, ale vy druheho a kazdeho dalsiho poslete nekam ....

Mno chtel bych videt firemniho zakaznika, ktery by vas s necim takovym neprisel zastrelit.

„Jiste, takze pokud vas web (napriklad) bude navstevovat spousta kliantu z nejake NATovane site, tak je vyfuckujete, protoze z ty IP prichazi moc dotazu.“

Pokud budou ti klienti navštěvovat i můj nameserver (po k tomu určeném portu), tak je vyfuckuju s velkou radostí :).

Teď nevím, jestli trolluješ, nebo to myslíš vážně. Opravdu se budou klienti ptát napřímo? To jako, že když budu chtít navštívit root.cz, tak si zjistím, že je hostován na adrese 91.213.160.5 a tuhle adresu si nastavím jako DNS server do operačního systému? A pak se budu chtít podívat na seznam, tak tu adresu změním na 77.75.73.77?

No nevím, používání rekurzivního DNS serveru je poněkud komfortnější :)

k bodu 3)
Tady bych pridal, ze DNSSEC nejenomze nepomaha, ale je vlastne vinikem cele situace.
Protoze DNS protocol nebyl navrzen uplne spatne, problem vznikul az v okamziku,
kdy DNS zaznamy zacaly zaplavovat gigadlouhe DNSSEC podpisy a podoble zhovadilosti ve spojeni s EDNS0, kdy muze byt velikost UDP DNS odpovedi vyznamne velka, ze vznika tzn. amplifikace, kdy odpoved je nasobe vetsi nez dotaz.
Pak utocnik posle maly request a server vygeneruje nekolikanasobne vetsi odpoved.
Jak toho zneuzit je pomerne jasna vec, staci podvrhnout cilovou adresu a mate zbran hromadneho niceni :)

Resenim je okamzite zapomenout, ze existoval nejaky DNSSEC a zacit premyslet nad DNSSEC2 v uplne jine forme!
Tak aby se velikost dotazu priblizila velikosti odpovedi a aby byla idelane idealne kryptograficky zasifrovana a to jak dotaz, tak odpoved.
To je podle me reseni.

Kdybyste si článek řádně přečetl a slyšel i to, co nechcete slyšet, tak byste musel nutně dojít k názoru, že chyba je na straně ne-řádné implementace BCP38, což se dotýká i jiných nestavových protokolů než je DNS (včetně ICMP).

Váš návrh řešení ničemu nepomůže, pokud nebude řádně implementováno BCP38 a zároveň bude DNS běhat stále po UDP.

Protoze DNS protocol nebyl navrzen uplne spatne, problem vznikul az v okamziku,
kdy DNS zaznamy zacaly zaplavovat gigadlouhe DNSSEC podpisy a podoble zhovadilosti ve spojeni s EDNS0, kdy muze byt velikost UDP DNS odpovedi vyznamne velka, ze vznika tzn. amplifikace, kdy odpoved je nasobe vetsi nez dotaz.

Tohle není tak docela pravda. Zdaleka nejčastějším typem útoku je čínská IP adresa, co vychrlí na server několik set dotazů typu ANY na apexy všech zón u nás hostovaných a zmizí. Dotaz má cca. 70 bajtů, odpověď je oříznuta serverem, takže má něco kolem 480 bajtů. Nikde žádný DNSSEC, nikde žádné EDNS0. Takže rozhodně není možné tvrdit, že za zesilovací útoky může DNSSEC.

DNSSEC zesiluje silu takovyho utoku, pokud je dobre proveden tak radove.

Ve dvojkové soustavě je to skutečně řádově, v desítkové soustavě je to 2× až cca. 4× (při špatně nastavené doméně). Stejně „řádově“ dokáže sílu útoku zvětšit i doména bez DNSSEC, viz v článku uvedený příklad dgtl.ws.

Super článek, informace v něm jsou přehledně shrnuty, jen je škoda, že OpenWRT nemá do 10.03.01 balíček s hashlimit k dispozici (asi je na čase vyrobit novou image pro router) a také to, že v mém případě je i přes vypnutou DNS router cílem tohoto distribuovaného útoku (ANY pro ripe.net a isc.org).

Ač byl poskytovatel požádán o zablokování na úrovni jejich FW, tak nejdříve hrál mrtvého brouka a pak na několikerou urgenci napsali, že to dělat nebudou, protože nikdo jiný ze zákazníků tyto problémy nehlásí, pravidla na FW by zpomalovala provoz i ostatním a ten 1GB za den příchozího provozu, co mi to v průměru generuje, se v přenesených datech ztratí (a co vlastně řeším, když už nemám FUP). IP adresu mi změnit také odmítli. Takže asi tak.

=> obratem poslat providera doprdele a v zadnym pripade mu uz nezapaltit ani korunu.

jinak existuje uz i patch do bindu - http://www.redbarn.org/dns/ratelimits

plus info from SANS - https://isc.sans.edu/diary.html?storyid=13261

My asi do Knot DNS něco budeme také implementovat, ale zatím nás to nepálí tolik, takže je to spíše v horizontu měsíců, než že bychom něco horečně nabouchali teď. Zároveň to bude potřeba dobře promyslet, abychom kvůli ratelimitingu neztratili výrazně na výkonu.

[lichometnicky mod on]
Clanky Pavla Tisnovskeho a Ondry Caletky nikdy nezklamou. Minimalne kvuli nim ma smysl Root sledovat :)
[lichometnicky mod off]

Kdyby tema nekoho vic zajimalo, tak dost zajimavej typ utoku, o neco promakanejsi nez ten v clanku, prezentovali kluci ze Zone H:
http://www.zone-h.org/news/id/4739
(myslim, ze neco o nem zaznelo i tady: http://www.youtube.com/watch?v=evI22gBKvaw ale nejak to ted v tom videu nemuzu najit)

Zajimavej je hlavne tim, ze se proti nemu da dost tezko branit a jako zesilovac muze pouzit velke mailservery typu Google, Yahoo apod.

Díky za pěkný článek, jen mi tu chybí jedna věc a to jak poznám (kromě zatížení), že někdo používá mé DNS servery k útokům či k něčemu jinému, než je překlad adres, které spravuje?

Různými způsoby, například nezvyklým nárůstem datového toku nebo opakujícími se sekvencemi v logu. S trochou nadsázky lze říct, že každý veřejný server je k takovému útoku zneužit, a ten který ne, ten může být zneužit zítra.

Velice hezky popsano, bohuzel se zda ze autor nikdy nebyl tercem podobneho utoku.

DNSSEC amplify je z technickeho pohledu katastrofa. Proste nelze realisticky predpokladat ze vsude budou source filtery, uz jenom proto ze mnoho ISP ma unixove stroje jako router v tranzitnim AS. Na takovem boxu proste z principu rp_filter nelze mit!

A jak takovy utok vubec vypada? V jednu chvili je spamovano nekolik stovek tisic az milionu autoritativnich DNS, ale zdrojem je zpravidla jeden stroj. To znamena ze hashlimit naprosto postrada smysl, protoze pri spravnem provedeni staci poslat amplify boxu 1 paket za 3-5s, trik je samozrejme v tom ze staci spamovat cely internet naraz.

Tyto incidenty bezne dosahuji 50-100GBps, vse z jednoho 1gbe stroje v nejake zapchle akademicke siti.

A jak do toho zapada wikileaks? Inu, Assange rad prehrava ten martyr complex takze nikdo se tam do reseni techto incidentu zrovna nehrne - Nejdriv to preci musi probehnou medii :-).

Hrube (UDP) DDoS utoky lze v dnesni dobe realisticky ustat az do 200GBps (pr0lexic) a nijak drahe to zas neni, 10gbps lze i zdarma (cloudflare) - coz je momentalne to co tam maji.

Limity četnosti dotazů rozhodně smysl mají. Každou chvíli se objeví nějaká adresa, generující stovky dotazů ta sekundu. Ono je to totiž jednodušší, než posílat každý paket jinam. Na vlastní oči jsem ne jednom serveru viděl provoz kolem 1 Mbps dovnitř a 10 Mbps ven. To rozhodně má cenu řešit.

Inu, pro tento konkretni utok to nijak nerozporuji. Protoze nebyl proveden spravne, pravdepobone utocnik jel round-robin pres seznam domen, a neresil kolikrat se autoritativni DNS opakuje.

Mam-li se tedy poustet do silenych spekulaci:

Vzal to proste round-robin pres domeny ale uz neresil kolikrat se dana IP kazdeho nameserveru pouzije. Vzhledem k tomu ze CZ ma v absolutnich cislech velmi vysoky podil podepsanych domen, reflektory utoku se staly nasi predni registratori kde je bezne k videni desitky tisic domen per ns.

Ma domenka je stavena na tom ze muj ns ktery hostuje 3 podepsane domeny podobny traffic v mrtg nezaznamenal, ale pomerne velky shared NS hosting (3k domen) uz ano.

PS: Amplify 1:10 odpovida spis "klasickemu" ANY amplify dotazu. DNSSEC ma ratio 1:50-1:100.

Nesmysl, k poměru 1:50 musí být v doméně něco hodně špatně a poměr 1:100 je tak leda laboratorní. DNSSEC dotaz na doménu druhého řádu, typ ANY zabere například 82 B. Odpoveď, obsahující SOA, 3×NS, 1×A, 2×AAAA, 5×SSHFP, 3×DNSKEY (2048+2×1024 bitů), 1×MX, 1×SPF a 1×NSEC3PARAM, k tomu všemu ještě RRSIG podpisy, zabere 3167 B. Zesilovací faktor je tedy cca. 39. Nedokážu si představit realistický případ, kde by k jednomu jménu existovalo ještě víc záznamů, i v tomto případě jsou v doméně některé záznamy ne zcela nezbytné.