Přes 170 DNS serverů v ČR bylo zneužito při DDOS útoku (diskuse)

[Honza Jaroš]

Nebyly to jen otevřené rekurzivní DNS. Provozuju si tři nameservery pro své domény a na primární, který mám v datacentru u Masterů, šel ten útok taky. Dotazy pouze na moje domény, podle Zabbixe to začalo někdy po půlnoci z pátku na sobotu, příchozí traffic kolem 200kB/s, odchozí 5-6 MB/s. Bohužel tohle nikde nesleduju a server to nijak extra nezatěžovalo, takže mě na to upozornil až dnes ráno ISP. Pak jsem teprve nasadil automatické blacklisty pro adresy, které se dotazovaly víc než bylo obvyklé.

Během dne jsem pak zahazoval kolem 60MB paketů za hodinu, šlo o několik stovek adres...

[Honza Jaroš]

V podstatě byl u mně hlavní problém s DNSSEC, na dotazy typu "any" pro danou doménu odesílal nameserver SOA, MX a A záznam plus DNSSEC informace. A právě DNSSEC klíče ty odpovědi dost nafoukly.

[vladki]

U nas si taky vybrali podepsanou domenu. Zmetci... Hashlimitem sem to omezil na 1 dotaz za sekundu, a provoz vyrazne klesl.

[Honza Jaroš]

No u mě je pikantní, že konkrétně u té nejvíc dotazované domény je DNSSEC podpis zatím k ničemu; Subreg mi už před delší dobou sliboval, že vedle CZ domén umožní nastavit DNSSEC podpisy i pro generické domény, takže jsem si připravil podepisovací infrastrukturu i pro ně - a od té doby je ticho po pěšině.

Zkusím je zase trochu pošťouchnout.

[Foo Bar]

Dá se tomu odlehčit ještě i jinak. Máme v Knot DNS teď rozpracovanou volbu, že odpověď na IN ANY přes UDP se vždy vrátí jen sekce QUERY s nastaveným TC (truncate) bitem. (Resp. případně půjde zakázat IN ANY úplně.) Tenhle mód u legitimním klientů nezpůsobí nic špatného, protože se zeptají v souladu s protokolem po TCP, ale u podvržených paketů to zruší tu amplifikaci paketů.

[Honza Jaroš]

Díky za informaci, to by mohl být důvod k přechodu na Knot

Nicméně zatím to filtrování přes netfilter - zdá se - funguje, takže si počkám, až Knot probublá do oficiálních stabilních repozitářů v Debianu. Bude to pohodlnější.

Spíš mě štve, že ten útok pořád trvá a připadá mi, že množství příchozích paketů dokonce vzrůstá. Za poslední půl hodiny jsem zahodil už 125MB...

[Jendа]

Pak jsem teprve nasadil automatické blacklisty pro adresy, které se dotazovaly víc než bylo obvyklé.

Hele, jak se tohle dělá, když má UDP dotaz v Src: nesmyslnou adresu? (samozřejmě musí přijít ze sítě, která UDP na hraničním routeru nefiltruje podle src, nevím, kolik takových sítí je)

[Ondrej 'SanTiago' Zajicek]

Src adresa nebude nesmyslna, v src adrese bude cil utoku (odpoved DNS serveru bude smerovat na tuto adresu).

[Honza Jaroš]

No já to nakonec řešil nějak takhle:

iptables -t mangle -A PREROUTING -i ${ifx} -p udp --dport 53 -j CONNLIMIT_DNS
iptables -t mangle -A CONNLIMIT_DNS -s ${secns1} -j RETURN
iptables -t mangle -A CONNLIMIT_DNS -s ${secns2} -j RETURN
iptables -t mangle -A CONNLIMIT_DNS -m hashlimit \
                      --hashlimit-above ${pocet}/second \
                      --hashlimit-mode srcip \
                      --hashlimit-htable-expire 60000 \
                      --hashlimit-name dns_ddos -j BLACKLIST_DNS
iptables -t mangle -A BLACKLIST_DNS -m recent --name dns_ddos --set
iptables -t mangle -A BLACKLIST_DNS -j DROP
iptables -t mangle -A CONNLIMIT_DNS -m recent --name dns_ddos \
                      --rcheck --seconds 60 -j DROP

Čili pokud přišlo z jedné adresy na port 53 víc než limitní počet paketů za sekundu, hodil si ho server na blacklist a nechal ho tam, dokud daná adresa alespoň na minutu počet příchozích paketů neomezila.

V jiné konfiguraci by se to asi spíš hodilo dát do klasického FORWARDu místo do mangle sekce...

[Honza Jaroš]

A je to tu zase...

~ # tcpdump -i eth0 -n port 53
...
09:11:29.799154 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799163 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799170 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799175 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799180 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799185 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799191 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799196 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799201 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799226 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799236 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799312 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799318 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799320 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799323 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799325 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799348 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799351 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799354 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799356 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799358 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799393 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799396 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.799399 IP 121.54.13.24.2671 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848098 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848125 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848133 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848140 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848146 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848151 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848156 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848161 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848166 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848172 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848182 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848188 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848193 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848198 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848203 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848223 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848227 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848229 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848232 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848234 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848266 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848270 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848272 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848275 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
09:11:29.848277 IP 121.54.13.24.19537 > 89.185.253.71.53: 18588+ [1au] ANY? jerryweb.info. (42)
...

[xkucf03]

příchozí traffic kolem 200kB/s, odchozí 5-6 MB/s

Jestliže se dá pomocí jednoho primárního/sekundárního DNS serveru vyrobit z 200 kB/s 5-6 MB/s, znamená to, že na zahlcení něčí gigabitové linky stačí cca 21-25 DNS serverů a 4-5 Mbit/s linka útočníka.

Má cenu v takové situaci řešit nějaké otevřené rekurzivní servery? Obávám se, že ne a tohle strašení a obviňování je bezpředmětné, protože stejně dobře poslouží ty autoritativní servery, které z principu musí existovat.

Užitečný by tedy byl spíš návod, jak nastavit rekurzivní i autoritativní servery tak, aby sloužili legitimním uživatelům a zároveň šly co nejméně použít pro útok.

Plus samozřejmě řešit příčinu – to, že jde posílat pakety s podvrženou zdrojovou adresou.

[Honza Jaroš]

Už jsem posílal dotaz mému ISP, jestli by nešlo vysledovat cestu paketů a upozornit správce příslušného AS, že by si to měl filtrovat. Uvidíme, jestli se s tím budou chtít patlat, znamenalo by to komunikovat s dalšími ISP a dohledávat to.

Každopádně včera měly všechny filtrované pakety TTL na 248, dnes mi to ukazuje hodnotu 250 (alespoň podle informací v /proc/net/xt_recent/). Takže by útočících počítačů skutečně mohlo být celkem málo.

Ale útočí na různé cíle, jen za noc jsem nasbíral kolem stovky adres a nepovedlo se mi zjistit, proč útočí právě na ně.

[Honza Jaroš]

Jinak pod tím blogpostem odkazovaným ve zprávičce se objevil i odkaz na graf provozu autoritativních provozů, od soboty je tam možno vidět zvýšený počet dotazů na záznamy typu ANY. Takže očividně otevřené rekurzivní servery skutečně nebudou primární problém.

[Honza Jaroš]

Mělo tam být "graf provozu autoritativních nameserverů domény .cz", takhle to dopadá, když člověk přepisuje kus textu...

[xkucf03]

Oprava: 4-5 Mbit/s → 4-5 MB/s (což je ale pořád jen trochu lepší domácí připojení a na věci to nic nemění)

[Honza Jaroš]

No mohli vytáhnout i víc, mám to pověšené na 100Mbps lince. Momentálně tedy už mimo NIX jen 10Mbps; poté co jsem díky těmhle kreténům přešvihl 500GB datový limit pro tranzitní připojení mimo NIX (normálně mi na tranzit jdou tak 2GB měsíčně) jsem se s ISP dohodl na změně tarifu, kdy mám mimo NIX jen 10Mbps, ale zase bez omezení dat. Na ty dvě giga měsíčně to stačí, většina provozu je v rámci NIXu.

Hardware to zvládal bez problémů, průměrná hodnota loadu o víkendu vyběhla cca o 0,25. Dell PowerEdge T110 s inteláckým X3440 ...

[lertimir]

Ale obecně takovému zneužití snad nejde moc bránit. Pokud se dotazuji autoritativního DNS na jeho záznam, tak mi musí odpovědět. A když je to paket z podvrženou IP (napadeného systému) tak prostě odejde jeden útočný paket na cílový systém.

[Honza Jaroš]

Přesně tak, viz výše. U mně je to celkem jednoduché, mám tam pár domén, takže útok se od běžného provozu nechá celkem snadno poznat podle četnosti dotazů (bylo to v řádu desítek až stovek za sekundu, tcpdump jel jak motorová myš; v běžném provozu je to několik dotazů za minutu). Ale netuším, co by s tím mohli dělat větší registrátoři...

[lertimir]

ble, ... s podvrženou IP (pardon)

[petr_p]

Však on taky není problém s DNS servery. Jen jich je několik, tak se na ně dobře ukazuje. Problém je v koncových stanicích, které byly použity k rozesílání požadavků. Správce sítí, kteří reagují na stížnosti kvůli napadaným strojům, aby jeden lupou hledal.

[pupu]

...pripadne v ISP, kteri nefiltruji provoz od svych zakazniku a nechaji je posilat podvrzene zdrojove adresy. Otazkou je, jestli je vubec technicky mozne takove filtrovani delat...

[vladki]

Snadno:

net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.rp_filter=1

[j]

Toto je neco uplne jineho.

[Ondrej 'SanTiago' Zajicek]

Kdepak, toto je jedna z moznosti, jak to filtrovani delat, viz dokumentaci:

rp_filter - INTEGER
        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path
            Each incoming packet is tested against the FIB and if the interface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path
...

(Tedy neni treba to zapinat obecne, uplne staci to zapnout jen na rozhranich smerovanych k zakaznikum).

[gtz]

Určitě je

[mozog]

Samozrejme to mozne je, a na CPE to lze jednoduse resit.

[j]

Jenze technicky tohle neni problem koncovych stanic.

Predne to naprosto extremne podporuje prave DNSSEC, kterej razantne zlepsuje efektivitu utoku. Druhak neni problem postavit botnet, kde budou tisice/desetitisice stroju a z pohledu DNS serveru se to pak vubec jako utok jevit nebude - jednoduse bude chodit celkem bezny mnoztvi dotazu. Pripadne muzu vyuzit velke mnozstvi DNS serveru a na kazdy poslat nekolik malo dotazu.

V kazdym pripade vygeneruju velmi slusny traffic na strane cile, aniz by prostrednici (DNSka) registrovaly nejaky problem.

Problem je totiz cestou - nemelo byt mozne poslat DNS dotaz s jinou IP nez tou svoji. Takovy dotaz by mel byt tipnut hned u zdroje.

On totiz spravce site zadny problem nema => nevidi zadny duvod proc by jej mel resit.

[xkucf03]

Problem je totiz cestou - nemelo byt mozne poslat DNS dotaz s jinou IP nez tou svoji. Takovy dotaz by mel byt tipnut hned u zdroje.

+1

[Ondrej 'SanTiago' Zajicek]

Jenze tohle jde delat prakticky pouze v koncovych sitich na hranici se zakazniky. Dal po ceste (mezi ISP) uz to nedava moc smysl, nebot tam muze byt routovani obecne asymetricke. Takze staci v Internetu jediny ISP, ktery to nefiltruje, a uz odtamtud ty pakety s podvrzenym zdrojem dojdou prakticky kamkoliv. No a najit toho zdrojoveho ISP je dost netrivialni, tipoval bych, ze to bude vyzadovat aktivni spolupraci spravcu v sitich vsude po ceste.

Takze asi jedine efektivni reseni je prave reseni na strane DNS serveru (jejich spravci jsou totiz motivovani to resit).

[faha]

Vcelku zajimava diskuze, lze nejak rp_filter aktivovat na zarizenich mikrotik, je to preci jen taky linux? Rad bych to zkusil nasadit u koncovych routeru tesne pred zakazniky (na ethernet a na wlan[AP]), google vsak dost mlci na toto tema, poradi nekdo?

[Heron]

Tam přece můžeš nasadit klasický filter a v chainu forward (a směr od nich ven) povolit pouze jejich subnety. Kdysi tohle bývalo pravidlem dávat i do chainu OUTPUT a vše ostatní zakázat. Z mašiny tak nešlo poslat packet s podvrženou src ip (pokud člověk nebyl root).

[Ondrej 'SanTiago' Zajicek]

A jak muzes z Linuxu poslat odchozi packet s podvrzenou src ip, aniz bys byl root?