Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2012/01/06 14:59]
flacco
+++ kb [2012/11/15 14:26]
flacco [DDOS / Amplifier Attacke auf bind]
@@ Zeile 203: / Zeile 203: @@
 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.
+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.
 ===== Postfix, Amavis & Dovecot =====
@@ Zeile 275: / Zeile 291: @@
 Die Option //mydestination// legt die Ziele fest, für die Postfix Endpunkt der Email-Zustellung, also nicht weiterleitendes "Relay" ist.
-Nach der Annahme einer Mail, muss die
+Nach der Annahme einer Mail, muss diese an AMaViS weitergegeben werden. Für die Einbindung von AMaViS als Viren- und Spam-Filter stehen mit "content_filter" und "smtpd_filter_proxy" zwei deutlich unterschiedliche Wege zur Verfügung. Während sich AMaViS mit der "smtpd_filter_proxy" Methode direkt in die Einliefernde SMTP-Sitzung einklinkt und diese bis zum Abschluss der Prüfung offen hält, schließt sich die "content_filter" Methode an die erfolgte Einlieferung an. Ist auf einem Internet-Mailserver Methode 1 die deutlich bessere, da hier "verseuchte" gar nicht erst angenommen werden, so macht dieses Vorgehen auf einem invis-Server keinen Sinn, da die Mails hier vom lokalen Fetchmail-Dienst eingeliefert werden und somit eine Blockade nicht Zielführend ist.
+Die Einbindung von AMaVis als Content-Filter findet an zwei Stellen im Postfix-Setup statt. In der Datei "main.cf" erfolgt die eigentliche Integration des Filters durch Benennung eines "Transportweges", welcher in <file>/etc/postfix/master.cf</file> konfiguriert wird. Zunächst die Datei "main.cf":
+<code>
+## Virenscanner
+content_filter=smtp-amavis:[127.0.0.1]:10024
+</code>
+Hier wird festgelegt, dass alle auf "normalem" Wege eingehenden Mails über die Adresse 127.0.0.1 auf Port "10024" dem Content-Filter zugeführt werden. Der eigentliche Transportweg wird hier mit "smtp-amavis" benannt. Damit Postfix weiß, was es mit diesem Transport weg auf sich hat, muss dieser wie gesagt in der Datei "master.cf" konfiguriert werden:
+<code>
+# Weitergabe an Amavis (betrifft nur content_filter, nicht smtp_proxy_filter)
+smtp-amavis     unix    -       -       y       -       2       smtp
+    -o smtp_data_done_timeout=1200
+    -o smtp_send_xforward_command=yes
+    -o disable_dns_lookups=yes
+    -o max_use=20
+</code>
+Wichtig hierbei sind vor allem die beiden Angaben in Zeile eins. Postfix wird mitgeteilt, dass die Weiterleitung per "smtp" erfolgt und maximal zwei parallele Sitzungen gleichzeitig geöffnet werden dürfen. Die Anzahl der maximalen SMTP-Verbindungen kann in Abhängigkeit der lokalen Rechenleistung und dem Mail-Aufkommen variiert werden. In der Konfiguration des AMaViS-Dienstes befindet sich ein korrespondierender Parameter, der mindestens auf den gleichen Wert eingestellt sein muss.
+Die nachfolgenden Optionen im Einzelnen:
+  * **smtp_data_done_timeout**: Timeout, nachdem die Weitergabe abgebrochen wird. Die Einstellung hier ist mit 1200 Sekunden doppelt so hoch wie der Vorgabewert, kann ja sein, dass AMaViS mal länger braucht. ;-)
+  * **smtp_send_xforward_command**: Die Daten der einliefernden Sitzung wie Name, Adresse, Protokoll und HELO Name des original SMTP-Clients werden einfach an den Content-Filter weitergereicht.
+  * **disable_dns_lookups**: Es werden zur Ermittlung des Endpunkts keine DNS-Anfragen gestartet. Da ja ohnehin die IP-Adresse angegeben wurde ist das auch nicht notwendig.
+  * **max_use**: Postfix erlaubt maximal X eingehende Verbindungen für diesen Transportweg.
+Von Bedeutung ist hier vor allem das "xforward" Kommando, da die darüber an AMaViS übermittelten Informationen in die SPAM-Bewertung einfließen können.
+==== AMaViS ====
+In der AMaViS-Konfiguration müssen keine besonderen Einstellungen für Annahme und Rückgabe der Mails vorgenommen werden, da die bisher besprochenen Transportwege den Standard-Vorgaben von AMaViS entsprechen.
+Wichtig ist allerdings die Konfiguration des lokalen Host-Namens sowie der lokalen Domain in der Datei <file>/etc/amavisd.conf</file>
+//**Hinweis:** Bei der Datei handelt es sich um eine Perl-Datei, es ist also besonders auf korrekte Syntax zu achten.//
+<code>
+##invis-server.org -- Default-Settings
+$mydomain = 'julgs-net.loc';      # (no useful default)
+$myhostname = 'zentrale.julgs-net.loc';  # fqdn of this host, default by uname(3)
+</code>
+Sollte der Weg der Rücklieferung vom Standard abweichen, müssen die folgenden Zeilen vom Kommentarzeichen befreit und entsprechend den Gegebenheiten angepasst werden:
+<code>
+#$forward_method = 'smtp:[127.0.0.1]:10025';  # where to forward checked mail
+#$notify_method = $forward_method;            # where to submit notifications
+</code>
+Weiterhin ist darauf zu achten, dass die Anzahl der maximal gestarteten AMaViS-Prozessen gleich oder größer der für Postfix vorgenommenen Einstellung ist. Der im Beispiel genannte Wert war "2":
+<code>
+$max_servers = 2;     # num of pre-forked children (2..30 is common), -m
+</code>
+==== Postfix - Rücknahme und Weitergabe an Dovecot ====
+Postfix nimmt von AMaViS geprüfte und nicht beanstandete Mails auf Port "10025" wieder entgegen. Auch hierfür muss in <file>/etc/postfix/master.cf</file> ein Transportweg eingerichtet werden:
+<code>
+## Ruecktransport von amavis an Postfix
+localhost:10025 inet    n       -       n       -       -       smtpd
+  -o smtpd_tls_security_level=none
+  -o content_filter=
+  -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>
+In Zeile 1 wird zunächst festgelegt, dass der Endpunkt dieses Transportweges ein SMTP-Dienst ist. Eine Beschränkung der maximalen Anzahl der Prozesse ist hier nicht notwendig, da hier ohnehin nur das ankommen kann was zuvor den bereits auf zwei max. Sitzungen beschränkten Weg durch AMaViS genommen hat. (Zugegeben, so ganz richtig ist das nicht, da durchaus auch andere Programme auf dem Server Mails auf 127.0.0.1:10025 einliefern könnten.)
+Die weiteren Optionen im Einzelnen:
+  * **smtp_tls_security_level**: Da die gesamte Kommunikation über die Loopback-Schnittstelle des Servers läuft ist eine Verschlüsselung obsolet.
+  * **content_filter** & **smtpd_proxy_filter**: Beiden Optionen ist kein Wert zugewiesen, was dazu führt, dass bei der Rücklieferung der Mails diese nicht in Form einer Endlosschleife wieder an AMaViS übergeben werden.
+  * **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.
+Ü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.
+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.