Schlagwort-Archive: sicherheit

SELinux Booleans

Bei SELinux Booleans handelt es sich um kleine Schalter, mit denen sich das Verhalten der SELinux-Richtlinien beeinflussen lässt. Dieser Artikel knüpft an die „Einführung in das grundlegende Konzept von SELinux“ an und erläutert die Verwendung von SELinux Booleans anhand eines einfachen Beispiels.

Hinweis: Das Beispiel aus diesem Artikel wurde auf einem RHEL/CentOS 7.3 getestet. Unter CentOS 7.2 funktioniert die hier gezeigte Konfiguration nicht. Für Details wird auf das Topic1 im CentOS-Support-Forum verwiesen.

Im Einführungsartikel2 wurde SELinux dazu genutzt, um den Zugriff des Apache auf das DocumentRoot-Verzeichnis /var/www/html zu beschränken. Nun möchte der Webmaster den Benutzern gestatten, Webseiten über ihre HOME-Verzeichnisse zu veröffentlichen und aktiviert dazu die Konfiguration für das Modul Userdir.3 4 5

[root@centos ~]$ cat /etc/httpd/conf.d/userdir.conf

    UserDir enabled
    UserDir public_html



    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    Require method GET POST OPTIONS


[root@centos ~]#

Nun kann ein Benutzer in seinem HOME-Verzeichnis den Ordner public_html erstellen und eine test.txt-Datei erstellen:

[jkastning@centos ~]$ mkdir public_html
[jkastning@centos ~]$ sudo chmod 711 /home/jkastning/
[jkastning@centos ~]$ sudo chmod 755 public_html/
[jkastning@centos ~]$ vim public_html/test.txt

Hello User

Nach einem Neustart des Dienstes httpd sollte sich nun die Datei index.html aus dem Benutzerverzeichnis abrufen lassen. Statt dessen wird der Zugriff verweigert.

apache_userdir_forbidden

httpd_enable_homdirs –> off

In den Logdateien finden sich Hinweise, die auf SELinux als Ursache hindeuten.

[root@centos ~]# tail /var/log/audit/audit.log|grep AVC
type=AVC msg=audit(1480446615.354:844): avc:  denied  { getattr } for  pid=23150 comm="httpd" path="/home/jkastning/public_html/index.html" dev="sda1" ino=1052157 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file

[root@centos ~]# tail /var/log/messages | grep SELinux
Nov 29 20:10:44 centos setroubleshoot: SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html. For complete SELinux messages. run sealert -l 13419731-cedd-4433-abb7-b2e7715d5636

Um weitere Informationen zu erhalten, führen wir das Kommando aus /var/log/messages aus (Ausgabe gekürzt):

[root@centos ~]# sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html.

*****  Plugin catchall_boolean (24.7 confidence) suggests   ******************

If you want to allow httpd to enable homedirs
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'None' man page for more details.
Do
setsebool -P httpd_enable_homedirs 1

In der obigen Ausgabe wird neben der Ursache auch gleich die Lösung mitgeliefert. Nach der Aktivierung des SELinux Boolean httpd_enable_homedirs kann der Inhalt der Datei index.html im Webbrowser abgerufen werden.

apache_userdir_allowed

httpd_enable_homedirs –> on

Damit wurde eine weitere Funktionalität von SELinux kurz vorgestellt. Für weiterführende Informationen sei auf die Manpages booleans(8)6, getsebool(8)7 und setsebool(8)8 verwiesen.

Einführung in das grundlegende Konzept von SELinux

SELinux1 (Security-Enhanced Linux; engl. „sicherheitsverbessertes Linux“) ist eine Erweiterung des Linux-Kernels, mit der eine zusätzliche Sicherheitsschicht in das Betriebssystem eingezogen wird.

In dieser Einführung wird das zu Grunde liegende Konzept kurz vorgestellt und erläutert, welche Modi SELinux besitzt, wie diese angezeigt und umgeschaltet werden können. An einem einfachen Beispiel mit dem Apache Webserver wird dargestellt, wie SELinux in der Praxis wirkt. Des Weiteren wird mit Hilfe des Beispiels das Vorgehen bei einer Fehleranalyse erläutert.

SELinux ist dazu gedacht, das bestehende Berechtigungskonzept unter Linux zu erweitern, um zu verhindern, dass kompromittierte Dienste auf Daten zugreifen, auf die kein Zugriff erforderlich ist.

Als einfaches Beispiel mag hier der Webserver Apache2 dienen.

Dieser liest die Dateien, welche er ausliefern soll, in der Standardkonfiguration aus dem dem Verzeichnis /var/www/html. Daneben darf der Dienst z.B. auch alle Verzeichnisse und Dateien unterhalb der Verzeichnisse /tmp und /var/tmp lesen.

user@host:~$ ls -ld /tmp
drwxrwxrwt. 5 root root 4096 Nov 27 19:05 /tmp
user@host:~$ ls -ld /var/tmp
drwxrwxrwt. 2 root root 4096 Nov 10 06:34 /var/tmp
user@host:~$

Grundsätzlich hat der Dienst Zugriff auf alle Verzeichnisse und Dateien, welche den Lese- bzw. Schreibzugriff für alle Benutzer erlauben.

SELinux kann nun dazu genutzt werden, um genau diesen Zugriff zu unterbinden. Die folgende Abbildung soll dies verdeutlichen:

selinux-example-apache

Mögliche Zugriffe mit und ohne SELinux am Beispiel des Apache

SELinux stellt einfach gesprochen ein Regelwerk dar, nach welchem bestimmt wird, auf welche Verzeichnisse, Dateien, Prozesse und Ports ein Dienst zugreifen darf. Dazu erhalten diese Objekte ein Label mit einem Security Context. Nur wenn das SELinux-Regelwerk den Zugriff von einer Ressource auf eine weitere Ressource explizit erlaubt, ist der Zugriff gestattet. Andernfalls wird die Interaktion unterbunden. Dabei unterscheidet SELinux die verschiedenen Label nach Kontexten. Diese sind:

  • user
  • role
  • type
  • sensitivity

Im Folgenden wird ausschließlich der Kontext „type“ weiter betrachtet. So besitzt z.B. der Dienst Apache das Label httpd_t, während Dateien unterhalb von /var/www/html das Label httpd_sys_content_t tragen. Da SELinux eine Regel besitzt, welche den Zugriff des Kontext httpd_t auf Dateien und Verzeichnisse mit dem Kontext httpd_sys_content_t gestattet, kann der Apache die Datei index.html aus dem Verzeichnis /var/www/html anzeigen:

output-index-html

Ausgabe der Datei /var/www/html/index.html

Obiger Screenshot enthält neben dem obligatorischen „Hallo Welt“ auch noch die Ausgabe des Verzeichnis-Listings, welches neben den üblichen Angaben wie Berechtigungen, Benutzer und Gruppe auch den SELinux-Kontext mit ausgibt. Wie man SELinux steuert und sich den Kontext von Verzeichnissen, Dateien und Prozessen anzeigen lässt, wird im Folgenden Abschnitt erläutert.

Steuerung von SELinux

SELinux kennt drei Modi:

  • Enforcing
  • Permissive
  • Disabled

In welchem Status sich SELinux befindet, kann mit dem Kommando getenforce abgefragt werden:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Obige Ausgabe bedeutet, dass SELinux im Modus „Enforcing“ ausgeführt wird. In diesem Modus verhindert SELinux Zugriffe, welche nicht explizit durch das Regelwerk erlaubt werden. Im Unterschied dazu werden diese Zugriffe im Modus „Permissive“ nicht verhindert, sie werden jedoch protokolliert. Dieser Modus eignet sich daher hervorragend, um das aktuelle Verhalten von Diensten zu analysieren und die Konfiguration ggf. anzupassen. Die Umschaltung zwischen den Modi „Enforcing“ und „Permissive“ kann zur Laufzeit erfolgen:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]# setenforce 0
[root@centos ~]# getenforce
Permissive
[root@centos ~]# setenforce 1
[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Der Standard-Modus wird in der Datei /etc/selinux/config festgelegt.

Anzeige der SELinux-Kontexte

Der kleine Punkt (im Screenshot rot markiert) hinter den Berechtigungen zeigt an, dass ein SELinux-Kontext für eine Datei bzw. ein Verzeichnis existiert:

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Welchen Kontext eine Datei bzw. ein Prozess besitzt, kann angezeigt werden, indem bekannte Kommandos mit der Option „-Z“ benutzt werden. Das folgende Listing zeigt einige Beispiele:

[root@centos ~]# ps -eZ | grep httpd
system_u:system_r:httpd_t:s0     2876 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2920 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2921 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2922 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2923 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2924 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2925 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     3152 ?        00:00:00 httpd
[root@centos ~]# ls -lisaZ /var/www/html/
total 12
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 ..
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
[root@centos ~]# ls -lisaZ /var/tmp
total 28
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
drwxr-xr-x. abrt abrt system_u:object_r:abrt_var_cache_t:s0 abrt
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-colord.service-MczkBW
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-cups.service-c3Aouq
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-httpd.service-oAqhlb
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-rtkit-daemon.service-xpSsO2
[root@centos ~]# ls -lisaZ /tmp |head -n4
total 96
drwxrwxrwt. root      root      system_u:object_r:tmp_t:s0       .
dr-xr-xr-x. root      root      system_u:object_r:root_t:s0      ..
-rw-r--r--. root      root      system_u:object_r:tmp_t:s0       anaconda.log
[root@centos ~]#

Die Datei index.html hat bei ihrer Erstellung im Verzeichnis /var/www/html automatisch den korrekten Kontext httpd_sys_content_t erhalten und kann daher im Webbrowser angezeigt werden. Wird eine Datei im Verzeichnis /tmp erstellt, erhält diese automatisch den Kontext user_tmp_t:

[root@centos ~]# echo 'TEST' > /tmp/test.txt
[root@centos ~]# ls -lisaZ /tmp/test.txt
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 /tmp/test.txt
[root@centos ~]#

Was tun, wenn’s klemmt?

Um zu erläutern, wie man einem Fehler auf die Spur kommt, baue ich zuerst einen ein. Dazu verschiebe ich die im vorangegangenen Abschnitt erzeugte Datei in das DocumentRoot des Apache und versuche, diese im Browser aufzurufen.

forbidden

Forbidden

SELinux verhindert den Zugriff des Dienstes „httpd“ auf die Datei „text.txt“, da keine Regel existiert, welche den Zugriff vom Kontext httpd_t auf user_tmp_t explizit erlaubt. Doch wie kann man dies feststellen, wenn man nicht bereits zu Beginn um den falschen Kontext weiß?

Zuerst wirft man einen Blick auf die Dateiberechtigungen, welche aber keinen Fehler erkennen lassen:

[root@centos ~]# ls -lZ /var/www/html/
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 test.txt
[root@centos ~]#

Da die Dateiberechtigungen als Fehlerquelle ausscheiden und in diesem Beispiel keine POSIX-ACL3 verwendet werden, bleibt nur noch SELinux als Fehlerquelle übrig. Daher suchen wir einmal in /var/log/audit/audit.log nach Ereignissen vom Typ „AVC“:

[root@centos ~]# tail /var/log/audit/audit.log | grep AVC
type=AVC msg=audit(1480277043.225:537): avc:  denied  { open } for  pid=2922 comm="httpd" path="/var/www/html/test.txt" dev="sda1" ino=924457 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

Treffer! Um die Sache weiter zu analysieren, untersuchen wir als nächstes /var/log/messages (Ausgabe gekürzt):

Nov 27 21:29:13 centos setroubleshoot: SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt. For complete SELinux messages. run sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a

Hier findet sich eine Bestätigung, dass SELinux den Zugriff blockiert hat und ein Vorschlag, wie dieser Vorfall genauer analysiert werden kann. Damit lassen sich umfassende Informationen abrufen, welche sogar die Lösung mit ausgeben (Ausgabe gekürzt):

[root@centos ~]$ sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a
SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt.

*****  Plugin restorecon (92.2 confidence) suggests   ************************

If you want to fix the label. 
/var/www/html/test.txt default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/test.txt

*****

Der Bericht gibt an, wie das Standard-Label für die Datei text.txt gesetzt sein sollte. Darüber hinaus ist dem Bericht der Befehl zu entnehmen, mit dem die Label wieder auf den Standardwert zurückgesetzt werden können. Nachdem dieser Befehl ausgeführt wurde, kann die Datei text.txt im Webbrowser geöffnet werden.

[root@centos ~]# /sbin/restorecon -v /var/www/html/test.txt
/sbin/restorecon reset /var/www/html/test.txt context unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
[root@centos ~]#
correct-selinux-context

Aufruf von test.txt mit korrektem SELinux-Kontext

Schlusswort

Es wurde in das grundlegende Konzept von SELinux und die möglichen Betriebsmodi eingeführt. Darüber hinaus wurde erläutert, wie man sich die zu einem Objekt gehörenden SELinux-Kontexte anzeigen lassen kann und wie diese auf einen Standard-Kontext zurückgesetzt werden können. Abschließend wurde ein kleiner Einblick in das Vorgehen zur Fehleranalyse gegeben.

Damit bin ich am Ende dieser kleinen Einführung angekommen, wobei das Thema SELinux damit noch lange nicht abschließend behandelt ist. Für weiterführende Informationen sei an dieser Stelle auf die Dokumentation der einzelnen Distributionen verwiesen.4 5 6

Quellen und weiterführende Links

Datenpanne im Internet – Bin ich betroffen?

Sie passieren ständig – Datenpannen1 im Internet. Und die Abstände zwischen ihnen werden gefühlt immer kürzer. In diesem Artikel möchte ich euch einen Weg aufzeigen, wie ihr selbst schnell und einfach feststellen könnt, ob ihr selbst von einer Datenpanne betroffen seid. Im Gegensatz zu vielen anderen Artikeln auf diesem Blog versuche ich dabei auf technische Details so weit wie möglich zu verzichten, um den Artikel allgemeinverständlich zu gestalten.

Datenpannen sind Verstöße, gegen die Datensicherheit und den Datenschutz, bei denen Staatsgeheimnisse, Betriebsgeheimnisse oder personenbezogene Daten Unberechtigten vermutlich oder erwiesenermaßen bekannt geworden sind. – Quelle: Deutschsprachige Wikipedia: Datenpanne

Und Datenpannen können überall passieren. Im Online-Shop, dem Online-Auktionsportal, im Online-Banking, in Tauschbörsen, in sozialen Netzwerken und auch im Cloud-Speicher-Dienst, dem wir unsere Dateien anvertrauen. Wikipedia listet einige bedeutende Vorfälle2, die in den vergangenen Jahren bekannt wurden.

Doch wie kann man nun überprüfen, ob man selbst von einer solchen Panne betroffen ist? Eine erfreulich einfache Möglichkeit bietet die Webseite https://haveibeenpwned.com/.3 4

https://haveibeenpwned.com

https://haveibeenpwned.com – Prüfe, ob einer deiner Accounts durch eine Datenpanne kompromittiert wurde.

Die Bedienung der Seite ist, wie bereits erwähnt, erfreulich einfach. Man trägt den zu überprüfenden Benutzernamen bzw. E-Mail-Adresse in das Suchfeld ein und startet die Suche. Das Ergebnis gibt Auskunft darüber, ob der Benutzername bzw. die E-Mail-Adresse von einer Datenpanne betroffen ist und bei welchem Dienst die Informationen stammen. Die folgenden beiden Screenshots zeigen zwei Beispiele. Das erste Beispiel zeigt einen Fall, bei dem die Kompromittierung eines Benutzernamens bis heute nicht bekannt geworden ist. Das zweite Beispiel zeigt die Abfrage einer E-Mail-Adresse, die mit anderen Daten bei einem Datenleck beim Cloud-Speicheranbieter Dropbox abgegriffen wurden.

username-not-compromised

Keine Kompromittierung des Benutzernamens bekannt

compromised-mailaddress

Die kompromittierte E-Mail-Adresse stammt aus einem Datenleck bei Dropbox

Neben der manuellen Überprüfung bietet die Webseite auch die Möglichkeit, eine E-Mail-Adresse zu hinterlegen. Taucht diese E-Mail-Adresse in einem öffentlich bekannt gewordenen Datenbestand auf, erhält man hierüber eine Nachricht an die hinterlegte E-Mail-Adresse.

Was tun, wenn ich betroffen bin?

Stellt man nun fest, dass die geprüften Benutzerdaten kompromittiert sind, sollte man umgehend handeln. Es ist dringend empfohlen, in diesem Fall

  1. die Zugangsdaten (Benutzername, E-Mail-Adressse, Passwort) beim betroffenen Dienst zu ändern.
  2. die Zugangsdaten (Benutzername, E-Mail-Adressse, Passwort) bei allen sonstigen Diensten zu ändern, bei denen die gleichen Zugangsdaten verwendet wurden.

Mit dem zweiten Schritt soll sichergestellt werden, dass mit den kompromittierten Benutzerinformationen noch weitere Benutzerkonten bei anderen Online-Diensten gekapert werden können.

Um den Umgang und die Verwaltung von Benutzernamen und Passwörtern so komfortabel wie möglich zu gestalten, empfehle ich die Verwendung eines Passwortmanagers wie z.B. KeePass.5 6 7

Enigmail unterstützt zukünftig nur noch GnuPG 2

Auf meinem Trusty-Notebook läuft Thunderbird mit dem Addon Enigmail in Version 1.8. Heute Morgen informierte mich Enigmail mit folgender Meldung darüber, dass die unter Ubuntu standardmäßig installierte GnuPG-Version 1.4.16 in zukünftigen Versionen von Enigmail nicht mehr unterstützt wird. Es wird ein Update auf GnuPG 2.0 oder neuer empfohlen.

enigmail-message

Enigmail-Meldung

Nichts leichter als das. Schließlich ist GnuPG 2 bereits in den Paketquellen von Ubuntu enthalten und kann aus diesen installiert werden.

sudo apt-get install gnupg2

Fertig. Mehr ist nicht zu tun. Ein Blick in die Enigmail-Einstellungen zeigt, dass das Addon nun automatisch das soeben installierte gpg2 verwendet.

enigmail-settings

Enigmail-Einstellungen

Die vorhandenen GnuPG-Schlüssel stehen automatisch auch in der neuen Version zur Verfügung. Die Bedienung funktioniert im Wesentlichen wie zuvor. Man verwendet nun lediglich das Kommando gpg2, statt des älteren gpg.

Der eigene Mailserver – Teil 3

Es ist Zeit für Teil 3 dieser kleinen Artikelreihe. In diesem Teil wird der Server einsatzbereit gemacht. Dazu sind im Wesentlichen die folgenden sechs Aufgaben zu erledigen.

Es gibt wieder viel zu tun. Also legen wir los.

Haben wir nicht was vergessen?

Wie ist es denn um den Update-Status des eigenen Servers bestellt? Evtl. ist jetzt eine gute Gelegenheit das System auf Updates zu prüfen und diese einzuspielen. Doch muss dies nicht manuell passieren.

In „Automatische Installation von Sicherheitsupdates“ erkläre ich, wie man die Update-Installation unter Ubuntu automatisieren kann. Exkurs Ende.

OpenDKIM

OpenDKIM soll Mailservern dabei helfen die Authentizität und die Integrität von eingehenden E-Mails zu überprüfen.

Versendet ein Mailserver eine E-Mail mit OpenDKIM, so bildet der Server einen Hashwert über den Inhalt der E-Mail. Dieser Hashwert wird mit einem privaten Schlüssel verschlüsselt und im Header der E-Mail gespeichert. Der empfangende Mailserver fragt über DNS einen speziellen TXT-Record ab, welcher das öffentliche Gegenstück zum privaten Schlüssel enthält, mit welchem der Hash verschlüsselt wurde. Der empfangende Mailserver nutzt diesen öffentlichen Schlüssel, um den Hashwert der Nachricht zu entschlüsseln. Abschließend bildet der Mailserver selbst den Hashwert der empfangenen E-Mail und vergleicht ihn mit dem soeben entschlüsselten Hashwert aus dem Mailheader. Stimmen beide Hashwerte überein, kann man mit hinreichender Sicherheit davon ausgehen, dass die E-Mail von einem autorisierten Absender stammt und unterwegs nicht verändert wurde.

Für die einzelnen Schritte in diesem Teil werden wieder root-Rechte benötigt. Entweder man öffnet eine root-Shell oder stellt den folgenden Befehlen ein sudo voran.

Als erstes wird das Paket OpenDKIM installiert.

:~$ sudo apt-get install opendkim opendkim-tools

Das OpenDKIM Paket richtet bei der Installation automatisch die benötigten Benutzerkonten und Upstart Jobs ein. Es muss nur noch ein Verzeichnis erstellt werden, in dem die Konfigurationsdateien und der private Schlüssel gespeichert werden. Der Zugriff auf dieses Verzeichnis wird auf den Benutzer und die Gruppe von opendkim beschränkt.

mkdir /etc/opendkim
chown opendkim:opendkim /etc/opendkim

Im nächsten Schritt wird im soeben erstellen Verzeichnis ein DKIM Schlüsselpaar erstellt.

cd /etc/opendkim
opendkim-genkey -r -h sha256 -d domainname.tld -s mail

Mit dem Parameter -r schränkt man das erstellte Schlüsselpaar in der Art ein, dass es nur zur Signatur von E-Mails verwendet werden kann. Die Angabe des Hash-Algorithmus sollte selbsterklärend sein. Der Parameter -d spezifiziert die Domain und -s gibt den Selektor an.4 Das Kommando gibt die beiden Dateien mail.private und mail.txt aus. Letztere enthält den öffentlichen Schlüssel in Form eines DNS TXT Records. Dies macht es einfach, den benötigten DNS Eintrag auf dem DNS Server hinzuzufügen. Ich komme in Kürze darauf zurück.

Die Datei mail.private wird in mail umbenannt. Anschließend wird festgelegt, welche Dienste den Schlüssel zur Signatur von Mails nutzen dürfen. Aber ein Schritt nach dem Anderen.

Zuerst wird die Datei umbenannt:

mv mail.private mail

Anschließend wird die Datei /etc/opendkim/KeyTable angelegt und mit Inhalt nach folgendem Muster befüllt:

domainname.tld domainname.tld:mail:/etc/opendkim/mail

Hier wird domainname.tld mit dem privaten Schlüssel für diese Domain verknüpft. Hat man mehrere Domains und Schlüssel, werden diese nach dem gleichen Muster hier eingetragen.

Als nächstes wird die Datei /etc/opendkim/SigningTable erstellt und mit folgendem Inhalt gefüllt:

*@domainname.tld domainname.tld

Dieser Eintrag weist OpenDKIM an, alle E-Mails von allen Adressen, die auf @domainname.tld enden, mit der Signatur von mail.domainname.tld zu versehen. Auch hier lassen sich ganz einfach weitere Domains hinzufügen.

Als letzte Datei wird die Datei /etc/opendkim/TrustedHosts erstellt, welche lediglich eine lokale IP-Adresse enthält:

127.0.0.1
::1

Diese Datei gibt an, welche Server Mails signieren dürfen und welche Server signierte Mails versenden dürfen, ohne Benutzeranmeldedaten zu übermitteln.

Damit nur OpenDKIM auf die Dateien unterhalb von /etc/opendkim zugreifen kann, wird der Zugriff noch entsprechend eingeschränkt:

chown -R opendkim:opendkim /etc/opendkim

Jetzt kann es der Konfigurationsdatei /etc/opendkim.conf an den Kragen gehen. An das Ende der Datei wird der folgende Inhalt angehängt:

## Benutzerspezifische OpenDKIM Konfiguration
Canonicalization        relaxed/relaxed
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
LogWhy                  Yes
PidFile                 /var/run/opendkim/opendkim.pid
Socket                  local:/var/spool/postfix/opendkim/opendkim.sock
SyslogSuccess           Yes
TemporaryDirectory      /var/tmp
UserID                  opendkim:opendkim

Da das Verzeichnis für den Socket noch nicht existiert, wird es jetzt angelegt und mit den entsprechenden Berechtigungen versehen.

mkdir /var/spool/postfix/opendkim
chown opendkim:root /var/spool/postfix/opendkim

Damit die Konfiguration wirksam wird, muss der Dienst einmal neugestartet werden:

service opendkim restart

Damit Postfix über den Socket mit OpenDKIM kommunizieren kann, fügt man den Benutzer Postfix der OpenDKIM Gruppe hinzu.

usermod -G opendkim postfix

Damit ist die erste Aufgabe für diesen Teil erledigt. Bevor wir OpenDKIM endgültig mit Postfix verbinden, wenden wir uns einem anderen Schlachtfeld zu.

Der ewige Kampf gegen den Spam…

…beginnt an dieser Stelle mit der Installation des milters und der Pakete, die benötigt werden, damit Spamassassin mit den DKIM Headers zusammenarbeitet.

sudo apt-get install spamass-milter pyzor razor libmail-dkim-perl

Es gibt mehrere Wege, SpamAssassin zu konfigurieren und zu nutzen. Der einfachste wäre alle Dienstfunktionalitäten zu ignorieren und Postfix die Mails einfach an SpamAssassin weiterleiten zu lassen, bevor diese an Dovecot geleitet werden. Doch dieser Weg führt zur dunklen Seite der Macht.

Ich möchte, dass Postfix die E-Mails über einen Unix-Socket an spamd zur Überprüfung gibt. spamd läuft im Hintergrund und wartet auf die Mails von Postfix. Dies ist schneller und ressourcenschonender. Denn es muss nicht für jede eintreffende E-Mail ein SpamAssassin Prozess gestartet werden.

In der Standardkonfiguration legt spamass-milter für jedes Postfach eine eigene AntiSpam-Datenbank an. Ob man dies möchte, hängt vom Einsatzzweck des jeweiligen Servers ab. Ich persönlich plane den Server für meine eigenen Domains und meine eigenen Postfächer zu nutzen. Daher werde ich es mit einer globalen Konfiguration versuchen, die für alle Postfächer gilt.

Benutzerkonten und Konfigurationsdateien

Bevor die Betriebsbereitschaft hergestellt werden kann, muss noch ein System-Benutzer für den Dienst spamd erzeugt und der Benutzer spamass-milter der spamd Benutzergruppe hinzugefügt werden.

addgroup --system spamd
adduser --system --home /var/lib/spamassassin --ingroup spamd spamd
usermod -a -G spamd spamass-milter

Fertig, nun werden erstmal ein paar Konfigurationsdateien gehackt.

Zu Beginn ist /etc/default/spamassassin dran. Nach der Bearbeitung sollte die Datei wie folgt aussehen:

SAHOME="/var/lib/spamassassin"
SAGLOBALCFGPATH="/etc/spamassassin"
 
# Change to one to enable spamd
ENABLED=1
 
# Options
# See man spamd for possible options. The -d option is automatically added.
OPTIONS="-x --max-children 5 --helper-home-dir ${SAHOME} -u spamd -g spamd --siteconfigpath ${SAGLOBALCFGPATH} --socketpath=/var/spool/postfix/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=0660"
 
# Pid file
# Where should spamd write its PID to file? If you use the -u or
# --username option above, this needs to be writable by that user.
# Otherwise, the init script will not be able to shut spamd down.
PIDFILE="/var/run/spamd.pid"
 
# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

Die ersten beiden Zeilen enthalten Variablen, die das SpamAssassin Home-Verzeichnis und das Verzeichnis mit der globalen Konfiguration beinhalten. Als nächstes wird der spamd Daemon aktiviert. OPTIONS enthält einen ganzen Blumenstrauß an Parametern. Hier wird festgelegt, dass nur eine Konfigurationsdatei für alle Benutzer verwendet wird. Die UID und GID, unter denen SpamAssassin ausgeführt werden soll, werden festgelegt. Der Pfad zur globalen Konfigurationsdatei wird angegeben, usw. usf. Am Ende wird noch das automatische Policyupdate aktiviert. Für weitere Erläuterungen dieser Datei verweise ich auf die Projektseite2, welche unter den Quellen verlinkt ist.

Das Verzeichnis für den Socket wird manuell erstellt und die entsprechenden Benutzerrechte vergeben:

mkdir /var/spool/postfix/spamassassin
chown spamd:root /var/spool/postfix/spamassassin/

Speichern und schließen! Jetzt geht es mit /etc/default/spamass-milter weiter. Diese Datei enthält nur eine einzige Zeile, die nach der Bearbeitung wie folgt aussehen sollte.

OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I -- --socket=/var/spool/postfix/spamassassin/spamd.sock"

Die Option „-u“ definiert, unter welchem Benutzerkontext der Milter ausgeführt wird. „-i“ gibt die Quell-IPs der Systeme an, deren Mails der Milter ignorieren soll. „-I“ ignoriert E-Mails von authentifizierten SMTP-Sendern. „-m“ hält SpamAssassin davon ab, sich zu sehr mit den Mail-Headern zu beschäftigen. Der Rest der Zeile gibt an, wohin der Milter die Mails zum Scannen leiten soll. Hier wird der Socket angegeben, der im letzten Schritt erstellt wurde.

Speichern, schließen, nächster!

An die Datei /etc/spamassassin/init.pre werden die beiden folgenden Zeilen angefügt:

## Add TextCat to assist enable language-based filtering
loadplugin Mail::SpamAssassin::Plugin::TextCat

Die beiden Zeilen bewirken, dass das TextCat-Plugin geladen wird, welches wir in der folgenden Konfigurationsdatei verwenden.

In der Datei /etc/spamassassin/local.cf wird direkt unterhalb des ersten Kommentars der folgende Code eingefügt:

## Force global Bayesian databases instead of per-user
bayes_path /var/lib/spamassassin/.spamassassin/bayes
bayes_file_mode 0777
 
## Ensure non-English and non-German e-mails are treated as spam
ok_languages en de
ok_locales en
 
## Set Pyzor and Razor config file paths
razor_config /etc/razor/razor-agent.conf
pyzor_options --homedir /var/lib/spamassassin/.pyzor

Zu Beginn wird festgelegt, wo die Datenbank für den Bayesian-Filter liegt.

Die nächsten beiden Optionen geben an, in welcher Sprache und welchem Zeichensatz eine E-Mail entsprechen muss, um nicht als Spam aussortiert zu werden. Die aktuelle Einstellung erlaubt E-Mails in englischer so wie deutscher Sprache und westlichem Zeichensatz. Eine vollständige Liste der untestützten Sprachen gibt es in der TextCat Dokumentation6, die verfügbaren Zeichensätze sind in der SpamAssassin Dokumentation für Konfigurationsdateien7 zu finden.

Auf die letzten beiden Zeilen werde ich in Kürze noch eingehen.

Wann immer man an den Konfigurationsdateien von SpamAssassin herumgemacht hat, ist es eine gute Idee, die Konfiguration mit folgendem Befehl auf Fehler zu überprüfen.

spamassassin --lint

Liefert das Kommando keine Ausgabe zurück, ist alles in Ordnung.

Zum Start werden einmal die aktuellen SpamAssassin-Regeln mit dem Kommando sa-update abgerufen. In Zukunft passiert dies automatisch.

sa-update
chown -R spamd:spamd /var/lib/spamassassin

Nun werden noch das Verzeichnis für den Socket angelegt, die Benutzerrechte korrigiert und die beiden Dienste neugestartet. Anschließend kann es schon zum nächsten Schritt weitergehen.

chown spamd:spamd /var/lib/spamassassin/.spamassassin
service spamassassin restart
service spamass-milter restart

Razor2 und Pyzor

Razor2 und Pyzor sind zwei Add-Ons für SpamAssassin. Sie erweitern die Fähigkeit Spam auszusortieren, indem auf zwei AntiSpam-Datenbanken zurückgegriffen wird, die ständig erweitert werden. Einmal eingerichtet, muss man sich nicht weiter um die beiden kümmern.

Zuerst werden die benötigten Verzeichnisse angelegt:

mkdir /var/lib/spamassassin/.razor
mkdir /var/lib/spamassassin/.pyzor

Laut der Dokumentation8 braucht es nur ein Kommando, um Pyzor in Gefechtsbereitschaft zu versetzen.

pyzor --homedir /var/lib/spamassassin/.pyzor discover

Um Razor in Gefechtsbereitschaft zu versetzen, bedarf es nur weniger Kommandos mehr:

razor-admin -home=/var/lib/spamassassin/.razor -register
razor-admin -home=/var/lib/spamassassin/.razor -create
razor-admin -home=/var/lib/spamassassin/.razor -discover

Der Datei /var/lib/spamassassin/.razor/razor-agent.conf ist folgende Zeile hinzuzufügen:

razorhome = /var/lib/spamassassin/.razor

Das wars…fast…noch zwei Kommandos und SpamAssassin ist klar zum Gefecht.

chown -R spamd:spamd /var/lib/spamassassin
service spamassassin restart
service spamass-milter restart

Training für SpamAssassin

Die Filter von SpamAssassin lernen selbstständig. Doch kann man den Lernprozess durch aktives Training unterstützen. Dazu lässt man eine gewisse Menge an E-Mails durch das Hilfsprogramm sa-learn analysieren.

Hat man z.B. nur solche E-Mails im Posteingang, bei denen es sich ganz sicher nicht um Spam handelt, kann man SpamAssassin wie folgt darauf trainieren, dass es sich dabei nicht um Spam handelt:

sa-learn --ham /path/to/your/inbox/on/the/server --progress

Genau so gut funktioniert das andersherum. Hat man einen Ordner, der ausschließlich Spam-Mails enthält, kann man den Filter wie folgt trainieren:

sa-learn --spam /path/to/directory/of/spam --progress

Der Trainingsprozess ist am effektivsten, wenn man ca. je 1.000 Nachrichten Spam und echte E-Mail hat. Der Filter wird sogar erst dann aktiv genutzt, wenn sich mindestens 200 Spam-Mails in der Datenbank befinden. Das Training kann man beschleunigen, indem man Mails aus seinem Google-Postfach mit Hilfe von Google exportiert, in ein Verzeichnis auf dem Server entpackt und das Trainingsprogramm auf dieses Verzeichnis anwendet.9 Führt man das Lernprogramm als root aus, muss man anschließend sicherstellen, dass alle Dateien in /var/lib/spamassassin/.spamassassin dem Benutzer spamd gehören.

Falls man SpamAssassin versehentlich mal falsch angelernt hat, kann man dies auch wieder rückgängig machen, in dem man das oben genannte Kommando mit der Option –forget auf die betroffene Menge Nachrichten anwendet.

ClamAV

Mit ClamAV wird ein Virenscanner in Stellung gebracht, der E-Mails und Anhänge auf Schädlingsbefall hin untersucht. Damit ClamAV die die E-Mail-Anhänge auch auf Virusbefall untersuchen kann, werden neben dem Milter auch noch eine ganze Reihe an Dekomprimierungsprogrammen installiert.

apt-get install clamav-milter arj bzip2 cabextract cpio file gzip lha lzop nomarch p7zip pax rar rpm unrar unzip zip zoo

Nach der Installation sind Änderungen an der Konfigurationsdatei /etc/clamav/clamav-milter.conf vorzunehmen. Die folgenden Zeilen sind auszukommentieren und durch die Zeilen im zweiten Codeblock zu ersetzen.

MilterSocket /var/run/clamav/clamav-milter.ctl
...
OnInfected Quarantine 
...
LogFacility LOG_LOCAL6
MilterSocket /var/spool/postfix/clamav/clamav-milter.ctl
...
OnInfected Accept 
...
LogFacility LOG_MAIL

Die erste Option gibt an, wo der Socket erstellt wird, der auf E-Mails von Postfix wartet. Da wie bei allen anderen Miltern auch der Socket innerhalb des Postfix chroot jail liegen muss, legt man das Verzeichnis für den Socket wie folgt an und setzt die Benutzerrechte entsprechend.

mkdir /var/spool/postfix/clamav
chown clamav:root /var/spool/postfix/clamav/

Die nächste Option erlaubt es, Nachrichten mit infiziertem Inhalt weiterzuleiten, statt sie in Postfix Warteschlange zu belassen. Denn um diese soll sich später Sieve kümmern. Zum Schluss wird ClamAV angewiesen, das Log von Postfix zu verwenden, um bei Problemen nur an einer Stelle suchen zu müssen.

Nun wird noch die Zeile

SOCKET_RWGROUP=postfix

in der Datei /etc/default/clamav-milter einkommentiert. Jetzt ist es Zeit für einen Neustart.

service clamav-daemon restart
service clamav-milter restart

ClamAV beinhaltet freshclam, um automatisch die Virusdefinitionen zu aktualisieren. Zum Abschluss sollte man sich vergewissern, dass der Updatemechanismus korrekt funktioniert. In der Logdatei /var/log/clamav/freshclam.log sollte in etwa folgende Ausgabe zu finden sein:

--------------------------------------
freshclam daemon 0.97.8 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
ClamAV update process started at Sun Mar 16 18:32:49 2014
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.97.8 Recommended version: 0.98.1
DON'T PANIC! Read http://www.clamav.net/support/faq
Downloading main.cvd [100%]
main.cvd updated (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Downloading daily.cvd [100%]
daily.cvd updated (version: 18609, sigs: 824724, f-level: 63, builder: neo)
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 236, sigs: 43, f-level: 63, builder: dgoddard)
Database updated (3248992 signatures) from db.local.clamav.net (IP: 207.57.106.31)
--------------------------------------

Nach der Konfiguration der ganzen Milter ist es jetzt noch nötig, diese in Postfix zu aktivieren. Dazu sind folgende Zeilen in der Datei /etc/postfix/main.cf einzukommentieren und die Konfiguration neu zu laden.

milter_default_action = accept
milter_connect_macros = j {daemon_name} v {if_name} _
non_smtpd_milters = $smtpd_milters
smtpd_milters = unix:/spamass/spamass.sock unix:/clamav/clamav-milter.ctl unix:/opendkim/opendkim.sock
service postfix reload

DNS Konfiguration

Ohne DNS funktioniert kein E-Mailsystem. Damit der Mailserver erreichbar ist, muss im DNS-Manager des eigenen Domainproviders ein MX-Record angelegt werden, welcher auf die öffentliche IP-Adresse oder einen A-Record des eigenen Mailservers zeigt.

Wie genau man einen DNS-Eintrag für die eigene Domain erstellt, ist von Anbieter zu Anbieter unterschiedlich. Zieht dazu am besten die Anleitung bzw. Hilfe eures Anbieters zu Rate. Ich werde am Ende dieses Abschnitts beispielhaft noch ein Bild meines DNS-Providers einfügen.

Als Nächstes wird noch ein TXT-Eintrag benötigt, welcher den öffentlichen DKIM Schlüssel beinhaltet. Dazu kann der Inhalt der Datei /etc/opendkim/mail.txt verwendet werden. Bitte zieht im Zweifel auch hierbei die Hilfe eures DNS-Anbieters zu Rate. Dort sollte beschrieben werden, wie ihr diesen Eintrag am besten erstellt.

Es folgt noch der Eintrag für die Funktionalität des SPF.

dns configuration

Beispielhafte DNS-Konfiguration im Interface von Goneo.

Im obigen Bild sind insgesamt 5 DNS Einträge zu sehen. Bei den ersten beiden Einträgen handelt es sich um einen A-Record für IPv4 und einen AAAA-Record für IPv6. Mit diesen Einträgen wird den IP-Adressen ein Name zugeordnet. Diese beiden Einträge sind nicht zwingend notwendig, man kann sich einen Namen jedoch leichter merken als eine IP-Adresse. In der dritten Zeile sieht man den MX-Record. Dieser gibt Auskunft darüber, welcher Server für die E-Mails einer Domain zuständig ist. Existiert für die Domain kein A-Record, muss hier eine IP-Adresse angegeben werden. Andernfalls kann man, wie in diesem Beispiel, auch einen Namen verwenden.

In Zeile 4 steht der TXT-Eintrag für das Sender Policy Framework (SPF)10 Hier wird festgelegt, welche Server E-Mails für die genannte Domain versenden dürfen.

Und in der letzten Tabellenzeile steht der Eintrag, welcher den öffentlichen DKIM-Schlüssel enthält. Der Name des Eintrags wird dabei nach dem Muster <selector>._domainkey.<domainname.tld> gebildet. Als Wert wird der öffentliche Schlüssel verwendet. Damit kann ein fremder Mailserver die Signatur der E-Mails überprüfen, die von dem eigenen Mailserver versendet werden.

Ein sehr wichtiger Schritt in der DNS Konfiguration fehlt jedoch noch. Es sollte unbedingt noch ein passender PTR-Record konfiguriert werden, welcher ein Reverse-Lookup der IP-Adresse des Servers erlaubt. Fast alle E-Mail-Server versuchen, mit einem Reverse-Lookup die IP-Adresse eines Servers in einen DNS Namen aufzulösen. Entspricht der aufgelöste Name nicht dem Namen aus dem Forward-Lookup, werden die meisten Mailserver die eingehende E-Mail abweisen. Dies ist eine übliche Vorgehensweise, um den Versand von Spam einzudämmen. Denn Spam wird oft von gekaperten Maschinen versendet, oder von Servern, wo sich der Spammer nicht die Mühe macht, den PTR korrekt zu konfigurieren.

dns-reverse

PTR-Einträge für IPv4 und IPv6

Der Screenshot zeigt einen Ausschnitt aus dem DNS-Konfigurationstool von Strato. Es zeigt zwei PTR-Einträge. Jeweils einen für IPv4 und einen für IPv6.

Konsultiert die Hilfe oder den Support eures Anbieters, wenn sich das Menü mit den entsprechenden Konfigurationsmöglichkeiten nicht auf Anhieb finden lässt.

Angeblich gibt es auch noch Hosting-Provider, die ihren Kunden das Recht vorenthalten, einen PTR-Eintrag zu setzen. In diesem Fall kann man sich entweder damit abfinden, dass es mit dem eigenen E-Mailserver nichts mehr wird, oder man wechselt den Hosting-Provider.

Mit E-Mail Filtern gegen Spam

Wir sind nun im letzten Abschnitt von Teil 3 dieser Artikelreihe angelangt. Zum Abschluss kommt die Konfiguration von Sieve, welcher zwei Dinge erledigen soll:

  1. E-Mails filtern, die von SpamAssassin als Spam markiert wurden.
  2. E-Mails filtern, die von ClamAV als virusinfiziert markiert wurden.

Sieve Filter finden sich an mehreren Stellen. Jeder virtuelle Benutzer kann eigene Filter im virtuellen E-Mail Home-Verzeichnis haben (das ist /var/mail/vmail/domainname/Benutzername/sieve). Global definierte Filter befinden sich in /var/mail/vmail/sieve-before und /var/mail/vmail/sive-after. Die Filterregeln in sieve-before werden vor den benutzerdefinierten Filtern angewendet, die in sieve-after nach diesen.

Ich erstelle einen ersten Filter im Verzeichnis /var/mail/vmail/sieve-before, indem ich die Datei masterfilter.sieve erstelle und mit folgendem Inhalt fülle:

# cat masterfilter.sieve 
require ["envelope", "fileinto", "imap4flags", "regex"];
 
# I don't even want to see spam higher than level 10
if header :contains "X-Spam-Level" "**********" {
    discard;
    stop;
}
 
# Twitter? Die in a fire.
if anyof (envelope "From" "bounce@tweet.twitter.com",
          envelope :contains "From" "@bounce.twitter.com") {
    discard;
    stop;
}
 
# Trash messages with improperly formed message IDs
if not header :regex "message-id" ".*@.*\\." {
    discard;
    stop;
}
 
# File low-level spam in spam bucket, and viruses in Infected folder
if anyof (header :contains "X-Spam-Level" "*****",
          header :contains "X-Virus-Status" "Infected") {
    if header :contains "X-Spam-Level" "*****" {
        fileinto "Junk";
        setflag "\\Seen";
    }
    else {
        fileinto "Infected";
    }
}

Sieve wendet die Filter sequentiell von oben nach unten an. Es spielt daher eine große Rolle, an welcher Stelle eine Filterregel erstellt wird.

Der erste Filter wertet das Spam-Scoring aus, welches von SpamAssassin durchgeführt und in den Header der E-Mails eingefügt wird. Dazu prüft der Filter das Feld „X-Spam-Level“ im Header einer E-Mail. Finden sich hier wenigstens zehn „*“, lässt Sieve die E-Mail verschwinden. Die Aktion wird in /var/log/mail.log protokolliert, doch nirgendwo sonst wird man etwas von dieser E-Mail zu Gesicht bekommen. Die Option stop sorgt dafür, dass die übrigen Mailfilter nicht mehr ausgewertet werden.

Der nächste Filter sortiert Twitter-Werbung aus. E-Mails zum Zurücksetzen des Passworts werden von diesem Filter nicht erfasst, da sie von einer anderen Absenderadresse kommen.

Darunter werden E-Mails abgefangen, die über keine gültige Message-ID verfügen. Dieser Filter nutzt reguläre Ausdrücke. In Sieve können reguläre Ausdrücke verwendet werden, die dem RFC 5228 entsprechen.11

Der letzte Filter funktioniert wie folgt. Er prüft, ob ein E-Mail Header entweder ein X-Spam-Level von 5 oder die Markierung „Infected“ enthält und verschiebt sie in den „Junk“-Ordner. E-Mails, die sowohl als Spam klassifiziert sind, als auch einen Virus enthalten, werden in den „Junk“-Ordner verschoben. Nur Mails, die nur einen Virus enthalten, aber nicht als Spam markiert sind, landen im Ordner „Infected“.

Sieve Filter sind extrem komplex. Es würde den Umfang dieser Artikelreihe sprengen, wenn ich versuche, sie allumfassend zu behandeln. Zum tieferen Verständnis empfehle ich die Quellen 1212, 1313 und 1414.

Die Datei masterfile.sieve wandeln wir in eine Binärdatei um. Dabei wird auch gleich eine Syntaxüberprüfung durchgeführt.

sievec masterfilter.sieve

Wird dieses Kommando als root ausgeführt, müssen die Besitzrechte wieder korrigiert werden.

chown vmail:vmail *.svbin

In Teil 4 dieser Artikelreihe werde ich noch darauf eingehen, wie man Sieve-Filter über das Webinterface von Roundcube erstellen kann, ohne sich in die Tiefen der RegEx-Syntax einarbeiten zu müssen.

Einrichtung eines E-Mail Clients (MUA)

Mit dem Ende dieses Artikels ist der Webserver bereits voll einsatzbereit und kann mit einem Mail User Agent genutzt werden. Dies ist ein guter Zeitpunkt, um ein Konto z.B. in Mozilla Thunderbird15 einzurichten, um die Konfiguration zu testen. Die folgenden Screenshots zeigen exemplarisch, wie ein Konto in Thunderbird hinzugefügt wird.

Wer an dieser Stelle bereits die Nase voll hat von den doch recht langen Artikeln, kann sich bereits entspannt zurücklehnen. Denn er betreibt einen für das Internet gewappneten MTA, MDA und MUA mit Anti-Spam und Anti-Virus Modulen.

Ich werde in Teil 4 noch weitergehen und Webmail einrichten, um die konfigurierten Postfächer auch über einen Webbrowser nutzen zu können. Teil 4 wird sich außerdem mit der Möglichkeit beschäftigen, eine zertifikatsbasierte Anmeldung zu konfigurieren.

Wenn ihr ebenfalls noch weitermachen möchtet, sehen wir uns in einer Woche. 😉

Der eigene Mailserver – Teil 2

Herzlich willkommen zurück bei der Artikelreihe „Der eigene Mailserver“.

Der erste Artikel dieser Reihe handelte von dem zu Grunde liegenden Serverbetriebssystem, dem Remote-Zugriff über SSH und der Installation der ersten Pakete.

In dieser Ausgabe geht es vor allem um die folgenden drei Punkte:

  1. Erwerb und Installation eines SSL/TLS Zertifikats.
  2. Grundlegende Konfiguration von Postfix, so dass E-Mails versendet und empfangen werden und Postfix mit Dovecot zusammenarbeitet.
  3. Grundlegende Konfiguration von Dovecot. Es werden drei virtuelle Benutzer und Mailverzeichnisse angelegt.

Und los geht’s!

Eine Sache noch…

Im ersten Artikel dieser Reihe habe ich geschrieben, dass der Betrieb eines Mailservers im Internet eine verantwortungsvolle Aufgabe ist. Dabei habe ich darauf hingewiesen, dass man stets die Sicherheit des eigenen Systems im Blick haben sollte. Daher ist es, denke ich, ein guter Zeitpunkt, an dieser Stelle zu prüfen, ob es Updates für den eigenen Server gibt und diese zu installieren.

Bei einem Ubuntu Server kann dies ganz einfach mit dem folgenden Befehl durchgeführt werden.

:~$ sudo apt-get update && sudo apt-get upgrade

 

SSL/TLS Zertifikat

Bei der Installation von Postfix und Dovecot im letzten Artikel wurde gefragt, ob man ein selbstsigniertes Zertifikat für Dovecot nutzen möchte. Dies habe ich verneint. Denn für einen Mailserver im Internet benötigt man ein gültiges und vertrauenswürdiges Zertifikat.

Gültig und vertrauenswürdig bedeutet in diesem Fall, dass das Zertifikat von einer anerkannten Zertifizierungsstelle ausgegeben wurde. Dieses Zertifikat wird vom Mailserver genutzt, um sich anderen Mailservern gegenüber zu identifizieren. Selbstsignierte Zertifikate oder jene der gemeinschaftlichen Zertifizierungsstelle CAcert werden von anderen Mailservern in der Regel nicht akzeptiert.

Zum Glück gibt es für Privatpersonen die Möglichkeit, kostenlos ein SSL/TLS Zertifikat z.B. bei der Zertifizierungsstelle StartSSL1 zu erhalten. Da ich noch kein Zertifikat besitze, werde ich im folgenden die Schritte dokumentieren, um ein Zertifikat von StartSSL zu erhalten. Für die folgenden Schritte muss JavaScript im Webbrowser aktiviert sein.

Wer bereits über ein gültiges und vertrauenswürdiges Zertifikat verfügt, kann dieses natürlich auch verwenden und diesen Abschnitt überspringen.

startssl-express-lane

Startseite von StartSSL.com

Mit der Express Lane geht es weiter zum nächsten Schritt, wo die Daten zur Person abgefragt werden und die CA Policy akzeptiert werden muss. Anschließend erhält man einen Authentifizierungscode per E-Mail.

Die Authentifizierung bei StartSSL erfolgt nicht wie gewohnt mit Benutzername und Passwort, sondern mittels eines Client-Zertifikats, welches mit Hilfe des Webbrowsers generiert und anschließend im Browser installiert wird.

Anschließend ist man direkt in seinem Account angemeldet und durchläuft den Assistenten, um die eigene Domain zu verifizieren. Man folgt der Express Lane, bis man bei folgendem Schritt angelangt ist. Den privaten Schlüssel sollte man tunlichst nicht auf dieser Seite generieren!2

generate-private-key2

Privater Schlüssel für Domain-Zertifikat

Den privaten Schlüssel sollte man immer auf einem der eigenen Systeme generieren. Dieser gehört niemals in die Hände von Dritten. Auch nicht in die einer Zertifizierungsstelle. Daher erstellen wir den privaten Schlüssel und den Certificate Signing Request (CSR) auf dem eigenen Server.

Da für die folgenden Schritte root-Rechte benötigt werden, wechseln wir mit folgendem Kommando den Benutzer, um uns die Arbeit ein wenig zu erleichtern.

johndoe@server:~$ sudo su
root@server:/home/johndoe#

Nun erstellt man mit dem folgenden Befehl den privaten Schlüssel. Dieser wird als domainname-private-ssl.key gespeichert.

root@server:/home/johndoe# openssl genrsa -out /home/johndoe/domainname-private-ssl.key 4096

Die Angabe 4096 stellt die Stärke bzw. Länge des Schlüssels in Bit dar. Achtung: Schlüssel mit einer Länge von unter 2048 Bit gelten heute nicht mehr als sicher.

Nun kann mit dem nächsten Befehl der CSR erstellt werden. Die Angaben im Code unten stellen dabei Beispiele dar. Beim Common Name ist der Name einzutragen, unter dem der Server später im Internet erreichbar sein wird. Es wird kein „challenge password“ vergeben. Dies müsste später bei jedem Neustart des Webservers eingegeben werden oder im Klartext in einer Textdatei hinterlegt werden. Der erste Fall ist extrem unpraktisch und der zweite extrem unsicher.

root@server:/home/johndoe# openssl req -new -key domainname-private-ssl.key -out /home/johndoe/domainname.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:server.domainname.tld
Email Address []:webmaster@domainname.tld

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
johndoe@server:/home/johndoe#

Den Inhalt des CSR kopiert man nun in das Eingabefeld des Certification Wizard von StartSSL. Man befolgt die weiteren Schritte des Assistenten und am Ende wird das neu erstellte SSL-Zertifikat angezeigt. Dieses kopieren wir nun in die Datei /etc/ssl/private/ssl-cert-mail-yourdomain.pem. Verwendet man dabei einen Editor wie vim, nutzt man :set paste, bevor man den Text des Zertifikats einfügt. Den im vorhergehenden Schritt erstellten privaten Schlüssel und den CSR kopiert man ebenfalls in das Verzeichnis /etc/ssl/private. Jetzt lädt man noch das Intermediate Zertifikat von StartSSL mittels des folgenden Befehls in das gleiche Verzeichnis herunter.

root@server:/home/johndoe# cd /etc/ssl/private/
root@server:/etc/ssl/private# wget https://www.startssl.com/certs/sub.class1.server.ca.pem
--2014-12-20 14:09:08--  https://www.startssl.com/certs/sub.class1.server.ca.pem
Resolving www.startssl.com (www.startssl.com)... 192.116.242.20
Connecting to www.startssl.com (www.startssl.com)|192.116.242.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2212 (2,2K) [application/x509-ca-cert]
Saving to: ‘sub.class1.server.ca.pem’

100%[========================================================================================================================================>] 2.212       --.-K/s   in 0s      

2014-12-20 14:09:09 (63,3 MB/s) - ‘sub.class1.server.ca.pem’ saved [2212/2212]

root@server:/etc/ssl/private#

Als nächstes verknüpft man das Zertifikat mit dem Intermediate-Zertifikat der Zertifizierungsstelle zu einem sogenannten „chain-certificate“. Das sind zwei Zertifikate in einer Datei. Dies ermöglicht es einem Client, die komplette Zertifizierungskette zu überprüfen.

:/etc/ssl/private# cat ssl-cert-mail-domainname.pem sub.class1.server.ca.pem > ssl-chain-mail-domainname.pem

Das soeben erstelle Zertifikat wird später sowohl für Postfix, als auch für Dovecot benutzt. Doch bevor wir fortfahren, schützen wir noch unseren privaten Schlüssel vor unbefugtem Zugriff, indem wir einzig dem root-Benutzer Leserechte auf diese Datei einräumen.

chmod 400 my-it-brain-private-ssl.key

Jetzt wo ich alle Zertifikate in der Reihe habe, geht es an die Konfiguration von Postfix.

/etc/postfix/main.cf

Los geht’s mit:

$ sudo vim /etc/postfix/main.cf

Im Folgenden wird die main.cf dargestellt, wie sie nach der Bearbeitung aussieht. Diese Datei ist nicht für Copy & Paste geeignet. Zum einen funktioniert die Datei nicht und zum Anderen möchte man ja auch erst verstehen, was dort passiert ist. Wer in die Tiefen der Postfix Konfiguration eintauchen möchte, dem sei die offizielle Dokumentation ans Herz gelegt.3 Die wesentlichen Elemente der Konfigurationsdatei werden im Folgenden näher beschrieben.

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
myorigin = /etc/mailname

## Customized smtpd parameters
smtpd_banner = $myhostname ESMTP
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname, permit
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_sender
smtpd_sender_restrictions = reject_unknown_sender_domain, reject_sender_login_mismatch, reject_unknown_sender_domain
smtpd_sender_login_maps = $virtual_mailbox_maps

## Dealing with rejection: use permanent 550 errors to stop retries
unknown_address_reject_code = 550
unknown_hostname_reject_code = 550
unknown_client_reject_code = 550

biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mx.domainname.de
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mx.domainname.de, domainname.de, h2381200.stratoserver.net, localhost.stratoserver.net, localhost, localhost.domainname.de
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot.conf -m "${EXTENSION}"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_authenticated_header = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
smtp_use_tls = yes
smtpd_tls_received_header = yes
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_auth_only = yes
tls_random_source = dev:/dev/urandom

## customized TLS parameters
smtpd_tls_ask_ccert = yes
smtpd_tls_cert_file = /etc/ssl/private/ssl-chain-mail-domainname.pem
smtpd_tls_key_file = /etc/ssl/private/domainname-private-ssl.key
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_ciphers = high
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s

## Customized Dovecot and virtual user-specific settings
canonical_maps = hash:/etc/postfix/canonical
home_mailbox = Maildir/
message_size_limit = 104857600
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_domains = hash:/etc/postfix/virtual-mailbox-domains
virtual_mailbox_maps = hash:/etc/postfix/virtual-mailbox-users
virtual_transport = dovecot

## This setting will generate an error if you restart Postfix before
## adding the appropriate service definition in master.cf, so make
## sure to get that taken care of!
dovecot_destination_recipient_limit = 1

## Other customized mail server settings
default_destination_concurrency_limit = 5
disable_vrfy_command = yes
relay_destination_concurrency_limit = 1
smtp_tls_note_starttls_offer = yes

Ziemlich zu Beginn der Konfigurationsdatei steht die Variable myorigin. Diese enthält den Namen des Mailservers. Auf einem debianbasierten System steht dieser Name in der Datei /etc/mailname.

Es gibt einige smtpd_sasl Optionen in der Datei. SASL ist das Protokoll, über welches Dovcot und Postfix miteinander kommunizieren. Dank des unter Ubuntu verfügbaren Metapakets mail-stack-delivery, welches im letzten Artikel installiert wurde, ist der Großteil der Konfiguration bereits erledigt.

myhostname, mydestination und mynetworks definieren, wer der Mailserver ist und wo (in welchem Netz) sich dieser befindet. Die erste Variable sollte als erstes den FQDN enthalten und nachfolgend einige alternative Namen, unter denen der Mailserver erreichbar ist. Die letzte Variable enthält die Netzadresse in CIDR-Notation. Ihr Wert kann meist so belassen werden, wie man ihn vorfindet.

Mit den smtpd Parametern geht es ans Eingemachte. Denn diese Parameter nehmen direkten Einfluss auf die Arbeitsweise des Mailservers.

Die Option smtpd_banner legt fest, wie sich der Server gegenüber anderen Mailservern identifiziert. Bei Ubuntu enthält diese Option meist noch die Variablen $myhostname und $mail_name zusammen mit dem Zusatz Ubuntu. Um möglichen Angreifern so wenig wie möglich über das eigene System zu verraten, kann diese Option auf das absolut notwendige Minimum gekürzt werden.

smtpd_banner = $myhostname ESMTP

smtpd_helo_required = yes sorgt dafür, dass sich andere SMTP-Server erst identifizieren müssen, bevor Postfix SMTP-Kommandos von diesen akzeptiert. Mit Hilfe dieser und der nächsten Option wird festgelegt, wie Postfix entscheidet, ob Mails akzeptiert oder abgewiesen werden. So wird mit smtpd_helo_restrictions festgelegt, welche HELO Nachrichten akzeptiert werden. permit_mynetworks legt fest, dass Clients aus dem eigenen Netz übermitteln dürfen, was sie wollen. Die übrigen Optionen sind weitestgehend selbsterklärend. Sie weisen den Mailserver an, allen Servern, die einen Namen übermitteln, der nicht über einen DNS-Lookup aufgelöst werden kann, das internationale Zeichen der Freundschaft zu zeigen.

SSL/TLS

Jetzt wird das SSL Zertifikat eingebaut. Zuerst wird mit der Option smtpd_tls_ask_ccert = yes festgelegt, dass Postfix andere Server auffordert, sich mit einem Zertifikat zu identifizieren. Die beiden Optionen smtpd_tls_cert_file und smtpd_tls_key_file enthalten den vollständigen Pfad zum SSL-Zertifikat und der Datei mit dem privaten Schlüssel, welcher zum Zertifikat gehört. smtpd_tls_CAfile enthält den vollständigen Pfad /etc/ssl/certs/ca-certificates.crt und hilft Postfix, die Zertifikate anderer Server zu überprüfen.

Die Option smtp_tls_ciphers = high verbietet Postfix, schwache Verschlüsselungs-Chiffren zu verwenden. smtpd_tls_security_level = may weist Postfix an, SSL/TLS zu verwenden, wenn der entfernte Server dies ebenfalls unterstützt. Damit folgt die Konfiguration dem RFC 2487.

master.cf

Es gibt noch eine Konfigurationsdatei, welche bearbeitet werden muss. /etc/postfix/master.cf steuert, wie Postfix mit anderen Diensten, wie z.B. Dovecot, interagiert. Hier wird festgelegt, dass Postfix auch auf Port 587 auf eingehende E-Mails lauscht und wie er sich mit Dovecot verbindet. Dazu sind zwei Änderungen notwendig.

Die folgende Zeile ist durch Entfernen des # einzukommentieren:

#submission inet n       -       -       -       -       smtpd

Am Ende der Datei wird der folgende Code eingefügt. Wichtig dabei ist, den Zeileneinzug der zweiten und dritten Zeile beizubehalten:

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver
  -f ${sender} -d ${recipient}

Map Files

In den Postfix Konfigurationsdateien finden sich Verweise auf „maps“ und „hashes“. Dies sind Orte, wo Postfix Informationen speichert. Diese werden im Folgenden näher erläutert.

Die Datei /etc/aliases legt fest, welche lokalen Benutzerkonten welchen E-Mail Adressen zugeordnet sind. Damit kann gesteuert werden, an welche E-Mail Adressen Statusmeldungen gesendet werden, die von unterschiedlichen Anwendungen generiert werden. Ich habe meine Datei nach dem folgenden Muster aufgebaut:

postmaster: webmaster@yourdomain.com
root: webmaster@yourdomain.com
www-data: webmaster@yourdomain.com

Damit werden alle lokalen Mails an eine echte E-Mail Adresse gesendet.

Postfix liest seine Informationen jedoch aus einer Binärdatei. Diese wird mit dem folgenden Befehl erstellt.

sudo newaliases

Virtuelle Benutzer

Jetzt geht es darum, wie Postfix entscheidet, wie und wohin er E-Mails zustellt.

Zuerst wird die Datei /etc/postfix/virtual-mailbox-domains erstellt, welche die Domain(s) beinhaltet, für die der Mailserver zuständig ist. Der Inhalt der Datei ist simpel und sieht wie folgt aus.

yourdomain.tld		OK

Aus dieser Map machen wir mit dem folgenden Kommando eine Hash-Datei.

postmap /etc/postfix/virtual-mailbox-domains

Als nächstes wird die Datei /etc/postfix/virtual-mailbox-users erstellt, welche Postfix mitteilt, für welche Benutzer er zuständig ist. Diese Datei besteht aus zwei Spalten. Ganz einfach ausgedrückt wird damit sichergestellt, dass wenn man sich als „name@domainname.tld“ am Dovecot anmeldet, Postfix weiß, dass man E-Mails von der Adresse „name@domainname.tld“ aus versenden darf.

Beispielinhalt der Datei:

you@domainname.tld			you@domainname.tld
postbot@domainname.tld			postbot@domainname.tld
webmaster@domainname.tld		webmaster@domainname.tld

Wenn die Datei angelegt ist, führt man erneut das postmap-Kommando aus.

postmap /etc/postfix/virtual-mailbox-users

Zuletzt wird noch die Map /etc/postfix/virtual erstellt. Mit Hilfe dieser Map können Alias-E-Mail Adressen den echten E-Mail Adressen zugeordnet werden. Die Aliase stehen dabei in der ersten, die ihnen zugeordneten „echten“ E-Mail Adressen in der zweiten Spalte.

Beispiel:

you@domainname.tld		you@domainname.tld
postbot@domainname.tld		postbot@domainname.tld
webmaster@domainname.tld	webmaster@domainname.tld
postmaster@domainname.tld	webmaster@domainname.tld
root@mail.domainname.tld	webmaster@domainname.tld
root@domainname.tld		webmaster@domainname.tld
abuse@domainname.tld		webmaster@domainname.tld
hostmaster@domainname.tld	webmaster@domainname.tld

Benötigt man eine sogenannte Catch-All Adresse, fügt man noch folgende Zeile in die soeben erstellte Datei ein:

@domainname.tld              you@domainname.tld

Ist man mit der Erstellung der Datei fertig, ist es wieder Zeit für postmap:

postmap /etc/postfix/virtual

Ok. Zeit kurz durchzuatmen. Als nächstes legen wir einen Benutzer und ein Verzeichnis an, wo die Mails für unsere virtuellen Benutzer abgelegt werden. Ich halte mich hier an das Tutorial von ars technica und verwende für den benötigten lokalen Benutzer ebenfalls die UID 5000 und die GID 5000.4 Im Dateisystem des Linux Root-Servers existiert bereits das Verzeichnis /var/mail. Hier landen die Mails für die lokalen Benutzer des Systems. Hier wird auch ein Verzeichnis angelegt, wo zukünftig alle Mails der virtuellen Benutzer landen. Dazu werden die beiden folgenden Befehle in einer root shell ausgeführt.

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /var/mail/vmail -m

Jetzt geht es Dovecot an den Kragen.

Als erstes öffnet man die Datei /etc/dovecot/conf.d/10-ssl.conf und kommentiert die Zeilen 12 und 13 aus. Dies erspart Ärger mit der SSL-Konfiguration. Schließlich soll das eigens für den Mailserver erstellte SSL-Zertifikat verwendet werden.

Bevor es an die eigentliche Konfiguration geht, werden noch einige Zeilen in ein paar anderen Konfigurationsdateien auskommentiert, damit die Konfiguration später nicht durch diese Optionen überschrieben wird.

  • Zeile mail_location in 10-mail.conf auskommentieren
  • Zeile auth_mechanisms = plain in 10-auth.conf auskommentieren
  • Die Sektion passdb in der Datei auth-system.conf.ext auskommentieren
  • Die Sektion userdb in der Datei auth-systems.conf.ext ebenfalls auskommentieren

Ist das erledigt, geht es nun der Datei 99-mail-stack-delivery.conf an den Kragen. Nach der Bearbeitung sollte diese wie folgt aussehen.
# /etc/dovecot/conf.d/99-mail-stack-delivery.conf
# Some general options
protocols = imap sieve
disable_plaintext_auth = yes
ssl = yes
ssl_cert = </etc/ssl/private/ssl-chain-mail-cert.pem
ssl_key = </etc/ssl/private/private-ssl.key
ssl_client_ca_dir = /etc/ssl/certs
ssl_cipher_list = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:R
SA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
mail_home = /var/mail/vmail/%d/%n
mail_location = maildir:/var/mail/vmail/%d/%n/mail:LAYOUT=fs
auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@

# IMAP configuration
protocol imap {
mail_max_userip_connections = 10
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}

# LDA configuration
protocol lda {
postmaster_address = webmaster@my-it-brain.de
mail_plugins = sieve
quota_full_tempfail = yes
deliver_log_format = msgid=%m: %$
rejection_reason = Your message to <%t> was automatically rejected:%n%r
}

# Managesieve configuration
#protocol managesieve {
#listen = 127.0.0.1:2000
#login_executable = /usr/lib/dovecot/managesieve-login
#mail_executable = /usr/lib/dovecot/managesieve
#managesieve_max_line_length = 65536
#}

# Plugins configuration
plugin {
sieve=~/.dovecot.sieve
sieve_dir=~/sieve
sieve_before = /var/mail/vmail/sieve-before
sieve_after = /var/mail/vmail/sieve-after
}

# Authentication configuration
auth_mechanisms = plain login

passdb {
driver = passwd-file
args = username_format=%u scheme=ssha512 /etc/dovecot/passwd.db
deny = no
master = no
pass = no
skip = never
result_failure = continue
result_internalfail = continue
result_success = return-ok
}

userdb {
driver = static
args = uid=5000 gid=5000 home=/var/mail/vmail/%d/%n
}

# Log all failed authentication attempts
auth_verbose=yes

service auth {
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/dovecot-auth {
mode = 0660
user = postfix
group = postfix
}
}

Was ist hier alles passiert?

Als Erstes wurde das POP3 Protokoll entfernt, da ich nur IMAP und Sieve nutzen werde. Sieve ermöglicht die Erstellung umfangreicher und flexibler Mailfilter-Regeln. Doch mehr dazu in Teil 3.

Als Nächstes wird SSL aktiviert und Dovecot der Ort des SSL-Zertifikats, des privaten Schlüssels und das Verzeichnis mit den Zertifikaten der Root CAs mitgeteilt.

Die mail_home und mail_location Direktiven legen fest, wo Dovecot die E-Mails zustellt. Hier sind zwei Variablen enthalten. „%d“ steht für die genutzte Maildomain. „%n“ steht für den Namen der virtuellen Benutzer. Dies bedeutet, dass eine E-Mail an „webmaster@domainname.tld“ im Verzeichnis /var/mail/vmail/domainname.tld/webmaster zugestellt wird.

Die mail_location Direktive legt fest, dass das „maildir“ Format5 genutzt wird. Das bedeutet, der Posteingang und weitere Verzeichnisse existieren auf dem Server in Form ganz normaler Verzeichnisse. Maildir ist eines von zwei weit verbreiteten E-Mail Speicherverfahren. Das andere ist MBOX, welches alle Nachrichten in einer einzigen langen Datei speichert. Ich habe mich für die Verwendung von Maildir entschieden, da ich so besser einzelne Nachrichten auf der Kommandozeile behandeln kann. Dies ist von Vorteil bei der Konfiguration und dem Training des Anti-Spam Systems in Teil 3 dieser Artikelreihe.

In der Sektion passdb wird definiert, wie und wo die Passwörter der virtuellen Benutzer gespeichert werden. Die Optionen in dieser Sektion stellen sicher, dass ein Benutzer, der ein falsches Passwort eingibt, keinen Zugriff auf ein Postfach erhält.

Mit den Optionen unter userdb wird festgelegt, dass ein virtueller Benutzer namens „vmail“ verwendet wird.

Bevor die Konfiguration von Dovecot beendet werden kann, sind noch die Passwörter für die virtuellen Benutzer zu vergeben, so dass diese sich mit einem Mailclient mit dem Server verbinden können, um E-Mails zu versenden und zu empfangen. Die Passwörter werden in diesem Fall in der verschlüsselten Datei /etc/dovecot/passwd.db gespeichert. Die Passwörter werden interaktiv in der Konsole generiert, damit sie nicht in der Bash-History gespeichert werden. Dabei hilft das doveadm Tool:

doveadm pw -s SSHA512

Das Tool fordert dazu auf, ein Passwort einzugeben und dieses zu bestätigen. Anschließend gibt es den verschlüsselten und gesalzenen String aus. Anschließend wird die Datei /etc/dovecot/passwd.db erstellt und nach diesem Muster gefüllt:

you@yourdomain.com:{SSHA512}OeR5ulGD3LZ0OHuj9muNqSvKB7hxsxnTquSd8AjK8QXrtOAGqxhxdRs093CzcuaX1PXmOkBGXbQCftYc0tpbo83uZ7Y=
postbot@yourdomain.com:{SSHA512}BPhYH6qtRAtcpCpHxZ919HAve7GGYc4QIIGPIIPCQ2JHhsfVJkzbEsITNL9dvf20YsPNec68LjfLi+TXwS35RrOnElE=
webmaster@yourdomain.com:{SSHA512}o0LG4pTPeHkTZDvqeQufuULcY07YPb2EyA46M5yYtZOAcLI2k4Ee7ADkHSePl/mYdinapCkc7ZEYDvOsi3wg/ungtos=

Jede Zeile startet mit der E-Mail Adresse des dazugehörigen E-Mail Kontos, gefolgt von einem Doppelpunkt und dem kompletten String für das verschlüsselte Passwort.

Der Posteingang und alles Andere

Die wirklich letzte zu bearbeitende Datei ist 15-mailboxes.conf, wo konfiguriert wird, welche Verzeichnisse für jeden virtuellen Benutzer erstellt werden. Hier wird sichergestellt, dass jeder Benutzer seinen eigenen Gesendet-, Entwürfe-, Spam-Ordner und Papierkorb bekommt. Es befinden sich bereits Ordnerdefinitionen in dieser Datei. Diesen fügen wir die Zeile auto = subscribe hinzu. Die Datei sollte ohne Kommentare in etwa wie folgt aussehen:

namespace inbox {
	mailbox Drafts {
		special_use = \Drafts
		auto = subscribe
	}
	mailbox Junk {
		special_use = \Junk
		auto = subscribe
	 }
	mailbox Trash {
		special_use = \Trash
		auto = subscribe
	}
	mailbox Sent {
		special_use = \Sent
		auto = subscribe
	  }
}

Dovecot wird neugestartet und anschließend testet man die Konfiguration mit

dovecot -n

Ähnelt die Ausgabe der folgenden, ist alles korrekt.

$ dovecot -n
# 2.2.9: /etc/dovecot/dovecot.conf
# OS: Linux 3.13.0-042stab092.3 x86_64 Ubuntu 14.04.1 LTS reiserfs
auth_mechanisms = plain login
auth_verbose = yes
mail_home = /var/mail/vmail/%d/%n
mail_location = maildir:/var/mail/vmail/%d/%n/mail:LAYOUT=fs
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  }
  mailbox Junk {
    auto = subscribe
    special_use = \Junk
  }
  mailbox Sent {
    auto = subscribe
    special_use = \Sent
  }
  mailbox Trash {
    auto = subscribe
    special_use = \Trash
  }
  prefix = 
}
passdb {
  args = username_format=%u scheme=ssha512 /etc/dovecot/passwd.db
  driver = passwd-file
}
plugin {
  sieve = ~/.dovecot.sieve
  sieve_after = /var/mail/vmail/sieve-after
  sieve_before = /var/mail/vmail/sieve-before
  sieve_dir = ~/sieve
}
protocols = imap sieve
service auth {
  unix_listener /var/spool/postfix/private/dovecot-auth {
    group = postfix
    mode = 0660
    user = postfix
  }
}
ssl_cert =  was automatically rejected:%n%r
}
protocol imap {
  imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
  mail_max_userip_connections = 10
}

Damit ist das Ende von Teil 2 erreicht. Postfix und Dovecot sind fast vollständig konfiguriert. Was ist noch zu tun?

In Teil 3 dieser Artikelreihe geht es um DNS. Es werden DNS Einträge benötigt, damit Clients den Mailserver finden und auch E-Mails an den richtigen Server geroutet werden können. Außerdem wird es noch um ein paar spezielle DNS-Records gehen, die anderen Servern beweisen sollen, dass wir legitime E-Mails und keinen Spam versenden.

Ebenfalls wird es um eine Anti-Spam Lösung gehen. Spamassassin in Kombination mit einem Virenscanner. Der Mailserver wird nochmal auf Herz und Nieren geprüft und dann im großen weiten Internet bekannt gemacht.

Zum guten Schluss geht es in Teil 4 darum, wie der Webmailer Roundcube installiert und konfiguriert wird. Dieser Teil ist optional, da der Webserver bereist am Ende von Teil 3 fertig für den produktiven Einsatz ist. Aber mal ehrlich, was ist ein Mailsystem schon ohne Webmail?

Bis nächste Woche.

Der eigene Mailserver – Start der Artikelreihe

Wie man den eigenen Mailserver mit eigener Domain möglichst sicher im Internet betreibt wird Gegenstand einer kleinen Artikelreihe sein.

Die Idee dazu kam mir, nachdem ich eine englischsprachige Artikelreihe zum Thema auf ars technica gelesen habe.1 Ich werde nach dem Muster von Lee einen Linux Mailserver aufsetzen und zur Nutzung mit einer eigenen Domain konfigurieren. Die dazu erforderlichen Schritte werde ich in den kommenden Artikeln festhalten. Sie sollen mir als Dokumentation und euch als Leitfaden dienen. Fangen wir an.

Ein paar Worte vorweg

Einen Mailserver im Internet zu betreiben ist eine verantwortungsvolle Aufgabe. Arbeitet man hier nicht sorgfältig, schafft man leicht ein sogenanntes Open Relay, welches sehr schnell als Spamschleuder missbraucht werden wird. Um genau dies zu verhindern, muss man bei jedem Arbeitsschritt die Sicherheit des Systems im Hinterkopf behalten und die eigene Konfiguration permanent auf mögliche Schwachstellen hin überprüfen.

Mit der Installation und Konfiguration ist es nicht getan. Der dauerhafte Betrieb eines Mailservers bringt einige wiederkehrende Aufgaben mit sich. Der Server ist regelmäßig zu warten. Sicherheitsupdates müssen installiert werden, die verwendeten Dienste sollten stets auf die aktuellste Version aktualisiert werden und von Zeit zu Zeit sollte man die Logdateien auf ungewöhnliche Vorkommnisse hin überprüfen.

Diese Artikelreihe wird keine Schritt-für-Schritt Anleitung. Grundlegende Kenntnisse in Linux, der Arbeit in einem Terminal, der Nutzung eines Texteditors und der Umgang mit der Paketverwaltung werden vorausgesetzt. Auch solltet ihr in der Lage sein, euch eure eigene Domain zu shoppen. 😉

Wer auf all dies keine Lust hat, hört am besten hier zu lesen auf. Allen anderen wünsche ich viel Spaß und Erfolg auf dem Weg zum eigenen Mailserver.

Wie ist diese Reihe aufgebaut?

Dieser Artikel gibt eine Einführung in die E-Mail Terminologie. Anschließend gehe ich auf das verwendete Betriebssystem und die Dienste ein, welche zur Realisierung des Mailservers zum Einsatz kommen.

Die Links im Text führen euch auf Seiten, die weiterführende Informationen zum verwendeten Begriff bieten. Die für diese Artikelreihe verwendeten Quellen werden als Fußnoten am Ende des jeweiligen Artikels aufgeführt. Benötigt ihr zur Durchführung einzelner Schritte weitere Informationen, so helfen euch diese Quellen weiter.

Die folgenden Artikel führen durch die Tiefen der Konfiguration, der hier vorgestellten Rollen und Dienste und beschreiben, wie man sein System härtet, um es so gut wie möglich vor Missbrauch zu schützen.

Die Terminologie

Ein Mailserver ist kein einzelner Dienst. Vielmehr setzt sich ein Mailsystem aus unterschiedlichen Komponenten zusammen, die nicht einmal auf demselben Rechner laufen müssen (und es bei größeren Installationen meist auch nicht tun).2

Diese Artikelreihe orientiert sich an der Terminologie aus der Mailserver-Einführung im Wiki von ubuntuusers.de. Die wichtigsten Begriffe möchte ich hier wiedergeben.

  • MTA (Mail Transfer Agent)/SMTP-Server: zuständig für den Transport der Mail von einem System zum anderen (mehr zu MTA und SMTP)
  • MDA (Mail Delivery Agent): stellt die Post auf dem lokalen System zu (mehr zu MDA)
  • MRA (Mail Retrieval Agent): holt Post von einem entfernten Server ab (mehr zu MRA)
  • IMAP-/POP3-Server: hält die Post für den Endbenutzer bereit, damit er sie mit seinem Mailprogramm (MUA – Mail User Agent) abholen und lesen kann (mehr zu IMAP, POP3 und MUA)

Der Server – Das Betriebssystem

Für einen echten E-Mailserver benötigt man einen Server mit einer öffentlichen IP-Adresse, welche im Internet geroutet wird. Hostingprovider, welche diese Server für eine monatliche Gebühr anbieten, findet man mit der Suchmaschine seiner Wahl reichlich im Netz.

Bei der Auswahl eines Hostingproviders kann man sich das erste Mal Gedanken über die Sicherheit machen. Hier empfiehlt es sich auf einen Anbieter setzen, der sich nach dem internationalen Standard ISO 27001 zertifizieren lässt. Diese Norm spezifiziert Anforderungen für die Implementierung geeigneter Sicherheitsmechanismen. So hosten z.B. auch Großbanken ihre Dienste in Rechenzentren, die sich an den Vorgaben der ISO 27001 orientieren.

Wenn man sich einen Root-Server sucht, sollte man außerdem darauf achten, dass der Provider neben der normalen IPv4 Adresse dem Server auch eine IPv6 Adresse spendiert. So stellt man von Anfang an sicher, dass der eigene Mailserver auch über das neue IP-Protokoll erreichbar ist.

Als Betriebssystem für einen Linux Mailserver kann im Prinzip jede beliebige Linux-Distribution dienen, solange die im nächsten Abschnitt genannten Pakete für die gewählte Distribution verfügbar sind.

Aufgrund persönlicher Vorlieben habe ich mich für Ubuntu Server 14.04.1 LTS entschieden. Diese Version verfügt über Long Term Support und wird bis April 2019 mit Sicherheitsaktualisierungen versorgt.

Darüber hinaus ist Ubuntu eine sehr beliebte Distribution, die bei fast allen Hostingunternehmen zur Verfügung steht. Ubuntu stellt dabei ein Metapaket bereit, welches es uns ermöglicht, zügig und sicher ein vollständiges Mailsystem aufzusetzen. Doch später mehr dazu.

Hat man seinen Root-Server bestellt und das Betriebssystem installiert, erfolgt der Zugriff darauf meist via SSH. Der SSH-Dienst wird über die Datei /etc/ssh/sshd_config konfiguriert. Bei Ubuntu ist die Standardkonfiguration schon ganz akzeptabel und bei Verwendung eines starken Passworts auch ausreichend sicher. Statt der Authentifizierung über Benutzername und Passwort kann man sich alternativ auch via Pulbic-Key3 authentifizieren. Damit ist man selbst vor dem unwahrscheinlichen Fall geschützt, dass jemand das verwendete Passwort errät.

Darüber hinaus werden noch einige Optionen in der /etc/ssh/sshd_config wie folgt gesetzt (Erklärung siehe Kommentar im Code):

# Niemand kann sich direkt als root einloggen.
PermitRootLogin no
# Nur die hier aufgeführten Benutzer dürfen sich einloggen.
AllowUsers JohnDoe JaneDoe
# Hiermit wird die Anmeldung mit Benutzername und Passwort deaktiviert.
PasswordAuthentication no 

Anschließend nicht vergessen, die geänderte Konfiguration neu zu laden.

Auf dem Server läuft außer dem OpenSSH-Server noch kein weiterer Dienst. Ob dies so ist, kann man mit dem Kommando netstat überprüfen, welches folgende Ausgabe liefern sollte:

john@server:~$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          150403263   1527/sshd       
tcp6       0      0 :::22                   :::*                    LISTEN      0          150403265   1527/sshd       
john@server:~$

Ok. Damit ist der Root-Server soweit, dass er nur auf SSH-Verbindungen wartet und diese nur akzeptiert, wenn sich ein autorisierter Benutzer mittels publickey authentifiziert.

Der SSH-Dienst ist ein beliebtes Ziel für Brute-Force-Angriffe. Um auch für diese gerüstet zu sein und den Server im Fall einer Attacke etwas zu entlasten, kann man noch zusätzlich das Paket fail2ban4 installieren. Mit diesem Paket ist es möglich, Brute-Force-Angriffe zu erkennen und die IP-Adresse des oder der Angreifer für eine gewisse Zeit zu blockieren. Hierzu setzt fail2ban automatisch die benötigten iptables-Regeln.

Was wird sonst noch benötigt?

Neben dem Betriebssystem benötigt man noch eine ganze Reihe weiterer Dinge. Da sind

  • Postfix, der MTA zum Senden und Empfangen von E-Mail
  • Dovecot, der MDA, welcher uns das Protokoll IMAP bereitstellen wird
  • SpamAssassin, um unseren Posteingang frei von Spam zu halten
  • ClamAV, um auch etwas gegen die Viren zu tun
  • Sieve, damit konfigurieren wir Filterregeln
  • Roundcube, da ein guter Webmailer in keinem Mailsystem fehlen darf
  • NGINX und PHP-FPM, um Roundcube auch ausliefern zu können

All diese Dienste gilt es zu härten und abzusichern. Die Kommunikationsverbindungen werden mit SSL/TLS gesichert. Für die eigene Maildomain werden DKIM und SPF konfiguriert.

Und ganz am Ende haben wir nicht nur einiges über Linux und die Absicherung von Diensten im Internet gelernt, sondern sind ebenfalls im Besitz unseres eigenen Mailservers.

Bevor es jetzt weitergehen kann, müssen die beiden folgenden Voraussetzungen erfüllt sein:

  1. Root-Server mit öffentlicher IP-Adresse und installierten Betriebssystem steht bereit.
  2. Man ist im Besitz einer eigenen Domain und hat einen DNS-Record gesetzt, welcher auf den eigenen Root-Server zeigt.

Und ab dafür

Hat man sich bei der Wahl des Betriebssystems für Ubuntu entschieden, hat man es jetzt leicht. Denn hier gibt es ein Metapaket, welches postfix und dovecot in einem Rutsch installiert und beide Anwendungen so konfiguriert, dass sie miteinander spielen mögen. Dazu führt man folgenden Befehl aus.

:~$ sudo apt-get install mail-stack-delivery

Nach einem kleinen Augenblick erscheint ein Bildschirm, der dazu auffordert, zu entscheiden, ob man ein selbstsigniertes SSL-Zertifikat für Dovecot nutzen möchte oder nicht.

Konfiguriere dovecot-core: Wollen Sie ein selbstsigniertes SSL-Zertifikat erstellen?

Konfiguriere dovecot-core: Wollen Sie ein selbstsigniertes SSL-Zertifikat erstellen?

Für eine reine Testumgebung reicht ein selbstsigniertes Zertifikat aus. Möchte man den Server mit eigener Domain im Internet betreiben, wählt man hier lieber „No“. In Teil 2 dieser Artikelreihe werde ich noch darauf eingehen, wie man an ein SSL-Zertifikat kommt, dem die gängigen Browser und Betriebssysteme vertrauen.

Einen Moment später erscheint eine Konfigurationsabfrage zu Postfix. Hier wählt man die Option „Internet Site“ aus, um später im Internet E-Mails senden und empfangen zu können.

Postfix Configuration: Internet Site

Postfix Configuration: Internet Site

Der nächste Konfigurationsdialog fordert dazu auf, den Domain-Namen des E-Mailsystems anzugeben. Hier wird der Name der eigenen Domain eingetragen. Möchte man den Server ausschließlich in einer Testumgebung im lokalen LAN betreiben, kann man hier auch so etwas wie testdom.local eintragen.

Postfix Configuration: System-E-Mail-Name

Postfix Configuration: System-E-Mail-Name

Anschließend lässt man die Installation bis zu Ende durchlaufen.

Weiter geht es in Teil 2 dieser Artikelreihe. Dort werde ich beschreiben, wie man ein SSL/TLS Zertifikat bekommt sowie wo und wie die Namen und Kennwörter von E-Mail Benutzern samt der zugehörigen Postfächer gespeichert werden. Am Ende von Teil 2 ist das Mailsystem schon fast voll funktionsfähig. Doch ich bin noch lang nicht fertig.

Denn es fehlt noch an AntiSpam, AntiVirus, Filter-Regeln, DKIM, SPF und unser Webmailer Roundcube. Also bleibt dran, es gibt noch viel zu entdecken.

Automatische Installation von Sicherheitsupdates

Wie bei jedem Betriebssystem sollten auch bei Ubuntu regelmäßig Updates installiert werden. Dabei handelt es sich um Fehlerkorrekturen, welche die Stabilität des Systems verbessern und insbesondere potenzielle oder erwiesene Sicherheitslücken schließen.1

Die Installation von Sicherheitsupdates ist eine Aufgabe, die man hervorragend automatisieren kann, um administrativen Aufwand zu sparen. Dazu installiert man unter Ubuntu das folgende Paket:

sudo apt-get install unattended-upgrades

Um die automatischen Updates zu aktivieren, wird die Datei /etc/apt/apt.conf.d/10periodic angelegt bzw. bearbeitet. Diese sollte mindestens die folgenden Einträge enthalten:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

In der Datei /etc/apt/apt.conf.d/50unattended-upgrades wird festgelegt, welche Art von Updates automatisch installiert werden sollen. Möchte man ausschließlich Sicherheitsupdates automatisch installieren lassen, so ist dies mit der folgenden Konfiguration möglich:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Damit ist schon alles Nötige getan. Unter /var/log/unattended-upgrades findet man noch ein Log, um überprüfen zu können, welche Änderungen am System durch die automatische Updateinstallation durchgeführt wurden.

Google will Ende-zu-Ende-Verschlüsselung in den Browser bringen

Beim Stöbern im Internet bin ich über mehrere Artikel gestolpert, die von Googles Plänen berichten, eine Ende-zu-Ende-Verschlüsselung für den Chrome Browser zu entwickeln.

So bin ich auch auf einen Artikel in Googles Security Blog gestoßen. Google schildert in diesem Blog die Absicht, eine „End-to-End“ Erweiterung für den Chrome Browser zu entwickeln, um die Benutzung von sicherer Ende-zu-Ende-Verschlüsselung für den Anwender zu vereinfachen.1

Die Chrome Erweiterung ist jedoch noch nicht erhältlich. Google hat in einem ersten Schritt den Quellcode der Erweiterung veröffentlicht, um ein Code-Review durch die Internet Community zu ermöglichen. Mit dieser Maßnahme möchte Google das Risiko von Fehlern und Schwachstellen im Quellcode minimieren und das Vertrauen in die Erweiterung stärken.

Auf jeden Fall ist dies ein Schritt in die richtige Richtung. Sind die heute verfügbaren Tools wie PGP oder GnuPG doch den meisten Anwendern zu kompliziert in der Anwendung.2

Doch wird Google wohl auch noch einige Zweifel ausräumen müssen. Als US-Konzern unterliegt Google auch der US-Gerichtsbarkeit. Ich frage mich, ob die US-Behörden nicht etwas dagegen haben, wenn Google seinen Kunden eine sichere Kommunikationsverschlüsselung anbietet, welche den Inhalt von E-Mails auch vor den Augen neugieriger NSA-Agenten schützt.

Musste doch im vergangenen Jahr der E-Mail Anbieter Lavabit seinen Betrieb einstellen, da ihn US-Behörden mutmaßlich zur Entschlüsselung und Herausgabe von Kundendaten aufforderten. Warum sollte Google nicht ähnlicher Druck drohen, wenn sie nicht eine Hintertür für die Behörden offen lassen?3

Google hat neben dem Blogpost auch eine Projektseite geschaltet, welche neben dem Quellcode auch einige FAQs bereit hält.4 Diesen ist zu entnehmen, dass die Erweiterung auf OpenPGP basiert, welches einen offenen und sicheren Standard darstellt. Nur ein einziger Abschnitt trübt die aufkommende optimistische Stimmung:

Are the private key(s) kept in memory, are they always purged after every operation, or is there a passphrase cache?

The private keys are kept in memory unencrypted. We recommend making sure your keyring has a passphrase so that private keys are stored encrypted in localStorage.

How safe are private keys in memory?

In memory, the private key is sandboxed by Chrome from other things. When private keys are in localStorage they’re not protected by Chrome’s sandbox, which is why we encrypt them there.

Please note that enabling Chrome’s „Automatically send usage statistics and crash reports to Google“ means that, in the event of a crash, parts of memory containing private key material might be sent to Google.

Auf Deutsch, öffnet man den Schlüsselbund durch Eingabe seiner Passphrase, wird der private Schlüssel in den Arbeitsspeicher geladen. Hat man in seinem Chrome Browser die Funktion aktiviert, automatisch Nutzungsstatistiken und Fehlerberichte an Google zu senden, könnte im Falle eines Browserabsturzes der private Schlüssel mit an Google übertragen werden. Wenn das passiert, bleibt nur das genutzte Schlüsselpaar zu sperren und sich ein Neues zu erstellen. Oder man schaltet von vornherein die Funktion zur Übermittlung von Nutzungsstatistiken und Fehlerberichten an Google ab.

Ob im Quellcode der End-to-End Erweiterung eine Funktion versteckt ist, um den privaten Schlüssel an Google oder einen dritten zu übermitteln, kann ein Code-Review durch die Community zeigen. Ob eine entsprechende Version im Chrome Browser selbst versteckt ist, wird hingegen nicht so schnell festzustellen sein, da der Quelltext nicht komplett offen liegt.

Ehrlich gesagt würde ich mich sicherer fühlen, wenn eine solche Funktion von einem Unternehmen entwickelt würde, das an deutsche Gesetze gebunden ist. Darum bin ich umso mehr gespannt, was die Community und Security-Experten zur neuen Erweiterung sagen. Ich bleib auf jeden Fall dran und halte euch auf dem Laufenden.

Auf dem Weg zur DE-Mail Adresse

Vor noch nicht allzu langer Zeit habe ich die De-Mail und den ePostbrief an dieser Stelle
als Rohrkrepierer bezeichnet. Doch habe ich die beiden Angebote nicht
aus den Augen verloren und beobachte gespannt die weitere Entwicklung.

Bisher habe ich in Erfahrung gebracht, dass der ePostbrief weiterhin kein Angebot bietet, welches dem De-Mail Gesetz entspricht. Via Twitter teilte mir die verantwortliche Stelle der Post jedoch mit, dass ein entsprechendes Angebot in Vorbereitung ist, welches sich aktuell in der Auditierungs- und Akkreditierungsphase befindet. Ich bleibe hier am Ball und warte wann der De-Mail Service der Post an den Start geht.

Etwas weiter bin ich bei der De-Mail. Hier habe ich heute die Identitätsprüfung für den De-Mail Dienst der Deutschen Telekom abgeschlossen. Ein kurzer Besuch im Telekom Shop genügte. Hier wurde das Ident-Formular ausgefüllt und mit einem gültigen Lichtbildausweis die Identität des Antragstellers verifiziert. Besitzt man schon den neuen Personalausweis kann die Registrierung und Identifizierung komplett online erfolgen.

Doch wofür braucht man die De-Mail nochmal? Die Antwort ist eigentlich ganz einfach. Die klassische E-Mail kann mit einer Postkarte verglichen werden. Jeder der sie in die Hände bekommt kann sie lesen. Auf das Internet übertragen bedeutet dies, dass jeder Server, den die Mail auf dem Weg zum Empfänger durchläuft, den Inhalt der Mail lesen und auch verändern kann. Bei der De-Mail hingegen soll dies durch den Einsatz einer Transportverschlüsselleung (TLS) verhindert werden. Damit soll die De-Mail so sicher sein wie ein klassischer Brief, dessen Integrität durch das Briefgeheimnis sichergestellt wird.

Nun halten einige die De-Mail für überflüssig. Schließlich gibt es bereits seit Jahren Verfahren zur E-Mail Verschlüsselung, die eine sichere und vertrauliche Kommunikation auch via E-Mail sicherstellen. Doch jeder, der bereits versucht hat die E-Mail Verschlüsselung der Generation unserer Eltern näher zu bringen wird zugeben, dass dies alles andere als leicht ist. Denken doch die meisten Menschen, wenn sie GnuPG hören, eher an eine neue Tierart aus Afrika, als an den GNU Privacy Guard. Die Usability ist furchtbar und nur IT-Spezialisten und echte Nerds greifen darauf zurück. Daher konnte sich die E-Mail Verschlüsselung bisher auch nur in Bereichen durchsetzen, wo die vertrauliche Kommunikation zwingend erforderlich ist.

De-Mail bietet hier eine echte Chance die sichere, rechtsverbindliche und vertrauliche Kommunikation über das Internet massentauglich zu machen.

Auch preislich ist der Dienst nicht unattraktiv. Bei der Telekom kostet die
Standard De-Mail nach der Ausschöpfung des Freikontingents nur 0,39€
brutto. Im Vergleich zum Porto von 0,58 € für einen Standardbrief schon
eine deutliche Ersparnis.

Ich bin jetzt jedenfalls für die De-Mail
gerüstet und hoffe, dass im Laufe des Jahres möglichst viele
öffentliche Einrichtungen und Unternehmen der Privatwirtschaft ebenfalls
die Möglichkeit schaffen, die Kommunikation via De-Mail abzuwickeln.
Denn nur wenn diese Institutionen mitziehen wird sich die De-Mail
durchsetzen können und einen echten Mehrwert bieten. Und so werde ich
skeptisch und gespannt die weitere Entwicklung der De-Mail beobachten.