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.
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.
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.
|
Offenes |
|---|
| Relaying im Allgemeinen bezeichnet das Verarbeiten und Weiterleiten von Mails an ihre Zieladresse. Üblicherweise versendet und empfängt jeder Mailserver Nachrichten nur für seine lokalen Benutzer sowie die jener Domains, für die der Rechner als Mailexchanger (MX) im DNS eingetragen ist. Diese Anforderung ist jedoch vergleichsweise jung und eine Folge des zunehmenden Spam-Problems. In den Jugendtagen des Internet war es sogar üblich, dass jeder Mailserver Mail beliebiger Nutzer annahm und versuchte, sie an beliebige Empfänger weiterzuleiten, eine Arbeitsweise, die man als "offenes Relay" bezeichnet und die einige Mail-Transfer-Agenten, darunter QMail, leider immer noch als Default-Konfiguration haben. Schmarotzer im NetzDamit ist es auch möglich, große Mails zu versenden, ohne seine Identität preiszugeben. Seit der Zunahme des Spam-Unwesens führt dies zu großen Problemen: Spammer wollen in der Regel anonym bleiben und außerdem möglichst nicht für Rechenleistung, Speicherplatz und Netzwerkbandbreite zahlen. Die schmarotzen sie bei den Betreibern der missbrauchten Mailserver - und denen der Empfänger-Server. Doch die bleiben nicht untätig und setzen sich zur Wehr: Wenn man den Spammer selbst schon nicht so leicht herausfindet, bestraft man stellvertretend jene, die sich durch Fehlkonfiguration ihrer Mailserver zu Helfershelfern machen. Blacklists wie die Open Relay Database (ORDB, [http://ordb.org/]) fahnden nach offenen Relays und eine stetig zunehmende Anzahl Mail-Administratoren konfiguriert ihre MTAs so, dass sie Mail von dort gelisteten Rechnern grundsätzlich abweist. Zweierlei KopfschmerzenWer seinen Mailserver nicht oder nur unzureichend überprüfen lässt, ob weiterzuleitende Mail von berechtigten Benutzern stammt, bekommt daher über kurz oder lang zwei Probleme: Spammer entdecken das offene Relay und verwenden dessen Ressourcen dankend für ihre Zwecke. Aber auch Blacklists finden und sperren das Relay mit der Folge, dass Mails berechtigter User vom Empfängersystem abgewiesen werden. Prominentestes Beispiel aus der letzten Zeit sind die Mailserver von Gmx.de und Gmx.net, die Ende Mai auf der schwarzen Liste von ORDB standen - mit der Folge, dass tausende Mails von GMX-Usern niemals ihre Empfänger erreichten. |
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
