Postfix Policy Daemons im Eigenbau. Sinn und Implementation.

Transkript

1 im Eigenbau. Sinn und Implementation. 2. Mailserver-Konferenz Magdeburg, 20. Mai 2005

2 Über die ISG.EE IT Support Gruppe an der ETH Zürich 15 Mitarbeiter Alle unsere Tools sind GPL

3 Über mich Arbeite seit 5 Jahren bei der ISG.EE Administration von Mail-Servers (unter anderem) Open-Source Projekte: Mailgraph, Postgrey, Gedafe, ISGTC, Perl-Module

4 im Eigenbau 1 Die Schnittstelle Was ist eine SMTP-Policy? Beispiel SMTP-Policies Motivation für ein externer Prozess Das Protokoll Konfiguration in Postfix 2 Implementation Implementation mit spawn Implementation als einzelne Prozess Datenbanken Testen Typische Fallen 3 Fragen und Diskussion

5 Was ist eine SMTP-Policy? Was ist eine SMTP-Policy? Entscheiden beim Mail-Verkehrseingang (SMTP-Protokoll), was mit einer gemacht werden soll: Zurückweisen mit einem definitiven Fehler Zurückweisen mit einem temporären Fehler Mail akzeptieren (kann später noch bouncen ) Kein Entscheid: weitere Policy-Regeln überprüfen Postfix: smtpd_xxx_restrictions

6 Was ist eine SMTP-Policy? Beispiel SMTP-Session 220 example.com ESMTP Postfix HELO ee.ethz.ch 250 example.com MAIL FROM: 250 Ok RCPT TO: 451 Greylisted for 300 seconds QUIT

7 Beispiel SMTP-Policies Policy-Beispiel: Relaying nur für lokale Clients Nur lokale Clients dürfen Mails schicken, die an Dritte weitergeleitet werden sollen. Input aus dem Mail-System: IP-Adresse der Mail-Client Policy: Bekannte Adresse? ACCEPT

8 Beispiel SMTP-Policies smtpd_recipient_restrictions In Postfix sind Policies mit smtpd_xxx_restrictions konfiguriert: smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_unlisted_recipient permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/client_access reject_unauth_destination

9 Beispiel SMTP-Policies Policy-Beispiel: SPF Bekämpfung von Fälschungen der Absender-Adresse: Darf dieser Mail-Client, Mails mit dieser Absender-Mail-Domain zu verschicken? Input aus dem Mail-System: Mail-Domain der Absender ( Envelope Sender ) IP-Adresse der Mail-Client Policy: Aus der DNS (SPF TXT-Einträge): erlaubte Mail-Clients für diese Mail-Domain Mail-Client nicht in der Liste? REJECT Ist mit den eingebauten Restrictions von Postfix nicht möglich.

10 Beispiel SMTP-Policies Policy-Beispiel: Greylisting Echte Mail-Servers reagieren auf temporäre Fehler indem sie später erneut Versuch die Mail zu versenden. Idee: einen temporären Fehler beim ersten Versuch erzeugen. Spammers haben keine echten Mailserver und kommen daher nicht wieder. Input aus dem Mail-System: IP-Adresse der Mail-Client Absender Adresse Empfänger Adresse Policy: Triplet neu? DEFER Nicht möglich mit den eingebauten Restrictions von Postfix.

11 Beispiel SMTP-Policies

12 Motivation für ein externer Prozess Geschichte Juni 2003: Greylisting-Paper von Evan Harris Juli 2003: SPF-Talk von Meng Weng Wong Juli 2003: Ankündigung von Wietse Venema: SMTPD Policy Delegation

13 Motivation für ein externer Prozess Warum ein externer Prozess? Hohe Komplexität (Implementation und Konfiguration) (Mail::SPF::Query ist 64KB Perl-Code) Sicherheit: Keine Abhängigkeit zu externen Libraries Hohe Flexibilität verlangt Policy-Entscheide können an einen anderen Server delegiert werden Performance kann trotzdem gut sein

14 Motivation für ein externer Prozess Anwendungsbeispiele für Policy-Daemons Authentisierung Anti-SPAM Nicht geeignet Authentisierung der eigenen Clients SPF Greylisting Spam-Trap Blacklisting Caller-ID / Sender-ID Content-Filter Outbound-Policy (z.b. SPF/SRS)

15 Das Protokoll Das Protokoll: Postfix Daemon request=smtpd_access_policy protocol_state=rcpt protocol_name=smtp helo_name=some.domain.tld queue_id=8045f2ab23 client_address= client_name=another.domain.tld instance= sasl_method=plain sasl_username=you sasl_sender= size=12345 [leere Zeile]

16 Das Protokoll Das Protokoll: Daemon Postfix action=defer_if_permit Greylisted [leere Zeile]

17 Das Protokoll Mögliche Antworten (aus accept(5)): OK all-numerical (wie OK) 4NN text (temporäre Fehler) 5NN text (definitive Fehler) REJECT optional text DEFER_IF_REJECT optional text DEFER_IF_PERMIT optional text

18 Das Protokoll Mögliche Antworten (aus accept(5)): restriction (entsprechende restriction applizieren) DISCARD optional text DUNNO FILTER transport:destination HOLD optional text PREPEND headername: headervalue REDIRECT WARN optional text

19 Konfiguration in Postfix Konfiguration in Postfix smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_unlisted_recipient permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/client_access reject_unauth_destination check_policy_service inet: :10023

20 Implementation mit spawn Implementation mit spawn Postfix-Äquivalent zu inetd Wrapper für Programmen, die mit stdin/stdout arbeiten Prozesse werden nach Bedarf gestartet (parallel) Prozesse nach maximal 100 (max_use) Anfragen terminiert

21 Implementation mit spawn Implementation mit spawn: master.cf # service type priv unpri chroot wakeup maxproc command :10023 inet - n n - - spawn user=nobody argv=/some/where/policy-server

22 Implementation mit spawn Implementation mit spawn: Hauptschleife while (<STDIN>) { if (/(.*?)=(.*)\n/) { $attr{$1} = $2; } elsif ($_ eq "\n") { fatal_exit "unrecognized request type" unless $attr{request} eq "smtpd_access_policy"; $action = smtpd_access_policy(\%attr); print STDOUT "action=$action\n\n"; %attr = (); } } (aus Postfix s greylist.pl, vereinfacht)

23 Implementation mit spawn Implementation mit spawn: Vor-/Nachteile Vorteile: Sehr einfache Implementation Ideale Integration in Postfix Überwachung durch Postfix Nachteile: Muss schnell starten Viele unabhängige Prozesse Schwierigkeit bei gemeinsame Daten (greylist.pl ist nicht zuverlässig)

24 Implementation als einzelne Prozess Implementation als einzelne Prozess Wie kann man das Locking Problem lösen? Nur ein Prozess Mehrere Clients Select-loop Schwierigkeit: nur Ausschnitte vom gesamten Verkehr Man muss zuerst den vollständigen Request zusammenbauen

25 Implementation als einzelne Prozess Implementation als einzelne Prozess: Vor-/Nachteile Vorteile: Schnell unabhängig der Startup-Zeit Kein Locking Nachteile: Skaliert nicht auf mehrere CPU Programmierung nicht ganz trivial

26 Implementation als einzelne Prozess Implementation als einzelne Prozess Die Implementation mit select ist komplex Abhilfe schafft Net::Server

27 Implementation als einzelne Prozess Implementation mit Net::Server Prozess-Modell ist wählbar und austauschbar: Inetd/spawn Single Multiplexing (einzelne Prozess mit select) Forking, Pre-Forking Optionen Logging Daemonifizierung Zugriffskontrolle (allow/deny) Signal-Handlung (inklusive HUP)

28 Implementation als einzelne Prozess Implementation mit Net::Server Prozess-Modell wählen Applikation als Subklasse schreiben $self->process_request und andere benötigte Prozeduren nach Bedarf überschreiben

29 Implementation als einzelne Prozess Implementation mit Net::Server::Multiplex $self->mux_input statt process_request Input konsumieren Wenn Input reicht, Request behandeln sub mux_input() { my ($self, $mux, $fh, $in_ref) while ($$in_ref =~ s/^([^\r\n]*)\r?\n//) { next unless defined $1; my $in = $1; # etwas mit $in tun } }

30 Datenbanken Datenbanken-Wahl Welche Datenbank ist am besten geeignet? Welche Vor- und Nachteile?

31 Datenbanken Datenbanken: Text-Dateien Vorteile: Einfach zu debuggen / auswerten Nachteile: Performance Random access (read/write) schwierig Locking muss selber gemacht werden

32 Datenbanken Datenbanken: Persistente Objekte Zum Beispiel mit Perl s Storable... Vorteile: Einfache Programmierung Nachteile: Alles im Memory! Nur ein globales Lock Keine Transactions / Recovery Prozedur

33 Datenbanken Datenbanken: Berkeley-DB Vorteile: Performance Angenehm für Key/Value (tie im Perl) Transactions und Recovery Locking Nachteile: Locking ist etwas komplex (Deadlock detection) Nur Key/Value-Modell Postgrey: Die CPU ist mit eingehende Mails pro Tag 0.2% ausgelastet (1.2 Ghz UltraSparc IIIi)

34 Datenbanken Datenbanken: SQLite Vorteile: Performance Public Domain! Flexibilität und Features von SQL Locking Nachteile: DBD ist schwieriger als tie Globales Lock (mit nicht zu häufige COMMITs aber trotzdem sehr schnell) Meine Empfehlung ausser es gibt spezielle Bedürfnisse

35 Datenbanken Datenbanken: MySQL / PostgreSQL Vorteile: Performance Flexibilität und Features von SQL Locking Client-Server Nachteile: Installation Komplexität des gesamten Systems

36 Testen Testen Von Hand telnet localhost Copy/Paste einer Policy-Request Mit XCLIENT Fälschung von Eckdaten einer SMTP-Session Client muss freigeschaltet werten: smtpd_authorized_xclient_hosts = localhost

37 Testen Testen telnet localhost 25 Trying Connected to localhost. Escape character is ^]. 220 smtp.ee.ethz.ch ESMTP Postfix XCLIENT NAME=test.example.com ADDR= Ok MAIL 250 Ok RCPT 450 Recipient address rejected: Greylisted

38 Typische Fallen Falle: Mails mit mehrere Empfänger Postgrey fügt einen Header ein, falls es ein Delay verursacht hat Mehrere Empfänger mehrere Header Lösung: Mit instance die Requests korrelieren und nur einmal den Header einfügen

39 Typische Fallen Falle: Crash des Daemon Postgrey: Crash wenn %n in der Absender-Adresse vorkommt Ursache: indirekt syslog (wie printf) wie ein puts gebraucht Konsequenz: 450 Server configuration problem Denial-of-Service!

40 Zusammenfassung Zusammenfassung Sehr mächtig für spezielle Anwendungen. Kein Content-Filter! Aufpassen, wie es in Postfix konfiguriert wird Implementation muss robust sein: das ganze Mail-System hängt davon ab Net::Server und SQLite sind nützlich bei der Programmierung

41 Fragen?