Inhaltsverzeichnis

SPAM-Abwehr mit Hilfe von Greylisting

Bild: Symbolbild Postfix und SPAM Ein auf SPAM-Versand optimiertes System, wird in aller Regel sehr viel daran gelegen sein, möglichst eine große Anzahl von Nachrichten in möglichst kürzester Zeit zu verschicken. Jede Verzögerung beim SPAM-Versand wird sich äußerst ungünstig auf die Erfolgsquote des Versenders auswirken. Hintergrund beim Thema greylisting ist nun, unbekannte Einlieferer mit einem temporären Fehler abzuweisen und so eine erneute erstmalige Zeitverzögerung zu erzwingen. Vergleichbar mit einer belegten Rufnummer bei einem Faksimilegerät.

Beides, greylisting wie auch policyd-weight setzen auf das PDP1) von Postfix auf. Mit Hilfe des Policy Delegation Protocols besitzt Postfix eine mächtige Schnittstelle, an der u.a. die wichtigsten Merkmale einer angebotenen eMail an eine externe Instanz zur Prüfung und Bewertung weitergegeben wird und anschließend darüber eine Entscheidung mitgeteilt bekommt, was mit der eMail passieren soll.

Für den ersten groben SPAM-Schutz setzen wir auf greylisting-Mechanismen. Greylisting macht es sich zu eigen, das unterschiedliche Verhalten von SPAMern und richtigen Mailservern zu betrachten. Beim greylisting werden folgende vier Schritte durchlaufen bzw. bewertet:

  1. Der MTA bewertet die drei folgenden technischen Eckdaten eines Zustellversuches, nachdem das einlieferndes System sein RCPT TO: abgesetzt hat:
    • Absender-IP-Adresse
    • eMail-Adresse des Absenders
    • eMail-Adresse des Empfängers
  2. Das Tripple aus IP-Adresse, Sender- und Empfänger-eMail-Adresse speichert der MTA nun in einer separaten Berkley-DB ab. Ist dieses Tripple neu, d.h. es wurde noch keine eMail von dem Absender an unseren Empfänger von diesem Mailserver eingeliefert, wird diue Annahme erst einmal mit einem temporärer Fehler 4xx abgeweisen.
  3. Ist der einliefernde Host ein SPAMer wird er die Nachricht verwerfen und sein Glück bei anderen weniger geschützten MTTAs versuchen. Ein richtiger Mailserver wird seine eMail in die deferred-Queue einstellen und nach wenigen Minuten einen erneuten Zustellversuch unternehmen.
  4. Kommt der einliefernde Mailserver erneut, wird nun das Tripple aus IP-Adresse, Sender- und Empfänger-eMail-Adresse positiv bewertet und unser MTA wird mit der weiteren Prüfung und Bewertung der eMail fortfahren. Ob und wann ein erneuter Zustellversuch unternommen wird, hängt einzig und allein vom Versender ab.

Installation

Für das Thema greylisting greifen wir auf das Paket postgrey von David Schweikert aus dem EPEL-Repository zurück.

Wir installieren also zu erst einmal das betreffende Paket mit Hilfe von YUM. 

 # yum install postgrey -y

Was uns das RPM alles auf unseren Server gebracht hat, finden wir mit Hilfe des Befehls rpm heraus. 

 # rpm -qil postgrey
Name        : postgrey
Version     : 1.34
Release     : 12.el7
Architecture: noarch
Install Date: Wed 05 Nov 2014 12:52:11 PM CET
Group       : Unspecified
Size        : 106568
License     : GPLv2+
Signature   : RSA/SHA256, Sun 16 Feb 2014 08:03:16 PM CET, Key ID 6a2faea2352c64e5
Source RPM  : postgrey-1.34-12.el7.src.rpm
Build Date  : Fri 07 Feb 2014 01:44:13 AM CET
Build Host  : buildvm-03.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://postgrey.schweikert.ch/
Summary     : Postfix Greylisting Policy Server
Description :
Postgrey is a Postfix policy server implementing greylisting. When a request
for delivery of a mail is received by Postfix via SMTP, the triplet CLIENT_IP /
SENDER / RECIPIENT is built. If it is the first time that this triplet is
seen, or if the triplet was first seen less than 5 minutes, then the mail gets
rejected with a temporary error. Hopefully spammers or viruses will not try
again later, as it is however required per RFC.
/etc/postfix/postgrey_whitelist_clients
/etc/postfix/postgrey_whitelist_clients.local
/etc/postfix/postgrey_whitelist_recipients
/etc/sysconfig/postgrey
/usr/lib/systemd/system/postgrey.service
/usr/sbin/postgrey
/usr/sbin/postgreyreport
/usr/share/doc/postgrey-1.34
/usr/share/doc/postgrey-1.34/COPYING
/usr/share/doc/postgrey-1.34/Changes
/usr/share/doc/postgrey-1.34/README
/usr/share/doc/postgrey-1.34/README-rpm
/usr/share/man/man8/postgrey.8.gz
/var/spool/postfix/postgrey

Konfiguration

Genau genommen müssen wir eigentlich nicht postgrey sondern postfix konfigurieren.

Bei der Grundkonfiguration unseres Postfix-SMTP-Servers hatten wir bereits in der Section SMTP Recipient Restrictions die nötige Konfigurationszeile angelegt. Wir aktivieren also die zugehörige Option check_policy_service unix:postgrey/socket in der Konfigurationsdatei. 

 # vim /etc/postfix/main.cf
...
 
################################################################################
## SMTP RECIPIENT RESTRICTIONS
#
# Django : 2014-10-29 - Schutz unserer Empfänger mit Hilfe der Recipient 
#          Restrictions 
# default: smtpd_recipient_restrictions =
smtpd_recipient_restrictions =
#          Postmaster, abuse und andere aufgaben- oder funktionsgebundene 
#          eMail-Adressen (Role-Accounts) whitelisten
           check_recipient_access btree:/etc/postfix/access_recipient-rfc
 
#          Black- und Whitelisting       (Kapitel 8.2.3 White- und Blacklisting)
           check_client_access cidr:/etc/postfix/access_client
           check_helo_access btree:/etc/postfix/access_helo
           check_sender_access btree:/etc/postfix/access_sender
           check_recipient_access btree:/etc/postfix/access_recipient
 
#          Unsere eigenen Nutzer zulassen-/erlauben             
#                                (Kapitel 8.2.2 Relaying erlauben und verbieten)
           permit_sasl_authenticated
           permit_mynetworks
 
#          RBL überprüfen               (Kapitel 10.11 Realtime Blackhole Lists)
           reject_rbl_client zen.spamhaus.org
           reject_rbl_client ix.dnsbl.manitu.net
           reject_rbl_client bl.spamcop.net
           reject_rhsbl_client multi.uribl.com
 
#          Greylisting via postgrey checken via Unix-Socket
#                                          (Kapitel 9.2.5 postgrey installieren)
           check_policy_service unix:postgrey/socket
 
#          Policyd-Weight check over TCP-Connection 
#                                      (Kapitel 9.3 policyd-weight installieren)
#          check_client_access btree:/etc/postfix/policyd_weight_client_whitelist,
#          check_policy_service inet:127.0.0.1:12525
 
#          Dynamische Prüfung auf existente Relay-Empfänger
#                            (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung)
           reject_unverified_recipient
 
#          Backupserver (MX) erlauben
           permit_mx_backup
 
#          alles andere an relaying verbieten   
#                                (Kapitel 8.2.2 Relaying erlauben und verbieten)
           reject_unauth_destination
 
#          Quota-Status-Policy-Daemon am Dovecot-Backend-System
#          Dovecotbuch (ISBN 978-3-95539-74-7) Seite 219 ff.  
#                          (Kapitel 11.11 "Der Quota-Policy-Server für Postfix")
           check_policy_service inet:10.0.0.77:10000
 
#          Zu guter Letzt alles durchlassen, was bis jetzt noch nicht 
#          beanstandet wurde
           permit

postgrey starten

Beim vorliegenden postgrey-RPM ist neben der Festlegung von User- und Dateirechten auch gleich ein passendes Startupscript installiert worden. Somit reicht ein einfaches service postgrey start aus: 

 # systemctl start postgrey

Fragen wir nun den Status des Daemon ab erhalten wir den genauen Status angezeigt. 

 # systemctl status postgrey
postgrey.service - Postfix Greylisting Service                                                                                                                                                             
   Loaded: loaded (/usr/lib/systemd/system/postgrey.service; disabled)                                                                                                                                     
   Active: active (running) since Wed 2014-11-05 13:09:04 CET; 7s ago
     Docs: man:postgrey(8)
  Process: 6074 ExecStart=/usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %%s seconds --daemonize $POSTGREY_OPTS (code=exited, status=0/SUCCESS)
  Process: 6072 ExecStartPre=/bin/rm -f /var/run/postgrey.pid (code=exited, status=0/SUCCESS)
 Main PID: 6076 (/usr/sbin/postg)
   CGroup: /system.slice/postgrey.service
           └─6076 /usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %s seconds --daemonize --...

Nov 05 13:09:04 vml000087.dmz.nausch.org systemd[1]: PID file /var/run/postgrey.pid not readable (yet?) after start.
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Process Backgrounded
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: 2014/11/05-13:09:04 postgrey (type Net::Server::Multiplex) starting! pid(6076)
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Binding to UNIX socket file "/var/spool/postfix/postgrey/socket"
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Setting gid to "996 996"
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Setting uid to "996"
Nov 05 13:09:04 vml000087.dmz.nausch.org systemd[1]: Started Postfix Greylisting Service.

Auch im Maillog finden wir diese Zeilen wieder. 

 # less /var/log/maillog
Nov  5 13:09:04 vml000087 postgrey[6076]: Process Backgrounded
Nov  5 13:09:04 vml000087 postgrey[6076]: 2014/11/05-13:09:04 postgrey (type Net::Server::Multiplex) starting! pid(6076)
Nov  5 13:09:04 vml000087 postgrey[6076]: Binding to UNIX socket file "/var/spool/postfix/postgrey/socket"
Nov  5 13:09:04 vml000087 postgrey[6076]: Setting gid to "996 996"
Nov  5 13:09:04 vml000087 postgrey[6076]: Setting uid to "996"

Mit einem Blick in die Prozessliste können wir uns vergewissern, ob der daemon auch gestartet wurde: 

 # ps auxw | grep postgrey
 postgrey  6076  0.0  1.3 171852 14032 ?        Ss   13:09   0:00 /usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %s seconds --daemonize --delay=60

Damit nun unser Diesnt beim Starten automatisch starten, sorgen wir mit folgendem Aufruf. 

 # systemctl enable postgrey
 ln -s '/usr/lib/systemd/system/postgrey.service' '/etc/systemd/system/multi-user.target.wants/postgrey.service'

Wollen wir überprüfen ob der Dienst automatisch startet, verwenden wir folgenden Aufruf. 

 # systemctl is-enabled postgrey
 enabled

Die Rückmeldung enabled zeigt an, dass der Dienst automatisch startet; ein disabled zeigt entsprechend an, dass der Dienst nicht automatisch startet.

postgrey Administration

Die Konfigurationsdateien rund um postgrey befinden sich im Verzeichnis /etc/postfix/: 

 # ll /etc/postfix/postgrey*
-rw-r--r--. 1 root root 8343 May  4  2011 /etc/postfix/postgrey_whitelist_clients
-rw-r--r--. 1 root root   59 Feb  7  2014 /etc/postfix/postgrey_whitelist_clients.local
-rw-r--r--. 1 root root  188 May  4  2011 /etc/postfix/postgrey_whitelist_recipients

Die Konfigurationsdateien im Verzeichnis /etc/postfix/ haben folgende Bedeutung bzw. werden für folgende Funktionen benötigt:

Nach Änderungen an den Postgrey Ausnahmelisten postgrey_whitelist_clients.local und postgrey_whitelist_recipients ist der Daemon von den Änderungen mit einem reload in Kenntnis zu setzen! 

 # systemctl restart postgrey

erfolgreiches Greylisting

Am nachfolgenden Beispiel sehen wir, dass ein Connectversuch von einem uns unbekanntem Mailserver erst einmal mit einem 450er abgewiesen wird und später nocheinmal zugestellt werden soll. 

Oct 12 04:35:39 nss postfix/smtpd[16118]: connect from mail04.mytoys-mail.de[213.61.120.248]
Oct 12 04:35:41 nss postgrey[8228]: action=greylist, reason=new, client_name=mail04.mytoys-mail.de, client_address=213.61.120.248, sender=newsletter@mytoys-mail.de, recipient=wtlbrft@nausch.org 
Oct 12 04:35:41 nss postgrey[8228]: cleaning up old logs... 
Oct 12 04:35:41 nss postfix/smtpd[16118]: NOQUEUE: reject: RCPT from mail04.mytoys-mail.de[213.61.120.248]: 450 4.2.0 <wtlbrft@nausch.org>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/nausch.org.html; from=<newsletter@mytoys-mail.de> to=<wtlbrft@nausch.org> proto=ESMTP helo=<mail04.mytoys-mail.de>
Oct 12 04:35:41 nss postfix/smtpd[16118]: disconnect from mail04.mytoys-mail.de[213.61.120.248]

Beim nächsten Zustellversuch wird die eMail dann entsprechend akzeptiert: 

Oct 12 11:28:39 nss postfix/smtpd[21938]: connect from mail04.mytoys-mail.de[213.61.120.248]
Oct 12 11:28:41 nss postgrey[8228]: action=pass, reason=triplet found, delay=24780, client_name=mail04.mytoys-mail.de, client_address=213.61.120.248, sender=newsletter@mytoys-mail.de, recipient=wtlbrft@nausch.org 
Oct 12 11:28:41 nss postfix/smtpd[21938]: 4EA6476022D: client=mail04.mytoys-mail.de[213.61.120.248]
Oct 12 11:28:41 nss postfix/cleanup[21942]: 4EA6476022D: message-id=<200810120235.m9C2Zceo068208@mail04.mytoys-mail.de>
Oct 12 11:28:41 nss postfix/qmgr[8783]: 4EA6476022D: from=<newsletter@mytoys-mail.de>, size=80786, nrcpt=1 (queue active)
Oct 12 11:28:41 nss postfix/local[21943]: 4EA6476022D: to=<wtlbrft@nausch.org>, relay=local, delay=2.1, delays=2/0.02/0/0.06, dsn=2.0.0, status=sent (delivered to mailbox)
Oct 12 11:28:41 nss postfix/qmgr[8783]: 4EA6476022D: removed
Oct 12 11:31:13 nss postfix/smtpd[21938]: disconnect from mail04.mytoys-mail.de[213.61.120.248]

graphische Statistiken Greylisting

Will man sich einen generellen Überblick über die Greylisting-Auswirkungen beim Mailverkehr informieren, greift man am besten auf Mailgraph-NG zurück.

BIL: Greilisting Statistik von Mailgraph-NG

FAZIT

Postgrey hat sich in der Abwehr von SPAM und anderen unerwünschten Verkehrs bestens bewährt, kann so doch jede Menge des unerwünschten Traffics abgelehnt werden.

Da es aber bei der initilaen Kontaktaufnahme immer zu ca. 5 Minuten Verzögerung oder auch mehr kommt, sind viele Anwender unglücklich, wenn z.B. eine telefonisch avisierte Nachricht nicht sofort zugestellt wird. Auch bei sporadischer Kontaktaufnahme kommt es bisweilen zu Verzögerungen.

Mittlerweilen erzielt man mit entsprechend konfigurierten postscreen ähnlich gute Ergebnisse wie mit greylisting.

summa sumarum:

In Zeiten von immer stärkeren Echtzeitkommunikationswünschen seiten der Anwender/Kunden, setzt man statt auf greylisting nunmehr besser auf postscreen!

Links

1)
Policy Delegation Protocol