Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2012/11/15 15:01]
flacco [Gegenmaßnahmen]
+++ kb [2014/03/28 14:05]
flacco [Letzte Etappe - Dovecot]
@@ Zeile 237: / Zeile 237: @@
 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 259: / Zeile 340: @@
   * Dovecot als SASL-Authentifizierungsbackend für Postfix zu nutzen.
-  * Dovecots Deliver als MDA einzusetzen.
+  * Dovecots LMTP-Dienst zur Mail-Einlieferung zu verwenden
-  * IMAP-ACLs zu ermöglichen.
+  * IMAP-ACLs / Shared Folders zu ermöglichen.
+  * Sieve-Filter zu ermöglichen
   * Amavis als content_filter zu nutzen.
+Das Ganze gilt natürlich nur, wenn kein Zarafa eingesetzt wird. Zarafa integriert den Email-Speicher und Funktionen wie Zugriffsrechte und Filterregeln, kommt also ohne externen IMAP-Server aus.
 Die genannten Anforderungen ergeben ein recht komplexes Setup, daher widme ich mich hier den Hintergründen. Zunächst allerdings nur dem Teil der Einlieferung neuer Mails via //**fetchmail**//.
 Größte Schwierigkeit hierbei ist ein sauberes Mailrouting durch alle Komponenten. Dies beginnt bereits beim Fetchmail-Daemon. Zunächst ein schematischer Überblick über die Wege einer eingehenden Email:
+//**Hinweis:** Die Grafik ist nicht aktuell, der Dovecot Delivery Agent fällt jetzt weg, die Einlieferung erfolgt direkt via LMTP.//
 {{:invis-postfix_dovecot.png|Überblick}}
@@ Zeile 420: / Zeile 506: @@
 //**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.
+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 zu überlassen und die Übergabe an Dovecot via LMTP (Local Mail Transfer Protocol) zu erledigen.
 Üblicherweise sind Maildirs in den Home-Verzeichnissen der Benutzer zu finden. Dies birgt einige Nachteile und Gefahren in sich. Die größte Gefahr dabei, geht wohl von den Nutzern selbst aus, die in der Lage sind diese Verzeichnisse einfach zu löschen. Dass ein Benutzer im "Aufräumrausch" einfach mal Verzeichnisse löscht, mit denen er nichts anfangen kann, dürfte wohl keine Seltenheit sein.
@@ Zeile 441: / Zeile 527: @@
 </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>
+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 die Relay-Domains Table den gleichen Aufbau hat wie die normale Transport-Table, wird Sie an als zusätzliche Transport-Table eingebunden. 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
+relay_domains = hash:/etc/postfix/relay_domains
-transport_maps = hash:/etc/postfix/relay
+transport_maps = hash:/etc/postfix/transport, $relay_domains
 </code>
-Die in der Konfiguration benannte Datei muss manuell angelegt und mit folgendem Inhalt versehen werden:
+Die in der Konfiguration benannte Datei "relay_domains" muss manuell angelegt und mit folgendem Inhalt versehen werden:
 <code>
 # for relaying domain
 # domain.de OK
-invis-net.loc   dovecot:
+invis-net.loc   lmtp:unix:private/dovecot-lmpt
 </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:
+Darin enthält Spalte 1 die Domain und Spalte 2 den zugehörigen Transportweg.
+Das Beispiel zeigt eine LMTP-Anbindung via UNIX-Socket. Die entsprechende Socket-Datei muss von Dovecot bereit gestellt werden. Alternativ wäre auch ein TCP/IP-Socket über die Localhost-Schnittstelle möglich.
 <code>
-## Dovecot Transport -- invis-server.org -- Stefan Schaefer
+# for relaying domain
-dovecot   unix  -       n       n       -       -       pipe
+# domain.de OK
-    flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver
+invis-net.loc   lmtp:[127.0.0.1]
-    -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.
+Die TCP/IP Methode ist etwas einfacher in der Konfiguration, da seitens Dovecot kein Socket definiert werden muss. UNIX-Sockets sind allerdings etwas performanter, da die übertragene Datenmenge durch Wegfall des TCP/IP bedingten Overheads geringer ist.
 ==== 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.
+Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1, inzwischen schon Version 2.2 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.
+Bei aller Freude über Peer Heinleins neues Dovecot Buch, ist doch festzustellen, dass die Aufgabenstellung die sich für die Dovecot-Konfiguration auf einem invis-Server stellt, mit dem Buch allein nicht zu bewältigen ist. Peer trennt im Prinzip zwischen einer Installation mit lokalen Benutzern und einer Hosting-Situation mit virtuellen Benutzern. Auf einem invis-Server haben wir es zwar mit lokalen Benutzern zu tun, aufgrund der Vorzüge, die das mit sich bringt, möchte ich sie aber lieber wie virtuelle Benutzer behandeln, da dies einige Vorteile mit sich bringt.
+Definieren wir zunächst die Ziele:
+  * Zugriff auf die LDAP-Benutzerkonten via PAM
+  * Ordner-Freigaben über IMAP-ACLs
+  * Sieve Filter und sei es nur für Abwesenheitsbenachrichtigungen
+  * Quotas, wenn auch nur zum Warnen
+  * SASL-Auth Schnittstelle für Postfix
+  * Lokale Email-Zustellung via LMTP
+==== Mailversand - SMTP-Auth mit Dovecot-SASL ====
+===== 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>