Tag: dns

ich benutze unbound als resolver fuer meine mailserver. nach dem upgrade von stretch auf buster wurde nichts mehr ins logfile unbound.log unter /var/log/unbound/ geschrieben.

die berechtigungen passen alle, owner und group sind “unbound” und schreiben duerfen beide auch.

wie sich rausgestellt hat, ist apparmor hier das problem. um das schreiben in die logfiles wieder zu erlauben, muss eine zeile in die datei /etc/apparmor.d/local/usr.sbin.unbound eingefuegt werden:

echo "/var/log/unbound/unbound.log rw," >> /etc/apparmor.d/local/usr.sbin.unbound

danach die config datei neu laden

apparmor_parser -r /etc/apparmor.d/usr.sbin.unbound

und unbound neu starten.

service unbound restart

that’s it.

mannmannmann… ich gestehe, dass ich ein paar minuten gebraucht habe, bis ich wusste, was die damit meinen…

unter DNS verstehe ich das “Domain Name System”. und ich hab gegruebelt.. gibts ne neue technick, die ich noch nicht kenne? hat das was mit dnssec zu tun? oder mit anycast dns gedoense? und was zum geier meinen die mit epedemie? die naechste grosse DDOS attacke auf DNS server? bis mir dann gekommen ist, dass ich das eher verstanden haette, wenn die “DNA” geschrieben haetten 😉

die antwort auf meine anfrage bzgl dnssec bei der zustaendigen registry fuer .vc domains kam fix:

meine urspruengliche frage nach dem WANN blieb natuerlich unbeantwortet. und dann frei nach dem motto: belaestige uns doch nicht mit deiner “endkunden anfrage” und wende dich in zukunft an deinen registrar. naja, soll ich nun dankbar sein, dass ich wenigstens irgendeine antwort bekommen habe?

tja.. ich wuerde ja gerne noch dnssec aktivieren fuer meine domain hier… aber leider scheint das die registry oder wer auch immer noch nicht zu unterstuetzen. “vc” ist ja nur ne kleine karibikinsel… wenns dann mal so weit ist, gibts dann auch nen dane eintrage usw. fuer diese webseite 😉

update:

die vorbereitungen sind wohl schon getroffen…

ich war einfach mal so frei und hab den dafuer zustaendigen registrar angeschrieben, wann das denn endlich “fixed” ist 😉

neulich im logfile eines bind dns servers gefunden:

25-Sep-2013 09:40:45.611 zone domain.tld/IN/trusted: zone transfer deferred due to quota

keine panik! die anzahl gleichzeitiger zonen transfers ist beschraenkt. (ich bin noch auf der suche nach der einstellung und dem default wert.) der bind holt das aber ziemlich bald nach.

auf debian systemen kommts beim upgrade auf neuere bind versionen (bzw. des ganzen systems) dazu, dass starten des bind diese warnung ausgespuck wird:

WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)

abhilfe schafft es, die datei /etc/bind/rndc.conf zu loeschen. vorher pruefen, ob in der /etc/bind/rndc.key der passende key drin steht. dann noch in der datei /etc/bind/named.conf pruefen, ob diese zeile vorhanden ist und ggf. einfuegen:

include "/etc/bind/rndc.key";

passend zu meiner plage mit dns amplification (1,2) bzw dns allgemein findet sich aktuell bei heise material:

Bericht: DDoS-Service als legitimes Geschäft mit Segen des FBI
DNS-Attacken: Denic schließt das Kappen von DNS-Antwortraten nicht aus
A Common Operational Problem in DNS Servers – Failure To Respond.
RIPE: Angriffe auf das Domain Name System nehmen zu

den kram von gestern wollte ich noch ein wenig verfeinern. im logfile des bind konnte ich auf einen blick erkennen, dass diese beiden die groesste menge der (mittlerweile “sinnlosen”) abfragen darstellt:

[...] query: deniedstresser.com IN ANY +E
[...] query: . IN RRSIG +E

um nur genau diese per iptables raus zu filtern, muss man erstmal im netzwerkverkehr mithorchen, um sich dann die genauen strings rauszusuchen. das macht man am einfachsten mit dem tool tcpdump, welches anders als der name vermuten laesst auch udp und icmp mitschneiden kann 😉

tcpdump -i eth0 -s 0 -w /tmp/tcpdump.dump udp port 53

die damit erzeugte datei schaut man sich am besten mit wireshark an und sucht sich die entsprechenden teile der pakete raus:

die relevanten (im screenshot markierten) teile, nach denen ich filtern wollte, sind dann in hexadezimaler schreibweise diese:

# hex fuer "deniedstresser.com: type ANY, class IN"
0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00
# hex fuer ": type RRSIG, class IN"
00 00 2E 00 01 00 00 29

die abfrage des typs ANY kann ich bedenkenlos komplett rausfiltern, da ich den abgefragten namen (deniedstresser.com) mit reingenommen habe. niemals hat dieser dns server genau diese abfrage zu beantworten.

iptables -I INPUT 1 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 30 --algo bm --hex-string '|0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00|' -j DROP

die abfrage nach der “recource record signature” der root zone darf ich nicht komplett rausfilter, da dem dns server vertrauete ipadressen sehr wohl genau diese abfrage machen koennen und duerfen. dafuer ist diese loesung mit iptables eigentlich eher ungeeignet. aber da ich weiss, dass die server mit den “vertrauten” ipadressen noch nichts mit DNSSEC am hut haben, nutze ich die regel erstens nur temporaer und zweitens sicherheitshalber nur wenn “geflutet” wird – sprich mehr als vier abfragen pro minuten von einer ipadresse kommt.

erst wieder die ip “taggen”:

iptables -I INPUT 2 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --set

und die anfrage wegschmeissen, wenn der counter in 60 sekunden die vier erreicht hat, :

iptables -I INPUT 3 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --rcheck --seconds 60 --hitcount 4 -j DROP

klar muessen die “angreifer” nur eine kleinigkeit an einer der abfragen aendern, um diese regeln zu umgehen. aber so schickt der dns server wenigstens nicht mal das “REFUSED” an den gefaelschten absender zurueck. ich hoffe ja, dass dieser “angriff” irgendwann vorueber ist, da der bind sowieso kein offener resolver mehr ist und somit fuer die angreifer uninteressant wird.

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 😉