Wie Einliefern von Spam verhindern?

[siradlib]

Hallo zusammen,

ich mache mir gerade Gedanken, wie ich meinen Server daran hindern, Spam von z.B. virenverseuchten Clients entgegenzunehmen.
Könnt ihr bitte mal ein paar Stich- bzw. Suchbegriffe in den Raum werfen?
Hintergrund ist der, dass ich ja nicht immer die volle Kontrolle über Client-PCs habe und ich davon ausgehe, dass früher oder später irgendjemand sich einen Wurm o.ä. einfangen wird. Ich möchte dann verhindern, dass dieser dann über meinen Mailserver weiterversandt wird.
Gehe ich richtig in der Annahme, dass Spamassassin nur eingehende Mails prüft?

Als System setze ich einen vServer mit CentOS 5.4 und Plesk 9.5.2 ein.
Mailer ist QMail und SpamAssassin sowie Greylisting sind aktiv.
Und dass ich auch an unsichere (PHP-) Skripte denken muss, ist mir bewußt.

Vielen Dank schon jetzt für alle Anregungen!

siradlib

 

[Whistler]

Setzt Du schon DNS-Blacklisten ein? Die von Heise ist ganz gut.

 

[danton]

Mailversand nur per Authentifizierung, da dürfte (fast) alle Spamschleudern dran scheitern...

 

[siradlib]

Mailversand nur per Authentifizierung, da dürfte (fast) alle Spamschleudern dran scheitern...

Ist natürlich sowieso aktiv, ich könnte mir aber vorstellen, dass per Trojaner auch mal eine SMTP-Session mitgehört wird. Und schon hätte man sein Passwort!
Oder kommt das in der Realität nicht wirklich vor?

 

[siradlib]

Setzt Du schon DNS-Blacklisten ein? Die von Heise ist ganz gut.

Aber ist es nicht so, dass eine Blacklist nur den Empfang von Spammails von anderen Mailservern verhindert?
Mir geht es hier aber um die Erkennung, ob ein Client Spam an meinen Server liefert.

 

[Whistler]

Das ist bei Greylisting nicht anders.
Meine Erfahrung ist, daß zombiverseuchte Clients (letztlich wieder Rustock) auch direkte Zustellversuche unternehmen und damit schnell auf der Sperrliste landen.
Für die eigenen Clients kann man auch noch Policies (nicht mehr als x Mails pro Minute mit max. y Empfängern keine gleichzeitige Anmeldung von 2 IPs usw.) sowie bei Bedarf sogar SSL-Clientzertifikate einstellen.

 

[siradlib]

Das ist bei Greylisting nicht anders.
Meine Erfahrung ist, daß zombiverseuchte Clients (letztlich wieder Rustock) auch direkte Zustellversuche unternehmen und damit schnell auf der Sperrliste landen.

Heißt also: Man suche sich eine gute Sperrliste wie z.B. die NiXSpam-Liste und erschlage das Problem damit. Oder?

Für die eigenen Clients kann man auch noch Policies (nicht mehr als x Mails pro Minute mit max. y Empfängern keine gleichzeitige Anmeldung von 2 IPs usw.) sowie bei Bedarf sogar SSL-Clientzertifikate einstellen.

Womit kann ich denn solche Policies erstellen?
Gibts abseits des "Selbstgeskripteten" etwas?

 

[d4f]

Policyd bietet die gewuenschten Funktionen und laesst sich in die meisten MTA iintegrieren

Uebirgens erhalte ich fast tagtaeglich Beschwerde-Emails von Banken und Spamfilter dass ein Kunde Spam verschickt - in letzter Zeit fast ausschliesslich sauber eingeloggt ueber SMTP mit einer niedrigen Senderate und individuell generiertem Inhalt. (Trojaner)
Der Kampf gegen die Windmuehlen wird immer schwerer..

 

[siradlib]

Uebirgens erhalte ich fast tagtaeglich Beschwerde-Emails von Banken und Spamfilter dass ein Kunde Spam verschickt - in letzter Zeit fast ausschliesslich sauber eingeloggt ueber SMTP mit einer niedrigen Senderate und individuell generiertem Inhalt. (Trojaner)

Vielen Dank für den Hinweis, Policyd werd ich mir mal anschauen.

Deine Erfahrung, dass Deine Kunden eingeloggt spammen würden, schockiert mich allerdings etwas. Kannst Du Dir darauf einen Reim machen? Wird da z.B. wirklich vom Trojaner das Passwort per Keylogging oder gar Sniffing ermittelt?

 

[d4f]

Der Spamversand erfolgte nur in sehr wenigen Faellen vom Rechner des Kunden selbst durch einen Bot, sondern in fast allen Faellen ueber ein Botnetz oder gekaperte Rootserver/Webspaces.
Anfangs versuchte ich durch eine Logikueberpruefung zu verhindern dass der Benutzer welcher immer aus <LAND> kommt ploetzlich aus <ANDERES-LAND> kommen kann.
Da aber (scheinbar ) einige Kunden berufsbedingt viel herumreisen hat sich diese Loesung als Schuss in den Ofen erwiesen.
Mein naechster naheliegender Gedanke war die Distanz zwischen den IP's zu ermitteln und daraus eine Schlussfolgerung zu ziehen ob es moeglich ist dass der Benutzer in der Zwischenzeit dahin gereist ist, allerdings steht die Umsetzung noch aus.

Die meisten entsprechenden Viren wurden nach Kundenaussage durch MSN oder Bildchen-Seiten eingefangen, es scheint als ob diese Rundum-Trojaner mittlerweile bedeutend mehr als nur den Massenmarkt abdecken koennten. Wuerde mich nicht wundern wenn die auch putty erkennen koennen und private-keys respektiv Passwoerter mitlesen...