Spam-Abwehr mit Postfix

E-Mail ist das gebräuchlichste Kommunikationsmittel unserer Zeit. Gleichzeitig ist aber auch kein Kommunikationsmittel so geplagt von Spam. Während selbst die unseriösesten Unternehmen ihre unerwünschte Briefwerbung auf Verlangen einstellen, bleiben solche Bemühungen bei E-Mail-Versendern ohne Reaktion oder verstärken sogar noch die Spam-Flut.

Einige wenige Einstellungen in Postfix, die ich natürlich nicht für mich behalten möchte, haben mir deutlich geholfen, meinen Spam praktisch au Null zu reduzieren.

1. Verifizierung am Backup-MX

Viele Seiten nutzen einen Backup-Mail-Exchanger, um Ausfällen vorzubeugen. Das ist zwar nicht erforderlich, da der absendende Server die Zustellung i.d.R. 4 Tage lang versucht, es verschafft aber dem jeweiligen Administrator die Genugtuung über ein Backup zu verfügen.

Spamversender versuchen jedoch gezielt, diesen Backup-Server zu nutzen, weil er zumeist schlechter abgesichert ist. Wer einen Backup-MX einsetzt, muss dort die gleichen Prüfungen durchführen, wie auf dem regulären Mail-Exchanger.

Dazu gehört vor allem auch die Verifizierung der Empfänger-Adressen. Wer einfach nur alles annimmt und an den primären MX weiterleitet, riskiert den Versand sogenannter “Backscatter”-Fehlermeldungen; d.h. dass Fehlermeldungen an den tatsächlichen Eigentümer einer Adresse gehen, die in Spam-Nachrichten als gefälschte Absenderadresse genutzt wurde. Dort werden diese Fehlermeldungen häufig als Spam eingestuft, was dem eigenen Ruf schadet.

Die Backend-Datenbank sollte also auf den Backup-MX repliziert werden, sodass dieser auch nach dem Ausfall des primären MX lokale Abfragen durchführen kann um die Existenz einer Empfänger-Adresse zu bestätigen. Hier empfiehlt sich der Einsatz einer Datenbank wie MySQL oder PostgreSQL, weil das eine automatische Replizierung ermöglicht.

2. Nachrichten von eigenen Domains ablehnen

Spam-Versender tragen häufig Adressen aus den Domains der Empfänger als Absenderadresse ein, weil viele Server diese Adressen als “interne Absender” behandeln und mit einer besseren Spam-Bewertung versehen. Ein MX darf niemals Nachrichten annehmen, die von seinen eigenen Domains stammen – außer natürlich, sie werden vom Backup-MX weitergeleitet.

Wer ein SQL-basiertes Backend nutzt, kann das mit einer einfachen SQL-Query einrichten:

/etc/postfix/lists/own_domains

user = ************
password = ************
hosts = ***.***.***.***
dbname = ********
query = SELECT 'REJECT %d is my domain, you may not use it in your sender address. Please go away, brainbug.' FROM domains WHERE ('%d' LIKE domain) OR ('%d' LIKE CONCAT('%%.',domain))

/etc/postfix/main.cf

smtpd_sender_restrictions = permit_inet_interfaces,
    permit_mynetworks,
    [...]
    check_sender_access mysql:/etc/postfix/lists/own_domains,
    [...]

3. Pause im Verbindungsaufbau

Es klingt, als ob diese Lösung zu einfach sei, doch sie funktioniert. Spammer haben es eilig, möglichst viele Nachrichten zu versenden bevor ihre Nachricht auf Blacklists landet. Sie reduzieren daher ihre Timeouts auf ein Minimum, um durch nicht erreichbare Server nicht ausgebremst zu werden.

Sorgt man für eine kurze Pause vor der ersten Rückmeldung des Servers, führt das zu einer drastischen Reduzierung von Spam, ohne dass fragliche Methoden wie Greylisting zum Einsatz kommen müssen.

Die Sleep-Anweisung sollte dann hinter den White- und Blacklists stehen. Whitelist-Einträge werden so nicht behindert und Blacklist-Einträge werden schnell abgelehnt, ohne unnötig Ressourcen zu blockieren.

/etc/postfix/main.cf

smtpd_client_restrictions = permit_inet_interfaces,
    permit_mynetworks,
    [...]
    sleep 5

4. Kein Geylisting

Greylisting bringt überhaupt nichts – außer Ärger mit den Nutzern, die unnötig lange Verzögerungen bei legitimen Nachrichten hinnehmen müssen. Außerdem müssen aufwendige Ausnahmeregeln für falsch konfigurierte Server gepflegt werden, die mit Greylisting nicht klar kommen und nach einen 4xx-Fehler keine weiteren Zustellversuch mehr unternehmen.

Die Legitimität einer Nachricht festzustellen, indem man sie zuerst ablehnt und dann darauf hofft, dass der Server es nochmals versucht, ist die denkbar schlechteste Vorgehensweise die einzig und allein zu dem Ergebnis führt, dass alle Nutzer verärgert sind.

Die kurze Pause beim Verbindungsaufbau (s.o.) erreicht genau das gleiche und lässt jede legitime E-Mail beim ersten Versuch durch. Platziert man sie hinter eine Whitelist kommen alle Nachrichten von namhaften Anbietern sofort durch, während der Rest mit 5 Sekunden Verzögerung zugestellt wird – damit können alle Nutzer gut leben.

Die Nutzung von fraglichen, nicht durch RFCs abgedeckten Methoden – und genau dazu gehört das Greylisting –  kann außerdem dazu führen, dass man selbst in der einen oder anderen Blacklist landet und dann Probleme beim Versand bekommt.

5. White- und Blacklists nutzen

Ohne Blacklists geht es nicht. Allerdings beinhalten selbst die besten Blacklists auch immer sogenannte “False-Positives”. Insbesondere die Freemail-Provider leiden ständig darunter, dass ihre Accounts für Spam-Operationen missbraucht werden und dann ihre Server in Blacklists auftauchen.

Wer nicht Gefahr laufen möchte, einen kompletten Freemail-Provider zu blockieren, nur weil einige seiner Accounts missbraucht wurden, muss Whitelists nutzen.

Das Spam-Aufkommen erhöht sich dadurch nicht wirklich, die nennenswerte Menge an Spam kommt von dedizierten Spam-Versand-Servern. Die wenigen zusätzlichen Spam-Nachrichten filtert ein gut konfigurierter SpamAssassin mühelos heraus.

Bei mehreren hundert Black- und Whitelists gilt es allerdings die richtig guten zu finden und gleichzeitig die Anzahl der nötigen Prüfungen nicht durch unnötig viele Blacklists in die Höhe zu treiben. Aktuell (April 2018) empfehle ich folgende Konfiguration:

/etc/postfix/main.cf

smtpd_client_restrictions = permit_inet_interfaces,
    permit_mynetworks,
    permit_dnswl_client list.dnswl.org,
    [...]
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client psbl.surriel.com,
    reject_rbl_client b.barracudacentral.org,
    reject_rbl_client ix.dnsbl.manitu.net,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    [...]

6. Eigenen DNS-Resolver nutzen

Wer White- und Blacklists nutzt, sollte einen eigenen DNS-Resolver nutzen. Praktisch alle Listen haben ein stündliches oder tägliches Abfrage-Limit, das ohne Bezahlung relativ niedrig gesetzt ist.

Wer die Resolver seines Providers oder sogar öffentliche Systeme wie Google-DNS nutzt, wird kaum eine Chance haben, tatsächliche Antworten zu bekommen. Stattdessen kommen je nach Anbieter entweder Fehlermeldungen oder leere Antworten zurück; die White- und Blacklists bleiben demnach ohne Wirkung.

Die Installation eines kleinen Resolvers ist schnell gemacht und schafft Abhilfe.

7. Syntax prüfen

Es bringt sehr viel, nicht nur Blacklists abzufragen, sondern auch möglichst viele Informationen auf eine korrekte Syntax zu überprüfen. Dazu zählen:

  • Ist die Absender-Domain ein FQDN? (reject_non_fqdn_sender)
  • Existiert die Absender-Domain überhaupt? (reject_unknown_sender_domain)
  • Ist der HELO-Name ein FQDN? (reject_non_fqdn_helo_hostname)
  • Enthält der HELO-Name ungültige Zeichen? (reject_invalid_helo_hostname)
  • Existiert für den HELO-Namen ein Hostname, der tatsächlich auf eine IP-Adresse verweist? (reject_unknown_helo_hostname)
  • Funktioniert ein Reverse-Mapping, d.h. mit einem DNS-Lookup IP –> Host –> IP kommt man wieder bei der Client-IP an (reject_unknown_client_hostname)

Bei manchen legitimen Seiten mit inkompetenten Administratoren kommt es mit reject_unknown_client_hostname leider immer noch zu Fehlern. Eine Alternative ist die Option reject_unknown_reverse_client_hostname, bei der nur die Existenz eines Reverse-Eintrages geprüft wird (IP –> Host), nicht aber ob dieser Host auch auf die richtige IP zeigt. Das ist zwar eine deutlich schwächere Prüfung, reicht aber zum Herausfiltern von Spammern auch aus.

/etc/postfix/main.cf

smtpd_client_restrictions = [...],
    reject_unknown_client_hostname,
    [...]
smtpd_helo_restrictions = [...],
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname
    [...]
smtpd_sender_restrictions = [...],
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    [...]

Um die Prüfungen zu beschleunigen sollten Optionen, die keine DNS-Abfragen erfordern (einfache Syntax-Checks wie z.B. reject_invalid_helo_hostname) immer vorne stehen.

8. Manuelle Blacklists pflegen

Blacklists können hilfreich sein, um hartnäckige Spammer auszuschließen, die gut genug sind, um nicht in DNS-Blacklists zu landen.

Außerdem kann eine solche Blacklist eine Unmenge an Spam abhalten:

news@*
newsletter@*
*@news.*
*@newsletter.*

Das lässt sich aber nur durchsetzen, wenn alle Nutzer einverstanden sind, denn so sortiert man natürlich auch viele legitime Newsletter aus, die ein Nutzer evtl. bestellt hat.

9. SPF prüfen

SPF ist einfach und erfordert dem Administrator nicht viel ab. Hier kann davon ausgegangen werden, dass gescheiterte SPF-Prüfungen tatsächlich Spam sind und noch während der SMTP-Session abgelehnt werden können. Eine einfache Möglichkeit, die in wenigen Minuten einsatzbereit ist, ist postfix-policyd-spf-perl.

Bei Debian erfolgt die Installation inkl. aller Perl-Pakete mit

apt-get update && apt-get install postfix-policyd-spf-perl

In die Datei /etc/postfix/master.cf fügt man ganz am Ende ein:

policy unix - n n - - spawn
 user=nobody argv=/usr/bin/perl /usr/sbin/postfix-policyd-spf-perl

Dann steht die Filterung in der Datei /etc/postfix/main.cf zur Verfügung:

smtpd_sender_restrictions = [...]
    check_policy_service unix:private/policy
    [...]

10. DKIM nicht prüfen

Bei DKIM sieht die Sache deutlich anders aus als bei SPF. Das Verfahren ist zwar technisch überlegen, allerdings sind viele Administratoren mit seiner korrekten Konfiguration überfordert.

Zusätzlich manipulieren viele Virenscanner, Spamfilter usw. in Dingen herum, die sie nichts angehen. Fügt z.B. ein Scanner einen Footer an die Nachricht an nachdem die DKIM-Signatur generiert wurde (“This message has been scanned by an incompetent AntiVirus software and found to be clean.”), führt das unweigerlich zu ungültigen DKIM-Signaturen.

Gleiches gilt natürlich bei Spamfiltern, die in der Betreffzeile herummanipulieren (***Spam*** vor der Betreffzeile), oder Virenscanner, die einen vermeintlich infizierten Anhang entfernen und den Rest zustellen statt die ganze E-Mail einfach abzulehnen oder in der Quarantäne zu verschieben.

Tatsache ist, dass DKIM-signierte Nachrichten in den allermeisten Fällen mit einer ungültigen Signatur ankommen und daher eine zuverlässige Filterung während der SMTP-Session unmöglich ist. Das macht aber nichts, denn SpamAssassin übernimmt die DKIM-Prüfung und kann zuverlässig zwischen falschen Signaturen und dem Werk inkompetenter Administratoren und/oder schlechter Content-Filter unterscheiden.

11. Einhaltung der RFCs erzwingen

Das Erzwingen von RFCs ist an den meisten Stellen sinnvoll.

Beispielsweise sortiert smtpd_helo_required zuverlässig Clients aus, die sich weigern, die SMTP-Session mit HELO oder EHLO zu beginnen. Nur so können die o.g. Prüfungen des HELO-Namens durchgeführt werden.

SSL sollte auf jeden Fall angeboten werden (smtpd_tls_security_level = may). SSL zu erzwingen ist leider nur bedingt möglich, weil selbst namhafte Unternehmen wie die Deutsche Post immer noch keinen ausgehenden Mailversand per SSL unterstützen. Erzwingt ein Empfänger die Verschlüsselung, stellt die Post keine Nachrichten zu. Wer SSL erzwingen möchte muss also sehr genau auf seine Logs schauen und umfangreiche Ausnahmelisten pflegen. Wer SSL anbietet sorgt jedoch dafür, dass es wenn immer möglich genutzt wird – ein entsprechender Headereintrag  (smtpd_tls_received_header) kann durch SpamAssassin positiv berücksichtigt werden. Natürlich sollte das Zertifikat vertrauenswürdig sein – dank LetsEncrypt ist das heute nicht mehr mit Schutzgeldzahlungen an Verisign oder den Rest der Zertifizerungsmafia verbunden.

Bei ausgehenden Nachrichten ist heutzutage ein höheres Sicherheitslevel möglich (smtp_tls_security_level = encrypt), so wird zuverlässig für Datenschutz gesorgt und man kommt beim Empfänger in den Genuss von Bonuspunkten bei SpamAssassin. Sollte tatsächlich eine Nachricht wegen der SSL-Forderung nicht zustellbar sein wird der Absener informiert, sodass man Ausnahmen definieren kann.

12. Anhänge filtern

Alle nicht erwünschten Anhänge sollten gefiltert werden.

Postfix kann das grundsätzlich selbst, es ist aber sehr aufwändig und achtet zumeist nur auf die Dateiendung oder den Mime-Type und nicht auf den tatsächlichen Inhalt der Datei. Ich bevorzuge die Nutzung einen Content-Filters (z.B. AMaViS), um solche komplexen Untersuchungen anzustellen.

Es sollten auch alle Office-Dokumente gefiltert werden, denn abgesehen von den damit einhergehenden Gefahren ist es einfach nur unhöflich, des Besitz einer bestimmten Software vorauszusetzen. Dabei ist es egal, ob der Absender Microsoft Office, OpenOffice, LibreOffice oder sonst irgend etwas voraussetzt. Das Argument “Aber OpenOffice kann doch jeder herunterladen” ist dabei belanglos, denn vielleicht habe ich ja Microsoft Office und will weder ein zweites Office installieren, noch habe ich Interesse jedes eingehende Dokument zu konvertieren. Und die Aussage “Open Office kann alles öffnen” ist einfach nur gelogen, denn jeder der das z.B. mal mit größeren PowerPoint-Präsentationen oder Word-Formularen versucht hat anstatt nur die ewige Propaganda nachzureden weis das. Das Dateiformat zum Austausch von Dokumenten im Internet ist PDF; inzwischen hat selbst Microsoft das gelernt und seine XPS-Versuche aufgegeben.

Das gleiche gilt natürlich auch für sonstige Dokument-Anhänge wie Photoshop, Flash, Programmdateien, Systemdateien, HTML-Dateien usw….

Ich pflege für meine Systeme eine Whitelist mit bestimmten Dateitypen, die man mir schicken darf, alles andere wird abgelehnt. Die Prüfung erfolgt anhand des Inhalts in nicht anhand des Namens:

  • GIF
  • JPG
  • PNG
  • PDF
  • TXT
  • PGP und ASC

13. Reverse-DNS

Wie oben bereits dargestellt erfolgt sinnvollerweise eine Prüfung des Reverse-Mappings (IP –> Hostname –> IP). Nur wenn die IP per Reverse-Lookup einem Hostnamen zugeordnet werden kann und dieser zu genau der gleichen IP aufgelöst werden kann, wird die E-Mail angenommen.

Es ist natürlich selbstredend, dass diese Konfiguration auch am eigenen System vorgenommen werden muss. Wer das nicht macht, läuft Gefahr auf Blacklists zu landen und Probleme beim Mailversand zu bekommen.

Konfiguration für Postfix

Zusammengefasst ergeben die vorstehenden Punkte diese Konfiguration für Postfix:

/etc/postfix/main.cf

[...]
smtp_tls_security_level = encrypt
smtpd_delay_reject = no
smtpd_helo_required = yes
smtpd_tls_received_header = yes
smtpd_client_restrictions = permit_inet_interfaces,
    permit_mynetworks,
    permit_dnswl_client list.dnswl.org,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client psbl.surriel.com,
    reject_rbl_client b.barracudacentral.org,
    reject_rbl_client ix.dnsbl.manitu.net,
    reject_rhsbl_reverse_client dbl.spamhaus.org
smtpd_helo_restrictions = permit_inet_interfaces,
    permit_mynetworks,
    permit_dnswl_client list.dnswl.org,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname,
    reject_rhsbl_helo dbl.spamhaus.org
smtpd_sender_restrictions = permit_inet_interfaces,
    permit_mynetworks,
    permit_dnswl_client list.dnswl.org,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    check_policy_service unix:private/policy,
    reject_rhsbl_sender dbl.spamhaus.org,
    check_sender_access mysql:/etc/postfix/lists/own_domains,
    check_sender_access mysql:/etc/postfix/lists/blacklist
smtpd_recipient_restrictions = permit_inet_interfaces,
    permit_mynetworks,
    reject_unauth_destination
[...]

/etc/postfix/master.cf

smtp inet n - y - - smtpd
  -o content_filter=smtp:[127.0.0.1]:10024
  -o smtpd_tls_security_level=may
submission inet n - y - - smtpd
  -o milter_macro_daemon_name=ORIGINATING
  -o mynetworks=
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_security_level=encrypt
  -o syslog_name=postfix/submission

Leave a Reply

Your email address will not be published. Required fields are marked *