Netz - Rettung - Recht (Artikel mit Tag spam)

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?

reCAPTCHA v 2.0

nospam@example.com (Thomas Hochstein) — Sun, 19 Feb 2017 19:42:53 +0000

Bereits vor rund zwei Wochen klagte ich über Spam über meine Kontaktformulare und kündigte an, von meiner bisherigen Lösung - einfache Rechenaufgabe - auf reCAPTCHA von Google zu wechseln.

Für die besonders betroffenen Formulare habe ich das jetzt umgesetzt. Dank der guten Dokumentation ist das gar nicht so schwierig.

Zunächst muss man einen Schlüssel (Key) für die API erzeugen, was einen Google-Account erfordern dürfte. Dann benötigt das Formular den nötigen Code zum Einbau des CAPTCHAs und schließlich das Script, das das Formular auswertet, den zugehörigen Code zur Auswertung. Für beides, insbesondere aber letzteres gibt es eine reCAPTCHA PHP client library; alternativ kann man sich auch von der bei s9y gewählten Lösung inspirieren lassen.

Schließlich will man vielleicht noch die eine oder andere Ergänzung an der Datenschutzerklärung vornehmen.

Geschafft! - Der Aufwand ist überraschend gering.

Spammer im Web rüsten auf

nospam@example.com (Thomas Hochstein) — Fri, 10 Feb 2017 08:04:24 +0000

Spam ist eine Pest - und beschränkt sich schon lange nicht mehr auf E-Mail und Newsgroups. Auch Webforen, Gästebücher, Wikis, Blogs und Kontaktformulare werden vollgemüllt; letztere vermutlich in der irrigen Annahme, es handele sich um eine Kommentarmöglichkeit.

Damit umzugehen ist ein zweischneidiges Schwert: einerseits ist es unbefriedigend, Spam ständig zu löschen und hinterherzuräumen; andererseits haben Gegenmaßnahmen wie insbesondere CAPTCHAs auch ihre Nachteile, namentlich die dadurch entstehende zusätzliche Hürde für legitime Nutzer, insbesondere solche mit Sehbehinderung.

Bisher bin ich bei den Kontaktformularen meiner Webseiten mit recht simplen Methoden gut gefahren, zuletzt über viele Jahre hinweg mit einfachen Rechenaufgaben, die sich in der Regel im Kopf lösen lassen. Mir war freilich klar, dass auch Spambots solche Aufgaben trivial lösen können - allein, sie haben es nicht getan. Bisher.

Seit wenigen Wochen bekomme ich hingegen von mindestens zwei Webseiten (nicht aber von den anderen) täglich mehrere E-Mails und andere Einträge; offensichtlich haben also Spammer nicht nur meine Kontaktformulare gefunden, sondern auch Bots darauf angesetzt, die mit den Rechenaufgaben leicht klarkommen. Zugleich bekomme ich vereinzelte Spamkommentare auch hier im Blog, und zwar für ältere Einträge, die mit reCAPTCHA abgesichert sind. Und schließlich berichtet Andreas Gohr vom Dokuwiki-Projekt ebenfalls über erfolgreiche Angriffe gegen das dort verwendete CAPTCHA.

Offensichtlich gibt es irgendwo dort draußen also neue Software, und die Rüstungsspirale zwischen Spam und Spamabwehr dreht sich weiter.

Hier im Blog habe ich vom “alten” reCAPTCHA auf die Version 2 gewechselt, die Serendipity seit Dezember 2016 unterstützt. Für meine Kontaktformulare werde ich wohl ebenfalls auf reCAPTCHA setzen müssen, sobald ich mich damit hinreichend vertraut gemacht habe. seufz

RBLs, RBL-Checks und "sie wissen nicht, was sie tun"

nospam@example.com (Thomas Hochstein) — Mon, 18 Oct 2010 19:07:00 +0000

RBLs (Realtime Blackhole Lists) sind mittlerweile über ein Jahrzehnt alt und eine weitverbreitete Methode der Filterung unerwünschter E-Mails. In diese Listen, die über das DNS propagiert werden, trägt der jeweilige Betreiber nach seinen Kriterien die IP-Adressen von Hosts ein, die gefiltert werden sollen. Manche dieser Listen sind sinnvoll, andere sind es nicht; manche zählen Spam-Quellen auf, offene Proxies und Relays, von Malware befallene Systeme, andere jedes System, dessen Betreibers Nase dem RBl-Provider nicht passt. Wer RBLs einsetzt, muß sich also informieren, welche Policy eine RBL verfolgt, und wie zuverlässig sie das tut.

Neben den RBLs gibt es auch Anbieter, die prüfen, ob bestimmte Systeme auf diesen RBLs landen; das sollte jeder Admin größerer Mailsysteme eigentlich selbst tun, um ggf. (das für die Listung ursächliche Problem zu beheben und dann) die Löschung von der jeweiligen RBL zu veranlassen, aber für diejenigen, die das nicht tun können oder möchten, sind solche Angebote sicher interessant. Nur sollten diese Anbieter von RBL-Checks auch wissen, was sie da eigentlich tun, was wohl nicht immer sichergestellt ist …

Ich bekam jedenfalls dieser Tage (mal wieder) einen Hinweis, eines meiner Systeme sei in der RBL hostkarma.junkemailfilter.com gelandet; wie der Name andeutet, versucht deren Betreiber Mailserver in gute, schlechte oder neutrale einzuteilen. Wie zuvor habe ich daraufhin mein System auf den Webseiten des RBL-Betreibers geprüft und bekam - wie immer - als Antwort, das System sei nicht gelistet. Diesmal bin ich der Sache nachgegangen und habe festgestellt, daß der RBL-Check-Anbieter grundsätzlich Recht hat: meine Maschine war tatsächlich in der RBL eingetragen! Aber warum bestreitet das der RBL-Provider dann? Nun, meinem System war dort der Wert "127.0.0.1" zugewiesen. Und der RBL-Provider meint zu diesem Wert folgendes:

127.0.0.1 - whitelist - trusted nonspam

Danke, keine weiteren Fragen mehr.

Once again: Spam gegen Spam

nospam@example.com (Thomas Hochstein) — Thu, 07 Sep 2006 21:31:00 +0000

Spam ist ein seit gut 10 Jahren bekanntes Übel, und Spam, der durch Spamfilter rutscht, leider auch nicht so selten, daß er einen Blogeintrag wert wäre. Spam, in dem Spam-Bekämpfung beworben wird, ist allerdings hinreichend selten, dafür aber umso dreister - und wenn die beworbene "Lösung" so (vermutlich unfreiwillig) humoristisch angehaucht ist wie in diesem Fall, dann sollte man diese Verbindung aus Unverschämtheit und unfreiwilliger Komik auch entsprechend würdigen.

Das angepriesene Werk will dem durchschnittlichen Nutzer in drei Schritten nahebringen, wie er Spam vermeiden kann, ja wie Spam geradezu ausgerottet wird, wenn nur jeder diese Schritte befolgt. Kurz gefaßt umfaßt dabei Schritt 1 die Auswahl einer passenden E-Mail-Adresse. In der aus einschlägigen Teleshoppingsendungen und (Tv-)Ratgebern bekannten Sprache erfahren wir auf 53 Seiten, was Spam ist, und daß wir eine E-Mail-Adresse auswählen sollen, die möglichst schwer zu erraten ist; am besten sollen wir dazu mit Papier und Stift in Ruhe unserer Kreativität freien Lauf lassen. Zwar ist richtig, daß damit das Erraten der Mailadresse erschwert oder unmöglich gemacht wird, aber so richtig zielführend mag die Übung dann nicht erscheinen. Garniert wird das (für Fortgeschrittene und Firmen) dann noch mit dem tollen Tip, leicht erratbare Adressen (info@, support@, …) abzuschalten und dort nur einen Autoresponder mit Verweis auf ein Webformular einzurichten (also collateral spam zu produzieren). Daß auch über ein Webformular gespamt werden könnte, scheint dem Autor noch nicht begegnet zu sein (oder es geht über den Horizont des 175-Seiten-Buches hinaus, daß sich gezielt auf E-Mail-Spam beschränken will).

Teil 2 ermahnt uns zur Vorsicht bei der Verwendung unserer Mailadresse. Wir sollten sie beispielsweise nicht - wer hätte das gedacht! - bei angeblichen Gratisangeboten und Gewinnspielen eingeben; und wenn doch, dann nutzt man die eingedeutschten Variante von "spamgourmet", dem besten dieser Dienste, den (zufällig!) der Verlag betreibt, der diese Publikation herausgibt. Die nächsten knapp 40 Seiten führen uns dann in die wunderbaren Geheimnisse dieser Technik ein (die ich als bekannt voraussetze) - allerdings übersieht der Autor, daß auch das das eigentliche Problem "Wie gebe ich eine auf Dauer erreichbare (!) Mailadresse für Kontakte an, ohne daß sie bespammt werden kann?" nicht löst.

Ein besonderes Schmankerl ist dann die Warnung vor dem Usenet:

Usenet (sprich: jusnet) oder auch Usernet genannt ist eine Erfindung, die aus den Anfangszeiten des Internet stammt. Aus den Zeiten als Internet-Verbindungen noch seeehr langsam waren und die hauptsächliche Nutzung des Internet die Email war. Ja, es gab früher Zeiten, da hat man das Internet fast nur zum Email-Versenden und Empfangen benutzt… Kann man sich heute kaum noch vorstellen, aber so beschränkt war die Internet-Nutzung damals…

Gut, knapp daneben ist auch vorbei, aber der Autor hat die Funktionsweise des Usenets schon richtig *räusper* erkannt:

Usenet bzw. Newsgroups dort sind einfach Diskussions-Runden zu allen möglichen und unmöglichen Themen. Und bei jeder Antwort eines Diskussions-Teilnehmers wird an ALLE Gruppen-Teilnehmer jeweils eine Email verschickt…

Genau, so kennen und lieben wir doch das Usenet. Kein Wunder, daß der Autor zu der folgenden vernichtenden Beurteilung kommt:

Und ich behaupte jetzt frech, dass alle, die heute noch das Usenet nutzen, sind – zumindest teilweise – in ihrem Verstand bis heute genauso beschränkt geblieben. […] Die einzige Erklärung für ein solch dummes Verhalten, die ich mir vorstellen kann, ist, dass diese Menschen – die Usenet-Nutzer – derart in ihren alten Gewohnheiten verhaftet sind, dass sie in dieser Beziehung aufgehört haben zu denken… Eine andere Erklärung dafür habe ich bisher nicht.

Nun gut. Bis Seite 124 lernen wir dann noch Foren, Newsletter, CC und BCC und Scams kennen. Die restlichen Seiten brauchen wir dann für Schritt 3 - eine Wunder-Software, die auf eine geheime Weise E-Mail-Adressen auf unseren Webseiten für Spambots unbrauchbar macht, und die wir beim Verlag als Käufer des Buches kostenlos erhalten, als Leser des kostenlosen E-Books allerdings nur vergünstigt erwerben können. Womit dann auch geklärt würde, was Ziel dieses recht länglichen Spam-Runs im PDF-Format ist …