Aktuelle Entwicklungstrends bei Postfix Antispam Maßnahmen durch policy-delegation

Transkript

1 Aktuelle Entwicklungstrends bei Postfix Antispam Maßnahmen durch policy-delegation GUUG-Frühjahrsfachgespräch Osnabrück, 23. März 2006 Aktuelle Entwicklungstrends bei Postfix

2 T-Systems Business Services T-Systems ist die Geschäftskundenmarke der Deutschen Telekom. Als führender Dienstleister bietet das Unternehmen mit Mitarbeitern Informationstechnik und Telekommunikation aus einer Hand. Konkret heißt das: Unsere Kunden haben für alle Bedürfnisse stets einen Ansprechpartner ob es um Unternehmensnetze geht, um ICT-Lösungen oder das Auslagern ganzer Geschäftsprozesse. Aktuelle Entwicklungstrends bei Postfix

3 T-Systems Business Services II Strategische Platform ist Microsoft-Software. Aktuelle Entwicklungstrends bei Postfix

4 T-Systems Business Services III Ich geh dann besser mal... Aktuelle Entwicklungstrends bei Postfix

5 state of mind Agentur für vernetzte Kommunikation Lösungen für Print, Multimedia und Websites. Aktuelle Entwicklungstrends bei Postfix

6 Inhalt 1 Aktuelle Entwicklungstrends bei Postfix DSN delivery status notification Vorlagen-gesteuerte DSN-Nachrichten Unterstützung von enhanced status codes Detaillierteres Logging Absenderabhängiger relayhost Gemeinsamer Code für LMTP- und SMTP-Clients Mehr Plugins Verfeinerung der TLS-Unterstützung Strikte Prüfung der Daemonen-Privilegien Beibehaltung der Groß-/Kleinschreibung bei Rewriting 2 Was ist eine (SMTP-)Policy? Die policy-delegierung im Allgemeinen Implementierung policy Delegierung: Greylisting Fertige Daemonen Aktuelle Entwicklungstrends bei Postfix

7 Das Entwicklungsmodell stable -Version wird ab und an veröffentlicht snapshot -Versions enthält neue Features die in die nächste stable einfließen Aktuelle Entwicklungstrends bei Postfix

8 Das Entwicklungsmodell II keine Bananenware: Stabil genug für den täglichen Gebrauch Aktuelle Entwicklungstrends bei Postfix

9 DSN delivery status notification Unterstützung von DSN gem. RFC Hiermit kann eine Quittierung der erfolgreichen (oder erfolglosen) Auslieferung vom Absender angefordert werden. Es gibt mehrere Reportklassen: failure, wenn eine Benachrichtigung bei Zustellproblemen erzeugt werden soll, delay für eine Benachrichtigung bei Zustellverzögerungen und success, für Benachrichtigung erfolgreicher Zustellung. User Agents mit DSN Unterstützung sind z.b. elm-2.4me+31 und mutt. Aktuelle Entwicklungstrends bei Postfix

10 DSN delivery status notification Lustige Anwendungen Damit kann man z.b. bei manchen Systemen sehen, wohin zugestellt wird! Aktuelle Entwicklungstrends bei Postfix

11 DSN delivery status notification Oha! /dev/null Aktuelle Entwicklungstrends bei Postfix

12 Vorlagen-gesteuerte DSN-Nachrichten Vorlagen-gesteuerte DSN-Nachrichten Seit snapshot bietet Postfix vorlagen-gesteuerte DSN-Meldungen und kann somit nun auch deutsch-sprachige Statusmeldungen erstellen: Aktuelle Entwicklungstrends bei Postfix

13 Vorlagen-gesteuerte DSN-Nachrichten Wann werden diese eingesetzt? Eine Zustell-Status-Nachricht wird immer dann generiert und an den Absender gesendet, wenn: ein Fehler bei der Zustellung aufgetreten ist eine Verzögerung bei der Zustellung auftritt eine Zustell-Bestätigung angefordert wurde eine Empfänger-Adressen-Bestätigung angefordert wurde Aktuelle Entwicklungstrends bei Postfix

14 Unterstützung von enhanced status codes enhanced status codes (RFC 3463) In Maps (siehe access(5)) kann man nun: REJECT You can t go here from there angeben was dann hoffentlich vom MUA (Outlook, Mozilla, etc.) in eine luser-verständlicher Fehlermeldung umgewandelt wird. In unserem Beispiel laut RFC: Delivery not authorized, message refused The sender is not authorized to send to the destination. Aktuelle Entwicklungstrends bei Postfix

15 Detaillierteres Logging Detaillierteres Logging delay=n wurde zu delay=n, delays=a/b/c/d, wobei: a: Zeit vor dem qmgr, einschließlich der Übertragungszeit b: Zeit innerhalb des qmgr c: Zeit für Verbindungsaufbau, inkl. DNS, HELO und TLS-Handshake d: Übertragungsdauer Alle Zeitangaben sind jetzt endlich genauer als 1s! Aktuelle Entwicklungstrends bei Postfix

16 Detaillierteres Logging Detaillierteres Logging II conn_use=n zeigt die Anzahl der Wiederverwendungen der Verbindung relay=hostname[ip.add.re.ss]:port zeigt nun auch den Port an, der kontaktiert wurde Aktuelle Entwicklungstrends bei Postfix

17 Detaillierteres Logging Beispiel Von mail.charite.de: Feb 1 15:13:49 mail postfix/smtp[14123]: 94A : to=<recipient@charite.de>, relay= [ ]:10025, conn_use=2,... relay= [ ]:10025 wir reden mit amavisd-new conn_use=2 das passiert wohl öfter Aktuelle Entwicklungstrends bei Postfix

18 Detaillierteres Logging Beispiel II... delay=3.4, delays=2.8/0.05/0/0.56, dsn=2.6.0, status=sent ( Ok, id= , from MTA([ ]:10026): Ok: queued as AEC B) delay=3.4, delays=2.8/0.05/0/0.56 am längsten dauerte die Übertragung (Zeit vor dem qmgr, einschließlich der Übertragungszeit) Aktuelle Entwicklungstrends bei Postfix

19 Absenderabhängiger relayhost Absenderabhängiger relayhost Für den Heimbenutzer in Abhängigkeit der Absenderadresse wählt Postfix den passenden relayhost sowie die dazugehörigen SMTP-AUTH Benutrzer und Passwort: sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay smtp_sasl_password_maps = hash:/etc/postfix/smtp_passwords smtp_sender_dependent_authentication = yes Aktuelle Entwicklungstrends bei Postfix

20 Absenderabhängiger relayhost Beispiel: Absenderabhängiger relayhost /etc/postfix/sender_relay enthält: smtp.gmx.de smtp.web.de und in /etc/postfix/smtp_passwords: ralf:ralfpass constanze:constanzepass Aktuelle Entwicklungstrends bei Postfix

21 Absenderabhängiger relayhost Aber Vorsicht! Dies deaktiviert natürlich das Connection Caching im smtp-client! Aktuelle Entwicklungstrends bei Postfix

22 Gemeinsamer Code für LMTP- und SMTP-Clients Gemeinsamer Code für LMTP- und SMTP-Clients Der smtp-client implementiert nun sowohl das (E)SMTP- als auch das LMTP-Protokoll. Dadurch werden viele lmtp_*-parameter eingeführt, die zuvor nur aus dem smtp_*-kontext bekannt waren. Aktuelle Entwicklungstrends bei Postfix

23 Mehr Plugins Every ten years I do... Wietse will nicht ewig an Postfix arbeiten: Every ten years I do something completely different Daher werden jetzt zahlreiche plugin -Möglichkeiten innerhalb von Postfix geschaffen. Aktuelle Entwicklungstrends bei Postfix

24 Mehr Plugins... something completely different Aktuelle Entwicklungstrends bei Postfix

25 Mehr Plugins Authentifizierungs-Plugins Unterstützung unterschiedlicher Authentifizierungs-Frameworks im kombinierten (s l)mtp-client und smtpd-server Cyrus-SASL Dovecot-SASL (vielleicht) Peter Bieringers simple-auth Cyrus-SASL problematisch: keine Doku, niemand versteht es... Aktuelle Entwicklungstrends bei Postfix

26 Verfeinerung der TLS-Unterstützung Lutz Jaenickes Patch hatte kleinere Fehler, die ausgemerzt wurden neuer per-site TLS policy-mechanismus, der besser gegen DNS-Spoofing Attacken schützt Generell: viele Verbesserungen bei TLS Aktuelle Entwicklungstrends bei Postfix

27 Verfeinerung der TLS-Unterstützung Begrenzung der Anzahl von neuen TLS Sitzungen pro Zeiteinheit Die TLS-Handshakes sind sehr CPU-intensiv. Das neue Limit smtpd_client_new_tls_session_rate_limit (standardmäßig deaktiviert) begrenzt die Anzahl von neuen (d.h. ungecachten) TLS Sitzungen. Aktuelle Entwicklungstrends bei Postfix

28 Strikte Prüfung der Daemonen-Privilegien Daemonen die keine root-rechte brauchen können nun nicht mehr als privileged gestartet werden sie müssen in der master.cf als unprivileged eingetragen sein kosequente Forcierung von least privilege Aktuelle Entwicklungstrends bei Postfix

29 Beibehaltung der Groß-/Kleinschreibung bei Rewriting Beibehaltung der Groß-/Kleinschreibung bei Rewriting Postfix behält die Groß-/Kleinschreibung bei, wenn Adressen mittels canonical, virtual, relocated und generic Maps umgeschrieben werden sogar wenn $zahl-ersetzungen durch reguläre Ausdrücke vorgenommen werden (pcre und regexp) local(8) und virtual(8) wandeln in Kleinschreibung um! Aktuelle Entwicklungstrends bei Postfix

30 Nicht-antike Versionen von Postfix können die Entscheidung über die Annahme einer Mail an ein externes Programm delegieren: Postfix übermittelt einen Satz von Metadaten an das externe Programm Diese Metadaten bestehen aus den Informationen, die Postfix bis zum Eintritt in die DATA-Sektion des SMTP-Dialogs gesammelt hat Aktuelle Entwicklungstrends bei Postfix

31 Was ist eine (SMTP-)Policy? Was ist eine (SMTP-)Policy? Während der SMTP Sitzung muß Postfix entscheiden, was mit der Mail passieren soll: abweisen temporär abweisen annehmen (und später bouncen?) delegieren: Soll sich doch jemand anders Sorgen machen! Aktuelle Entwicklungstrends bei Postfix

32 Aktuelle Entwicklungstrends bei Postfix Was ist eine (SMTP-)Policy? Was soll ich mir Sorgen machen? Aktuelle Entwicklungstrends bei Postfix

33 Die policy-delegierung im Allgemeinen Die policy-delegierung im Allgemeinen Seit Version 2.1 hat Postfixs smtpd die Möglichkeit der policy-delegierung an externe Programme. Warum externe Programme? Aktuelle Entwicklungstrends bei Postfix

34 Die policy-delegierung im Allgemeinen Gründe Komplexität der Implementierung und Konfiguration Mail::SPF::Query sind 64kB Perl lange und komplexe Algorithmen Sicherheit Komplexität ist der Feind der Sicherheit keine Abhängigkeit von Postfix von externen Bibliotheken Strikte Trennung von Postfix und Entscheider Hohe Flexibilität Perl, Python, VisualBasic, brainfuck,... Entscheidung auf entferntem Server Performance kann immernoch gut sein Der Server kann mit Postfix auf derselben Maschine laufen Postfix kann via TCP- oder Unix-Domain-Sockets mit dem Server kommunizieren Aktuelle Entwicklungstrends bei Postfix

35 Implementierung Das policy-protokoll Der Client (Postfix) sender eine Folge von name=wert Paaren, getrennt durch newlines und terminiert mit einer Leerzeile. Der Server (das externe Programm) antwortet mit einem name=wert Paar, ebenfalls terminiert mit einer Leerzeile. Protokolle können so einfach sein... Aktuelle Entwicklungstrends bei Postfix

36 Implementierung Konkret: Der Client I Postfix version 2.1 und neuer übermitteln: request=smtpd_access_policy protocol_state=rcpt protocol_name=smtp helo_name=some.domain.tld queue_id=8045f2ab23 sender=foo@bar.tld recipient=bar@foo.tld recipient_count=0 client_address= client_name=another.domain.tld reverse_client_name=another.domain.tld instance= <Leerzeile> Aktuelle Entwicklungstrends bei Postfix

37 Implementierung Konkret: Der Client II Postfix version 2.2 und neuer übermitteln zusätzlich: sasl_method=plain sasl_username=you sasl_sender= size=12345 ccert_subject=solaris9.porcupine.org ccert_issuer=wietse Venema ccert_fingerprint=c2:9d:f4:87:71:73:73:d9:18:e7:c2:f3:c1:da:6e:04 Aktuelle Entwicklungstrends bei Postfix

38 Implementierung Konkret: Der Client III Postfix version 2.3 und neuer übermitteln noch mehr: encryption_protocol=tlsv1/sslv3 encryption_cipher=dhe-rsa-aes256-sha encryption_keysize=256 Aktuelle Entwicklungstrends bei Postfix

39 Implementierung Konkret: Der Server Der Server (unser externes Programm) anwortet: action=defer_if_permit Greylisted <Leerzeile> Der Server kann mit jeder Aktion antworten, die in access(5) aufgeführt ist. Aktuelle Entwicklungstrends bei Postfix

40 Implementierung Konkret: Mögliche Antworten OK Number (wie OK) 4xx Text (temporärer Fehler) 5xx Text (permanenter Fehler) REJECT Optionaler Text (permanenter Fehler) DEFER_IF_REJECT optionaler Text DEFER_IF_PERMIT optionaler Text restriction (diese Restriktion oder Restriction Class ausführen) DISCARD optionaler Text DUNNO FILTER transport:nexthop HOLD optionaler Text PREPEND Headername: Headerwert REDIRECT WARN optionaler Text Aktuelle Entwicklungstrends bei Postfix

41 Implementierung Konkret: Und was ist im Fehlerfall? Das externe Programm darf Postfix nicht über Fehler informieren! Stattdessen: Warnung loggen, Verbindung abbrechen! Postfix gibt dem Client dann eine generische, temporäre Fehlermeldung zurück. Beim nächstenmal gehts sicher besser... Aktuelle Entwicklungstrends bei Postfix

42 policy Delegierung: Greylisting policy Delegierung: Greylisting RFC-konforme MTAs behalten eine Mail nach einem temp. Fehler in der Queue und versuchen es später nocheinmal. Policy: Mail beim ersten Mal mit temporärem Fehler abweisen! Echte MTAs probieren es mind. ein zweitesmal Spambots haben (noch?) keine Queue, sie versuchen es nicht nocheinmal Aktuelle Entwicklungstrends bei Postfix

43 policy Delegierung: Greylisting Was kommt von Postfix? Postfix liefert u.a.: IP Adresse des Client Envelope Sender Envelope Recipient Aktuelle Entwicklungstrends bei Postfix

44 policy Delegierung: Greylisting Die Policy Wir wollen die folgende Policy: Tripel aus IP Addresse, envelope sender und envelope recipient unbekannt: mit temp. Fehler abweisen sonst: annehmen Postfix kann das nicht von sich aus, hier kommt die Policy-Delegierung ins Spiel. Aktuelle Entwicklungstrends bei Postfix

45 policy Delegierung: Greylisting Konfigurationsbeispiel Postfixs main.cf: smtpd_recipient_restrictions =... check_policy_service inet: :9998 check_policy_service unix:/some/where/policy check_policy_service unix:private/policy Aktuelle Entwicklungstrends bei Postfix

46 policy Delegierung: Greylisting Ein Beispiel von Postfix ohne policy Delegierung smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/client_access reject_unauth_destination Aktuelle Entwicklungstrends bei Postfix

47 policy Delegierung: Greylisting Ein Beispiel von Postfix mit policy Delegierung smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/client_access reject_unauth_destination check_policy_service inet: :10023 Aktuelle Entwicklungstrends bei Postfix

48 Fertige Daemonen Fertige Daemonen Michael Tokarev hat ein Rohgerüst für einen Policy-Server in Perl geschrieben: Aktuelle Entwicklungstrends bei Postfix

49 Fertige Daemonen Fertige Daemonen II postgrey greylisting daemon von David Schweikert gld greylisting daemon von Salim Gasmi SPF Policy Server von Meng Weng Wong Aktuelle Entwicklungstrends bei Postfix

50 Fertige Daemonen Fertige Daemonen III policy weight von Norbert Felber Wie SpamAssassin, gewichtet RBLs, RHSBLs und HELO, nutzt aber natürlich nicht den Inhalt der Mail Policyd von Cami C, Greylisting, Sender(Envelope, SASL oder Host/IP)-basiertes Throttling (nach Anzahl und/oder Volumen pro Zeiteinheit), Ratelimiting nach Empfänger, Überwachung von Spamtraps, Blacklisting, HELO Auto Blacklisting und HELO Randomization Preventation. Aktuelle Entwicklungstrends bei Postfix

51 Fertige Daemonen Fertige Daemonen IV Abbildung: Mailgraph in der Charité Aktuelle Entwicklungstrends bei Postfix