Vlákno názorů k článku Zabezpečte svůj DNS server od j - Par tehcnickych: 1) toto prevazne nepali majitele/provozovatele onoho DNS...
-
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.
ČLÁNKY DO MAILU