der nameserver eines kunden war versehentlich noch offen fuer anfragen aus aller welt und wurde fuer ddos attacken missbraucht. er kriegt eine kleine anfrage rein und schickt eine grosse antwort an die gefaelschte absende ip raus. dieses “verfahren” ist auch als “dns amplification” bekannt.
um eine gute amplification attacke zu machen, braucht es zwei dinge. das protokoll sollte keinen handshake benoetigen, damit man die absendeadresse faelschen kann. also entweder icmp oder udp um die (gefaelschte abfrage nach dem motto “fire and forget” los zu jagen. und dann sollte natuerlich die antwort um ein vielfaches groesser sein als die abfrage selber.
in dem mir vorliegenden falle wurde z.b. eine abfrage vom typ “ANY” auf die domain “deniedstresser.com” gemacht. so schaut das ganze dann aus: (das x.x.x.x repraesentiert den “offenen resolver”)
dig ANY deniedstresser.com @x.x.x.x
die antwort habe ich als verkleinertes bild (klick zum vergroessern) eingefuegt und auch noch etwas gekuerzt, weils einfach noch viel mehr ist. aufgrund der etwas ausgefallenen antwort vermute ich mal, dass diese domain genau fuer diesen einen zweck uebrhaupt existiert.
solche anfragen kamenzwischen 10 und 50 stueck pro sekunde von unterschiedlichen ipadressen (die gefaelschten natuerlich), wobei ungefaehr immer 10 die gleiche absende ip hatten. die menge ist nichts, womit ein einzelner dns server mit bind nicht fertig wuerde. aber da es wahrscheinlich noch hunderttausende offene dns resolver gibt, koennen die angreifer damit wunderbare attacken fahren.
aber wie wird man diese dinger nach dem beseitigen des problems wieder los? selbst wenn man den dns server so konfiguriert, dass er diese rekursiven anfragen nicht mehr aufloest, sendet er immerhin noch ein “REFUSED” mit ein bischen overhaed drumherum zurueck. das ist dann immernoch eine ddos attacke, aber wenigstens ohne nennenswerte “amplification”.
ein einfaches blocken per iptables ist auch nicht das wahre, denn:
die gefaelschten ips des absenders sind halt einfach gefaelscht. man blockt also jemanden, der eigentlich garnichts dafuer kann, sondern das opfer ist. den traffic auf der leitung mindert das etwas, da die antworten nicht mehr raus geschickt werden. beobachtungen haben aber gezeigt, dass sofort neue ipadressen als absender erschienen, sobald man welche geblockt hat.
beim suchen bin ich auf eine loesung gestossen, die in meinem falle erst einmal ausreichend ist. dabei wird mit iptables in das paket “reingeschaut”.
die erste regel schaut in die udp pakete an port 53, ob darin eine dns any anfrage steckt und setzt fuer die ip einen tag “dnsanyquery”:
iptables -I INPUT 1 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --name dnsanyquery --set
die zweite regel prueft, ob die erste regel noch weitere vier mal in der letzten minute angewandt wurde. wenn ja, dann wird die anfrage weggeworfen:
iptables -I INPUT 2 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --name dnsanyquery --rcheck --seconds 60 --hitcount 5 -j DROP
mit diesen regel funktionieren “normale” dns any abfragen weiterhin und alle anderen abfragen bleiben davon sowieso unberuehrt. da die absender ips ohnehin gefaelscht sind, wird auch niemand “unnoetig” ausgesperrt.
leider bekommen die “angreifer” nicht mit, dass der dns server kein offener resolver mehr ist und feuern steandig weiter. so habe ich naemlich gerade eben den naechsten mist im logfile gefunden, der sich im sekundentakt vermehrt:
20-May-2013 22:43:08.459 client 69.140.111.56#27203: view external: query: . IN RRSIG +E
na toll.. da wird als “amplification packet” der “signature resource record” der root zone abgefragt. *seufz* …darum kuemmere ich mich aber heute nicht mehr.
und was hat das ganze nun mit pfingsten zu tun? nix.. war halt nur heute passiert und so musste ich mich wenigestens nicht ueber das wetter aufregen, weil ich einen guten teil des tages vor der kiste gesessen habe 😉
