Rate Limiting in DNS mit BIND9

Abstract

Mein Monitoring meldete dieser Tage, dass es einen DIG-Check eines extern gehosteten DNS-Servers zeitweise nicht durchführen konnte. Die Ursache war Überlastung. Deshalb habe ich nun Rate Limit in BIND9 eingeführt. Dieser Artikel gibt dazu eine kleine Einführung.

Mein Monitoring meldete dieser Tage, dass es einen DIG-Check eines extern gehosteten DNS-Servers zeitweise nicht durchführen konnte. Die Ursache war Überlastung. Deshalb habe ich nun Rate Limit in BIND9 eingeführt. Dieser Artikel gibt dazu eine kleine Einführung.

Ich kann an dieser Stelle nicht alle Aspekte eines DNS-Setups mit BIND9 erörtern, dazu ist das Thema zu komplex. Dem interessierten Leser empfehle ich, Fragen an die BIND-Mailingliste zu stellen oder deren Archive zu durchsuchen – außerdem natürlich das Studium der Dokumentation von BIND.

Warum Rate Limiting in einem DNS-Server?

Von einem DNS-Server, der auch Internet-Domains hostet, will man eigentlich nur, das er seine Arbeit erledigt: "Set it and forget it." Für gewöhnlich hat man mehrere dedizierte DNS-Server in verschiedenen Netzen, und mindestens einer davon wird extern gehostet. Das Ziel ist meist maximale Redundanz, Leistungsfähigkeit und Erreichbarkeit.

Rate Limit widerspricht in gewisser Weise diesen Zielen, da es ab einem einstellbaren Schwellenwert sozusagen die Auskunft für kurze Zeit verweigert. Es gibt Rate-Limit-Lösungen in vielen Software-Produkten und für viele Protokolle; es ist also nicht wirklich etwas Neues. Dass man nun auch bei DNS-Servern zu diesem Mittel greift, liegt an einer sich immer weiter verbreitenden Angriffsmethode. Der Wikipedia-Artikel DNS Amplification Attack beschreibt dies ausführlich.

Wie pflegt man Rate Limits in BIND ein?

Es gibt wohl schon RedHat-Pakete, die den Rate Limit Patch enthalten, hier wäre dann nur noch die Konfiguration zu erledigen. Hier der Link RRL_Patch, um den Patch für seine BIND-Version zu beziehen. Je nachdem wie man BIND gewöhnlich installiert, kann man direkt die Sourcen patchen:

# cd /home/sys4/bind-9.8.5-P1
# wget http://ss.vix.su/~vjs/rl-9.8.5-P1.patch
# cat rl-9.8.5-P1.patch | patch -p0

Bei Debian oder Ubuntu bietet es sich an, die Raring BIND9 Pakete zu rekompilieren. Beschrieben habe ich das an anderer Stelle für Dovecot.

Konfiguration von Rate Limits

Ich empfehle ausdrücklich die Dokumentation. Danach könnte man z.B. Folgendes in der named.conf auf einem autoritativen Nameserver im Internet View einpflegen.

rate-limit {
   responses-per-second 5;
   window 5;
   exempt-clients { deine_acl; };
   log-only no;
};

Abgesehen von den Rate-Limit-Einstellungen ist hier der Parameter exempt-clients erwähnenswert. Dieser Parameter ist sozusagen ein Whitelisting für z.B. IP-Adressen oder Netze, die an anderer Stelle in einer ACL definiert worden sind.

Will man erst einmal nur mitlesen "was so passiert", kann man log-only auf yes setzen. Die passende Konfiguration dazu sieht so aus:

...
channel query-errors-log {
               file "/var/log/query-errors.log" versions 100 size 2M;
               severity debug 2;
               print-severity yes;
               print-time yes;
       };
...
category query-errors { query-errors-log; };
...

Funktionstest

Zum Testen des Rate Limits sollte man das Log mit tail -f beobachten und von einer nicht gewhitelisteten IP-Adresse z.B. Folgendes ausführen:

for i in {1..10}; \
do dig @dein.dns.server.de +short +tries=1 +time=1 deine-domain.de a; \
done

Das Resultat in /var/log/query-errors.log sollte dann so aussehen:

20-Jun-2013 11:16:15.988 info: client 1.2.3.4#35892: view internet: rate limit slip response to 1.2.3.0/24 for deine-domain.de IN A  (9d315a3d)

Ausblick

Rate Limiting auf Nameservern ist sicher nicht die finale Antwort auf Amplification Attacks. Diverse Möglichkeiten stehen zur Auswahl, können kombiniert werden und werden durchaus kontrovers diskutiert. So gut wie es funktioniert, gehe ich aber davon aus, es wird in die STABLE Versionen von BIND aufgenommen werden.

Im Alltag ermöglicht die Implementierung einen ausgewogenen Kompromiss, zwischen schnellstmöglichen Antworten und Eigenschutz – vor allem deshalb, weil Rate Limiting sich sehr fein justieren lässt. Denkbar wäre auch eine Kombination mit Fail2ban oder iptables recent für schwere Angriffe, ähnlich wie in meinem Artikel zu Botnet beschrieben.

Als Ausblick möchte ich außerdem auf DNS Firewalls mit Response Policy Zones (RPZ) hinweisen, der RPZ patch ist bereits verfügbar. Zu diesem Feature werden sich meine Kollegen evtl. an dieser Stelle später noch äußern.

Robert Schetterer, 20. June 2013