Názory k článku Zabezpečte svůj DNS server
-
j (neregistrovaný)
Par tehcnickych:
1) toto prevazne nepali majitele/provozovatele 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...) -
Ondřej CaletkaZlatý podporovatelV 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ů.
-
Ondřej CaletkaZlatý podporovatel
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.
-
j (neregistrovaný)
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.
-
a (neregistrovaný)
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).
-
a (neregistrovaný)
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á.
-
j (neregistrovaný)
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.
-
Ondřej CaletkaZlatý podporovatel
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ší :)
-
Apache (neregistrovaný)
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.
-
Ondřej CaletkaZlatý podporovatel
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.
-
Ondřej CaletkaZlatý podporovatel
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. -
PavelM (neregistrovaný)
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.
-
pepazdepa (neregistrovaný)
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
-
[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.
-
Ondřej CaletkaZlatý podporovatel
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.
-
ezdiy (neregistrovaný)
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.
-
Ondřej CaletkaZlatý podporovatel
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.
-
ezdiy (neregistrovaný)
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.
-
Ondřej CaletkaZlatý podporovatelPS: 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é.
ČLÁNKY DO MAILU