Der eigene Mailserver – Teil 4

Herzlich willkommen zum vierten und letzten Teil dieser Artikelreihe. An dieser Stelle haben wir bereits einen voll funktionsfähigen und sicher konfigurierten E-Mail Server. E-Mailkonten können im MUA unserer Wahl eingerichtet und genutzt werden. Auf dem Server selbst können mit Leichtigkeit neue Benutzer, Mailboxen und Aliase angelegt werden. Was bleibt also noch zu tun?

Dieser Artikel beschreibt wie man das System noch weiter härten kann. Es wird gezeigt, wie der Webmailer RoundCube eingerichtet wird und wie man den Zugriff auf diesen absichert. Der Artikel endet mit einem kleinen Ausblick, um welche Features der Server noch erweitert werden könnte.

Und los geht’s!

DNS-based Blackhole List (DNSBL)

DNS-based Blackhole Lists oder kurz DNSBL sind Listen, welche von IP-Adressen oder Adressbereiche enthalten, von denen aus Spam versendet wurde.

SpamAssassin, welches in Teil 3 eingerichtet wurde, prüft bereits etliche dieser Listen und markiert eingehende E-Mails entsprechend. Dieser Artikel geht noch einen schritt weiter und beschreibt wie Postfix so konfiguriert werden kann, dass E-Mails auf Basis dieser Listen abgewiesen werden. Dazu wird in Postfix die Funktion Postscreen[1. Postfix Postscreen Howto] aktiviert.

Um Postscreen zu aktivieren, muss die Datei /etc/postfix/master.cf bearbeitet werden. Zu Beginn der Datei sollten folgende Einträge zu finden sein:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd
#smtp      inet  n       -       -       -       1       postscreen
#smtpd     pass  -       -       -       -       -       smtpd
#dnsblog   unix  -       -       -       -       0       dnsblog
#tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd

Hier ist die erste Zeile aus- und die folgenden vier einzukommentieren, so dass die Zeilen anschließend wie folgt aussehen:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
#smtp      inet  n       -       -       -       -       smtpd
smtp      inet  n       -       -       -       1       postscreen
smtpd     pass  -       -       -       -       -       smtpd
dnsblog   unix  -       -       -       -       0       dnsblog
tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd

Falls diese Zeilen fehlen sollten, müssen sie am Anfang der master.cf eingefügt werden. Durch diese Zeilen werden die benötigten lokalen Ports und Unix Sockets, für den Postscreen Prozess, geöffnet.

Nach dieser Änderung ist die Datei /etc/postfix/main.cf am Ende um folgende Einträge zu ergänzen. Hier wird Postfix mitgeteilt, dass Postscreen zu nutzen ist und welche DNSBLs verwendet werden sollen.

postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_access_list = permit_mynetworks
postscreen_dnsbl_sites = zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net

Die erste Zeile bewirkt, dass alle Server abgewiesen werden, die versuchen den Verbindungsaufbau in irgendeiner Form abzukürzen (um schneller Spam versenden zukönnen). In Zeile 2 wird die Prüfung anhand von DNSBLs aktiviert. Zeile 3 fügt den Inhalt der Variable „mynetworks“ hinzu, um LAN Clients von der Prüfung auszuschließen. In der vierten Zeile werden schließlich drei DNSBLs angegeben, welche zur Prüfung herangezogen werden.

Es können natürlich auch mehr, als drei DNSBLS angegeben werden. Darüber hinaus bietet Postscreen noch eine Reihe weiterer Konfigurationsparameter. Für weitere Informationen zu diesen Parametern wird auf die Dokumentation verwiesen.[2. Postfix – Postscreen DNSBL Konfigurationsoptionen]

Jetzt kann Postfix mit dem Befehl

sudo service postfix restart

neugestartet werden und schon ist die neue Konfiguration aktiv. Wer sehen möchte wie Postscreen arbeitet, kann sich selbst eine E-Mail senden und das Log /var/log/mail.log studieren.

Webmail mit allem was dazugehört

Wenn es um Webmail geht, ist zuerst die Entscheidung zu fällen wo Webmail gehosted werden soll und welche Anwendung man dafür verwenden möchte. Für große Umgebungen ist man gut beraten Webmail auf einem separaten Server zu installieren. Für die eingene kleine Umgebung kann man Webmail jedoch auch mit auf dem E-Mailserver installieren, wenn der eigene Server über genügend RAM und CPU Leistung verfügt.

Die im Folgenden beschriebene Webmail-Konfiguration setzt sich im wesentlichen aus diesen Anwendungen zusammen:

Jede der genannten Anwendungen ist so umfangreich, dass man ihnen einen eigenen Artikel oder gar eine eigene Artikelreihe widmen kann. Dieser Artikel beschränkt sich daher darauf, eine möglichst sichere Webmail-Konfiguration zu erstellen.

Wo möglich verwende ich die Version einer Anwendung, welche über die Paketquellen zur Vergfügung gestellt wird. Da PHP-FPM nicht in den Paketquellen für Ubuntu 14.04.1 enthalten ist, greife ich hierbei auf ein PPA zurück.

Als erstes werden Nginx und MySQL aus den Paketquellen installiert.

sudo apt-get install nginx-full mysql-server

Zusammen mit den Paketen werden alle benötigten Abhängigkeiten installiert. Nach einigen Minuten wird man aufgefordert ein Passwort für den MySQL-Benutzer „root“ zu vergeben. Für diesen Benutzer sollte ein möglichst langes und komplexes Passwort vergeben werden.

PHP-FPM ist in Trusty noch nicht in den Paketquellen enthalten. Daher wird zuerst ein PPA zur Paketverwaltung hinzugefügt.

add-apt-repository ppa:ondrej/php5
apt-get update
apt-get install php5-fpm php5-mysqlnd php-pear php5-mcrypt php5-intl

Fall man beim Hinzufügen des PPA die folgende Fehlermeldung erhält, fehlt noch ein Paket, welches wie folgt nachinstalliert werden kann. Anschließend kann das PPA wie oben beschrieben hinzugefügt werden.

:~$ sudo add-apt-repository ppa:ondrej/php5
sudo: add-apt-repository: command not found
:~$ sudo apt-get install software-properties-common
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  gir1.2-glib-2.0 libcurl3-gnutls libdbus-glib-1-2 libgirepository-1.0-1
  librtmp0 python3-dbus python3-gi python3-pycurl python3-software-properties
Vorgeschlagene Pakete:
  python-dbus-doc python3-dbus-dbg libcurl4-gnutls-dev python3-pycurl-dbg
Die folgenden NEUEN Pakete werden installiert:
  gir1.2-glib-2.0 libcurl3-gnutls libdbus-glib-1-2 libgirepository-1.0-1
  librtmp0 python3-dbus python3-gi python3-pycurl python3-software-properties
  software-properties-common
0 aktualisiert, 10 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 818 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 3.451 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J

Im Anschluss an die Installation wird der PHP Interpreter konfiguriert. Dazu gehört, dass PHP-FPM statt über TCP Sockets über UNIX Sockets kommuniziert. Dazu wird in der Datei /etc/php5/fpm/pool.d/www.conf folgende Zeile einkommentiert, bzw. hinzugefügt, falls sie fehlt.

listen = /var/run/php5-fpm.sock

Anschließend werden die Zugriffsrechte für den Socket korrekt gesetzt.

listen.owner = www-data
listen.group = www-data

Hier kann noch eine Menge mehr konfiguriert werden. Zum Beispiel kann PHP-FPM zur Nutzung von memcached konfiguriert werden, welches die Auslieferung von PHP-Anwendungen beschleunigt. Dies würde jedoch den Umfang dieser Artikelreihe sprengen. Steht genügend RAM zur Verfügung, sei auf die Dokumentation zu PHP-FPM verwiesen, um memcached einzurichten.

Wie nach allen Änderungen an Konfigurationsdateien, ist auch hier der betroffene Dienst neu zu starten.

service php5-fpm restart

Nun geht es wieder um Nginx. Als erstes wird die Hauptkonfigurationsdatei /etc/nginx/nginx.conf bearbeitet. Sie sollte anschließend wie folgt aussehen:

user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
	worker_connections 1024;
	multi_accept on;
}

http {
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 10 10;
	types_hash_max_size 2048;
	server_tokens off;
	port_in_redirect off;
	client_max_body_size 4096k;
	client_body_timeout 10;
	client_header_timeout 10;
	send_timeout 10;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	# Gzip Settings
	gzip on;
	gzip_disable "msie6";
	gzip_min_length 1100;
	gzip_vary on;
	gzip_proxied any;
	gzip_buffers 16 8k;
	gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/rss+xml text/javascript image/svg+xml application/x-font-ttf font/opentype application/ vnd.ms-fontobject;

	# Sitewide SSL settings
	ssl_session_cache shared:SSL:10m;
	ssl_buffer_size 4k;

	# Sitewide proxy settings
	set_real_ip_from 127.0.0.1;
	real_ip_header X-Forwarded-For;

	# Virtual Host Configs
	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

Der Wert von worker_processes ist auf die Anzahl der physikalisch vorhandenen CPU Cores zu setzen.

Als nächstes wird die Datei /etc/nginx/conf.d/php5-fpm.conf mit folgendem Inhalt erstellt.

upstream php5-fpm-sock {
	server unix:/var/run/php5-fpm.sock;
}

Damit wird eine Variable namens „php5-fpm-sock“ erstellt, welche auf den Unix Socket verweist.

Nun wird die Datei /etc/nginx/sites-available/roundcube erstellt und mit folgendem Inhalt befüllt.

server {
	server_name www.domainname.tld;
        listen 80;
	return 301 https://mail.domainname.tld$request_uri;
}

server {
	server_name mail.domainname.tld;
        listen 80;
	return 301 https://$host$request_uri;
}

# HTTPS server
server {
	listen 443 ssl spdy default_server;
	server_name mail.domainname.tld;
	root /usr/share/nginx/roundcube;
	index index.html index.php;
	autoindex off;

	ssl on;
	ssl_certificate /etc/ssl/private/ssl-chain-mail-domainname.pem;
	ssl_certificate_key /etc/ssl/private/domainname-private-ssl.key;
	ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
	ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS;
	ssl_prefer_server_ciphers on;
	ssl_ecdh_curve secp521r1;

	# Client auth via certs
#	ssl_client_certificate /etc/ssl/private/yourdomain.crt;
#	ssl_trusted_certificate /etc/ssl/private/yourdomain.crt;
#	ssl_verify_client on;

	location / {
#		if ($ssl_client_s_dn !~* "you@yourdomain.com") {
#			return 301 http://www.jurassicsystems.com/;
#		}
#		error_page 403 @fallback;
	}

	location ~ ^/(README|INSTALL|LICENSE|CHANGELOG|UPGRADING)$ {
		deny all;
	}

	location ~ ^/(bin|SQL)/ {
		deny all;
	}

	location ~ ^/.*\.php {
		try_files $uri =404;
		include fastcgi_params;
		fastcgi_pass php5-fpm-sock;
		fastcgi_param HTTPS on;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_intercept_errors on;
	}

	location @fallback {
		return 301 http://www.domainname.tld/;
	}
}

Ist die Datei erstellt wird ein symbolischer Link im Verzeichnis /etc/nginx/sites-enabled erstellt und der Link auf die Standardseite gelöscht.

ln -s /etc/nginx/sites-available/roundcube /etc/nginx/sites-enabled/roundcube
rm /etc/nginx/sites-enabled/default

Anschließend benötigt Nginx einen Neustart.

Sind Webserver und Interpreter funktionsfähig, wird es Zeit sich um die MySQL Datenbank zu kümmern.

Erstellung der Datenbank

Zum Glück gibt es hier nicht viel zu tun. Der MySQL Server ist in der Standardkonfiguration bereits recht sicher konfiguriert. Mit dem hier beschriebenen Setup wird der MySQL Server nicht aus dem Internet erreichbar sein und diesen Umstand sollte man nicht ändern.

Als Erstes startet man das SQL Interfaces und verbindet sich mit dem root-Benutzer.

mysql -u root -p

Mit den folgenden Kommandos wird nun eine Datenbank für roundcube angelegt und ein Benutzer mit Zugriffsrechten auf diese Datenbank erstellt.

create database roundcubedb;
grant all on roundcubedb.* to 'roundcubedb'@'localhost' identified by 'enter-a-password-here';
exit

Fertig. Webserver, PHP Interpreter und Datenbankserver inkl. Benutzer sind einsatzbereit. Jetzt fehlt nur noch die eigentliche Webmail Anwendung.

Installation von Roundcube

Die Webmail Anwendung wird direkt von der Roundcube Download Seite heruntergeladen. Auf dem Server können wir den Download direkt auf der Kommandozeile starten.

http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/1.0.4/roundcubemail-1.0.4.tar.gz
tar -xzvf roundcubemail-1.0.4.tar.gz

Anschließend wird das entpackte Verzeichnis an die korrekte Stelle im Dateisystem manövriert und die Zugriffsrechte korrekt gesetzt.

rm -rf /usr/share/nginx/roundcube
mv /usr/share/nginx/roundcubemail-1.0.4 /usr/share/nginx/roundcube
chown -R www-data:www-data /usr/share/nginx/roundcube

Nun wird die URL https://mail.domainname.tld/installer im Webbrowser aufgerufen und der Webinstaller gestartet.

roundcube-webmail-installer

Start des Roundcube Webmail Installationsprogramms

Auf der Startseite des Installationsprogramms wird geprüft, ob alle Voraussetzungen für die Installation erfüllt sind. Hier sollte alles OK sein, außer bei den nicht installierten DBMSs und der Datums- und Zeitkonfiguration ganz am Ende der Seite.

Auf der zweiten Seite sind die Optionsfelder mit den individuellen Werten der eigenen Installation auszufüllen. Das Feld product_name sollte auf einen Wert gesetzt werden, der beschreibt, um wessen Webmailer es sich hierbei handelt. Die Checkbox ip_check sollte aktiviert werden, um Roundcube’s Session-Sicherheit zu steigern. Des Weiteren sollte der Wert des Felds identities_level auf „many identities with possibility to edit all params but not email address“ gesetzt werden. Damit sind Benutzer in der Lage alle Optionen in Roundcube anzupassen, ohne die eigene E-Mail Adresse ändern zu können. Damit ist es ihnen möglich ihr eigenes Passwort zu ändern.

Anschließend werden die Angaben zur eigenen Datenbank gemacht. Das Feld db_prefix kann leer gelassen werden.

Abschließend wird mit einem Klick auf Create Config die Konfigurationsdatei /usr/share/nginx/roundcube/config.inc.php erstellt. Die folgende Seite kann mit einem Klick auf Continue bestätigt werden.

Roundcube_Config_created

Die Roundcube Konfiguration wurde erstellt.

Auf der letzten Seite des Installers wird mit einem Klick die Datenbank initialisiert. Darüber hinaus können hier noch weitere Tests ausgeführt werden. Verlaufen alle Tests erfolgreich, so ist es geschafft. Bevor man den eigenen Roundcube Webmailer nutzt, sollte man noch das Verzeichnis des Webinstallers entfernen.

rm -rf /usr/share/nginx/roundcube/installer

Herzlich willkommen im eigenen Webmail-Interface.

roundcube-webmail-interface

Roundcube Webmail Interface

Damit sind wir am Ende der vierteiligen Artikelreihe angelangt. Nach einem langen Weg ist der eigene E-Mail Server fertig. Er kann E-Mails empfangen und versenden. Und dies von Desktop Mailclients, Smartphones, Tablets oder via Webmail. Der Server ist sicher konfiguriert und es wurde alles getan, damit die eigenen Mails nicht von fremden Spamfiltern herausgefischt werden.

Persönliches Fazit

Zuerst möchte ich Lee Hutchinson danken, dessen hervorragende, englischsprachige Artikelreihe[3. Taking e-mail back, part 4: The finale, with webmail & everything after] mich dazu angeregt hat, mich selbst an einem E-Mail Server Projekt zu versuchen.

Am Ende dieser Artikelreihe habe ich viel über E-Mail im allgemeinen sowie MTAs, MDAs und MUAs im speziellen erfahren. Darüber hinaus konnte ich mich mit etlichen Techniken beschäftigen, die helfen, einen Server zu härten und vor den Gefahren des Internets zu schützen. Allein das war es wert, den ganzen Konfigurationsaufwand auf sich zu nehmen. Und hey, ich habe jetzt meinen eigenen Mailserver. :-)

Ich kann mir vorstellen, zukünftig auf dem bisher erreichten aufzubauen. So ist es denkbar eine zertifikatbasierte Webmail-Anmeldung zu implementieren oder einen Kalenderserver zu integrieren. Mehr dazu in folgenden Artikeln.

Ein paar Worte noch zum Schluss. Haltet euer System stets Up-to-Date!

Ihr könnt euch die Arbeit ein klein wenig erleichtern, in dem ihr die Installation von Sicherheitsupdates auf dem Server automatisiert.

Ihr seid für die Sicherheit eures Servers verantwortlich. Pflegt ihn und haltet ihn aktuell. Nichts ist schlimmer als veraltete Systeme, die im Internet vor sich hin gammeln.

2 Gedanken zu „Der eigene Mailserver – Teil 4

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.