An die Betreiber öffentlicher DNS-Resolver

[Lord Gurke]

Hallo,

weniger eine Frage als eine... Tja... "Mahnung" passt wohl am Besten:
Wer offene DNS-Resolver anbietet sollte wenigstens über Rate-Limiting nachdenken und ggf. auch über ein cleveres Monitoring welches obszön große DNS-Antworten automatisch blackholen kann.
Sonst läuft man über kurz oder lang mit einer Wahrscheinlichkeit von über 90% Gefahr, Teil einer großen DNS-Amplification-Attack zu werden.

Wir betreiben mehrere VPN-Einwahlsysteme über die Kunden öffentliche IP-Netze bekommen können. Einige der Kunden haben (ob gewollt oder nicht kann ich momentan nicht sagen) DNS-Resolver unter den IPs erreichbar gemacht.

In den letzten Tagen haben wir bereits beobachtet, dass die Anfragen dagegen schon tendenziell steigend waren und haben auch bereits Kunden deshalb angeschrieben, sogar z.T. bei der ersten großen Welle per DPI-Firewall Anfragen auf bestimmte, extra für DNS-Amplification registrierte Domains gefiltert.
Im Anhang sieht man den heutigen traurigen Höhepunkt. Während der Feiertage ist üblicherweise deutlich weniger Traffic auf den Systemen, heute sind aber Rekorde in Sachen Paketrate gefahren worden!
Die Einbrüche sind dadurch zu erklären, dass wir zwischenzeitlich immer wieder Quell-IPs oder die Kombination aus Ziel- IP und Port gefiltert haben.
Dennoch sieht man, was man sich damit antut und warum es keine clevere Idee ist, einen offenen DNS-Resolver für die ganze Welt zu betreiben.

Häufig sind das übrigens DNS-Dienste auf den Routern (Linksys allen voran), die unwissentlich offen stehen und die Anfragen garnicht selbst auflösen sondern nur an die im Router eingetragenen Resolver weiterleiten.
Das hat den Effekt, dass z.T. die Bandbreite fast verdoppelt wird und unsere (nur aus unserem Netz erreichbaren) Resolver natürlich auch ungewöhnlich stark penetriert werden.

Not so handy, Andy....

 

[virtual2]

Davon kann ich nur ein Lied singen, hab oft genug mit Incoming DNS Amplification DDoS Arbeit. Leider sind das gut und gerne 5-25Gbit.

 

[Lord Gurke]

Noja, DIE Bandbreite werden die Tunnelrouter wohl eher nicht schaffen - alleine deshalb weil letztlich der Kunde i.d.R. nicht mehr als 10-20 MBit/s Bandbreite für den Upload hat
Aber das ist halt auch einer der Gründe, warum wir versuchen so etwas halbwegs zeitnah zu filtern, auch wenn es nicht die Masse ist.

 

[virtual2]

Die Masse machts, leider hilft dagegen nur mehrfach 10Gbit Uplink und richtig viel Tuning.

 

[Deleted member 11691]

Für unsere Kundenmodems wurde seit Anfang an den Tunnel-Endpunkten DPI mit Filtering verwendet, das auf Incoming für's Service DNS greift. Kunden, die das nicht möchten, wurden auf einen anderen Endpunkt geworfen, der überhaupt nicht gegen gängige DoS-Angriffe abgesichert ist, was natürlich allein deren Entscheidung ist. Oder ihr macht es so, wie die upc cablecom:

Wichtige Mitteilung: Viren, Würmer oder Trojaner über Ihren Internet-Anschluss versendet

Sehr geehrter Herr xxx

upc cablecom ist von unabhängigen Instanzen aufmerksam gemacht worden, dass über Ihren Internet-Anschluss Viren, Würmer oder Trojaner, so genannte Malware, versendet werden. Anhand der unten aufgeführten Angaben haben wir festgestellt, dass die aufgezeichnete IP-Adresse zum angegebenen Datum Ihrem Internet-Anschluss zugeordnet gewesen ist.

IP-Adresse: 178.*.*.*
Vorfall-Datum: *.12.2013 *:*:*
Adresse des Modems (MAC): **:**:**:**:**:**

Wir gehen davon aus, dass Ihr Computer von einem Virus oder Trojaner infiziert ist oder durch Dritte missbraucht wird. Wir ersuchen Sie deshalb dringend, Ihren Computer vor solchen Missbräuchen besser zu schützen. Auf upc-cablecom.ch/sicherheit finden Sie zahlreiche Anleitungen.

Ein slcher Vorfall ist unter Artikel 4 und 12 unserer Allgemeinen Geschäftsbedingungen (AGB) geregelt, die Sie bei Vertragsabschluss akzeptiert haben. Unter upc-cablecom.ch/agb finden Sie die AGB.

Wir bitten Sie, uns innerhalb der nächsten 48 Stunden unter upc-cablecom.ch/abusedesk mit Bezug auf die Abuse-Referenz #*-*****# mitzuteilen, welche Schutzmassnahmen Sie ergriffen haben. Gerne unterstützen wir Sie, um Ihren Computer besser vor Angriffen zu schützen.

Bei Fragen sind wir gerne für Sie da: unter der Nummer 0800 66 88 66 oder rund um die Uhr auf upc-cablecom.ch/support.

Freundliche Grüsse


Abusedesk, upc cablecom

Ihr fragt euch was das mit offenen Resolvern zu tun hat? Nunja, man hat dort nachgefragt was denn genau sei und Logs verlangt und anhand dieser konnte dann sichergestellt werden, dass da ein offener Resolver lief.

 

[iLLogical]

Wenigstens reagiert da mal ein ISP

 

[rauppe31]

Ja, stimmt.

Der Brief den Fusl da abgeschrieben hat hab ich bekommen
Aber von schnell reagiert kann man da nix sagen. Bei meinem neuen MikroTik war der DNS-Server per Default so eingestellt, dass er DNS-Anfragen von aussen beantwortet.

Den neuen Router hatte ich aber schon etwa 4 Monate in Betrieb und gestern hab ich diesen Brief (als Weihnachtsgeschenk ) erhalten.

 

[vb-server]

Ihr fragt euch was das mit offenen Resolvern zu tun hat? Nunja, man hat dort nachgefragt was denn genau sei und Logs verlangt und anhand dieser konnte dann sichergestellt werden, dass da ein offener Resolver lief.

Nicht ganz ;-) Aufgrund der Tatsache dass nur beim WAN ausgehender Traffic war und sonst bei keinem Interface, vermutete ich einen OpenResolver, was dann auch so war ;-)

 

[Lord Gurke]

Weil mir gerade akut ein Ei gepl.... ein Punkt überschritten wurde, veröffentliche ich hier ein paar iptables-Regeln, die all jenen helfen können, die entweder diese Anfragen an eigene DNS-Server selbst filtern oder auf einem VPN-Server etc... filtern möchten.
Beim VPN-Server muss "INPUT" durch "FORWARD" getauscht werden
Ebenso müssen diese Einträge - wenn IPv6 genutzt wird - auch nochmal mit ip6tables eingetragen werden, das habe ich mir hier aus Gründen der Übersichtlichkeit gespart.

iptables -I INPUT 1 -p udp --dport 53 --match string --algo kmp --hex-string "|04|ghmn|02|ru" -j DROP
iptables -I INPUT 1 -p udp --dport 53 --match string --algo kmp --hex-string "|06|krasti|02|us" -j DROP
iptables -I INPUT 1 -p udp --dport 53 --match string --algo kmp --hex-string "|08|fkfkfkfa|03|com" -j DROP
iptables -I INPUT 1 -p udp --dport 53 --match string --algo kmp --hex-string "|03|amp|0A|crack-zone|02|ru" -j DROP
iptables -I INPUT 1 -p udp --dport 53 --match string --algo kmp --hex-string "|04|pkts|04|asia" -j DROP

Damit werden die fünf meistgefragten Hosts gefiltert. Auch wenn iptables hier in den Payload des Pakets hineinschauen muss, geht das mit erstaunlich wenig CPU-Last. Selbst ein Raspberry schafft es, Paketraten um die 1000 Pakete/s mit gerade einmal 3-4% CPU-Zeit zu filtern.

Nachtrag: Es wird auch erstaunlich häufig auf isc.org angefragt, die habe ich aber in die Filterliste nicht mit aufgenommen.
Treppenwitz: Das ISC erklärt auf ihrer Seite was DNS Amplification Attacks sind, wie man sich davor schützt und haben selbst eine DNS-Top-Zone die fast 4K groß ist....

 

[Deleted member 11691]

Selbst ein Raspberry schafft es, Paketraten um die 1000 Pakete/s mit gerade einmal 3-4% CPU-Zeit zu filtern.

1000 Pakete pro Sekunde sind recht wenig, findest du nicht auch? Zumindest kommt mir das Verhältnismäßig als DNS-Provider sehr sehr wenig vor, wenn ich so auf die Query-Stats der letzten 30 Sekunden schaue.
Da wir sowieso PDNS-Recursor und PDNS-Authserv einsetzen, ist das ziemlich simpel, ein Lua-Script für bzw. gegen solche Attacken zu schreiben. Außerdem bietet PDNS-Recursor die Möglichkeit, TCP-before-UDP zu akivieren, was Google von deren Nameservern aus unerklärichen Gründen wieder entfernt hatte. Inzwischen liefern die nämlich ANY-Queries ohne weiteres einfach aus, was wiederrum die Möglichkeit bei der Gesamtbandbreite zu sehr viel DRDoS-Angriffen führen dürfte. Also: Google -> Kein gutes Vorbild... Bzw. nicht immer

 

[Lord Gurke]

Ich hatte das mit einem Raspberry (als Router konfiguriert) getestet, nur um zu sehen wie viel zusätzliche Last das auf die CPU bringt - interessanterweise ist es scheinbar effektiver die Pakete per iptables zu verwerfen als sie dem PDNS zu geben....

Wir hatten in der Spitze (allerdings auf internen DNS-Servern, die die weitergeleiteten Anfragen von Kunden bekommen haben) irgendwas um die 15k Pakete - auch nicht soooo dramatisch viel, aber dem PDNS hat es gereicht um damit 15-20% CPU-Zeit zu essen. Scheinbar hat der ein furchtbar ineffektives internes EDNS-Handling für übergroße UDP-Antworten.

 

[Deleted member 11740]

Kein Wunder. Ohne PDNS jetzt zu kennen, wird schon allein durch die Abstraktion der Backenends sicherlich viel Zeit verbraten. Im Gegensatz dazu sucht das Kernelmodul für ipt einfach nur nach einem HEX-String in den Paketen auf Port 53. Das das viel effizienter ist liegt doch auf der Hand. Dafür ist es nicht so flexiebel wie PDNS.