Das vielfältig konfigurierbare Postfix-Plugin Policyd wehrt Spam per Greylisting, Senderdetektion, Mailmengen-Messung, Blacklisting und HELO-Rotationserkennung ab.
|
Inhalt |
|---|
|
72 | Crypto-Server 6.3 im Test Zwei-Faktor-Authentifizierung, die mehrere Systemplattformen unterstützt, ist die Stärke des Cryptocard-Produkts. 76 | Apache Modsecurity Ein Apache-Modul etabliert eine Webapplication-Firewall, die OS-Command- und SQL-Injections sowie XSS/Cross-Site-Scripting-Angriffe filtert. |
An mein treues Postfix habe ich so einiges angeflanscht, zum Beispiel Spamassassin und Virenfilter – und nun: Policyd. Das Addon bindet sich nicht wie andere über den »content_filter«-Mechanismus ein, sondern per »check_policy_service«, den es ab Postfix 2.2 gibt. Das eröffnet mir die Möglichkeit, Policyd an sinnvoller Stelle in mein Regelwerk zu integrieren. So jage ich Spam, der schon abgelehnt ist, nicht durch den Policy-Daemon – oder umgekehrt. Die Installation des C-Programms von [1] ist einfach, nach dem Entpacken genügt
gmake build && gmake install
im »policyd«-Verzeichnis. MySQL ist nötig, Policyd liefert ein SQL-Skript mit, das alle Tabellen erzeugt. Und ich lege einen Cronjob an, der veraltete Einträge periodisch aus der Datenbank entfernt:
0 * * * * /usr/local/policyd/cleanup -c /usr/local/policyd/policyd.conf
Die vielen Policyd-Prüfungen lassen sich in der Konfigurationsdatei einzeln (de-) aktivieren – besonders nützlich.
HELO Random Prevention
Spammer fälschen praktisch immer die Serveridentifikation im »HELO«-Kommando, korrekte MTAs senden hier ihren FQDN. Um sich vor den HELO-Blacklisten zu schützen, schicken Spammer gern jede Mail sogar mit einem anderen HELO. Policyd, nicht faul, ist in der Lage, Mails abzuwehren, die von der gleichen IP-Adresse, aber mit unterschiedlichen HELOs kommen.
Auch die erwähnten HELO-Blacklists beherrscht Policyd. Einsichtiger Sonderfall: Meldet sich ein Mailer mit dem FQDN meines eigenen Servers an, setze ich ihn ohne Zögern sofort vor die Tür.
Sender Throttling
Policyd versteht es, zu verhindern, dass derselbe Absender den Mailserver mit einer großen Zahl Mails überflutet. Als Detektor eignen sich die From-Adresse oder deren Domain-Part, der SASL-Benutzername oder die IP-Adresse beziehungsweise ein Netzblock. Als limitierende Kriterien dienen die Anzahl der eingelieferten Mails oder deren Gesamtgröße, je nachdem, welche Grenze zuerst überschritten ist.
Recipient Throttling und Greylisting
Policyd kann verhindern, dass ein Benutzer mehr als eine bestimmte Anzahl Mails innerhalb einer bestimmten Zeitspanne erhält. Solche Limits sind sinnvoll, wenn es um allgemeine Adressen geht wie »info@doma.in« oder »support@doma.in«.
Beim Greylisting lehnt Postfix den Empfang jeder Mail zunächst mit dem Error 450 ab. Versucht der sendende Server es nach kurzer Wartepause wieder, akzeptiert Postfix die Mail [2]. Diese Methode ist recht effektiv bei der Abwehr von Massenmailern oder Bot-Netzen, denn ihnen fehlen die Warteschlangen für erneuten Versand.
Wenn sich Spammer jedoch einen löchrigen Mailserver kapern und als Relay missbrauchen, scheitert Greylisting leider. Denn ein normaler MTA wird bei einem Fehler 450 einen zweiten, dann erfolgreichen Versuch starten. Trotzdem: Policyd ist zurzeit mein liebstes Addon. (jk)
|
Infos |
|---|
|
[1] Policyd: [http://policyd.sourceforge.net] [2] P. Heinlein, “Greylisting schützt vor Wurm-generierten Spam-Mails”: Linux-Magazin 09/04, S. 66 |
Copyright © 2002 Linux New Media AG






