Der Betrieb eines Mailservers wie QMail in einem Netzwerk verlangt ein hohes Maß an Verantwortung gegenüber den eigenen Nutzern, aber auch gegenüber anderen Mail-Admins. Die Aufgabe, den Server abzusichern, ergibt sich folglich bereits aus der Tatsache, dass man ihn überhaupt betreibt.

Ungeschützte Mailserver laden zum Missbrauch ein: So dürfen sich QMail-Neulinge, deren Mail Transfer Agent (MTA) im Auftrag von Spammern unerwünschte Mails verschickt (siehe Kasten “Offenes Relay?”), nicht wundern. Ihr Server verhält sich standardmäßig[1] wie ein offenes Relay – eine ebenso verantwortungslose, möglicherweise sogar jobgefährdende Einstellung.

SMTP, aber nicht für jeden

Die Achillesferse jedes MTA ist der SMTP-Zugang. Darüber liefern die Mailprogramme berechtigter User ihre elektronische Post zur Weiterleitung an die Empfänger ein. Doch deren Mailaufkommen verblasst, sobald Spammer Mails hierüber auf einen Schlag an tausende Benutzer zustellen lassen. Bleibt solchen Schmarotzern der Zugang verwehrt, suchen sie sich üblicherweise andere offene SMTP-Server aus. Wem nicht gefällt, dass das Absichern des eigenen Servers somit dem Sankt-Florians-Prinzip (“0h heiliger Sankt Florian, verschon mein Haus, zünd andre an!”) folgt, konfiguriert seinen Rechner als Teergrube[2], doch führt dies an dieser Stelle zu weit.

Die QMail-eigene Variante der Zugriffsbeschränkung mit Hilfe der Konfigurationsdatei »rcpthosts« deckt zunächst nur ein sehr eingeschränktes Szenario ab: Die Datei nimmt alle Domains auf, für die der Mailserver Mails empfangen soll. Das verhindert das Mailrelaying allerdings nicht nur für die unberechtigten Benutzer, sondern für alle.

Zum Glück lässt sich diese Einschränkung mit Hilfe des Programms »tcpserver« aus dem Paket »ucspi-tcp-0.88.tar.gz« aufheben [1], [3], [4]. Es erlaubt einen Schutz des SMTP-Ports, bei dem nicht die Empfängeradresse den Ausschlag gibt, sondern der Absender. Jedoch darf das Programm »qmail-smtpd«, das am SMTP-Port lauscht, dann nicht mehr wie in[1] gezeigt per »inetd« starten, sondern muss der Obhut der Daemontools (siehe Kasten “Daemontools”) übergeben werden.

Für den »tcpserver« legt man explizit fest, von welchen IP-Adressen der Server weiterzuleitende Mails annimmt. Zu diesem Zweck füllt man zunächst eine Datei (etwa »/etc/tcp.smtp«) mit Leerzeichen-freien Einträgen der Art:

IP-Adresse:allow,RELAYCLIENT=""

Statt » IP-Adresse« dürfen nicht nur einzelne IP-Nummern, sondern auch Bereiche nach dem Muster »192.168.0.« für ein gesamtes Subnetz stehen. Der Eintrag »RELAYCLIENT=””« setzt für jede Verbindung aus diesem Adressbereich eine Umgebungsvariable. Deren leeren Inhalt interpretiert QMail als Erlaubnis zum Relaying. Vergisst man »RELAYCLIENT« zu setzen, bleibt Relaying verboten; nur Mails an die in »rcpthosts« gelisteten Domains sind erlaubt.

Ein Aufruf von »tcprules« aus[4] überführt diese Datei ins »cdb«-Format[11]:

tcprules /etc/tcp.smtp.cdb U /etc/tcp.smtp.tmp < /etc/tcp.smtp

Im Aufruf des »tcpserver« fügt man nun den Parameter »-x /etc/tcp.smtp.cdb« ein; der anschließende Neustart des Daemons aktiviert den Schutz.

Für Road-Warriors

Benutzer mit von Dritten dynamisch zugewiesener IP-Adresse können den Mailserver auf diese Art und Weise jedoch nicht als Smarthost benutzen. Dann bleibt nur übrig, die einliefernden Mailclients aufzufordern, sich zu authentifizieren. Dabei spielen zwei Varianten in der Praxis eine Rolle; keine davon kennt QMail von Haus aus.

SMTP-Auth fordert den Benutzer dazu auf, sich zu authentifizieren, wenn er eine Mail einliefern will. SMTP after POP hingegen gibt ihm ein – konfigurierbares – Zeitfenster (oft 15 Minuten), um seine Mails nach einem authentisierten Zugriff über POP zuzustellen. Bei der Entscheidung für die eine oder andere Methode gilt es zu beachten, dass ältere Mailclients oft noch kein SMTP-Auth unterstützen.

Die SMTP-Auth-Funktionalität lässt sich über das derzeit von Eric M. Johnston gepflegten Patch »qmail-smtpd.c«[5] nachrüsten (Listing 1). Da falsche Zugriffsrechte für das neue Tool »checkpassword« immer wieder für Schwierigkeiten sorgen, werden sie dort präventiv gesetzt. Den »smtp«-Eintrag in der »inetd .conf« ändert man zu

smtp stream tcp nowait qmaild U /usr/sbin/tcpd /var/qmail/bin/tcp-env U /var/qmail/bin/qmail-smtpd U /bin/checkpassword /bin/true

und startet den »inetd« mit »/etc/init.d/inetd restart« neu. Kommen die Daemontools zum Einsatz, hängt man

/bin/checkpassword /bin/true

an den Aufruf von »/var/qmail/bin/qmail-smtpd« an und startet neu.

Zum Testen des SMTP-Auth-Zugangs per Telnet (Listing 2) sind Username und Passwort des Testkontos in Base64-kodierter Form erforderlich. Dazu verhilft das Perl-Modul MIME::Base64 (siehe Kasten “Perl-Module installieren”):

berbig@chekov:~$ perl -e
'use MIME::Base64 qw(encode_base64);
print encode_base64("berbig");'
YmVyYmln

Anschließend kann die Umstellung der Clients beginnen.

Alle Anstrengungen zur Absicherung des Zugangs über Passwörter sind natürlich nutzlos, wenn die Passphrase dem Accountnamen entspricht oder leer, simpel oder leicht zu erraten ist. Eine Passwort-Policy muss die genannten Schritte daher begleiten und unterstützen.

Bitte nach ihnen!

Für SMTP after POP benötigt QMail das Programm »envdir« aus den Daemontools[6] (siehe Kasten “Daemontools”) sowie das Paket »relay-ctrl« von Bruce Guenter[7], dessen Installation Listing 3 beschreibt. Der Eintrag in der Datei »RELAY_CONTROL_EXPIRY« (im Beispiel »900«) gibt die Zeit in Sekunden an, die der Benutzer Zeit hat, seine Mails nach einem erfolgreichen POP-Connect abzuliefern.

Um »relay-ctrl« zu aktivieren, müssen die »run«-Skripte für »qmail-pop3d« und »qmail-smtpd« bearbeitet werden. Listing 4 zeigt den neuen Inhalt der Datei »/service/qmail-pop3d/run«; Listing 5 beschreibt, wie sich »/service/qmail-smtpd/run« mit und ohne Unterstützung für SMTP after POP unterscheiden.

»envdir /etc/relay-ctrl relay-ctrl-chdir« bedeutet, dass das Verzeichnis »/etc/relay-ctrl« als Quelle für Umgebungsvariablen des Programms »relay-ctrl-chdir« Verwendung findet. Für jede Datei in diesem Verzeichnis setzt »envdir« eine gleichnamige Variable und weist ihr den Datei-Inhalt als Wert zu.

»relay-ctrl-chdir« wiederum bekommt das Programm »tcpserver« übergeben und macht dessen Ausführung von den Berechtigungen abhängig. Der Eintrag »relay-ctrl-check« vor dem Aufruf von »qmail-smtpd« überprüft, ob dem User der Zugriff erlaubt wird.

»relay-ctrl-allow« auf POP-Seite (Listing 4) erzeugt für den über POP authentifizierten Benutzer eine Datei mit dessen IP-Adresse als Dateinamen (zum Beispiel »192.168.0.1«), die den Usernamen in der Form »USER= frank« enthält. »relay-ctrl-check« liest sie bei einem SMTP-Zugriff aus.

Um die Bereinigung dieser Dateien in dem Verzeichnis »/var/spool/relay-ctrl/allow/« kümmert sich der in Listing 3 genannte Cronjob: Er löscht die Einträge zu alter Authentifizierungen – eine Vorsichtsmaßnahme, die nicht zwingend erforderlich ist, da »relay-ctrl« von sich aus das Alter der Dateien überprüft.

Nicht nur Initskripte, auch die von den Daemontools verwalteten Services müssen nach Änderungen neu gestartet werden. Die Befehle

svc -d /service/* und<a> svc -u /service/*
</link>

stoppen und starten alle im »services«-Verzeichnis abgelegten Dienste neu. Alternativ ist statt »*« das Verzeichnis des gewünschten Dienstes anzugeben.

Zum Testen schickt man anschließend eine Mail, ohne vorher per POP auf den passenden Account zugegriffen zu haben. Der Versuch muss scheitern. Erst beim Zugriff auf die Mailbox über POP sollte das Versenden anschließend funktionieren.

01 patch -d /Pfad/zu/qmail-1.03 <  /Pfad/zu/<$>qmail-smtpd.c  
02 cd /Pfad/zu/qmail-1.03
03 make
04 make setup check
05 chmod 4711 /bin/checkpassword

01 berbig@chekov:~$ <strong>telnet localhost 25</strong>
02 Trying 127.0.0.1...
03 Connected to localhost.
04 Escape character is '^]'.
05 220 testrechner ESMTP
06 <strong>EHLO testrechner</strong>
07 250-testrechner
08 250-AUTH=LOGIN
09 250-PIPELINING
10 250 8BITMIME
11 <strong>auth login</strong>
12 334 VXNlcm5hbWU6
13 <strong>YmVyYmln</strong>
14 334 UGFzc3dvcmQ6
15 <strong>cGFzc3dvcnQ=</strong>                  (Base64 für »passwort«)
16 235 go ahead      (erfolgreiche Authentifizierung)
17 <strong>quit
</strong>

01 tar xzvf relay-ctrl-3.1.1.tar.gz
02 cd relay-ctrl-3.1.1
03 mkdir -p /var/spool/relay-ctrl/allow
04 chmod 700 /var/spool/relay-ctrl
05 chmod 777 /var/spool/relay-ctrl/allow
06 mkdir /etc/relay-ctrl
07 echo "/var/spool/relay-ctrl/allow" >  /etc/relay-ctrl/RELAY_CTRL_DIR
08 echo "900" > /etc/relay-ctrl/RELAY_CONTROL_EXPIRY
09 echo "1-59 * * * *    root envdir  /etc/relay-ctrl /usr/sbin/relay-ctrl-age"  >> /etc/crontab

Schwarze Listen

Nun lässt sich QMail zwar kaum mehr als offenes Relay missbrauchen, doch gegen Spam, der an Benutzer des Mailservers geschickt wird, hilft keine der genannten Maßnahmen. Hier setzen RBLs (Realtime Blocking oder Black Lists) wie die in Kasten “Offenes Relay?” erwähnte ORDB an. RBL-Projekte testen und sammeln mit unterschiedlichen Schwerpunkten Mailserver, die als (potenzielle) Spamquelle auffallen.

QMail kann diese mit dem Programm »rblsmtpd« aus dem Paket »ucspi-tcp« ([3], [4]) über DNS abfragen und blockt dann alle Mail-Zustellversuche der gelisteten Server ab. Hierzu muss das »run«-Skript für den SMTP-Daemon entsprechend Listing 6 so angepasst werden, dass das Programm »rblsmtpd« inklusive Optionen vor dem Aufruf von »qmail-smtpd« stehen bleibt.

Bei der Auswahl der RBLs ist jedoch abzuwägen, in welchem Rahmen man das Risiko eingehen möchte, dass unter den abgewiesenen Mails auch erwünschte sein können: Auf sehr aktiven RBLs landen unter Umständen schon mal unschuldige Server und wenn ein gängiger Freemailer geblacklistet wird, bedeutet das auch den Verlust erwünschter Mails, deren Absender von diesem Mailprovider unter Umständen nicht einmal informiert werden.

01 #!/bin/sh
02 exec /usr/local/bin/softlimit -m 2000000 envdir /etc/relay-ctrl relay-ctrl-chdir /usr/local/bin/tcpserver -v -R -H -l 0 0 110  /var/qmail/bin/qmail-popup host.domain.tld /pfad/zu/checkpassword relay-ctrl-allow /var/qmail/bin/qmail-pop3d Maildir 2>&1

exec /usr/local/bin/softlimit -m 2000000 /usr/local/bin/tcpserver -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" -u "$QMAILDUID" -g U "$NOFILESGID" 0 smtp /var/qmail/bin /qmail-smtpd 2>&1

exec /usr/local/bin/softlimit -m 2000000 envdir /etc/relay-ctrl relay-ctrl-chdir /usr/local/bin/tcpserver -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c U "$MAXSMTPD" -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp relay-ctrl-check /var/qmail/bin/qmail-smtpd 2>&1

exec /usr/local/bin/softlimit -m 2000000 /usr/local/bin/tcpserver -v -R -H -l 0 -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" -u "$QMAILDUID" -g "$NOFILESGID" 0 U smtp /var/qmail/bin/qmail-smtpd 2>&1

exec /usr/local/bin/softlimit -m 2000000 /usr/local/bin/tcpserver -v -R -H -l 0 -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" -u "$QMAILDUID" -g "$NOFILESGID" 0 U smtp /usr/local/bin/rblsmtpd -r relays.ordb.org /var/qmail/bin/qmail-smtpd 2>&1

Spam-Attentäter

Auch RBLs sind also nicht der Weisheit letzter Schluss. Ergänzend oder alternativ sei es daher den eigenen Usern überlassen, über Spam oder Nicht-Spam zu entscheiden. Entscheidungshilfen hierfür gibt das Perl-Modul Spamassassin aus dem Paket »Mail-Spamassassin«[9], das Mails auf verschiedene charakteristische Merkmale untersucht und das Ergebnis in den Headern der jeweiligen Mail verewigt. Zwei Tools, »procmail« oder der »qmail-scanner«[10], bringen es mit QMail zusammen. Letzterer empfiehlt sich, wenn man QMail außerdem den Gebrauch von Virenscannern nahe bringen möchte.

Der Weg über »procmail« besticht dagegen durch seine Einfachheit. Da dieser Mail Delivery Agent auf den meisten Systemen bereits installiert ist, müssen lediglich passende Konfigurationen erstellt werden. Als Basis für eine individuelle Lösung kann Listing 7 dienen. Die Zeilen 1 und 2 sorgen für die Vorverarbeitung aller eingehenden Mails durch Spamassassin. Die folgende Regel sorgt dafür, dass alle als Spam markierten Mails im IMAP-Ordner »Spam« enden, während – den Zeilen 6 bis 8 entsprechend – alle anderen Mails normal im Postfach des Benutzers landen.

Sicher ist noch nicht sicher

Wer Spam sofort löschen möchte, indem er Zeile 5 durch »/dev/null« ersetzt, sei gewarnt: Zunehmend nutzen Spammer Spamassassin als eine Art Qualitätssicherungstool, mit dem sie dafür sorgen, dass ihre Mails nicht mehr als Spam erkannt werden. So werden sich Spam und erwünschte Mail immer ähnlicher.

Den eigenen Mailserver schützen ist an sich schon keine banale, dafür aber eine immer währende Aufgabe. Bei QMail kommt das Problem hinzu, dass dessen Autor diverse Schutzmaßnahmen nicht für wichtig genug hält, um sie in den offiziellen Code aufzunehmen. So muss der QMail-Admin auf Patches und Add-ons Dritter zurückgreifen. (pju)

cd archivname; perl Makefile.PL
make; make install

cd /var/qmail
tar xzvf daemontools-0.76.tar.gz
cd admin/daemontools-0.76
./package/install

SV:123456:respawn:/command/svscanboot

mkdir -p /var/qmail/supervise/qmail-pop3d/log
cat > /var/qmail/supervise/qmail-pop3d/run << EOF
#!/bin/sh
exec /usr/local/bin/softlimit -m 2000000 /usr/local/bin/tcpserver -v -R -H -l 0 0 110 /var/qmail/bin/qmail-popup Host.Domain.tld /Pfad/zu/checkpassword /var/qmail/bin/qmail-pop3d Maildir 2>&1
EOF
cat > /var/qmail/supervise/qmail-pop3d/log/run << EOF
#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t /var/log/qmail/pop3d
EOF
chmod 755 /var/qmail/supervise/qmail-pop3d/run
chmod 755 /var/qmail/supervise/qmail-pop3d/log/run
mkdir -p /var/log/qmail/pop3d
ln -s /var/qmail/supervise/qmail-pop3d /service

01 :0fw
02 | /usr/local/bin/spamassassin -P 
03 :0 w
04 * ^X-Spam-Status: Yes
05 $HOME/Maildir/.Spam/
06 :0 w
07 *
08 $HOME/Maildir/