DNS Dampening

RESPEKT! Einfach nur Respekt!

Und wenn jetzt noch im allerletzten Satz das falsche "Ein" gegen das richtige "Einen" ausgetauscht werden sollte, gibt es so gut wie Nichts mehr zu meckern ... ;-)

Herzlichen Gruß, wirklich vielen und großen Dank auch schon für Deine bisherigen Arbeiten und diversen Veröffentlichungen und auch weiterhin hoffentlich noch richtig viel Spaß und Erfolg bei Deiner Arbeit und auch sonst so ...! :-)

Deine Überlegungen von "schlimmstenfalls logarithmisch" und "linear" sind zwar sehr löblich, aber dennoch ist der Code recht ineffizient. Der Grund dafür ist die lineare Suche, die noch dazu unter einem Mutex statt findet, sodass alle anderen Threads warten, während du den Speicher durchkämmst.

Für diese Aufgabe sind Hashtabellen typischerweise die bessere Lösung.

Welche Algorithmen sich bewähren, ist noch offen.
Welche Datenstrukturen sich bewähren, ist noch offen.
Die aktuellen Annahmen besagen, daß die Optimierung auf den durchschnittlichen Fall mit der linearen Suche entlang der Häufigsstatistik erfolgt.

Alle Annahmen können nur durch die Praxis, vor allem mit Messen, Messen und Messen geprüft werden.

Aktuell habe ich Probleme mit Kollateralschäden. Es trifft z.B. IPv6 Tunnelbroker, die Kunden mit qmail haben.

Nett. Man kann sowas ähnliches übrigens auch mit einem vorgeschalteten iptables + recent Modul erreichen, so zwischen den entsprechenden bind-Instanzen und dem Internet irgendwo ein Linux läuft. Ist zwar wahrscheinlich performanter, da alles interessante im kernel abläuft, aber dafür nicht so schön bzw. so einfach parametrisierbar nach Requesttyp. Bitte um Aufnahme in die Mainline ersuchen, wenn dann irgendwann die meisten Binds der Welt mit sinnvollen Dampening defaults laufen würden, hättest du auf jeden Fall einen Preis verdient ;)

@Stefan: Aber auch bei Hashmaps ist Vorsicht geboten: Ein Angreifer, der deine Hashfunktion kennt, kann gezielt eine Überlast verursachen, indem er nur Schlüssel sendet, die den selben Hash haben.

Wie schützt Du Dich vor IP-Spoofing? Was passiert, wenn ich ein paar tausend Abfragen mit den IP-Adressen der Resolver der Telekom im Absender schicke?

IP Spoofing ist genau der Grund, weswegen der Zinnober gemacht wird. Meine Antwortpakete stellen ja genau den Angriff dar.

Ich schweig dann also eine Weile (bis die Punkte verfallen) und mache dann erst weiter. Ja, das öffnet einem DoS Tür und Tor. Ja, es kann sein, daß dann der DTAG Resolver meine Domains gar nicht mehr auflösen kann, weil ich seinen legitimen Paketen auch nicht antworte.

Wie sinnvoll ist eine Lösung, die "DoS Tür und Tor öffnet"?
Sie macht es sogar noch viel einfacher, Domains für manche Gruppen, zum Beispiel DTAG-Kunden oder x-beliebige andere aus dem Netz zu schießen. Ich muß Deine Nameserver gar nicht mehr unter Dauerfeuer nehmen, sondern ich kann das bequem und bandbreitenschonend über die Strafpunkte steuern. Also DoS statt dDoS.

Es gibt keine offensichtliche Lösung des Problems. Allerdings hat mir Dein Kommentar geholfen, meine aktuellen Experimente an diesem Problem auszurichten: Wie kann ich wenigstens ansatzweise legitime Anfragen beantworten, während der Angriff selbst versandet.

Abwarten!

Hallo Lutz,

ist vielleicht ein bisschen off-topic, aber hast du dich mal mit Namecoin beschäftigt?

http://de.wikipedia.org/wiki/Namecoin

Was hältst du von so einem Ansatz?

Gruß
jym

Namecoin skaliert nicht, weil es zu viele "zentrale" Stellen hat. Namecoin ist nicht massentauglich, weil es nicht in die aktuelle Protokollversion hineinwächst, wie es DNSSEC derzeit tut.

Das eigentliche Problem des Lösungsansatzes ist, daß er nicht allgemein genutzt werden kann:

Blockiere ich die gespooften IPs (allgemein), so kann ich dafür sorgen, daß ganze Access Netze einen Resolver nicht mehr erreichen. Ein einfaches Beispiel hierfür ist:

Man nehme an, die DNSes von google z.B. würden ein Dampening anwenden wollen. Ich suggeriere eine Amplification attack seitens der recursor mehrerer großer Provider. Der DNS des Anbieters (im Beispiel google) würde also die Recursor der Zugangsprovider 'blacklisten' zumindest solange ich regelmässig (aber nur gelegentlich) einige Anfragen aussende, um die Penalty gezielt oben zu halten. Die Amplification-Attacke ist abgewendet, dafür habe ich sie gegen eine Service-Denial beim Dienstanbieter getauscht. Daher wäre ein Dampening für keinen Diensteanbieter umsetzbar, sofern er gelegentlich erreichbar sein möchte. Das schlimmste aber ist, ich kann spezifische Targets für spezifische Kunden (Clients) gezielt ins Dampening treiben und somit 2 Parteien direkt schaden, wenn ich es geschickt anstelle. (Sorge dafür das Firma X nicht mehr bei Clouddiensteanbieter Y resolven kann ... Nicht so klug ;-) )

Could you please have your whole blog in English.We also would like to read

Please use the language selector in the top navigation to switch to English