Spam durch Grey- und Whitelisting mit Postgrey bekämpfen

© Andrey Bayda, 123RF

Postzusteller

Gegen Spam – eine der hartnäckigsten Plagen des Internets – entwickeln Hersteller immer neue Gegenmittel. Dieser Beitrag zeigt, wie sich Postgrey in Postfix integrieren lässt, woraus eine wirkungsvolle Lösung für Grey- und Whitelisting entsteht.
Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

Spammer fluten Mailserver in jeder Sekunde mit Unmengen unerwünschter Post. Ham, der erwünschte Anteil, macht dagegen nach konservativen Schätzungen nur noch fünf bis zehn Prozent des Mailaufkommens im Internet aus. Für die Spammer rechnet sich ihr Geschäft, das sie noch immer mit den Empfängern machen, die auf Links in den Mails klicken und damit gefälschte Arzneimittel und Ähnliches kaufen.

Silver Bullet

Wenn man sich schon jahrelang mit dem Problem beschäftigt hat, ist es womöglich schwer zu glauben, aber man kann sofort 95 Prozent allen Spams loswerden (Abbildung 1). Die Aussage stößt oft auf Unglauben. Doch der Autor dieses Beitrags geht noch weiter: Mit einer Wunderwaffe und einer Handvoll zusätzlicher Zeilen in der Mailserver-Konfiguration lässt sich der Anteil auf 97 oder mehr steigern.

Abbildung 1: So sinkt das Spamaufkommen, nachdem Greylisting aktiviert wurde.

Die angesprochene Wunderwaffe ist das Greylisting. Aber wie funktioniert es? Der empfangende SMTP-Server beantwortet einfach alle Mails von erstmals auftauchenden Absendern mit einem temporären SMTP-Fehlercode. Die Fehlermeldung könnte so etwas bedeuten wie: "Tut mit wirklich leid, aber im Moment ist kein Plattenplatz mehr frei, versuche es doch ein bisschen später noch einmal." Oder: "Ich habe gerade ein internes Konfigurationsproblem und kann die E-Mail deshalb nicht sofort zustellen. Versuch es doch in einem Augenblick wieder."

Beim Greylisting geht man nun davon aus, dass es Spammer darauf anlegen, so viele E-Mails wie möglich so schnell wie möglich zu versenden. Meistens benutzen sie kompromittierte Mailserver, deren Sicherheitslücken schon bald geschlossen werden könnten. Außerdem könnte die benutzte IP-Adresse auf einer Sperrliste landen. Deshalb sind Spammer gezwungen, so viele Mails in so kurzer Zeit wie möglich abzusetzen, auch um den Preis, bei Problemen keinen zweiten Versuch unternehmen zu können. Das kann ein kundiger Admin zu seinem Vorteil im Anti-Spam-Kampf ausnutzen.

Kluge Wahl

Es gibt eine ganze Reihe von Greylisting-Implementierungen und normalerweise sind sie einfach anzuwenden. Jon Atkins stellt zum Beispiel eine clevere Qmail-Version bereit [1]. Dieser Beitrag konzentriert sich aber auf Postgrey [2], dass sich nahtlos in Ubuntus Default-Mailserver Postfix integriert und voll kompatibel mit Debian ist.

Wie funktioniert es im Einzelnen? Sobald ein entfernter Delivery Agent eine neue Verbindung zum Mailserver aufbaut, schlägt die Greylisting-Software in einer Datenbank (das kann auch ein Verzeichnis mit Symlinks sein) nach, ob und wann sich dieser Agent schon einmal mit dem Mailserver verbunden hat. Außerdem überprüft sie, ob der Admin diese Adresse oder die zugehörige Domain in einer Whitelist führt.

Bestand in letzter Zeit keine Verbindung zu dem fraglichen Agent, landet dessen IP-Adresse zusammen mit einem Zeitstempel in der Datenbank. Erfolgt kein zweiter Verbindungsversuch in einem bestimmten Intervall (zum Beispiel fünf Minuten), gilt der Absender als Spammer und wird ausgesperrt. Die Idee dabei ist: Legitime Mailversender kommen wieder, anders als Spammer, die verzweifelt versuchen, riesige Mengen Mail um jeden Preis abzusetzen.

Tabelle 1 zeigt QMails Retry-Time-Intervalle in Bezug auf einen seriösen Absender. Man sieht, dass es wichtig ist, in Abhängigkeit vom benutzten Mailserver die Zeitintervalle anzupassen, in denen ein erneuter Verbindungsversuch erwartet wird. Sonst könnten sich lange Wartezeiten bei der Zustellung ergeben.

Tabelle 1

QMail Delivery Retry Events

Einlieferungs-versuch

Sekunden

D-HH:MM:SS

1

0

0-00:00:00

2

400

0-00:06:40

3

1600

0-00:26:40

4

3600

0-01:00:00

5

6400

0-01:46:40

6

10000

0-02:46:40

7

14400

0-04:00:00

8

19600

0-05:26:40

9

25600

0-07:06:40

10

32400

0-09:00:00

11

40000

0-11:06:40

12

48400

0-13:26:40

Einlieferungs-versuch

Sekunden

D-HH:MM:SS

13

57600

0-16:00:00

14

67600

0-18:46:40

15

78400

0-21:46:40

16

90000

1-01:00:00

17

102400

1-04:26:40

18

115600

1-08:06:40

19

129600

1-12:00:00

20

144400

1-16:06:40

21

160000

1-20:26:40

22

176400

2-01:00:00

23

193600

2-05:46:40

24

211600

2-10:46:40

Einlieferungs-versuch

Sekunden

D-HH:MM:SS

25

230400

2-16:00:00

26

250000

2-21:26:40

27

270400

3-03:06:40

28

291600

3-09:00:00

29

313600

3-15:06:40

30

336400

3-21:26:40

31

360000

4-04:00:00

32

384400

4-10:46:40

33

409600

4-17:46:40

34

435600

5-01:00:00

35

462400

5-08:26:40

36

490000

5-16:06:40

37

518400

6-00:00:00

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite