Tak sobie obserwuję logi serwera DNS

2009-01-17 00:00:00

W logach serwera DNS zaobserwowałem tysiące dziwnych wpisów:

17-Jan-2009 14:37:42.010 client 69.50.142.11#2141: view external: query (cache) './NS/IN' approved

Moje logi wskazały jeszcze takie IP generujące te wpisy:

209.123.8.64 35138.ds.nac.net.
209.123.8.99 35173.ds.nac.net.
216.201.82.19 ns1.nationalnet.com.
216.201.83.2 ns2.nationalnet.com.
216.240.131.173
63.217.28.226 63-217-28-226.btnaccess.net.
69.31.52.214
69.50.137.175 69-50-137-175.nationalnet.com.
69.50.142.11 nat1520.nationalnet.com.
74.86.34.144 softlayer.com.
91.199.112.18
66.230.128.15 ns.isprime.com.

Abuse nationalnetu odpisało mi, że to jest atak DDOS na ich IP polegający na spoofowaniu adresu nadawcy w pakiecie udp zawierającym zapytanie do serwera DNS. Serwer DNS odpowiada i geneneruje ruch przyczyniając się do DDOSu takiego IP.

Obecnie pakiety udp z takimi IP:
66.230.160.1 ns2.isprime.com.
63.217.28.226 63-217-28-226.static.pccwglobal.net.
206.71.158.30
dobijają mi się do serwera.

To jest DNS amplification attack. Atakujący wysyła pakiety udp ze sfałszowanym IP nadawcy do serwera DNS o wielkości 45 bajtów a serwer generuje odpowiedź wielkości 500 bajtów.

Targetowane są strony porno i prowajderzy je hostujący. Nie wiem czy chodzi o walkę konkurencji czy o zbawianie świata.

Zabezpieczenie na poziomie iptables wygląda tak:

iptables -A INPUT -i eth1 -p udp --dport 53 -m length --length 45:45 -j DROP
iptables -A INPUT -s 1.2.3.4 -p udp --dport 53 -j DROP

blokowane są pakiety udp o długości 45 bajtów pochodzące z interfejsu zewnętrznego eth0.
ALBO
po prostu można DROPować cały ruch z takim adresem IP

Zabezpieczenie na poziomie serwera DNS (bind) wygląda następująco:
1) aktualizacja do 9.4.2 lub wyżej (w 9.4.0 na pewno nie zadziała)
2) podział na view "internal" i "external"
3) zabronienie allow-query wszystkim i dopuszczenie w konkretnej strefie:

view "external" {
        match-clients { any; };
        recursion no;
        allow-query { none; }; // to jest ważne

        zone "lemat.priv.pl" {
        type master;
        notify yes;
        file "/etc/bind/extern.lemat.priv.pl";
        allow-query { any; }; // i to jest ważne
        };
};

bind zapytany o . NS (o serwery root) nie odpowie ich listą (500 bajtów) ale informacją "denied" (45 bajtów) i atak będzie bezcelowy - bo atakujący będzie wysyłał dokładnie tyle bajtów co serwer będzie odpowiadał.

po tej operacji logi serwera będą wyglądały tak:

22-Jan-2009 13:22:33.157 client 65.173.218.96#58833: view external: query (cache) './NS/IN' denied

niestety nie doszukałem się informacji czy da się binda spatchować tak, aby nie generował w ogóle informacji zwrotnej na bzdurne zapytania.

Z ciekawostek - obecnie obserwuję wzmożony ruch wszelkich testerów DNS:

21-Jan-2009 23:15:21.419 client 192.172.226.155#51215: view external: query (cache) '2b9055701b9699bf.c2623a2bb0201a80.test1.openresolvers.org/A/IN' denied
22-Jan-2009 00:36:28.909 client 38.229.0.10#54362: view external: query (cache) 'recursion-test.cymru.com/A/IN' denied
23-Jan-2009 06:01:04.168 client 149.20.58.131#55900: view external: query (cache) 'localhost/A/IN' denied
24-Jan-2009 12:07:52.391 client 149.20.58.131#59004: view external: query (cache) 'www.google.com/A/IN' denied