SPAM Versand unterbinden

Wer einen Mailserver betreibt, hat sich bestimmt schon mit der Abwehr von SPAM beschäftigt. Dazu gibt es diverse Möglichkeiten wie z.B. Blacklists, Inhaltsanalyse, DNS-Checks und SPF. Im wesentlichen versucht man damit die Postfachinhaber vor SPAM zu schützen.

Dann gibt es noch die Pflicht, sein System soweit abzusichern, dass niemand ohne Authentifizierung Mails an andere Systeme darüber verschicken kann (Open Relay).

Was macht man aber, wenn die Zugangsdaten eines Postfachinhabers einem SPAM Versender bekannt sind? Möglicherweise wurde der Postfachinhaber Opfer von Schadsoftware, oder hat das selbe Passwort auch bei anderen Diensten verwenden, die gehackt wurden. Möglicherweise hat er sich auch im Urlaub an einem öffentlichen PC per Webmail eingeloggt. Auch wenn hier SSL zum Einsatz kommt, kann ein Key Logger auf dem PC die Zugangsdaten ausspähen.

Ein konkreter Fall:

Innerhalb von 15 Minuten ist die Mail Queue auf über 100 nicht ausgelieferte Mails angestiegen.

Ein Blick in die Queue zeigt eindeutigen SPAM:

933871 (2, 2/933871)
Return-path: user@domain.de
From: Amy Bauer
To: empfaenger@domain.de
Subject: This is a good way to make some extra cash.
Date: Tue, 14 Aug 2012 0:22:31 +0200
Size: 993 bytes

Ein Blick in die Logs zeigt, dass die Mails mit der Kenntnis von Zugangsdaten eines Postfachs platziert wurden:

# grep "user@domain.de" /var/log/messages
... vpopmail[23030]: vchkpw-smtp: (PLAIN) login success user@domain.de: ...
... spamdyke[22836]: ALLOWED from: user@domain.de to: empfaenger@domain.de origin_ip: ...

Der Erste Schritt ist ein Reset des Passwort:

# vpasswd user@domain.de

Danach zeigt ein Blick in die Mail Queue noch über 4000 ausstehende Mails an. Auch diese müssen gelöscht werden:

# qmHandle -f'user@domain.de'

Jetzt sollte der Nagios Check wieder grün werden:

Der ganze Spuk hat damit nur 45 Minuten gedauert und ärgerliche 2352 SPAM Mails zugelassen. Jetzt kann man erstmal in Ruhe analysieren.

Anzahl der bereits versendeten Mails ermitteln:

# grep 'from user@domain.de' current|wc -l
2352

Prüfen, ob der Passwort Reset wirkt:

# grep "password fail user@domain.de" /var/log/messages|wc -l
4089

Beteiligte IP’s ermitteln (die ersten 10):

# grep "password fail user@domain.de" /var/log/messages|cut -d: -f6|sort|uniq|head -n10
108.175.8.93
109.169.14.10
109.95.211.48
112.213.91.154
115.112.236.244
121.170.176.69
122.155.169.4
124.109.2.77
174.122.141.130
176.9.40.38

Wer sich die Zeit nehmen will, sollte die Provider der IP’s darüber informieren:

# whois 122.155.169.4|grep remarks
remarks: ***send spam abuse to support@idc.cattelecom.com***

Zum Schluss stellt sich die Frage, wie man einen solchen Vorfall zukünftig verhindern kann?

Eine Möglichkeit ist, auch ausgehende Mails einer Inhaltsanalyse zu unterziehen, was aber mit Artikel 10 des Grundgesetztes kaum zu vereinbaren wäre.

Eine weitere Möglichkeit wäre die Anzahl der erlaubten Mails pro Zeitintervall zu beschränken. Mehr als eine Mail pro Sekunde dürfte für normale Postfächer verdächtig sein.

Richtig wäre auch, die Postfachinhaber in regelmäßigen Abständen für Sicherheit zu sensibilisieren:

  • Meldet euch nicht an fremden Rechnern und schon gar nicht im Ausland am Webmail an!
  • Wählt für jeden Dienst ein eigenes Passwort!
  • Antiviren Software und Firewall sind Pflicht und müssen auch aktuell gehalten werden!

Für welche Maßnahme man sich auch entscheidet, eine Erkenntnis ist allgegenwärtig:

Sicherheit ist ein Prozess, der niemals abgeschlossen ist!