Dampening für Bind 9.9.7-P2
Nachdem ich lange nur selbst Dampening gemacht habe, das öffentliche Interesse auf Sparflamme blieb und andere sich mehr oder weniger darum kümmerten, den Versionsupdates nachzuhecheln, wurde ich von einen Bekannten gebeten doch mal wieder meinen Stand öffentlich zu machen.
Aktuell habe ich eine Version gegen 9.9.7-P2 auf der Platte. Die mußte ich aber heftig aufhübschen und in einen normal nutzbaren Patch gießen. Das hat einige Zeit gedauert. Sorry.
Hier ist der Patch: bind-9.9.7-P2-dampening.patch (und er tut auch für 9.9.7-P3, wie ich soeben festgestellt habe).
Was hat sich getan?
Eigentlich nicht viel.
- Die Evaluierung zwischen Heap und Queue-Implementation ist zugunsten der Queue ausgefallen. Sie ist leicht schneller und stabiler auf Fremdsystemen. Der Heap hat dafür mehr Eleganz beim Rekonfigurieren.
- Man kann nun per configure die Funktion mit --enable-dampening aktivieren und unabhängig davon das Logging der Strafpunkte im Querylog mit --enable-dampening-log anschalten. Hintergrund der Trennung ist der Wunsch nach konsistenten Logfiles, egal ob die Funktionalität benutzt wird oder nicht.
Was fehlt noch?
Wie immer zuviel.
- Es wäre schön, wenn ich den Code für die Parametrisierung der QTypes in die Konfig bekommen könnte. Der Parsercode ist aber etwas sehr umständlich für mich.
- Es wäre auch schön, wenn das Resizing der Tabellengröße per rndc reconfigure stabil funktionieren würde.
- Nötig sind Tests, anhand derer man sehen kann, ob Dampening korrekt implementiert wurde.
- Ein Slip-Modus, in dem mit einer niedrigen Rate die Umschaltung auf TCP eingefordert wird, wäre nützlich. Ich habe aber noch nicht verstanden, wie das korrekt geht, so daß der befugte Client nicht die TC-Pakete des DRDoS abbekommt.
- Die Interaktion zwischen Dampening und RRL ist zu klären. Kommen die beiden sich ins Gehege?
- Man müßte es zum Upstream durchbekommen, damit es dort mit gepflegt wird.
So, das wär's erstmal.
Taugt es für Euch?
RRL prüft auf die Abfolge der immer gleichen Anfrage. Die DRDoS Nasen sind aber inzwischen oft genug schlau genug, die QNames zu variieren und pro QName unter dem Radar von RRL zu bleiben. Dampening addiert quer über alle QNames und QTypes auf. Und es erwischt auch die langsamen Angriffe.
Der Unterschied wird relevant, wenn man nicht eine einzelen TLD betreibt (dafür wurde RRL gemacht), sondern einen Nameserver mit vielen authoritiven Zonen (z.B. eine Firma mit aktiver Marketing-Abteilung oder schlicht ein ISP). In dieser Breite greift RRL nur die besonders krassen Fälle von Dummheit raus.
Gemessen hat das jemand anders: http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf
rate-limit {
responses-per-second 5;
window 5;
exempt-clients {
acl1;
acl2;
acl3;
};
log-only no;
};
Total 2 comments