sqlgrey: einfaches und robustes Greylisting

Spam nervt und stiehlt jedem Nutzer täglich Zeit. Um zu vermeiden, dass wir eines Tages nur noch mit dem Löschung von dubiosen Angeboten beschäftigt sind, müssen wir uns immer wieder mit Gegenmaßnahmen befassen. Eine dieser Gegenmaßnahmen ist Greylisting.

Was ist Greylisting?

Das Wort Greylisting entstand aus den Wörtern Blacklisting (in diesem Kontext: permanentes Verbot einer E-Mailadresse) und Whitelisting (permanente Erlaubnis für eine E-Mailadresse) und bezieht sich auf die Mischung dieser beiden Verfahren. Das Verfahren funktioniert vereinfacht wie folgt:

  1. Ein dem Mailserver unbekannter Absender (freund@absender.tld) möchte gern ein Mail an person1@mailserver.tld senden.
  2. Der Mailserver (mit installiertem Greylisting) aber lehnt die Übermittlung nach Erhalt der Absender und Zieladresse unter Angabe eines temporären Fehlers ab (meist mit einer Greylisting-Erklärung für das Logfile).
  3. Der Mailserver trägt die IP des Absendermailserver ( absender.tld, 123.123.123.123 ) zusammen mit dem Absender (freund@absender.tld) und der Zieladresse (person1@mailserver.tld) in seine Datenbank ein.
  4. Ein vernüftig konfigurierter Mailserver wird innerhalb der nächsten 10 bis 60 Minuten eine erneute Zustellung versuchen. So ist es auch und so versucht der Mailserver von freund@absender.tld erneut, die Mail an person1@mailserver.tld zu übergeben.
  5. Der Zielmailserver schaut nun wiederum in seine Datenbank, ob ihm diese Kombination aus Quell-IP (wahlweise auch Quell-Subnetz), Absender und Adressat bereits bekannt ist. Da dem in diesem Fall so ist, nimmt er die Mail an und bestätigt die Annahme.

Die Idee hinter dieser “Verkomplizierung” der Mailzustellung ist, dass die Spammaschinen entweder das Handling von temporären Fehlern ausgeschaltet oder dieses in Ihren Mailprogrammen/ -servern gar nicht implementiert haben, um den Durchsatz zu erhöhen.

Wie kann ich Greylisting einsetzen?

Da Greylisting wie oben erläutert noch vor der Annahme der Mail geschehen muss, kann man dieses entweder direkt im Mailserver integrieren (z.B. Plugin) oder alternativ dem Mailserver als Proxy vorschalten.

Versuch 1: postgrey

Da ich Postfix einsetze suchte ich nach einer Lösung, die damit out-of-the-box zusammenarbeitet. Ich fand zunächst postgrey, welches extra für diesen Fall konzipiert und erstellt wurde, aber wohl auch mit exim laufen soll.

Nach einer Installation mittels

apt-get install postgrey

und dem Einfügen folgender Zeile in die main.cf von postfix ( /etc/postifx/main.cf ) innerhalb der smtpd_recipient_restrictions

check_policy_service inet:127.0.0.1:60000

stand mir der postgrey-deamon bereits zur Seite.

Die Reihenfolge der Regeln innerhalb der main.cf sieht bei mir so aus:

smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_rbl_client dnsbl.ahbl.org
reject_rbl_client cbl.abuseat.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
check_policy_service inet:127.0.0.1:60000
reject_unknown_client
warn_if_reject reject_unknown_hostname
permit

Ich war erstaunt, dass alles so reibungslos funktionierte, beobachtete mein Logfile und freute mich, dass ich nun weniger Spam erhielt.

Ein paar Wochen lang funktionierte das System wunderbar: Kaum ein Spamchen traute sich noch in eine meiner Mailboxen und auch sonst gab es keinen Grund zum Klagen – vielleicht bis auf die 1-2 Male, bei denen ich auf eine Mail dringend wartete und dann aufgrund von Greylisting länger warten musste (bis zum 2. Versuch).

Doch dann passierte… NICHTS! Keine einzige Mail erreichte mein Postfach. Sehr verwunderlich, denn ich erhalte doch zumindestens ein paar Status-Mails über wichtige Cronjobs von meinem Server und auch ein paar Newsletter. Das Problem war schnell ausgemacht: postgrey konnte nicht starten, weil die Datenbank korrupt war.

Warum? Keine Ahnung! Lösung? Nunja, Google erwähnte so einige Tools für die von postgrey verwendete Berkeley-DB mit dem man solche Fehler beheben können soll. Leider funktionierten diese Tools nicht wie gewünscht und ich war gezwungen, postgrey durch Löschen der alten DB eine neue DB anlegen zu lassen. Dadurch waren alle bekannten Absender wieder unbekannt und die Mailzustellung, auch von Menschen mit denen ich täglich kommuniziere, war verzögert. Das war sehr ärgerlich. Weiterhin wurden in der Zeit des defekten postgreys alle Mails mit einem temporären Fehler abgelehnt worden und ich konnte nur hoffen, dass ich alle Mails noch einmal erhalte.

Mir war die Berkeley-DB noch nie ganz geheuer. Ich weiß, dass sie ziemlich bekannt ist und z.B. auch von amavis standardmäßig verwendet wird. Nichtsdestotrotz ist sie für mich eine “Black Box” und nicht so leicht wartbar. Daher suchte ich nach einer Möglichkeit einen Dienst auf MySQL-Basis zu betreiben.

Versuch 2: Die Alternative sqlgrey

Das Projekt sqlgrey basiert auf dem Code von postgrey und hat sich zur Aufgabe gemacht, die Vorteile von postgrey mit den Vorteilen von MySQL zu verbinden.

Nach meiner Einschätzung haben sie dies ganz gut geschafft, denn es funktioniert bisher fehlerfrei und ist (für mich) leichter wartbar. So bietet sqlgrey mit 4 Tabellen ganz einfach die Möglichkeit, ganze Domains vom Greylisting aus- oder einzuschließen oder dies auch nur für einzelne Adressen zu ermöglichen. Ich verwende dies, um meinen Mailnutzern die Wahlfreiheit über dieses Sicherheitsfeature zu bieten.

Die Installation gestaltet sich relativ einfach.

Download der aktuellen Version, z.B.


mkdir ~/downloads
cd ~/downloads
wget http://dfn.dl.sourceforge.net/sourceforge/sqlgrey/sqlgrey-1.6.8.tar.bz2

auspacken

tar -xjf sqlgrey-1.6.8.tar.bz2

und installieren

make
make clean
make install

Dann einen unpriviligierten User und Gruppe anlegen, unter denen der daemon laufen soll:

groupadd sqlgrey
useradd -d /etc/sqlgrey -g sqlgrey -c SQLgrey-User -s /bin/false sqlgrey

Danach müssen wir eine MySQL-Datenbank anlegen, in der sqlgrey die Daten speichern kann.

Ich empfehle dafür einen neuen DB-User anzulegen, diesen mit einem langen Zufallspasswort zu versehen sowie ihm nur Zugriff auf diese Datenbank zu geben (ohne GRANT). Die Tabellen werden beim ersten Start von sqlgrey automatisch angelegt.

Mit den neuen Informationen muss man nun noch die Datei /etc/sqlgrey/sqlgrey.conf füttern:

db_type = mysql
db_name = sqlgrey

db_host = localhost
db_port = default
db_user = sqlgrey
db_pass = -DBPASS-

Die restlichen Einstellungen kann man getrost erst einmal default lassen oder eben gleich mal nach eigenem Gusto verändern – jede Option ist gut dokumentiert.

Danach können wir den daemon starten und im Syslog ggf. nach Fehler suchen.

/etc/init.d/sqlgrey start

Sofern nicht (noch) vorhanden, muss nun noch in der Postfix-Config ( /etc/postfix/main.cf ) noch der Policyserver eingefügt werden (siehe oben bei postgrey, Portänderung beachten!).

smtpd_recipient_restrictions =
[...]
check_policy_service inet:127.0.0.1:2501
[...]
permit

/etc/init.d/postfix reload

Sofern alles läuft (externe Testmails müssten erst abgelehnt werden und beim zweiten Versuch dann durchkommen), müssen wir dann noch den Systemstart einrichten:

update-rc.d sqlgrey defaults 80

So startet der sqlgrey relativ spät bei jedem Systemstart.

Fertig! :)

Hinweise

Zu beachten ist, dass Postfix keine Mails annehmen kann, wenn der sqlgrey nicht läuft – es ist also wichtig, diesen Dienst im Auge zu behalten!

Explizite Ein- bzw. Ausschlüsse (OPTIN/OPTOUT) können über die entsprechenden Tabellen vorgenommen werden.

Da bisher kein Debian-Paket zur Verfügung steht, sollte man die Mailingsliste für Annoucements einer neuen Version abonieren, um keine Bugfixes zu verpassen.

7 Gedanken zu „sqlgrey: einfaches und robustes Greylisting“

  1. Pingback: WE ARE ROOT

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *