Dotaz: DDoS útok na jmenný server

[jura5]

Zdravím. Už zhruba třetí den čelím problémům s name server které vypadají jako DDoS útok. Jsem bombardovám dotazy které vypadají takto:

01-Aug-2013 10:42:17.656 queries: client 198.24.166.2#44324: query: LINEAGE2-GAME.RU IN ANY +E

01-Aug-2013 10:42:17.692 queries: client 198.24.166.2#34040: query: LINEAGE2-GAME.RU IN ANY +E

01-Aug-2013 10:42:17.722 queries: client 198.24.166.2#52086: query: LINEAGE2-GAME.RU IN ANY +E

evntuelně takto:

31-Jul-2013 18:12:25.604 queries: client 192.111.139.131#50267: query: . IN ANY +E

31-Jul-2013 18:12:25.692 queries: client 185.16.84.91#46920: query: . IN ANY +E

31-Jul-2013 18:12:25.693 queries: client 185.16.84.91#46920: query: . IN ANY +E

31-Jul-2013 18:12:25.693 queries: client 185.16.84.91#46920: query: . IN ANY +E

31-Jul-2013 18:12:25.694 queries: client 185.16.84.91#46920: query: . IN ANY +E

Jsou to desítky dotazů během vteřiny, které zatěžují server i linku. Name server je BIND9.3.4. Útočící adresy přibývají rychleji než je stačím zamykat. Máte nějaký námět jak se bránit.

---

---

Odpovědi

[ewew]

V prvom rade je nutné nastaviť v iptables, že ak nejaká IP adresa prekročí počet spojení za sekundu začne danú IP adresu zahadzovať alebo odmietne s RST príznakom. Táto možnosť je automatická ale neviem aký to bude mať efekt na výkon servera. Ďalšia možnosť je zmeniť parametre IP stacku aby držal kratší čas otvorené spojenia a aby mal menej pokusov o nadviazanie spojenia. Ak to nebude stačiť, je možnosť použiť blackhole v routovacej tabuľke, možno to vie aj iptables.

Iná možnosť je žiadosť o zablokovanie u nadradeného ISP alebo AS.

[jura5]

Když nebude zbytí budu se muset do toho pustit. Nešla ale na to předtím použít Cisco ASA5505?

[alkoholik]

OMG! DNS->UDP.
Nejdriv by nam mel prozradit, proc vlastne provozuje verejny DNS server.

[jura5]

Protože si sami spravujeme své domény. Asi by bylo jednodušší tu zodpovědnost přehodit na ISP nebo registrátora.

[Jezus]

Máš povolené rekurzivní dotazy? Pokud ano, tak je vypni. Na autoritativním NS nemají co dělat. Pouze autoritativní server (bez rekurze) by se měl při desítkách dotazů za vteřinu šťourat v nose i na nejslabším VPSku.

Jinak cílem útoku nejspíš nebudeš ty jako takový, ale nějaký jiný chudák - ten co si myslíš, že se tě dotazuje. Omrkni DNS Amplification.

[jura5]

Tak jsem se v tom ztratil. NS je v DMZ, běží na něm i proxy server squid a forwarding pošty do vntřní sítě. Když vypnu rekurzi tak se obojí zastaví. Není třeba zapnout nějaké výjimky?

[alkoholik]

Pro bind:

acl "known_networks" {
        # localhost
        127.0.0.1;
        ::1;
        # zname site
        a.b.c.d;
...
}

options {
...
        allow-query-cache {
                known_networks;
        };

        allow-recursion {
                known_networks;
        };

        allow-query { any; };
}

[ewew]

Nastala chyba.

[pavelk]

TTy si myslis ze operator ti bude nekoho jentak zablokovavat,jsi asi nezkusny

[Ed]

Ahoj,

DDoS pomoci DNS amplification jsou popularni uz pres pul roku. Co s tim muzes udelat, pokud provozujes autoritativni server? Pouzij nejakou formu rate limitingu.

• Nejcistsi je asi pouzit Response Rate Limiting patch do Bindu, resp. jeho obdobu v dalsich autoritativnich serverech. To ma tu vyhodu, ze posilas zkracene odpovedi, takze tvuj NS bude i nadale dostupny i tem nestastnikum, na ktere se utoci.
• Trochu vic problematicke je limitovani dotazu bud trivialnim pravidlem v iptables, nebo nejakym jinym resenim zalozenym na *Query* Rate Limitingu. Jsou tam vetsi potencialni rizika, ale zase to muze byt jednodussi na nasazeni.

Ed

[AraxoN]

Ako už bolo napísané, skutočná obeť nie si ty, ale tá IP adresa, ktorá je v logu (podvrhnutá). Pre túto IP adresu si ty jeden z útočníkov, keďže mu posielaš odpovede, ktoré si on nepýtal. Obmedzenie rekurzívnych dotazov je dobrý začiatok, ale problém nerieši, pretože aj negatívna odpoveď poslúži na zosilnenie útoku.

Mne sa osvedčil iptables modul hashlimit. Keďže nadviazať TCP spojenie so sfalšovanou adresou nie je nič jednoduché, riešiť v skutočnosti potrebuješ len UDP protokol.