© AlexGrue, Fotolia.com

Es wäre doch praktisch, unerwünschte E-Mails direkt beim Einliefern abzuweisen, ohne sie erst rechenintensiv zu durchleuchten. Das haben sich auch die Entwickler von Postfix gedacht und ihrem Server in Version 2.8 Postscreen spendiert. Das Modul filtert und sortiert aus, ohne den Inhalt der Mails anzuschauen.

Einen sehr großen Teil des heutigen Spam verschicken gekaperte Windows-Rechner, auf denen sich Schadsoftware eingenistet hat. Ohne Zutun und Wissen der Nutzer versenden die Spambots oder Zombies genannten Maschinen eine Flut unerwünschter Werbe-Nachrichten. Experten von Symantec haben ermittelt, dass 95 Prozent des weltweiten Spam-Aufkommens aus Botnetzen kommt – Tendenz steigend [1].

Ein Türsteher für Postfix

Auch die Postifx-Entwickler um Mastermind Wietse Venema haben die Zeichen der Zeit erkannt: Der Kampf gegen Spam mutiert zunehmend zu einem gegen Zombies (Abbildung 1, [2]). In der neuen Postfix-Version 2.8 [3] erhalten Admins jetzt mit Postscreen einen intelligenten Türsteher, der Nachrichten von Spambots einfach und zuverlässig erkennt und aussortiert. Herkömmliche Spamfilter wie das populäre Spamassassin greifen dagegen erst viel später in die Verarbeitung der Nachrichten ein.

Abbildung 1: Postfix-Entwickler Wietse Venema erklärt in einer IBM-Präsentation, wie die Zombie-Angriffe den Mailserver an der Arbeit hindern. 95 Prozent des Spam kommen aus Botnetzen.

Zu diesem Zeitpunkt haben die unerwünschten Nachrichten bereits wertvolle Systemressourcen verbraucht, denn die Volltextanalyse aller Mails, wie sie Spamassassin vornimmt, ist sehr rechenintensiv. Am Ende verbringt ein Mailserver mehr Zeit damit, unerwünschte Nachrichten nicht zuzustellen, als damit, legitime Post zu ihren Empfängern zu transportieren. Zudem erreichen viele Filter ihre volle Leistungsfähigkeit erst, wenn der Admin sie mit einer ausreichend großen Anzahl unerwünschter Nachrichten trainiert hat. Postscreen hingegen versucht Spambots und Zombies schon anhand einer einzigen gesendeten Nachricht zu erkennen.

Ab und zu ist das Ziel der Angreifer auch gar nicht das Versenden von Spam, sondern das Auslösen eines Denial of Service: In der Standardkonfiguration lässt Postfix maximal 100 Instanzen des SMTP-Daemon »smtpd« zu. Da jede davon immer genau eine Mail verarbeiten kann, ist die Anzahl gleichzeitiger Verbindungen ebenfalls auf 100 beschränkt. Weitere Anfragen weist der Server ab. Gemäß RFC 5321 [4] muss ein Client dann fünf Minuten warten, bevor ihn der Server wieder bedient. Selbst wenn der Administrator die maximale Anzahl der Smtpd-Instanzen erhöht, können Angreifer einen Server dauerhaft blockieren.

Lauert aber Postscreen vor dem Smtpd, lauscht Letzterer nur noch auf dem Submission-Port 587, während Postscreen auf Port 25 eingehende Nachrichten annimmt und via Submission an Smtpd übergibt. Auch mit Postscreen ist eine Denial-of-Service-Attacke zwar prinzipiell nicht ausgeschlossen, aber sie lässt sich mit wesentlich weniger Ressourcen abwehren, da eine einzige Instanz von Postscreen viele eingehende SMTP-Verbindungen gleichzeitig verarbeiten kann. Es bleiben also mehr Smtpd-Prozesse übrig, die ihrer eigentlichen Aufgabe nachkommen können.

Am besten immer schön der Reihe nach

Ziel von Postscreen ist es, Spam so früh und so einfach wie möglich auszusortieren. Das heißt, die Filterung sollte am Anfang des Prozesses stehen, die Tests geraten erst stufenweise aufwändiger: Zuerst führt das Programm die einfachen und schnellen Tests aus, erst später die aufwändigen und rechenintensiven. Jeder Schritt hilft so, das Spam-Aufkommen zu reduzieren. Im ersten Schritt fragt Postscreen Listen schlechter und guter Clients ab, so genannte Black- und Whitelists. Anschließend findet eine Prüfung auf Verletzungen des SMTP-Protokolls statt, die typisch für Zombies und Spambots sind. Im dritten Schritt kann der Admin noch tiefer gehende Protokolltests aktivieren. Trotzdem zählt Postscreen nicht zu den Mailfiltern im eigentlichen Sinne, denn es ignoriert den Inhalt der Nachrichten komplett.

Schwarze und weiße Listen

Die erste Liste, die Postscreen abfragt, ist statisch, der Parameter »postscreen_access_list« in der Postfix-Konfiguration definiert sie. Vorgabe ist »permit_mynetworks« , das sind alle vertrauenswürdigen Adressen aus »mynetworks« , die sich der Administrator auch mit dem Befehl »postconf -d mynetworks« ausgeben lassen darf. Für eine weiße Liste mit “guten” Adressen ist also gesorgt.

Aber um sich weitere Tests zu ersparen und Nachrichten direkt abzuweisen, benötigt der Administrator auch eine schwarze Liste. Er legt diese Blacklist am besten im CIDR-Format [5] an und pflegt anschließend Adressen ein, die ihm als störende Spamschleudern auffallen. Hier hat der Admin die Reihenfolge der Regeln zu beachten. Steht in »/etc/postfix/postscreen_access.cidr«

192.168.100.101 permit 192.168.100.0/16 reject

dann blockiert der Server alle IP-Adressen aus dem Netzwerk 192.168.100.0 mit Ausnahme von 192.168.100.101. Der Eintrag

postscreen_access_list = permit_mynetworks,? cidr:/etc/postfix/postscreen_access.cidr

in der Datei »/etc/postfix/main.cf« schaltet die Liste aktiv.

Dynamisches Blacklisting ohne Zutun des Admin

Neben den statischen Listen legt Postscreen automatisch dynamische Black- und Whitelists an. Sie bilden einen intelligenten Cache: Ein Rechner, der einmal als Bot eingestuft ist, landet auf der dynamischen Blacklist. Absolviert ein Client hingegen alle Tests erfolgreich, trägt der Server dessen Adresse in die dynamische Whitelist ein und gibt seine Mail beim nächsten Mal sofort an den »smtpd« weiter.

Als dritte Art von Listen gibt es dynamische, im Internet gepflegte Listen [6]. Die heißen DNS-based Blackhole List (DNSBL) oder Realtime Blackhole List (RBL) und fungieren als eine Art kollektives Gedächtnis: Darauf spezialisierte Mailserver-Betreiber melden auf ihnen als schlecht erkannten IP-Adressen. Bekannte Vertreter sind etwa Spamhaus.org und Spamcop.net.

Die gewünschten Listen aktiviert der Administrator mit dem Parameter »postscreen_dnsbl_sites« . Listen sind durch ein Leerzeichen getrennt und können unterschiedlich gewichtet sein. Die Wertungen der Blacklists addieren sich, Punkte von Whitelists zieht die Antispam-Logik vom Score ab. Erst wenn der Punktestand nach allen Listen zusammen den mit »postscreen_dnsbl_threshold« definierten Schwellenwert erreicht, stuft Postscreen eine IP-Adresse als Absender von Spam ein:

postscreen_dnsbl_threshold = 3 postscreen_dnsbl_sites = zen.spamhaus.org*2, bl.spamcop.net*1,

Der Code zeigt zwei DNSBL-Anbieter mit unterschiedlicher Gewichtung in der Postfix-Konfiguration in »/etc/postfix/main.cf« . Erst wenn beide eine Adresse übereinstimmend als Spammer identifizieren, ist der Schwellenwert erreicht und der Absender landet auf der Blacklist.

Wie beim Telefonieren

Das SMTP-Protokoll erinnert bisweilen an ein Telefongespräch. Der Sender ruft an und der angerufene Server meldet sich mit seinem Namen. Listing 1 zeigt einen typischen SMTP-Dialog. Die Meldungen des Servers beginnen immer mit einer Zahl, dem Statuscode. Er signalisiert dem Client, dass der Server seine Eingabe erfolgreich bearbeitet hat.

01 220 mail.examplet.net ESMTP Postfix 02 HELO client.example.net 03 250 mail.example.net 04 client MAIL FROM: joerg@example.net 05 250 OK 06 RCPT TO: sabine@example.net 07 250 OK 08 DATA 09 354 End data with <CR><LF>.<CR><LF> 10 From: Joerg Mustermann <joerg@example.net> 11 To: Sabine Musterfrau <sabine@example.net> 12 Subject: HDL 13 14 Hallo Lausemädchen, 15 wir sehen uns nachher. 16 . 17 250 OK: queued as E82C21839B9 18 QUIT 19 221 Bye

Spambots haben es jedoch eiliger als gewöhnliche Mailclients, es dauert oft weniger als 1,5 Stunden – und schon landen sie auf einer DNS-Blacklist. Also versuchen sie in möglichst kurzer Zeit möglichst viele Nachrichten zu versenden. Aus diesem Grund warten die meisten Bots nicht ab, bis der Server sie begrüßt, sondern versuchen ihre Nachrichten sofort absetzen.

Verzögerungstaktik

Genau dieses Verhalten will Postscreen provozieren. Mit dem Parameter »postscreen_greet_wait« kann der Administrator festlegen, wie lange Postscreen warten soll, bevor es den Statuscode 220 sendet. Auch wenn die Bots unter Zeitdruck stehen, sollte der Wert nicht zu hoch sein, um nicht versehentlich erwünschte Nachrichten auszuschließen. Zum Glück hilft auch die erwähnte statische Whitelist beim Unterscheiden.

Mit »postscreen_greet_banner« lässt sich zudem ein Text festlegen, der bereits vor dem Statuscode 220 gesendet wird. In der Regel meldet sich der SMTP-Server mit dem Statuscode 220 und seinem Hostnamen, beispielsweise »220 mail.example.net« , und ein Client, der sauber implementiertes SMTP spricht, wartet geduldig mit seinem »HELO« . Spambots hingegen lassen sich sehr oft von einem zusätzlichen Text verwirren und zu einem vorzeitigen »HELO« überreden. Spätestens wenn der Server beispielsweise »220-mail.example.net« (kein Statuscode, da ohne Leerzeichen) sendet, verraten sich die meisten Spambots.

Während der Entwicklung von Postscreen hat Entwickler Ralf Hildebrandt [7] das Programm bereits auf [mail.charite.de] eingesetzt: Rund 60 Prozent aller Bots grüßten zu früh, nur 8 Prozent davon befanden sich nicht auf DNS-Blacklists. Eine später durchgeführte Messung für [mail.python.org] fiel noch deutlicher aus: Sieben von zehn Bots betreiben Pregreeting und nur ein Prozent davon war nicht blacklisted.

Das zeigt, welches Potenzial in diesem Abtesten steckt. Selbst wenn der Administrator keinerlei DNS-Blacklists aktiviert und nur die Einhaltung des SMTP-Protokolls prüft, kann er schon einen beträchtlichen Teil des Nachrichtenaufkommens aussortieren.

Tests und Aktionen für eingehende E-Mails

Selbstverständlich gibt es noch weitere Tests, die der Server nach der Begrüßung veranstalten kann:

• Bare Newline sendet nur unvollständige Zeilenenden.
• Command Pipelining enttarnt Spambots, die nicht die Antwort des Servers abwarten.
• Non-SMTP Command erkennt Bots, die offene Proxyserver tunneln.

Diese Tests sind normalerweise deaktiviert, die Parameter »postscreen_bare_newline_enable« , »postscreen_pipelining _enable« beziehungsweise »postscreen_non_smtp_command_enable« aktivieren sie. Ihr Nutzen ist jedoch begrenzt. Nur wenige Zombies versagen beispielsweise beim Bare-Newline-Test und selbst ein Client, der ihn erfolgreich besteht, muss sich danach neu mit dem Smtpd verbinden.

Wichtiger als solche Tests sind die Aktionen, die Postscreen nach einem Test ausführt. Wenn nicht ausdrücklich anders definiert, loggt Postscreen nur die Ergebnisse. Das gibt dem Administrator die Möglichkeit, in Ruhe einzelne Einstellungen auszuprobieren, bevor er die Filter scharf schaltet. Die Aktionen kennen folgende Werte:

• »ignore« ignoriert das Testergebnis und führt weitere Tests aus.
• »drop« beendet die Verbindung sofort mit Status 521 (Does not accept mail).
• »enforce« wartet weitere Tests ab und antwortet solange mit Statuscode 550 (Mailbox unavailable).

Die Aktionen zu den eben erläuterten Filtern selbst lauten:

• »postscreen_blacklist_action« : Die Aktion für statische Zugriffslisten. Vorgabe ist »ignore« .
• »postscreen_dnsbl_action« : Aktion für DNS-Blacklists. Vorgabe ist »ignore« .
• »postscreen_greet_action« : Aktion bei Pregreeting. Vorgabe ist »ignore« .
• »postscreen_bare_newline_action« : Aktion für den Bare-Newline-Test. Vorgabe ist »ignore« .
• »postscreen_pipelining_action« : Aktion den Command-Pipelining-Test. Vorgabe ist »enforce« .
• »postscreen_non_smtp_command_action« : Aktion für den Non-SMTP-Command-Test. Vorgabe ist »drop« .

Solange die Tests nicht zu einem eindeutigen Ergebnis führen, also der Client weder auf der schwarzen noch auf der weißen Liste landet, führt Postfix sie bei der nächsten Verbindung desselben Clients wieder aus.

Umstieg auf Postscreen

Wer Postscreen statt des Smtpd die E-Mails annehmen lassen will, schreibt »/etc/postfix/master.cf« um (Abbildung 2). Aus dem Standardeintrag

Abbildung 2: Ein SMTP-Port für die internen Nutzer, eine Adresse für Postscreen – das regelt der Admin in der Datei »/etc/postfix/master.cf«.

smtp inet n - n - - smtpd -o Parameter

wird jetzt:

smtpd pass - - n - - smtpd -o Parameter smtp inet n - n - 1 postscreen

Nach einem »postfix reload« nimmt Postscreen die Mails entgegen.

Da Postscreen typischerweise vor Smtpd auf Port 25 lauscht, können Endbenutzer mit ihren Mail User Agents (MUA) nicht mehr über diesen Port Nachrichten versenden, denn Postscreen beherrscht keinerlei Authentifizierung. Auf Port 25 geht nur noch Post von anderen SMTP-Servern ein. Die Nutzer mit ihren Mailclients können aber Postscreen umgehen und direkt über Port 587 oder SSL-verschlüsselt über Port 465 Post beim Smtpd einliefern.

Oft will es der Administrator seinen Nutzern aber weiterhin ermöglichen, Port 25 zu nutzen. Da dieser Port belegt ist, schafft nur eine zweite IP Abhilfe. Auf [mail.example.net] läuft weiterhin Smtpd, und auf einer zweiten IP, etwa [mail-external.example.net], lauscht Postscreen. Wichtig hierbei ist, Postscreen und Smtpd ihre IP ausdrücklich in »master.cf« mitzuteilen, denn sonst versuchen beide sich an jede greifbare Schnittstelle zu binden.

Der Administrator ändert nun noch den MX-Resource-Record für die Domäne auf »mail-external« und wartet ab, bis alle anderen SMTP-Server auf Postscreen umschwenken. Die Nutzer bekommen von der Änderung nichts mit, ihre Einstellungen funktionieren weiterhin – nur erhalten sie weniger Spam. Listing 2 zeigt die vollständige Konfiguration aus den Beispielen in der Datei »main.cf« , Listing 3 den für das beschriebene Szenario relevanten Teil der »master.cf« .

01 # Global Postfix configuration file. This 02 # file lists only a subset of all parameters. 03 # For the syntax, and for a complete 04 # parameter list, see the postconf(5) manual 05 # page (command: "man 5 postconf"). 06 # 07 # LOCAL PATHNAME INFORMATION 08 queue_directory = /var/spool/postfix 09 command_directory = /usr/sbin 10 daemon_directory = /usr/libexec/postfix 11 data_directory = /var/lib/postfix 12 13 # QUEUE AND PROCESS OWNERSHIP 14 mail_owner = postfix 15 16 # INTERNET HOST AND DOMAIN NAMES 17 myhostname = mail.example.net 18 mydomain = example.net 19 20 # RECEIVING MAIL 21 inet_interfaces = all 22 inet_protocols = all 23 mynetworks = 127.0.0.0/8 192.168.13.0/28 24 mydestination = $myhostname, mail-external.example.net, localhost.$mydomain, localhost 25 26 # REJECTING MAIL FOR UNKNOWN LOCAL USERS 27 unknown_local_recipient_reject_code = 550 28 29 # ALIAS DATABASE 30 alias_maps = hash:/etc/aliases 31 alias_database = hash:/etc/aliases 32 33 # JUNK MAIL CONTROLS 34 header_checks = regexp:/etc/postfix/header_checks 35 36 # SHOW SOFTWARE VERSION OR NOT 37 smtpd_banner = $myhostname ESMTP $mail_name 38 39 # DEBUGGING CONTROL 40 debug_peer_level = 2 41 debugger_command = 42 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 43 ddd $daemon_directory/$process_name $process_id & sleep 5 44 45 # INSTALL-TIME CONFIGURATION INFORMATION 46 sendmail_path = /usr/sbin/sendmail.postfix 47 newaliases_path = /usr/bin/newaliases.postfix 48 mailq_path = /usr/bin/mailq.postfix 49 setgid_group = postdrop 50 html_directory = no 51 manpage_directory = /usr/share/man 52 sample_directory = /usr/share/doc/postfix-2.8.3/samples 53 readme_directory = /usr/share/doc/postfix-2.8.3/README_FILES 54 55 #### POSTSCREEN 56 # Statische Listen 57 postscreen_access_list = permit_mynetworks, 58 cidr:/etc/postfix/postscreen_access.cidr 59 postscreen_blacklist_action = drop 60 61 # DNS Blackhole Lists 62 postscreen_dnsbl_threshold = 3 63 postscreen_dnsbl_sites = zen.spamhaus.org*2, 64 bl.spamcop.net*1, 65 postscreen_dnsbl_action = enforce 66 67 # Pregreeting 68 postscreen_greet_banner = $smtpd_banner 69 postscreen_greet_action = enforce 70 71 # Weitere Postscreen-Tests 72 postscreen_bare_newline_enable = no 73 postscreen_non_smtp_command_enable = yes 74 postscreen_non_smtp_command_action = drop 75 postscreen_pipelining_enable = no

01 # 02 # Postfix master process configuration file. For details on the format 03 # of the file, see the master(5) manual page (command: "man 5 master"). 04 # 05 # Do not forget to execute "postfix reload" after editing this file. 06 # 07 # ==================================================================== 08 # service type private unpriv chroot wakeup maxproc command + args 09 # (yes) (yes) (yes) (never) (100) 10 # ==================================================================== 11 192.168.13.20:smtp inet n - n - - smtpd -o myhostname="mail.example.net" 12 178.146.13.20:smtp inet n - n - 1 postscreen -o myhostname="mail-external.example.net" 13 smtpd pass - - n - - smtpd 14 dnsblog unix - - n - 0 dnsblog 15 tlsproxy unix - - n - 0 tlsproxy 16 submission inet n - n - - smtpd 17 -o smtpd_tls_security_level=encrypt 18 -o smtpd_sasl_auth_enable=yes 19 -o smtpd_client_restrictions=permit_sasl_authenticated,reject 20 -o milter_macro_daemon_name=ORIGINATING 21 smtps inet n - n - - smtpd 22 -o smtpd_tls_wrappermode=yes 23 -o smtpd_sasl_auth_enable=yes 24 -o smtpd_client_restrictions=permit_sasl_authenticated,reject 25 -o milter_macro_daemon_name=ORIGINATING 26 #628 inet n - n - - qmqpd 27 pickup fifo n - n 60 1 pickup 28 cleanup unix n - n - 0 cleanup 29 qmgr fifo n - n 300 1 qmgr 30 #qmgr fifo n - n 300 1 oqmgr 31 tlsmgr unix - - n 1000? 1 tlsmgr 32 rewrite unix - - n - - trivial-rewrite 33 bounce unix - - n - 0 bounce 34 defer unix - - n - 0 bounce 35 trace unix - - n - 0 bounce 36 verify unix - - n - 1 verify 37 flush unix n - n 1000? 0 flush 38 proxymap unix - - n - - proxymap 39 proxywrite unix - - n - 1 proxymap 40 smtp unix - - n - - smtp 41 # When relaying mail as backup MX, disable fallback_relay to avoid MX loops 42 relay unix - - n - - smtp 43 -o smtp_fallback_relay= 44 # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 45 showq unix n - n - - showq 46 error unix - - n - - error 47 retry unix - - n - - error 48 discard unix - - n - - discard 49 local unix - n n - - local 50 virtual unix - n n - - virtual 51 lmtp unix - - n - - lmtp 52 anvil unix - - n - 1 anvil 53 scache unix - - n - 1 scache

Fazit

Postscreen vermag einen herkömmlichen Filter zwar nicht völlig zu ersetzen, ergänzt ihn aber sinnvoll, da er ihm einen Großteil der Arbeit abnimmt. Hier verfolgt eine Software wirksam den Ansatz, Spam anhand der Charakteristika von Spambots zu erkennen und nicht einfach nur Absender oder Inhalt zu checken. Wer mehr Informationen dazu sucht, wird in den Manpages fündig ([8] und [9]) oder liest sich in das Postscreen-Howto ein [10].

In der Vergangenheit war der Kampf gegen Spam ein digitales Wettrüsten. Kaum war eine neue Technik zur Spamabwehr entwickelt, änderten die Versender ihre Vorgehensweise. Darum bleibt abzuwarten, ob Postscreen auch langfristig eine so wirksame Verbesserung wie aktuell bringt. Denn auch die Spammer werden sich anpassen, sobald Postscreen weitere Verbreitung findet. Andererseits arbeiten auch die Entwickler um Wietse Venema bereits an neuen Abwehrmechanismen gegen die Spam-Mafia.