Skip to content

Mini HowTo: OpenDKIM für Postfix installieren

Foto: Lourdes Cardenal
Campo de Criptana Molinos de Viento / La Mancha.
Foto: Lourdes Cardenal, CC BY-SA 3.0, via Wikimedia Commons
Bekanntlich bin ich der Ansicht, daß alle Spammer an ihren Eiern aufgehängt gehören. Da dieser Wunsch für mich momentan etwas schwierig umzusetzen ist, ich aber trotzdem Interesse an einer weitestgehend Spam bzw. Phishing freien Mailverkehr habe, muss ich wie einst Sisyphos (oder war es Don Quixote?) gegen unerwünschte Mails kämpfen. Da ich nicht der einzige bin, der diesen Wunsch hegt, gibt es eine breite Palette an Tools, die einen dabei unterstützen. Als Domaindiktator setze ich dabei am Mailserver an: "DomainKeys ist ein Identifikationsprotokoll zur Sicherstellung der Authentizität von E-Mail-Absendern, das von Yahoo entwickelt wurde und seit Ende 2013 ein Internet-Standard ist. Es wurde konzipiert, um bei der Eindämmung von unerwünschter E-Mail wie Spam oder Phishing zu helfen." DKIM-Signaturen machen also Veränderungen an Header und Body einer Mail erkennbar.
Da es einige Stolperfallen bei der Einrichtung gibt, die das korrekte Funktionieren verhindern können, habe ich mir ein kurzes und rudimentäres HowTo verfasst:

Das Szenario: Alle Mails der Doman domainname.de sollen signiert werden. Alle eingehenden Mails sollen verifiziert werden. Wir haben Zugriff auf Nameservereinträge der Domain und ein Postfix Server sowie Amavis und Spamassassin verrichten ihren Dienst auf einem debian System. Den DKIM Dienst soll openDKIM übernehmen, das wir gleich mal in einem Terminal zusammen mit ein paar Tools installieren:
sudo apt install opendkim opendkim-tools

Dann legen wir ein Schlüsselverzeichnis an und generieren den Schlüssel. Wichtig ist die korrekte Rechtevergabe in den Schlüsselverzeichnissen! Zudem sollte der Dienst nicht als root laufen sondern unter dem User opendkim. Dieser darf in keiner anderen Gruppe Mitglied sein, ansonsten quittiert der Dienst den selbigen mit einer Fehlermeldung.
mkdir /etc/opendkim/keys/domainname.de
/usr/bin/opendkim-genkey -D /etc/opendkim/keys/domainname.de/ -d domainname.de -s 2020
chown -R root:opendkim /etc/opendkim/keys/domainname.de
chmod 640 /etc/opendkim/keys/domainname.de/2020.private
chmod 644 /etc/opendkim/keys/domainname.de/2020.txt

Im Anschluss bearbeiten wir die /etc/opendkim.conf:
Domain   domainname.de
Selector 2020                             # Das ist der im vorigen Schritt angegebene Selector. Interessant für diejenigen, die den DKIM Key regelmäßig aktualisieren.
KeyFile  /etc/opendkim/domainname.de/2020.private
Socket   inet:8891@localhost
Canonicalization        relaxed/simple    # Auf Headermodifikationen nicht gleich allergisch reagieren
Mode                    sv                # Mails [s]ignieren und [v]erifizieren

Wir starten den Dienst: sudo systemctl restart opendkim und regeln, daß der Dienst beim Systemstart gleich gestartet wird: systemctl enable opendkim. Dann befassen wir uns mit der Integration von openDKIM in Postfix. Dazu editieren wir die /etc/postfix/main.cf:
smtpd_milters = inet:localhost:8891
non_smtpd_milters = $smtpd_milters

Danach muss Postfix diese Änderung bekannt gegeben werden: sudo systemctl reload postfix.

Das war es im Grunde dann auch schon. Bis auf eine Kleinigkeit: Die Integration des Schlüssels als TXT Record im Nameservereintrag von domainname.de. Diese Einstellung unterscheidet sich von Provider zu Provider, daher an der Stelle auch nur der allgemeine Hinweis:


Record NameRecord TypeText
mail._domainkeyTXTv=DKIM1; k=rsa; p=MI.. (Hier Inhalt von /etc/opendkim/keys/domainname.de/2020.txt einfügen, dabei alle >"< entfernen und alle Zeilen nach p= in einen Schlüssel ohne Leerzeichen verbinden.)

Das korrekte Eintragen des Schlüssels kann kompliziert sein, vor allem der Teil nach "p=" darf weder um- noch unterbrochen sein. Ansonsten wird der Schlüssel nicht erkannt!

Testen des Keys:
# opendkim-testkey -d domainname.de -s mail -vvv

opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'mail._domainkey.domainname.de'
opendkim-testkey: key not secure
opendkim-testkey: key OK

Sofern keine Fehlermeldungen auftreten, kann man sich nun darum kümmern, eingehenden Spam weiter zu filtern. In Amavis ist der DKIM Filter in einigen Debian Derivaten deaktiviert, lässt sich aber einfach aktivieren. Dazu muss in der Konfigurationsdatei /etc/amavis/conf.d/20-debian-defaults folgender Parameter gesetzt werden:
$enable_dkim_verification = 1;

In der Datei /etc/amavis/conf.d/50-user muss für eine erweitere Anzeige der Überprüfungsergebnisse dann als letztes noch folgender Parameter gesetzt werden:
$allowed_added_header_fields{lc('Authentication-Results')} = 1;

Im täglichen Mailverkehr empfiehlt sich darüber hinaus ein Addon für den freien Mailclient Thunderbird zur Kontrolle der empfangenen Mails: Den DKIM Verifier. Dieses Addon überprüft beim Öffnen einer Mail die Gültigkeit der Signatur. Somit kann man sich (halbwegs) sicher sein, daß die Mail vom signierenden Mailserver stammt. Natürlich nutzen auch einzelne Spammer DKIM. "Es ist wichtig zu beachten, dass eine E-Mail durch eine beliebige Domain signiert seinen kann. Eine gültige Signatur alleine ist daher kein Hinweis auf eine vertrauenswürdige E-Mail. Um zu entscheiden ob eine E-Mail vertrauenswürdig ist sollte immer überprüft werden wer der Signierende ist! In einigen Fällen kann die Abwesenheit einer DKIM Signatur nützlich sein um betrügerische E-Mails zu erkennen. Falls bekannt ist, dass eine Domain alle ihre E-Mails mittels DKIM signiert, ist das Nichtvorhandensein einer DKIM Signatur ein starker Hinweis auf eine gefälschte E-Mail." (Aus der Addon Beschreibung)

Quellen:
debianwiki, Steven Jenkins, Michael Kofler, WikiPedia, Philippe Lieser, Patrick Koetter

Den ClamAV Virenscanner aufbohren

Auf einem Mailserver hier läuft der Open Source Virenscanner Clamav. Von Haus aus - verglichen mit kommerziellen Virenscannern - nicht mit einer besonders hohen Erkennungsrate gesegnet, lässt sich dieser jedoch mit Virenkennungen von Drittanbietern aufrüsten. Seit einigen Jahren ist für mich dabei der ClamAV Unofficial Signatures Updater von eXtremeSHOK, über den ich bei Alex gestolpert bin, eindeutiger Favorit. Auch wenn die aktuelle Version von 2017 ist, seinen Job macht es stabil und richtig: Die gewählten Virenkennungen lädt es nach wie vor bei diversen Anbietern herunter, es bleibt ClamAV überlassen, diese anzuwenden:

Bei den Kennungen für yara löst ein Eintrag jedoch Fehler aus:

LibClamAV Error: yyerror(): /var/lib/clamav/maldoc_somerules.yar line 235 undefined identifier "uint32be"
LibClamAV Warning: cliloadyara: failed to parse or load 1 yara rules from file /var/lib/clamav/maldocsomerules.yar, successfully loaded 14 rules.

Nun kann man entweder die betreffende Datei löschen und gut ist es oder einfach den fehlerhaften Eintrag bearbeiten. Ich habe bei mir letzteres getan und erhalte mir somit die Kennungen. Einfach mit einem Editor /var/lib/clamav/maldoc_somerules.yar öffnen, nach uint32be suchen und diese Zeile löschen oder einkommentieren.

Nach dem Abspeichern den Dienst zum erneuten Laden der Virenkennungtsdatenbank veranlassen:

sudo service clamav-daemon reload-database

Das editieren des Eintrags bringt nichts, die fehlerhafte Definition wird mit dem nächsten Update wieder installiert. Wie es aussieht hilft zur Zeit nur der Tipp von Vladki77:
Edit /etc/clamav-unofficial-sigs/master.conf and set:
yararulesproject_enabled="no"
enable_yararules="no"
And delete *.yar and *.yara from /var/lib/clamav/

Sehr schade, sobald sich da (hoffentlich) etwas ändert, vermerke ich das hier.

Alex hat auch zusammengefasst, wie die Erkennungsrate von Spamassassin deutlich erhöht werden kann.

Stress am Morgen wegen: "config: SpamAssassin failed to parse line"

Eine Email zu einem fehlerhaften Updatelauf der RulesDuJour kann einem schon mal den Morgenkaffee verderben:

RulesDuJour Run Summary on xxxxxxxxx:

***NOTICE***: /usr/bin/spamassassin --lint failed. This means that you have an error somwhere in your SpamAssassin configuration. To determine what the problem is, please run '/usr/bin/spamassassin --lint' from a shell and notice the error messages it prints. For more (debug) information, add the -D switch to the command. Usually the problem will be found in local.cf, user_prefs, or some custom rulelset found in /etc/mail/spamassassin. Here are the errors that '/usr/bin/spamassassin --lint' reported:

[1247] warn: config: failed to parse line, skipping, in "/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf": <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
[1247] warn: config: failed to parse line, skipping, in "/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf": <!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
Der Inhalt von "/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf" ist eine HTML Datei mit einem Refresh von 0.1.

Schon verdächtig. Ist Schäuble schon drin? Auch wenn man von einem Fehler ausgeht: Lieber auch mal außer der Reihe einen Sicherheitscheck des Systems starten. Natürlich von einer LiveCD aus, neben verschiedenen Virenscannern auch mit rkhunter. Das ist ein Linux-Tool, welches nach Rootkits, Hintertüren und möglichen lokalen Exploits sucht. Es vergleicht vorhandene Dateien anhand von sogenannten md5 -hashes mit kompromittierten Dateien, sucht nach von Rootkits angelegten Ordnern, falschen Dateirechten, versteckten Dateien, verdächtigen Strings in Kernelmodulen und führt eine Reihe weiterer Tests durch.

Sinnvollerweise schiebt man noch einen Check mit einem weiteren Tool, chkrootkit hinterher. Das Werkzeug ist recht einfach zu bedienen.

Bei dem betroffenen System fielen dann auch gleich mehrere veraltete und angreifbare Versionen von Programmen auf:

- OpenSSL 0.9.8e                                           [ Vulnerable ]
- Procmail MTA 3.22                                        [ Vulnerable ]
- OpenSSH 4.6p1                                            [ Vulnerable ]

Zumindest OpenSSL (0.9.8g) und OpenSSH (4.7p1) liegen ja schon seit einigen Monaten in aktuelleren Versionen vor. Och nööö... Schon ist der Nachmittag geregelt. Und das bei dem schönen Wetter:



Naja, zum Glück gibt es auch Backups, daher ist das Problem mit der fehlerhaften Datei 99_FVGT_Tripwire.cf wenigstens schnell erledigt.

SpamAssassin Rulesets mit RulesDuJour erweitern

Zwar erledigt SpamAssassin den meisten Spam, mit den RulesDuJour wird dessen Erkennungrate noch weiter verbessert. Die Installation auf beliebigen Linux Systemen ist eigentlich kein größeres Problem. Die Anleitung auf howtoforge veranschaulicht, wie man RulesDuJour installiert und aktualisiert.

Ein Hinweis noch, mit:

spamassassin --lint --debug

kann man prüfen, ob die neuen Regeln in spamassassin eingebunden wurden. So oder ähnlich sehen die eingebundenen Rules in der Ausgabe davon aus:

[12369] dbg: config: using "/etc/mail/spamassassin" for site rules dir
[12369] dbg: config: read file /etc/mail/spamassassin/70_sare_evilnum0.cf
[12369] dbg: config: read file /etc/mail/spamassassin/70_sare_random.cf
[12369] dbg: config: read file /etc/mail/spamassassin/tripwire.cf


Sollte es Probleme bei der Verwendung mit amavisd geben:

Folgende Zeile in die local.cf setzen:
include /etc/spamassassin/rulesdujuor/

Damit werden die Rules auf jeden Fall eingelesen.

Via
cronjob