Der ein oder andere schüttelt jetzt vielleicht den Kopf: „SPF? Den Mist braucht doch keiner! Macht nur Ärger!“ – Richtig, SPF ist doof. Und trotzdem verwenden große E-Mail Privider SPF, um die Herkunft von E-Mails zu überprüfen und so festzustellen, ob es sich um Spam handelt oder nicht. Mehr Informationen dazu, wieso SPF doof ist, könnt ihr euch auf der Blog-Seite von Heinlein-Support einholen: https://www.heinlein-support.de/vortrag/spf-dkim-greylisting-der-neue-spamschutz (Empfehlung!)
Für jene unter euch, die ganz einfache, simple Mailserver verwenden, kann so ein SPF-Eintrag im DNS aber trotzdem sinnvoll sein: Nicht, weil ihr SPF selbst nutzen sollt, um Spammer zu identifizieren (dafür gibt es wesentlich bessere Technik), sondern um besonders schlechte Provider wie Microsoft (Hotmail, Outlook.com) oder GMX dazu zu bringen, eure E-Mails nicht als Spam zu klassifizieren ;) Fehlt ein SPF Record in der Absenderdomain, sind sich diese Provider nicht sicher, ob sie die Mail als harmlos einstufen sollen oder nicht. In einigen Fällen landen eure E-Mails dann schnell im Spam oder werden erst gar nicht akzeptiert. Habt ihr hingegen einen einen SPF Record in eurem Zonefile, kann derjenige Provider nachsehen und wird feststellen, dass der sendende Server tatsächlich legitimiert ist, die E-Mail zu verschicken. Alles ist gut und euch wird vertraut.
Wie in den Vortragsfolien von Peer Heinlein schon steht: Ausgehend SPF zu nutzen, schadet nicht und hilft in einigen Fällen. Nur selbst danach filtern sollte man nicht.
Ich habe meinen Beitrag zum Sammeln von Let’s Encrypt-Domainbestätigungen um einen Abschnitt erweitert: Mit einer einfachen Weiterleitung auf eine spezielle Subdomain kann man nicht nur alle Subdomains zusammenfassen, sondern auch alle Hosts. Setzt man mehrere Subdomains auf mehreren Hosts ein, ist es ganz praktisch, seine Bestätigungsdateien immer nur noch in einem Verzeichnis auf einem Hosts zu erstellen. Das erspart einem zwar leider auch nicht das Erstellen dieser Dateien, aber immerhin muss man dazu nicht auch noch auf sämtlichen Hosts eingeloggt sein.
DANE ist ein noch rar gesätes Protokoll, das Domainnamen mit einem oder mehreren TLS-/SSL-Zertifikaten verknüpft. Durch das DNS wird dem Client diktiert, welche Sicherheitszertifikate für eine Domain gültig sein sollen. Hintergrund ist, dass jede große, anerkannte CA der Welt (und davon gibt es hunderte) theoretisch für jede Domain gültige TLS-Zertifikate ausgeben kann. Dass das viel Spielraum für Manipulation und Missbrauch bietet, liegt auf der Hand. Indem man im DNS Informationen dazu ablegt, welche einzelnen Zertifikate oder Zertifizierungsstellen (CAs) für die Domain genutzt werden dürfen, kann man die Sicherheit signifikant verbessern. Normalerweise wird DANE in Kombination mit DNSSEC (Internetstandard zur Absicherung von DNS-Zonen) eingesetzt. Prinzipiell ist DNSSEC für die Nutzung von DANE nicht zwingend erforderlich. Es stellt sich jedoch die Frage, ob es sinnvoll ist, DANE Informationen in einer nicht manipulationssicheren Zonendatei unter zu bringen … besser ist es, DANE mit aktiviertem DNSSEC zu nutzen.
Im Manual Mode des Let’s Encrypt Referenzclients muss jede Domain über eine individuelle Datei im Unterverzeichnis /.well-known/acme-challenge/ derselben Domain bestätigt werden. Bei vielen Domains bremst das Wechseln zwischen den Verzeichnissen und das erstellen der notwendigen Verzeichnisstruktur den Arbeitsablauf. Damit die Domains schneller bestätigt werden können, sammle ich alle ACME Responses in einem gemeinsamen Verzeichnis /var/www/acme-challenges/. Egal, welche Domain gerade bestätigt werden soll: Die Datei zur Bestätigung wird hier abgelegt und steht dennoch unter der gewohnten URL bereit. Und so geht’s:
Die meisten Webdienste, die eine Zwei-Faktor-Authentifizierung anbieten, unterstützen das TOTP (Time-based one time password) -Verfahren. Dabei bleiben die Codes nur eine gewisse Zeit lang gültig und ändern sich ständig. Zugriff auf die Codes bekommt man bei den Yubikeys nur über eine dritte Software, die mit dem Yubikey kommuniziert. Das liegt daran, dass der Yubikey keine eigenständige Code-Berechnung ausführen kann, weil ihm für eine eigene Systemuhr die notwendige Energieversorgung fehlt. Die Berechnung des Codes geschieht immer im Yubikey selbst – die geheimen Schlüssel verlassen also niemals den Yubikey. Die Clientprogramme liefern dem Yubikey nur die Systemzeit, holen die fertig generierten Einmalcodes ab und zeigen sie an. „Yubikey Authenticator“ heißt der TOTP Client für den Yubikey, den es für Android, Linux, Windows und MacOS gibt.
Wie bereits bekannt sein dürfte, kann man die Erkennungsrate von Spamassassin verbessern, indem man die Software von bereits als Spam markieren E-Mails mittels sa-learn lernen lässt.
Seit einigen Monaten binde ich in mein Spamassassin zusätzlich die Filterregeln von Heinlein Support ein, die täglich aktualisiert werden und vom Betreiber so 1:1 auch für mailbox.org verwendet werden. Seitdem hat sich die Erkennungsrate für Spam signifikant verbessert. Zu meinem bestehenden Cronjob zur Aktualisierung der allgemeinen Filterregeln habe ich einfach einen zweiten Cronjob für die Heinlein Support-Filterregeln hinzugefügt:
Dass das Unternehmen seine Filterregeln frei für alle Admins zur Verfügung stellt, macht es durchaus sympathisch, finde ich. Vielleicht stellt in Zukunft ja auch der Mailprovider Posteo seine Filter zur Verfügung?
Nachdem ich im Sommer diesen Jahres meine Aktivitäten im sozialen Netzwerk Diaspora schon pausiert hatte, habe ich vor ein paar Tagen meinen Account deaktiviert. Ich will hier kurz begründen, wieso ich meine social Networking Aktivitäten heruntergefahren habe bzw. im Diaspora Netzwerk nicht mehr aktiv war und wohl auch nicht mehr so schnell aktiv sein werde.
Für WordPress gibt es verschiedene Plugins, über die sich ein Blog mit dem Yubikey absichern lässt. Eine Möglichkeit ist, die Authentifizierung via Yubikey OTP, die Yubico Server und dieses WordPress Plugin abzuwickeln. Der Vorteil: Yubikey OTPs funktionieren auf jedem Rechner, der eine USB-Schnittstelle hat, weil der Yubikey in diesem Fall nur eine Tastatur simuliert. Nach Nachteil bei dieser Methode: Man verlässt sich auf fremde Server (Die Yubico Authentifizierungsserver), über die man keine Kontrolle hat.
Neben der Yubico OTP-Methode beherrscht mein Yubikey Neo auch die Authentifizierung über das FIDO U2F Verfahren. Auch hierbei werden Einmalpasswörter generiert – allerdings ohne die Hilfe fremder Server. Ein Nachteil hierbei: Damit U2F funktionieren kann, muss der Webbrowser dies unterstützen. Google Chrome / Chromium beherrscht U2F seit Version 40. Firefox kommt noch ohne native U2F Unterstützung. Über ein Browser-Addon kann man das aber nachrüsten. Im Folgenden erkläre ich die Einrichtung der Authentifizierung über U2F. Ich gehe davon aus, dass der Browser U2F bereits beherrscht.
Für WordPress gibt es verschiedene Plugins, über die sich ein Blog mit dem Yubikey absichern lässt. Eine Möglichkeit ist, die Authentifizierung via Yubikey OTP, die Yubico Server und