Automatische Rotation von DKIM-Schlüsseln 
von Stefan Neben (Immobilien Scout GmbH)
Samstag, 10.05.2014, Stage 11, 16:00-16:30 Uhr
Track: Security nach Snowden
Das Verfahren Domainkeys Identified Mail (DKIM) basiert auf asymmetrischer Verschlüsselung. Die E-Mail wird mit einer Digitalen Signatur versehen, die der empfangende Server anhand des öffentlichen Schlüssels, der im Domain Name System (DNS) der Domäne verfügbar ist, verifizieren kann. Schlägt dies fehl, hat der empfangende Mail Transfer Agent (MTA) oder das empfangende Anwendungsprogramm die Möglichkeit, die E-Mail zu verweigern oder auszusortieren.
Admins wünschen sich eine System-Landschaft mit einem hohen Automationsgrad: Einmal angeworfen, soll die Maschinerie laufen. Eingriffe sollen nur nötig sein, wenn sich die Struktur verändert. Das IS24-System-Engineering-Team hat vor kurzem ein spannendes Projekt zur automatischen Rotation von DKIM-Schlüsseln erfolgreich beendet, das nun ein Stück dieser automatisierten System-Landschaft darstellt.
Dieser Ablauf wurde nötig, um den Zugriff auf sensible Elemente zu erneuern, wenn Mitarbeiter das Unternehmen verlassen. Das betrifft besonders Passwörter und Schlüssel. Diese Aufgabe ist unliebsam und zögert sich daher in der Regel hinaus, wenn sie überhaupt passiert. Zusätzlich müssen Admins im Falle einer Kompromittierung schnell handeln! Eine bestehende Automation, die nur über einen Kommandozeilen-Aufruf getriggert werden kann, spart auch hier Zeit und vor allem Nerven.
Bezogen auf DKIM stellen sich mehrere Herausforderungen: Wie stelle ich sicher, das keine fehlerhaften Konfigurationen auf den Zielsystemen landen? Wie konstruiere ich alles, das ein durch Tests abgebrochender Rollout-Vorgang nicht das produktive Setup negativ beeinflusst?
Vergleichbares Testen kann nur mit produktiven DNS TXT-Records stattfinden. Wie stelle ich (natürlich voll automatisiert) sicher, das zum Zeitpunkt des Integrationstests ein produktiver und entsprechender DNS TXT-Record besteht? Mails können (per default drei) Tage signiert in der Mail-Queue hängen. Was kann passieren, wenn eine Schlüssel-Rotation genau in dieser Zeit stattfindet und wie kann ich das verhindern?
Der Vortrags erläutert, wie das Beispiel-Setup mittels Postfix, OpenDKIM und Milter betrieben wird. Ein Cron-Aufruf triggert ein Python-Skript, das seinerseits dazu die Schlüssel erzeugt. Die generierten Schlüssel liegen dazu im SVN und werden per RPM-Paket auf die jeweiligen Systeme gebracht. Fehlertoleranz schaffen ein Paket-Staging über verschiedene Repositorys, und Integrationstests mit dem frisch erstellten Schlüssel-RPM. Dazu sendet ein Python-Skript sendet eine Nachricht per E-Mail an den Test-MTA, der signiert sie und sendet sie an einen Blackhole Postfach-Server. Schließlich holt das selbe Python-Skript diese Nachricht wieder ab und validiert die DKIM-Signatur.
Ein Fehler stoppt das Propagieren des RPM-Pakets, ansonsten rollt der Prozess es auf dem Ziel-System aus. Weiterhin ist die Lösung in das Nagios-Monitoring eingebunden, das kontinuierlich die Fehlerfreiheit der produktiven Signierung überprüft. Dazu setzt das Team Bind als DNS-Server ein. Alle erwähnten Python-Skripte werden in Kürze auf Github veröffentlicht.
Über den Autor Stefan Neben:
Stefan Neben finished his Master in Information Technology in 2008. He started to work at Heinlein Professional Linux Support GmbH in 2008. There he worked as Administrator for the productive Mail-Servers, gives Courses about linux essentials and bash scripting and act as a system integrator for the Heinlein-Mailappliance. Further he authored the initial Heinlein-Mailtrace-Daemon in perl.
In 2012 he changed to Immobilienscout24, were he worked in the system engineering team untli today. The main goal is to create a fully automated datacenter in every aspect. To reach this a wide range of topics have to be handled (VM provisioning, configuration management, monitoring, infrastructure testing, much scripting, ...). And the work is still going on ...