Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2012/11/15 15:01]
flacco [Gegenmaßnahmen]
+++ kb [2014/03/18 08:41]
flacco [ISC DHCP LDAP Schema nach Samba 4 LDAP überführen]
@@ Zeile 231: / Zeile 231: @@
 Für die Abwehr eines solchen Angriffes ergeben sich genau zwei Ansatzpunkte:
-  * Der Dienst selbst
+  * **Der Dienst selbst**
-  * Die Firewall
+  * **Die Firewall**
 Über die Firewall lassen sich Limits für Anfragen pro Zeit auf bestimmte Ports einrichten. Eine solche Maßnahme ist zwar wirksam um die Gesamtbelastung des Servers zu senken, sie bestraft allerdings auch diejenigen, die einen Dienst regulär nutzen.
 Reduziert man also die Anfragen auf Port 53/UDP beispielsweise auf 200 pro Sekunde, lässt die Firewall eben nur noch eben diese 200 Anfragen auf den DNS-Server zu, ungeachtet dessen, ob eine Anfrage gut oder böse ist. Schöpft der Angreifer das Limit bereits aus, sind Störungen des regulären Betriebs die Folge. Prinzipiell, hat der Angreifer auch auf diese Weise sein Ziel schon erreicht. Der einzig messbare Erfolg dieser Strategie ist die Reduktion des Traffics.
+Hier noch beispielhaft eine entsprechende Firewall-Regel:
+<code>
+linux:~ # iptables -A INPUT -p UDP -i eth0 --sport 1024: --dport 53 -m limit --limit 200/s -j ACCEPT
+</code>
 Besser ist also die Abwehr am Dienst selbst oder eine Kombination mehrerer Maßnahmen.
@@ Zeile 254: / Zeile 260: @@
 Soll der Nameserver allerdings öffentlich für alle Anfragen zur Verfügung stehen, kommt diese Abwehrstrategie nicht in Frage.
+Es bietet sich an Clients deren Anfragen dem Muster des Angriffs entsprechen auf eine Blacklist zu setzen. Da die Angriffe allerdings von ständig neuen Hosts (vermutlich aus einem Bot-Netz) kommen, darf eine solche Blacklist aber nicht statisch sein.
+Generell kann //**bind**// über die Direktive "//allow-query//" Anfragen mit einem "Refused" beantworten oder mit der Direktive "//blackhole//" gänzlich ins Leere laufen lassen. Da es ja um die Vermeidung von Traffic geht bietet sich Letzteres an. Nützlich ist natürlich auch, dass //**bind**// mit Access-Control-Lists umgehen kann.
+Zur Abwehr habe ich eine externe Konfigurationsdatei erzeugt, die lediglich eine ACL namens "blackhole" enthält. Die darin aufgeführte Liste wird dynamisch durch ein per Cron-Job regelmäßig ausgeführtes Shellscript gepflegt. Das Shellscript durchsucht beim Aufspüren der Angreifer wiederum die Datei "/var/log/messages" nach entsprechenden Einträgen. Voraussetzung ist ein aktiviertes Query-Logging.
+Das Shellscript:
+<code>
+#!/bin/bash
+# Dynamisch Blacklist fuer bind erzeugen
+cat /var/log/messages |grep "IN ANY +E" |cut -d " " -f7|cut -d "#" -f1| sort -u >> /var/tmp/badhosts.tmp
+cat /var/tmp/badhosts.tmp | sort -u > /var/tmp/badhosts
+# Attacking Hosts acl erstellen
+echo "acl blackhole {" > /etc/named.d/named.blackhole
+for badhost in `cat /var/tmp/badhosts`;do
+    echo -e "\t$badhost;" >> /etc/named.d/named.blackhole
+done
+echo -e "};\n" >> /etc/named.d/named.blackhole
+# bind reload
+/etc/init.d/named reload
+</code>
+Das geht sicherlich auch noch eleganter, aber auf die Schnelle erfüllte es seinen Zweck. Ausgeführt wird das Script einmal pro Minute. Häufig, aber erforderlich.
+In der Datei "named.conf" wird zunächst vor der Options-Sektion die vom Shellscript erzeugte Konfigurationsergänzung "named.blackhole" eingebunden:
+<code>
+...
+include /etc/named.d/named.blackhole
+...
+</code>
+Innerhalb der Options-Sektion wird //**bind**// dann lediglich mitgeteilt, was er mit der generierten ACL machen soll:
+<code>
+options {
+...
+        blackhole { blackhole; 2.0.0.0/8; 224.0.0.0/3; };
+        allow-query { any; };
+...
+};
+</code>
+Nach 4 Tagen war die Liste der Angreifer bereits über 2000 Einträge lang.
+Die Kombination aus oben gezeigter Firewall-Regel und dem hier vorgestellten Blackhole-Mechanismus lies die ausgehende tägliche Datenmenge des betroffenen Servers wieder auf Normalmaß schrumpfen. Trotzdem war dies nur ein Teilerfolg, da die Firewall-Regel auch reguläre Anfragen blockiert hat.
+Die wirklich funktionierende Lösung des Problems brachte ein Patch für //**bind**// von Vernon Shryver und Paul Vixie, der ein per Client Rate-Limiting über die Konfiguration des Nameservers selbst erlaubt. Genau beschrieben wird die Funktionsweise des Patches auf der zugehörigen Internet-Seite: [[http://www.redbarn.org/dns/ratelimits]]
+Im Gegensatz zum Firewall-Ansatz, wird hierbei jeder anfragende Client individuell betrachtet. D.h. Bleibt ein Client mit seinen Anfragen unter einer einstellbaren Anzahl pro Sekunde werden alle Anfragen beantwortet, überschreitet er sein Limit, antwortet //**bind**// einfach nicht mehr.
+Entsprechend gepatchte //**bind**// Versionen stellen wir über unsere invis-Repositories im OpenBuildService zur Verfügung, auch noch für ältere openSUSE-Versionen (11.1, 11.2 und 11.3).
+Die Konfiguration ist denkbar einfach. In der Options-Sektion der Datei "/etc/named.conf" genügt folgender Eintrag:
+<code>
+options {
+...
+     rate-limit {
+          responses-per-second 25;
+          window 5;
+     };
+...
+};
+</code>
+Näheres zu den Parametern der "rate-limit" Direktive ist auf oben genannter Internet-Seite nachzulesen.
+Die Kombination aus Blacklist und Rate-Limit ohne Firewall-Regel funktioniert hervorragend.
 ===== Postfix, Amavis & Dovecot =====
@@ Zeile 474: / Zeile 555: @@
 Alle weiteren Dateien sind logisch unterteilt im Verzeichnis "/etc/dovecot/conf.d" zu finden.
+===== ISC DHCP LDAP Schema nach Samba 4 LDAP überführen =====
+Suchen und ersetzen der Attributnamen und Objektklassen:
+<code>
+linux:~ # cat README.ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > ad.README.ldap
+</code>