Mailserver, SSL und stunnel

Zuerst einmal, Fisch für Kenny! ;o)

Er hatte mich durch diesen Artikel zu stunnel/SSL darauf gebracht, mein bisheriges Problem mit dem Mailserver und SSL ebenfalls durch stunnel zu lösen. stunnel ist ein netter, kleiner Daemon, der nix anderes macht, als Anfragen zu laufenden Diensten via SSL zu tunneln (war ja klar, der Name sagt immerhin schon alles — [http://www.stunnel.org/]). Das ist besonders gut, wenn der jeweilige Dienst zum Beispiel gar kein SSL kann. Oder wie in meinem Fall, wenn man zu blöde ist, das Stück Software dazu zu bewegen, es selbst ordentlich zu können.

Mein Mailserver besteht aus dem Gespann Postfix/Dovecot ([http://www.postfix.org/] und [http://www.dovecot.org/]). Beide sind in der Lage, auch SSL-verschlüsselte Verbindungen aufzubauen. Jedoch durfte ich feststellen, dass allein die Konfiguration wirklich hässlich ist und wohl viele Stolpersteine mitbringt. Schon in Postfix gibt es für die SSL/TLS-Konfiguration zig Zeilen, die man in die main.cf schreiben muss. Dovecot ist da zwar genügsamer, aber letztlich soll ja alles aus einem Guss sein.

Weiterer Vorteil ist, dass man mit stunnel ja sämtliche Dienste, die verschlüsselt arbeiten sollen, mit einem Zertifikat für die Domain ausstattet. Das ist nach außen hin dann auch recht konsistent. Es sei denn, jemand will unbedingt für HTTPS ein anders signiertes Zertifikat nehmen. Oder wenn es um Subdomains geht, die ebenfalls gern eigene Zertifikate haben wollen, wenn man sich nicht gleich ein Wildcard-Cert kreiert hat.

Jetzt ist es für die benötigten Dienste meinerseit völlig unerheblich, was da im Zertifikat steht, zumal es ein selbst signiertes ist — also eher nur für den “internen Gebrauch”.

Da ich (resp. wir, da meine bessere Hälfte ja durchaus auch von meinen Admin-Tätigkeiten profitiert) den Mailserver definitiv nur für uns betreibe und wir keinen öffentlichen Maildienst anbieten, reichen uns die selbst erstellten Zertifikate. Zumal ich so etwas erst einmal kostenlos testen möchte, bevor ich mir überlege, zig bis zig hunderte von Euronen dafür auszugeben.

stunnel ist wirklich leicht zu bedienen, die default-Konfiguration ist eigentlich selbst erklärend. Aufpassen muss man nur an den Stellen, wo z. B. der Mailserver bereits die Ports belegt hat. Andere Sache ist die absolute Sicherheit durch Sperrung der non-SSL-Ports nach außen. Dies habe ich gestern nachgeholt, nun sind wir gezwungen, SMTP und IMAP nur noch via SSL zu nutzen.

Hier ein kurzer Ablaufplan, was man machen muss, wenn man Postfix/Dovecot (ausschließlich) mit SSL benutzen will:

1. stunnel nachinstallieren. Bei Ubuntu z. B. mit “apt-get install stunnel”
2. Die stunnel-Konfiguration anpassen. Meist nur etwas auskommentieren und die Pfade zu den Zertifikaten einstellen.
3. stunnel probeweise neustarten und sich die Logs anschauen. Meist meckert er rum, weil bereits ein Port schon belegt ist (bei mir war es der 465/SMTPS von Postfix, der es in sich hatte; siehe weiter unten).
4. Postfix und Dovecot so anpassen, dass sie dumm wie Stulle werden, wenn es um SSL/TLS geht. Einfachste Lösung: alles auskommentieren, was damit zu tun hat.
   1. Postfix: Hier in main.cf nach allen Zeilen suchen, die so etwas wie SSL oder TLS im Namen tragen und ein # davor. Dann muss man meist in der master.cf aber noch die smtps-Zeile ebenfalls auskommentieren, sonst lauscht Postfix dennoch auf dem Port rum, und das wollen wir ja nicht (darauf muss man erstmal kommen, bei so vielen config-Dateien).
   2. Dovecot: Ziemlich simpel. Einfach in der Zeile “protocols = …” nur noch imap (und ggf. pop3, falls benötigt) eintragen. Also imaps und pop3s raus!
5. Postfix, Dovecot und stunnel neustarten. stunnel wirklich erst nach den Maildiensten neustarten! Zur Kontrolle die Logs von stunnel prüfen, er sollte nun nicht mehr rummaulen, dass einer der gewünschten Ports belegt ist.
6. Bevor wir mit der Abschottung weitermachen, testet nun das Senden und Empfangen von Mails via SSL! Thunderbird, Evolution und Co. haben sich je nach DNS und Serverkonfiguration zwar pissig, was die automatische Suche nach den Einstellungen betrifft, doch das bisschen Einstellungen bekommt ihr sicher auch manuell hin. (Zur Info: die Standard-Ports für SSL sind demzufolge: 465 = SMTPS, 993 = IMAPS, POP3S = 995)
7. Ihr könnt mit SSL Mails durch die Gegend schubsen? Dann geht’s weiter mit der Abschottung der unverschlüsselten Ports, denn die lauschen weiterhin rum. Und da wir als sicherheitsbewusste Menschen uns auch selbst erziehen wollen und müssen, sperren wir diese Ports (SMTP/25 und IMAP/143, für die Poppigen POP3/110) für den äußeren Zugriff.
   1. Postfix: In der master.cf gibt es eine smtp-Zeile. Lustigerweise stehen hier zwar nur die Dienstbezeichner und keine Ports und damit war mir nicht gleich klar, dass dort auch IP:Port oder IP:Dienstname stehen darf. Also ändern wir die Zeile beginnend mit “smtp inet [...]” (und endend mit “[...] smtpd“) in “127.0.0.1:smtp inet [...]“. Schwups, Postfix ist nur noch lokal zu erreichen! (Es gibt ggf. noch eine zweite smtp-Zeile, aber da geht es um einen unix-Socket, der ist für uns irrelevant; also nix anfassen, wo unix drinsteht.)DAS ist natürlich das Blödeste, was man tun kann. Es sei denn, man will auch keine Emails mehr empfangen. *grummel* Hier muss man also anders absichern. Einzig sinnvolle Methode wäre also eine Authentifizierung über IMAP, was wir ja schon gesichert haben.
   2. Dovecot: Hier einfach im imap { … }-Block die Zeile “listen = 127.0.0.1” einfügen, da der stunnel ja lokal läuft, muss also auch nur über das lokale Loopback-Device kommuniziert werden. IMAP ohne SSL nach außen nicht mehr möglich. (pop3 funktioniert analog dazu, also die listen-Zeile auch in diesen Block kopieren.)
8. Damit die Änderungen wirksam werden, nochmals Postfix und Dovecot neustarten. Fertig!

Wenn ihr keine groben Schnitzer drin habt, sollte das Senden und Empfangen weiterhin laufen. Immerhin habt ihr das bereits im Schritt 6 getestet. Wenn ihr von außen eine telnet-Session mit “telnet 25” (bzw. 143 oder 110) startet, sollte dies mit einem Fehler quittiert werden, dass der Server die Verbindung nicht angenommen hat, weil’s da ja nix gibt. (Nicht Tür zu, sondern Tür weg!)

Wer noch ein Stückchen paranoider sein will, setzt völlig andere Port-Adressen und kaskadiert die Verbindung über mehrere Server hinweg, oder so … (stunnel auf ‘nem separaten Server laufen zu lassen, finde ich persönlich aber dann doch zu affig.)

Mehr zu SSL/TLS (Secure Socket Layer / Transport Layer Security) siehe auch auf http://de.wikipedia.org/wiki/Transport_Layer_Security (SSL ist begrifflich identisch zu behandeln)

Apropos Postfix/Dovecot: Kann mir irgendwer erklären, wie ich “Sichere Authentifizierung” ordentlich aktiviert bekomme? Das ist bei mir ebenfalls eine Angelegenheit, die ich durch die Dokumentation der beiden Pakete noch nicht herausgefunden habe. Dank SSL-Zwang ist das nicht mehr sooooo wichtig, aber beruhigen würde es mich schon, wenn das ginge. Ich will dabei gleich einmal darauf hinweisen, dass ich mit Virtuellen Konten und Domains via MySQL-Datenbank arbeite! Dies bringt so manches Mal mit sich, die Wege anders beschreiten zu müssen.

Übrigens: weiterer Linux-lastiger Inhalt wird demnächst einmal auf eine andere Domain ausgelagert, statt hier gesammelt im Linux-Fokus. Ich merke nun doch, dass solcher Inhalt wirklich besser in einem eigenen Bereich aufgehoben ist. Auch für den Android-Fokus habe ich bereits eine eigene Domain auserkoren, denn durch dieses Rooten und CustomRom-Gedöns habe ich genügend Stoff. Die Namen verrate ich aber jetzt noch nicht. Ein bisschen Spannung muss ja bleiben. (Doch neugierig? ;o) — Dann bookmarke: /bin/bash — Linux und Co. und androot — Android, Root und CustomRoms)

Edith sagt (mitten in der Nacht): Habe nun noch einmal mehrere Stunden Rumwerkeln hinter mir und dabei festgestellt, dass ich Postfix nun doch aus der stunnel-Konfiguration nehmen musste. Nach mehreren Tests funktionieren die TLS-Einstellungen jetzt doch.

Jetzt nur noch mit Dovecot rumspielen, und dann funktioniert dann dort auch alles, wie gewünscht. Und dann ebenfalls ohne stunnel. Es ist zwar echt ein gutes Hilfsmittel, aber sollte eigentlich keine Dauerlösung für Software sein, die eigentlich von selbst in der Lage ist, SSL-gestützte Kommunikation anzubieten.

Ich glaube, zu Mailservern muss ich echt einen intensiven Beitrag verfassen. So trivial die Nutzung für den Endnutzer in den meisten Fällen ist, so hochkomplex ist die Einrichtung und Wartung für den Sysadmin …

Edith sagt zum zweiten Mal: Auch Dovecot hat nun geklappt, ergo: Mailserver-System ist nun doch stunnel-frei!