howto

Postgrey als Tarpit mit taRgrey

Irgendwie habe ich wohl ein neues Hobby. Es kam schleichend und man kann es ausführen egal ob es regnet oder ob die Sonne scheint. Und ich mag es sehr: Spammer ärgern!
Wie bereits in früheren Howtos gezeigt, ist es recht einfach einen Postfix mit Greylisting-Funktionen auszustatten. Aber Greylisting alleine mach noch kein super Antispammer-Charma. Dafür muss noch etwas mehr her. Eine tolle Erweiterung von Greylisting ist das Tarpitting. Beim Tarpitting wird nicht nur die Annahme einer E-mail mit einem temporären Fehler abgelehnt, sonder der Spammer im besten Fall auch noch eine gewisse Zeit „gefangen“ gehalten.
Wieso ist das eine Waffe gegen Spammer? Nun, das Absetzen einer Spammail dauert normalerweise zwischen 2 und 5 Sekunden. Wenn man den bösen, bösen Spambot aber in eine Tarpit (also Teergrube) geleitet bekommt, kann man ihn durchaus für 80-120 Sekunden an sich binden in denen er sonst niemand eine Spammail schreiben kann. Natürlich macht das bei einer Spammail keinen Sinn, aber wenn man 22.000 Spamversuche mit 85 Sekunden Verzögerung generiert, macht mich das irgendwie glücklich.

Aber jetzt einmal zum Eingemachten. Folgendes haben wir vor: Auf einem Debian mit Confixx, Postfix und Postgrey die Erweiterung taRgrey von SATOH Kiyoshi installieren. Allerdings ohne die S25R-Option. Ich gehe davon aus, dass Postgrey schon einwandfrei funktioniert. Wenn nicht, hier vorbei schauen.

Zunächst etwas obligatorisches:

apt-get update

Nun müssen wir herausfinden, welche Version von Postgrey auf unserem System installiert ist, was mit einem

postgrey --version

schnell erledigt ist.

Je nach dem Ergebnis laden wir uns nun den passenden Patch von http://k2net.hakuba.jp/targrey/index.en.html herunter.

Am einfachstes ist es wohl, direkt in das passende Verzeichnis /usr/sbin zu wechseln. Denn da liegt auch unsere zu patchende Datei „postgrey“. Die wir in einem Atemzug auch direkt einmal sichern.

cd /usr/sbin/
wget http://k2net.hakuba.jp/pub/targrey-0.30-postgrey-1.27.patch
cp postgrey postgrey.bak

Nun müssen wir pachten, also die Änderungen am Postgrey-Daemon vornehmen. Das ist recht einfach. Ein kurzes

patch -p1 

und als Ergebnis sollte es eine Ausgabe in der Art geben

patching file postgrey
Hunk #10 succeeded at 537 (offset 1 line).
Hunk #11 succeeded at 556 (offset 1 line).
Hunk #12 succeeded at 628 (offset 1 line).

Mit diesem Patch haben wir Postgrey um folgende Funktionen erweitert:

···* tarpitting: –tarpit=35 (35 Sekunden Tarpitting und Greylisting)
···* taRgrey: –tarpit=65 –targrey (Greylisting nur dann, wenn vorher das Tarpitting stattgefunden hat)
···* greylisting retry threshold: –retry-count=2 (Nach zwei Zustellversuchen wird die E-mail zugestellt)
···* auto-whitelist count delay: –auto-whitelist-delay=3600 (wann die E-mail in die Whitelist aufgenommen wird)

Um diese Funktionen nutzen zu können, müssen wir aber noch die /etc/postfix/main.cf anpassen.
So könnte sie nach dem Anpassen aussehen.

/etc/postfix/main.cf

smtpd_recipient_restrictions =
                permit_sasl_authenticated,
                permit_mynetworks,
                check_client_access hash:/etc/postfix/backupmx,

                ### Relaying aus!
                reject_unauth_destination,

                ### Postgrey - greylisting
                check_policy_service inet:127.0.0.1:60000,

                ### SPF Eintrag
                #check_policy_service unix:private/policy,

                ### Rejects
                reject_unauth_pipelining,
                reject_non_fqdn_sender,
                reject_non_fqdn_recipient,

smtpd_data_restrictions =
                permit_mynetworks
                permit_sasl_authenticated
                check_client_access hash:/etc/postfix/backupmx
                check_policy_service   inet:127.0.0.1:60000
                permit

Neu ist hier vor allem dass die „smtpd_data_restrictions“, ebenfalls mit dem postgrey-Server, aufgerufen werden. Das ist auch korrekt so, denn wenn eine E-mail mit den „smtpd_recipient_restrictions“ gefiltert wird, fällt sie erst einmal in die Teergrube und landet auf der Tarpitting-Blacklist. Dann wird sie in den „smtpd_data_restrictions“ geprüft und Postgrey stellt fest, dass es der E-mail gelungen ist, durch das Tarpitting zu gelangen. (nur interessant für den taRgrey-Modus)

Jetzt bleibt nur noch die passenden neuen Optionen an Postgrey weiter zu reichen. Das geschieht am einfachsten über die

/etc/default/postgrey

POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=1000 --auto-whitelist-clients 5  --max-age 40 --tarpit=85 --retry-count=2"

jetzt noch einmal alles neu starten…

/etc/init.d/postfix stop
/etc/init.d/postgrey restart
/etc/init.d postfix start

und schon sollten die Logfiles etwas anders aussehen:

May 26 23:45:34 vs10214 postfix/smtpd[13249]: connect from mail.gmx.net[213.165.64.20]
May 26 23:46:58 vs10214 postfix/smtpd[13249]: NOQUEUE: reject: RCPT from mail.gmx.net[213.165.64.20]: 
450 4.7.0 : Recipient address rejected: defer_if_permit requested; from= to= proto=SMTP helo=
May 26 23:46:58 vs10214 postfix/smtpd[13249]: disconnect from mail.gmx.net[213.165.64.20]

Wie man sieht, gibt es zwischen dem connect und dem reject eine Zeitspanne von 84 Sekunden. Das stimmt ja mal ziemlich genau mit den oben angegebenen 83 Sekunden Tarpitting überein… Leider kann postgrey nun keine angepasste reject-message mehr abgeben, sondern es kommt stets ein monotones “ Recipient address rejected: defer_if_permit requested“, aber es funktioniert!

Jetzt benötigt jede Spammail ca. 85 Sekunden um zugestellt zu werden. Wirklich JEDE? Leider nein, denn viele Spambots setzen einfach ihren Spam ab und disconnecten direkt wieder, ohne in unsere Teergrube zu fallen. Man kann das aber leicht in den Los erkennen, wer die 85 Sekunden ausharrt und wer nicht. Wer das Tarpitting durch hält baut die Verbindung erst nach dem DATA ab. Die ganz bösen Spammer, bauen aber schon nach dem RCPT ab.

Also mal schnell ein bisschen Logdateien tunen. Was sagt z.B. ein

tail -n 100 /var/log/mail.log | grep "lost connection"

Also bei mir sehe ich dann folgendes:

May 26 23:29:42 bender postfix/smtpd[27527]: lost connection after DATA from 
May 26 23:29:43 bender postfix/smtpd[27589]: lost connection after DATA from 
May 26 23:30:31 bender postfix/smtpd[27241]: lost connection after DATA from 
May 26 23:30:32 bender postfix/smtpd[27620]: lost connection after DATA from 
May 26 23:30:43 bender postfix/smtpd[27619]: lost connection after DATA from 
May 26 23:30:48 bender postfix/smtpd[27303]: lost connection after DATA from 
May 26 23:31:30 bender postfix/smtpd[27017]: lost connection after DATA from 
May 26 23:31:30 bender postfix/smtpd[27618]: lost connection after DATA from 
May 26 23:31:38 bender postfix/smtpd[26936]: lost connection after DATA from 
May 26 23:32:50 bender postfix/smtpd[27017]: lost connection after CONNECT from 
May 26 23:32:58 bender postfix/smtpd[27241]: lost connection after DATA from 
May 26 23:33:02 bender postfix/smtpd[27300]: lost connection after DATA from 
May 26 23:33:03 bender postfix/smtpd[27620]: lost connection after RCPT from 
May 26 23:33:13 bender postfix/smtpd[27619]: lost connection after DATA from 
May 26 23:34:15 bender postfix/smtpd[27240]: lost connection after DATA from 
May 26 23:34:49 bender postfix/smtpd[27303]: lost connection after DATA from
May 26 23:35:33 bender postfix/smtpd[27536]: lost connection after DATA from 
May 26 23:36:22 bender postfix/smtpd[27527]: lost connection after RCPT from 

Wie man sieht, werden fast alle Verbindungen erst nach dem DATA getrennt. Wer jetzt aber die Zeit bei einem „lost connection after RCPT“ zwischen dem „connect“ und dem „lost connection“ vergleicht wird sehen, dass auch hier die passenden 85 Sekunden nach zu zählen sind. RICHITG, logisch, denn erst wenn Postgrey weiterarbeiten möchte, merkt er ja dass die Verbindung schon beim RCPT abgebrochen wurde.

Will man jetzt aber wirklich mal wissen wie viel Zeit Spammer in der hauseigenen Teergrube verbringen, das mal eintippen:

cat /var/log/mail.log | grep "May 26" | grep -c "lost connection after DATA" 

und das Ergebnis (bei mir 4729) mit 85 mal nehmen: =401965 Sekunden… in Stunden: 111,6 Stunden! Und das nur am 26 Mai. – HERRLICH!

Happy tarpitting

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s