systemd-Unit für srsd unter Debian

nospam@example.com (Thomas Hochstein) — Mon, 14 Aug 2017 05:10:00 +0000

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?

Verzögerungen beim SSH-Login

nospam@example.com (Thomas Hochstein) — Wed, 05 Jul 2017 06:05:00 +0000

Manchmal dauert der SSH-Login auf einem meiner Server etwas länger. Dann ist entweder dort die Load zu hoch oder es gibt Probleme mit der DNS-Auflösung meiner IP-Adresse oder das Netz ist dicht - meistens das heimische WLAN. Dieser Tage aber dauerte es nicht nur “etwas” länger - vielmehr hatte ich regelmäßige Verzögerungen im Bereich von etlichen Sekunden beim Login, immer auf denselben Maschinen (eine davon in meinem heimischen Netz!) und nach (!) dem Anzeigen des Login-Banners. Die Load war in Ordnung, die DNS-Auflösung sollte jedenfalls im lokalen Netz funktionieren, und ständig überlastet kann die Netzanbindung eigentlich auch nicht sein, jedenfalls nicht immer zu denselben beiden Maschinen.

Eigenartig.

Nachdem ich mich - wie üblich - zunächst einmal einfach nur geärgert und darauf gehofft hatte, dass das Problem sich von selbst lösen möge, sah ich mich dann doch gezwungen, zum Äußersten zu greifen und ins Logfile zu schauen. Dort fanden sich dann Einträge dieser Art:

Jul  3 21:11:02 myhost dbus[23288]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Jul  3 21:11:02 myhost systemd[1]: Started Login Service.
Jul  3 21:11:27 myhost dbus[23288]: [system] Failed to activate service 'org.freedesktop.login1': timed out

Ein Timeout - das würde ja passen! — Aber warum?

Die einfachste Lösung ist in solchen Fällen oft - und gerade bei absoluter Ahnungslosigkeit - ein gezielte Suche bei Google oder einer anderen Suchmaschine des jeweiligen Vertrauens. Mich brachte das in diesem Fall zu einem Stackexchange-Eintrag, der genau auf mein Problem passte: Dieser “Hänger” geschieht, wenn dbus neu gestartet wurde - und genau das hatte ich nach dem Einspielen von Updates getan!

Die Lösung soll sein, danach auch logind wieder zu starten. Und tatsächlich: service systemd-logind restart, und schon war wieder alles paletti.

(Vielleicht hilft das dem einen oder anderen, der - namentlich unter Debian Jessie - vor demselben Problem steht.)

Netz - Rettung - Recht (Artikel mit Tag systemd)

systemd-Unit für srsd unter Debian

SPF und DKIM

SRS

systemd unit file für srds

Was meint die werte Leserschaft?

Verzögerungen beim SSH-Login