Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2012/01/06 17:07]
flacco
+++ kb [2014/03/18 08:29]
flacco [Letzte Etappe - Dovecot]
@@ Zeile 204: / Zeile 204: @@
 Im Beispiel wurden zwei gleichzeitige Threads ermöglicht. Hierfür steht die Ziffer (2) am Beginn der Definition des Daten-Backends. Vorgegeben ist der Wert 1, da die Erhöhung nur dan funktioniert, wenn das zugrunde liegende System Multithreading-fähig ist. Bei modernen Linux-Systemen ist dies in der Regel der Fall.
+===== DDOS / Amplifier Attacke auf bind =====
+Noch ein schönes Thema für die Knowledgebase, diesmal im Hinblick auf das Thema Rootserver.
+==== Die Attacke ====
+Beginnend etwa am 25. Oktober 2012 geriet einer meiner produktiv genutzten Rootserver unter Beschuss. Aufgefallen ist mir das Ganze nur, weil invis-Server meiner Kunden immer schlechter via Internet erreichbar waren. Zunächst ließ mich mein Monitoring-System vermuten, dass es Probleme mit den DSL-Anbindungen bei den Kunden gibt. Es stellte sich aber heraus, dass der DNS-Server der für meine Kunden dynamisches DNS (DDNS -- ist im Root-Server Buch beschrieben) betreibt, attackiert wurde und dadurch seinen Dienst nicht mehr zuverlässig erledigen konnte.
+Im Logfile tauchten massiv immer wieder die gleichen Anfragen auf:
+<code>
+Nov 15 15:11:02 rs2 named[2637]: client 77.xxx.xxx.xxx#64253 (.): query: . IN ANY +E (178.xx.xx.xx)
+</code>
+Derartige Anfragen sind unschön. Sie nutzen aus, dass der DNS Server, so er ein offener Resolver ist, auch Anfragen beantwortet, die außerhalb seines eigenen Datenbestandes liegen. Im Beispiel werden schlicht alle (ANY) Informationnen zur Rootzone (**.**) erfragt.
+Eine solche Anfrage erzeugt Antworten die weit größer (bis zum Faktor 60, laut einigen Dokumentationen) sind als die früher üblichen 512 Byte. In den Traffic-Logs des Servers spiegelte sich das deutlich nieder. Während in Zeiten vor dem Angriff auf dem Server eingehend ca. 1 bis 2 GB und ausgehend 2 bis 3 GB pro Tag anfielen, stieg der ausgehende Traffic im Verlauf der Attacke bis auf ca. 25 GB pro Tag an. Der Nameserver (im Einsatz ist bind) stieß an die Grenzen seiner Möglichkeiten und beantwortete reguläre Anfragen nicht mehr zuverlässig.
+Die Diskrepanz zwischen eingehender und bis zum Faktor 60 höherer ausgehender Datenmenge gibt dieser Form des Angriffs ihren Namen DDOS/Amplifier (Verstärker).
+Da eine Anfrage im Rechenzentrum ergeben hat, dass von weiteren Attacken auf andere Server nichts bekannt ist und die Attacke auf meinen Server von immer anderen Hosts ausging, liegt der Schluss nahe, dass es sich um einen gesteuerte, zielgerichteten Angriff handelt (Distributed Denial Of Service Attack / DDOS).
+Leider sind weder die Gründe dafür noch die Angreifer ohne Weiteres ermittelbar.
+==== Gegenmaßnahmen ====
+Für die Abwehr eines solchen Angriffes ergeben sich genau zwei Ansatzpunkte:
+  * **Der Dienst selbst**
+  * **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.
+Vielfach ist im Internet zu lesen, dass derartige Angriffe vor allem durch sogenannte "open resolver" begünstigt wird. Ein "open resolver" ist ein Nameserver, der für alle DNS Anfragen generell zur Verfügung steht. Einen DNS-Server so zu konfigurieren, dass er nur noch Fragen zu seinem eigenen Datenbestand, also seinen Zonen beantwortet führt zwar direkt zum Ziel, ist aber dann nicht möglich wenn es beispielsweise darum geht Forward-Nameserver für die eigenen Kunden zu sein.
+Ist es nicht erforderlich allgemeine DNS-Anfragen zu beantworten lässt sich der oben beschriebene Angriff leicht abwehren. In der Datei "/etc/named.conf" muss in der Options-Sektion lediglich folgender Eintrag eingefügt werden:
+<code>
+options {
+...
+        # Rekursion verbieten
+        recursion no;
+...
+};
+</code>
+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 343: / Zeile 474: @@
   -o smtpd_proxy_filter=
   -o mynetworks=127.0.0.0/8
+  -o smtpd_delay_reject=no
+  -o smtpd_client_restrictions=permit_mynetworks,reject
+  -o smtpd_helo_restrictions=
+  -o smtpd_sender_restrictions=
   -o smtpd_recipient_restrictions=permit_mynetworks,reject
+  -o smtpd_data_restrictions=reject_unauth_pipelining
+  -o smtpd_end_of_data_restrictions=
+  -o smtpd_restriction_classes=
+  -o smtpd_error_sleep_time=0
+  -o smtpd_soft_error_limit=1001
+  -o smtpd_hard_error_limit=1000
+  -o smtpd_client_connection_count_limit=0
+  -o smtpd_client_connection_rate_limit=0
+  -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
 </code>
@@ Zeile 354: / Zeile 498: @@
   * **mynetworks**: Legt das Netzwerk fest auf dem dieser Transportweg zur Verfügung steht. Hier werden die im normalen Postfix-Setup genannten Netzwerke auf dass Loopback-Netz beschränkt. Benötigt wird diese Einstellung vor allem für die nachfolgende Zeile.
   * **smtpd_recipient_restrictions**: Hiermit wird die Einlieferung von Mails auf den zuvor benannten Netzwerken ohne weitere Restriktionen erlaubt. Alle Einlieferungsversuche aus anderen Netzen jedoch unterbunden.
+//**Achtung:** In einigen der jüngeren invis-Releases (7.0/7.1) habe ich darüber hinaus die Option "-o local_header_rewrite_clients=" gesetzt. Dies wird auch an anderer Stelle so angegeben. Diese Option sorgt allerdings dafür, dass das zuvor vorgenommene Address-Rewriting (aus lokaler Mail-Adresse mache externe Adresse) beim Rückliefern der Mail wieder rückgängig gemacht wird. Bedeutet die Empfänger einer solchen Mail sehen als Absende-Adresse die lokale Email-Adresse des Absender, die aber im Internet-Mailverkehr keine Gültigkeit hat.//
 Postfix ist zwar durchaus in der Lage Mails direkt in sogenannte "Maildirs" einzuliefern, allerdings ist dieser direkte Weg mit allerlei Nachteilen verbunden, da dadurch einige Stärken von Dovecot ungenutzt bleiben. Besser ist es die Verteilung der Mails in die jeweiligen Postfächer Dovecots eigenem MDA //**deliver**// zu übertragen.
@@ Zeile 361: / Zeile 507: @@
 Weiterhin verhindern Maildirs in den Home-Verzeichnissen der Benutzer die Anwendung von IMAP-ACLs also die Freigabe von Mail-Ordnern für andere Nutzer. Ursache hierfür sind die meist restriktiven Dateisystem-Zugriffsrechte  bei Home-Verzeichnissen, die gesetzte IMAP-ACLs überlagern. D.h. die Maildirs müssen an einen anderen Ort verfrachtet werden und einem neutralen Benutzer gehören.
+Üblicherweise werden für diesen Zweck sowohl ein Benutzer als auch eine Gruppe "vmail" angelegt:
+<code>
+linux:~ # groupadd -g 399 vmail
+linux:~ # useradd -c "Benutzerkonto fuer Dovecot Mailhandling" -s /bin/false -g vmail vmail
+</code>
+Anschließend müssen die Rechte am Arbeits und Mail-Spool-Verzeichnis so angepasst werden, dass //vmail// darin schreiben darf:
+<code>
+linux:~ # chown vmail.mail /var/lib/dovecot
+linux:~ #  chmod 0775 /var/lib/dovecot
+linux:~ #  chown -R .vmail /var/spool/mail
+</code>
+Damit Postfix weiß, auf welchem Weg es Mails lokal zuzustellen hat, muss dies in Abhängigkeit zur Empfänger-Domain bekannt gemacht werden. Genutzt werden für diesen Zweck entsprechende Lookup-Tables. Hintergrund ist hier, dass Postfix über die Empfänger keine Kenntnis hat oder braucht. Es bekommt einfach nur gesagt, welche Domains lokal "relayed" werden und wer sich um die Zustellung kümmert. Für beide Zwecke gibt es mit //relay_domains// und //transport_maps// eigene Lookup-Tables. Da in unserem Fall beide Tables den gleichen Inhalt haben, werden Sie an die selbe Datenquelle gebunden. Vorgenommen wird diese Konfiguration wieder in der Datei: <file>/etc/postfix/main.cf</file>
+<code>
+# Relay Domains und Transportwege-Regelungs Tabelle bekannt machen
+relay_domains = hash:/etc/postfix/relay
+transport_maps = hash:/etc/postfix/relay
+</code>
+Die in der Konfiguration benannte Datei muss manuell angelegt und mit folgendem Inhalt versehen werden:
+<code>
+# for relaying domain
+# domain.de OK
+invis-net.loc   dovecot:
+</code>
+Darin enthält Spalte 1 die Domain und Spalte 2 den zugehörigen Transportweg. Letzterer muss natürlich in der Datei <file>/etc/postfix/master.cf</file> noch angelegt werden:
+<code>
+## Dovecot Transport -- invis-server.org -- Stefan Schaefer
+dovecot   unix  -       n       n       -       -       pipe
+    flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver
+    -f $sender -d $recipient
+</code>
+Benannt werden hier vor allem der Benutzer unter dessen Kennung der MDA (deliver) ausgeführt wird, der zu verwendende Delivery-Agent selbst, Absender- und Empfängeradresse sowie ein paar Flags, die das Verhalten des Delivery-Agents beeinflussen.
+==== Letzte Etappe - Dovecot ====
+Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1 zum Einsatz. Erwähnenswert ist das, da sich an dessen Konfiguration mit Einführung von V. 2.x einiges geändert hat. Einerseits betrifft dies Namen von Konfigurationsoptionen und andererseits den Aufbau der Konfiguration an sich. Unter openSUSE wurde die Konfiguration der Übersicht halber in mehrere Dateien gesplittet. Im Verzeichnis "/etc/dovecot" ist nach wie vor eine (wenn auch stark geschrumpfte) Datei "dovecot.conf" zu finden. Sie dient quasi als Hauptkonfigurationsdatei in die alle weiteren Dateien inkludiert werden. Ähnlich wie das bereits beim Apache-Webserver der Fall ist.
+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/iscDchp/g > ad.README.ldap
+</code>