Exim gegen Mail-Relaying, Spam und Viren absichern

Das Medium E-Mail bildet zugleich ein Einfallstor für unangenehme Erscheinungen wie Spam und Viren. Schlimm genug, dass sich der Admin der Folgen erwehren muss. Keinesfalls sollte er durch Nachlässigkeit selbst zum Täter werden - eine probate Form der Ignoranz wäre es, den eigenen Mailserver als Open Relay zu betreiben.

Durchfallgefahr

Zum Open Relay wird ein Mailserver, wenn über ihn Mail laufen darf, obwohl er weder für die Empfänger- noch die Absender-Domain zuständig ist (Abbildung 1). Spammer entdecken und missbrauchen offene Mailrelays sehr schnell. Am Ende landet die IP-Adresse des Servers in speziellen Antispam-Datenbanken, den so genannten Realtime Blackhole Lists.

Abbildung 1: So sollte es nicht sein: Über das offene Mailrelay läuft auch Mail, für die der Mailserver weder die Empfänger- noch die Absender-Domain ist.

Viele von Spam geplagte MTAs binden gern solche RBLs ein, mit der Konsequenz, dass sie alle E-Mails des offenen Relay-Servers abweisen. Hat der betroffene Admin den Fehler behoben, kann er nur beten, dass ihn alle RBLs automatisch austragen. Klappt das, vergehen oft bis zu 24 Stunden, bis sein Server wieder salonfähig ist.

MTA richtig konfigurieren

Im Folgenden sei am Beispiel von Exim [http://www.exim.org] erläutert, wie ein MTA sicher gegen Missbrauch gestaltet sein soll. Die Konfiguration in der »/etc/exim.conf« gliedert sich in mehrere Abschnitte (Abbildung 2). Mit Version 4 hat in Exim der Abschnitt ACL Einzug gehalten. Alle sicherheitsrelevanten Einstellungen, die mehrheitlich zuvor im Router-Abschnitt residierten, finden sich jetzt in ACL, mit eigener Syntax und eigenem Regelsatz - Firewallregeln nicht unähnlich. [2]

Abbildung 2: Die Konfigurationsdatei von Exim gliedert sich in Abschnitte. Mit Version 4 hat dort eine ACL-Sektion Einzug gehalten, in deren Unterabschnitten der Admin wiederum das SMTP-Handling regelt und Clam AV und Spamassassin einbindet.

Der ACL-Abschnitt besteht wieder aus Unterabschnitten, die den Ablauf eines SMTP-Dialogs widerspiegeln (siehe auch [http://www.exim.org/exim-html-4.63/doc/html/spec_html/ch07.html#id2545170]). Das Listing 1 zeigt einen SMTP-Dialog ohne SMTP-Authentifizierung, vergleichbar zu dem im Prävention-Artikel Gesagten. Nachdem sich der Absender- mit dem Empfänger-Server verbunden hat, meldet sich der Empfänger mit dem Code »220« und seinem Namen. Daraufhin stellt sich der Absender-Server vor und dann mit »250« der Empfänger nochmals. Nach dieser Einleitung übermittelt der Sender die eigentlichen E-Mail-Daten, zuerst die Envelope-Adresse »MAIL FROM:«, dann die Envelope-Adresse »RCPT TO:«. Beide bestätigt der Empfänger mit »250 ok«.

Mit dem Kommando »DATA« kündigt der Absender die eigentliche Nachricht an. Der Empfänger erkennt das Textende anhand eines Punktes, bestätigt mit »250 Mail delivered« den Empfang und beschließt mit »QUIT« den Dialog. An den einzelnen Stationen des SMTP-Dialogs setzen nun die ACL-Optionen aus Tabelle 1 an, prüfen zum passenden Zeitpunkt die einlaufenden Daten und lösen entsprechende Aktionen aus, siehe Abbildung 3.

Abbildung 3: Der SMTP-Dialog

Um den Server gegen Mail-Relaying abzusichern, genügt meist eine Standardkonfiguration, die die Option »acl_smtp_rcpt« verwendet. Denn von diesem Zeitpunkt ab liegen alle Informationen vor, um die E-Mail zu akzeptieren oder abzuweisen. Eine auf die ACL-Option angesetzte Regel kann dann eine der Aktionen in Tabelle 2 auslösen und so Annahme oder Verweigerung der einlaufenden Mail steuern.