Zvyseny DNS provoz

[Dalibor Toman]

DD,

zjistil jsem, ze nase DNS servery vykazuji v poslednich dnech zvyseny provoz (zvyseni na nekolikanasobne mnozstvi paketu za sekundu). Pri zkoumani pricin jsem zjistil, ze od nekolika zakazniku (zatim jsem nasel 2) bezi trvale nekolik desitek DNS requestu za sekundu. Jedna se vzdy o kratky (cca 70bytu) dotaz na zaznamy v root zone ('.'), ktery vyvola odpoved o cca 2000B delky. Cele to pripomina DNS amplification utok ale nase sit nepovoluje zfalsovani IP odesilatele paketu (a ani to nevypada, ze se zakaznicke zarizeni o to pokousi).
Nevidel to uz nekdo? At nemusim slozite zjistovat, co za to muze (vir, zblble zarizeni nejaky pekny vanocni darek v podobe spatne fungujiciho zarizeni apod)?

Dik

[backslash]

Ano, je to DNS amplification attack. Pred tyzdnom som to riesil, vacsinou su to IN ANY dotazy na ripe.net, isc.org alebo na korenovu zonu. Nase rekurzivne servery maju povoleny resolving len pre lokalnych klientov a nastastie utok bol vedeny len z jednej taiwanskej IP. Takisto redirectujeme DNS requesty na vonkajsie DNS servery na nase DNS resolvery, takze to schytali tie nase, ale stacilo par minut bafcania s tcpdumpom a vinnici boli najdeni. Takto nam aspon preverilo ze pravidla mame spravne.

[Dalibor Toman]

Ano, je to DNS amplification attack. Pred tyzdnom som to riesil, vacsinou su to IN ANY dotazy na ripe.net, isc.org alebo na korenovu zonu. Nase rekurzivne servery maju povoleny resolving len pre lokalnych klientov a nastastie utok bol vedeny len z jednej taiwanskej IP. Takisto redirectujeme DNS requesty na vonkajsie DNS servery na nase DNS resolvery, takze to schytali tie nase, ale stacilo par minut bafcania s tcpdumpom a vinnici boli najdeni. Takto nam aspon preverilo ze pravidla mame spravne.

jak jsem psal zdrojem dotazu jsou nasi zakaznici uvnitr nasi site (prokazano tcpdumpem provozu na linuxu mezi zakaznikem a DNS i na mikrotiku u zakaznika, navic nase border routery nepusti k nam do site packet s nasi IP jako src). A nezaznamenal jsem, ze by se zakaznikovo PC pokouselo o odesilani packetu se zfalsovanou SRC IP (ale mozna to zakaznikuv vlastni NAT zahodi/zamaskuje sam).

Nejaky hint jaka aplikace/vir ci co to tak asi muze zpusobovat by nebyl? Abych mel neco konkretnejsiho pro zakaznika. Zatim se mi nepodarilo nic uskojiveho vypatrat

Dik

[Majklik]

A na co ty dotazy jsou? Chyť na co se ptají, co je tam za sekvenci dotazů a jaká jde na to odpověď ke klientovi? Vyvolává tento zvýšený tok dotazů k tomě i zvýšený tok od tebe dál?
Jiná varianta (vedle úmyslného pokusu o útok) je, že může jít o DNS tunelování provozu. Dneska se to používá pro obcházení sítě, kde je moc restriktivní, tak se normálně IP provoz tuneluje a vhodně balí do DNS dotazů. Režie brutální, ale nikdo to skoro nehlídá. Nebo se to používá i pro obejití placených hotspotů. Ovládají se tak i boti na dálku, kdy místo dříve populárního IRC dělají boti dotazy na specifické domény a v podzáznamech mají, co mají dělat atd.
Jiná možnost je, že může jít o zblbnutý pokus o DNSSEC resolving když vy ho nepodporujete a klient na něm zuřivě trvá a používá natvrdo forward k vám.

[Dalibor Toman]

A na co ty dotazy jsou? Chyť na co se ptají, co je tam za sekvenci dotazů a jaká jde na to odpověď ke klientovi?

u zjsem to psal = dotaz ANY na '.' (root zona). Tazatel inzeruje pomoci EDNS0, ze akceptuje 4KB packety, takze mu resolver posle skoro 2KB dat s odpovedi (nabobtna protoze obsahuje RSIG zaznamy)

Vyvolává tento zvýšený tok dotazů k tomě i zvýšený tok od tebe dál?

na nasi strane do Internetu zadne problem nevznikne - resolver cacheuje. A i kdyby ne tech par set packetu nevic nic neznamena

Jiná varianta (vedle úmyslného pokusu o útok) je, že může jít o DNS tunelování provozu. Dneska se to používá pro obcházení sítě, kde je moc restriktivní, tak se normálně IP provoz tuneluje a vhodně balí do DNS dotazů. Režie brutální, ale nikdo to skoro nehlídá. Nebo se to používá i pro obejití placených hotspotů. Ovládají se tak i boti na dálku, kdy místo dříve populárního IRC dělají boti dotazy na specifické domény a v podzáznamech mají, co mají dělat atd.

to jsem samozrejme proveroval. Dotazy jsou neustale stejna data a odpovedi take - protoze se pta furt na stejne veci. DNS tunneling vypada jinak - minimalne by se muselo menit jmeno v dotazu.

Jiná možnost je, že může jít o zblbnutý pokus o DNSSEC resolving když vy ho nepodporujete a klient na něm zuřivě trvá a používá natvrdo forward k vám.

mozne je vsechno, nase oba zakaznicke resolvery ale DNSSEC podporuji. Navic mi nedochazi proc by se bezny klientsky resolver mel vubec ptat na root zonu.
Vlastne nevim jak DNSSEC funguje na strane klienta. Predpokladam, ze klient musi verit tomu, ze DNS resolver 'to dela spravne a duveryhodne', protoze jinak by si musel veskery resolving delat sam.