Skip to content

systemd-Unit für srsd unter Debian

Ich fürchte, das wird einer dieser Beiträge, bei dem die notwendige Vorrede bald länger wird als der Beitrag selbst …

Aber fangen wir einfach einmal vorne an: Der Kampf gegen unerwünschte E-Mails, die einen mit Malware oder Angeboten für die Verlängerung oder Vergrößung verschiedenster Körperteile (neuerdings auch - noch sachnah - gerne für den Wechsel der Krankenkasse) beglücken, heutzutage meist als Spam bezeichnet, tobt seit Jahrzehnten. Nach den verschiedensten Filtern entstanden auch mehrere Ansätze, die gar nicht so sehr den Spam an sich bekämpfen, sondern weiter vorne - oder auch parallel - ansetzen und die (meist mit Spam verbundene) Fälschung von Absenderadressen verhindern bzw. umgekehrt eine (begrenzte) Garantie für die Echtheit des Absenders übernehmen wollen.

SPF und DKIM

Dazu gehören SPF (Sender Policy Framework, früher: sender permitted from) und DKIM (DomainKeys Identified Mail).

Bei SPF nutzt der Verantwortliche für eine Domain (meist ein Provider) das DNS (Domain Name System), um dort bekanntzugeben, von welchen Servern (welchen IP-Adressen) “echte” Mail mit einem Absender aus dieser Domain stammen dürfen. So kann bspw. GMX festlegen, dass legitime Mail mit einem Absender @gmx.net (also bspw. irgendwer@gmx.net) nur von einem ihrer Mailserver ausgehen dürfen:

thh@thangorodrim:~$ host -t txt gmx.net 
gmx.net descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

(Da sieht man dann auch direkt das erste Problem: wer als Kunde von GMX eine E-Mail mit seiner GMX-Adresse über einen anderen Mailserver versenden will, steht vor Schwierigkeiten.)

SPF funktioniert besonders gut zusammen mit DNSEC, also digital signierten DNS-Einträgen, deren Echtheit sich prüfen lässt.

DKIM geht einen Schritt weiter und publiziert nicht (nur) eine (sich ggf. oft ändernde) Liste legitimer Absender-Server für eine Domain, sondern veröffentlicht im DNS einen digitalen Signaturschlüssel, mit dem dann die wesentlichen Teile der Header (“Kopfzeilen”) einer jeden ausgehenden Mail digital signiert werden. Auch hier steht natürlich vor Problemen, wer nicht den Server des Anbieters zum Mailversand nutzt, denn nur der kann entsprechend digital signieren.

SPF und auch DKIM werden aber vor allem dann zum Problem, wenn man E-Mails weiterleiten möchte - also eine Mailingliste betreibt, oder auch nur einen einfachen Mailverteiler, oder eine Mailweiterleitung von einem Postfach auf ein anderes eingerichtet hat. In allen Fällen geht dann nämlich die E-Mail mit dem (im Beispiel) GMX-Absender bei der Mailingliste (oder dem Mailverteiler, oder dem ersten eigenen Postfach) ein und wird von da weiterversandt (an die Teilnehmer der Mailingliste, den Verteiler ode das Weiterleitungsziel, also das andere eigene Postfach). Dort aber kommt die E-Mail mit einem GMX-Absender, aber von einem falschen Server aus an! (Nämlich von dem Mailinglistenserver, dem Mailverteiler-Server oder dem Server, der zum ersten eigenen Postfach gehört.) Das führt zu einer fehlschlagenden SPF-Prüfung, und wenn bei der Weiterleitung (gerade bei einer Mailingliste!) Header eingefügt oder geändert wurden, dann schlägt auch die DKIM-Signaturprüfung fehl.

SRS

Das SPF-Problem für Weiterleitungen lösen will SRS, das Sender Rewriting Scheme: der technische Absender der Mail (der Envelope-From) wird geändert, so dass die E-Mail nicht mehr von (im Beispiel) GMX kommt, sondern vom Weiterleitungsserver.

Die E-Mail von irgendwer@gmx.net wird also vom Server postfach.provider.example mit einem Absender wie weiterleitung@postfach.provider.example weitergeschickt. Jetzt kommt die Mail für den letztendlichen Empfänger vom “richtigen” Server, nämlich postfach.provider.example (sie hat ja keinen GMX-Absender mehr!).

Das allerdings ist nur der erste Schritt: Fehlermeldungen (wie zum Beispiel über ein volles Postfach) sollen ja nicht beim Weiterleitungsserver landen, sondern an den ursprünglichen Absender zurückgehen. Dieser muss sich also aus der neu erzeugten Absenderadresse rekonstruieren lassen. Da hilft so etwas wie VERP (Variable envelope return path); statt weiterleitung@postfach.provider.example nehmen wir also weiterleitung+irgendwer=gmx.netg@postfach.provider.example. Da steckt die alte Adresse drin; wir wissen also, wo wir Fehlermeldungen an diese Adresse hinschicken müssen.

Auch das genügt aber noch nicht; denn nur echte Fehlermeldungen sollen an den Absender zurückgehen, nicht aber möglicher Spam, der mit leerem Absender (wie eine Fehlermeldung) an die durch den Weiterleitungsserver erzeugte Absenderadresse geht. Was hinderte einen Spammer, seine unerwünschten Nachrichten an weiterleitung+irgendwer=gmx.netg@postfach.provider.example zu schicken? Und dann senden wir den Mist auch noch an irgendwer@gmx.net weiter! Die von uns erzeugten neuen Absenderadressen müssen also kryptographisch gesichert werden, damit nur wir sie erzeugen können, ein Dritter sie aber nicht erraten kann.

systemd unit file für srds

Und “schon” sind wir beim eigentlichen Thema dieses Eintrags angekommen! :-)

Eine Software, die solche kryptographisch sicheren Absenderadressen erzeugen kann, ist srsd, der auch in Debian als Paket verfügbar ist. Auf meinem alten Server hatte ich das vor Jahren einmal kurzfristig aufsetzen müssen, weil Weiterleitungen (ein simpler Mailverteiler) scheiterten, und diese Lösung wollte ich nunmehr auch auf dem neuen Server haben.

Eine Anleitung für die Konfiguration von Exim 4 mit srsd hat Adrian Zaugg geschrieben; sie setzt allerdings auf ein altes sysvinit-Startup-Script. systemd kann zwar auch damit umgehen; ich hätte aber lieber ein “natives” unit file für systemd gehabt.

Also habe ich mich ein wenig belesen und bin bei folgender Lösung gelandet, die als /lib/systemd/system/srsd.service zu speichern ist:

[Unit]
Description='srsd - SRS daemon'
After=syslog.target

[Service]
Type=simple
User=Debian-exim
Restart=on-failure

ExecStart=/usr/bin/srsd --secretfile /etc/exim4/srsd.secret
ExecStopPost=/bin/rm /tmp/srsd

[Install]
WantedBy=multi-user.target

Dann noch das kryptographische Geheimnis erzeugen (bspw. mit openssl rand -base64 12 > /etc/exim4/srsd.secret), und dann kann es mit systemctl enable srsd und systemctl start srsd losgehen.

Meine Variante der Anbindung an Exim kann ich dann gelegentlich[tm] mal nachliefern.

Was meint die werte Leserschaft?

Ich bin sicher, es geht besser - das war mein erstes unit file, und vieles daran ist aus copy & paste mit nachfolgendem Ausprobieren entstanden. Vielleicht (nein, sogar sicher!) kann ich ja noch etwas von meinen Lesern lernen? :-)

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Sven Hartge am :

Sven Hartge

Eine Unit vom Typ "simple" braucht (in der Regel) kein PIDFile, da ja dort der Daemon sich nicht selbst in den Hintergrund fork()t, sondern weiter im Vordergrund läuft. systemd kennt dabei ja die PID vom Kid-Prozess.

Sven Hartge am :

Sven Hartge

Außerdem würde ich den Socket für srsd auf keinen Fall in /tmp haben wollen, weil durch den bekannten Namen ein Angriff theoretisch möglich wäre.

Besser ist der Socket in /run/srsd/srsd.sock aufgehoben. Da srsd nicht als root läuft, braucht es einen Eintrag in /etc/tmpfiles.d/srsd.conf, damit das Verzeichnis vorab korrekt angelegt wird:

d /run/srsd 0700 Debian-exim Debian-exim

Alle beteiligten Programme müssen dann natürlich auf den neuen Pfad konfiguriert werden.

Thomas Hochstein am :

Thomas Hochstein

Stimmt, PIDFile funktioniert mit "simple" auch gar nicht, wie ich jetzt sehe.

Und der Angriffsvektor ist ein Argument, wobei der Socket ja AFAIS schon ohne Root-Rechte angelegt wird … aber sicher ist sicher. Und so habe ich direkt etwas über /etc/tmpfiles.d/ gelernt!

Thomas Hochstein am :

Thomas Hochstein

Leichter gesagt als getan - der Pfad zum Socket ist hardcoded. :-(

Thomas Hochstein am :

Thomas Hochstein

Ja, vielleicht mal was für einen Bugreport - ich hab’s in der Todo-Liste unter "irgendwann" abgelegt. ;-)

Oder hoffen, dass die Einbindung von libsrs2 in Exim dereinst über den Experimental-Status hinauskommt.

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Favatar, Pavatar, Twitter, Identica, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck