Automatische Rotation von DKIM-Schlsseln

von Stefan Neben (Immobilien Scout GmbH)

Das Verfahren Domainkeys Identified Mail (DKIM) basiert auf asymmetrischer Verschlsselung. Die E-Mail wird mit einer Digitalen Signatur versehen, die der empfangende Server anhand des ffentlichen Schlssels, der im Domain Name System (DNS) der Domne verfgbar ist, verifizieren kann. Schlgt dies fehl, hat der empfangende Mail Transfer Agent (MTA) oder das empfangende Anwendungsprogramm die Mglichkeit, die E-Mail zu verweigern oder auszusortieren.

Admins wnschen sich eine System-Landschaft mit einem hohen Automationsgrad: Einmal angeworfen, soll die Maschinerie laufen. Eingriffe sollen nur ntig sein, wenn sich die Struktur verndert. Das IS24-System-Engineering-Team hat vor kurzem ein spannendes Projekt zur automatischen Rotation von DKIM-Schlsseln erfolgreich beendet, das nun ein Stck dieser automatisierten System-Landschaft darstellt.

Dieser Ablauf wurde ntig, um den Zugriff auf sensible Elemente zu erneuern, wenn Mitarbeiter das Unternehmen verlassen. Das betrifft besonders Passwrter und Schlssel. Diese Aufgabe ist unliebsam und zgert sich daher in der Regel hinaus, wenn sie berhaupt passiert. Zustzlich mssen 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 (natrlich voll automatisiert) sicher, das zum Zeitpunkt des Integrationstests ein produktiver und entsprechender DNS TXT-Record besteht? Mails knnen (per default drei) Tage signiert in der Mail-Queue hngen. Was kann passieren, wenn eine Schlssel-Rotation genau in dieser Zeit stattfindet und wie kann ich das verhindern?

Der Vortrags erlutert, wie das Beispiel-Setup mittels Postfix, OpenDKIM und Milter betrieben wird. Ein Cron-Aufruf triggert ein Python-Skript, das seinerseits dazu die Schlssel erzeugt. Die generierten Schlssel 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 Schlssel-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. Schlielich 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 Lsung in das Nagios-Monitoring eingebunden, das kontinuierlich die Fehlerfreiheit der produktiven Signierung berprft. Dazu setzt das Team Bind als DNS-Server ein. Alle erwhnten Python-Skripte werden in Krze auf Github verffentlicht.

Ü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 ...