Spamversand

[hogiebaer]

Hallo,

habe seit ein paar Tagen das Problem, dass scheinbar von einer unserer 2 IP´s Spam versand wird.

Der einzige Hinweis auf dem Server ist, dass im /tmp Verzeichnis eine
Sessiondatei existiert, in der nicht wie üblich Variablen gespeichert sind, sondern eine Rückmeldung der Zielprovider, dass die IP in der CBL (Spamhaus) steht

Hier einmal ein Auszug aus der Sessiondatei

E1135578{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135656{I554}p3pismtp01-064.prod.phx3.secureserver.net Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.
E1226549{I550}IP 85.214.xxx.xxx in zen.spamhaus.org : Access Denied, please see www.spamhaus.org
E1135285{B421}Temporarily rejected for 85.214.xxx.xxx. Try again later.
E1226142{E421}4.7.0 Try again later, closing connection. (DATA) c12si2068959bkw.2 - gsmtp
E1135492{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135597{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135551{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135250{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135533{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135655{I554}fed1rmimpi112 cox 85.214.xxx.xxx blocked. Error Code: IPBL0001 - Refer to Error Codes section at http://postmaster.cox.net/confluence/display/postmaster/Error+Codes for more information.
E1135704{F521}85.214.xxx.xxx blocked by sbc:blacklist.mailrelay.att.net. DNSRBL: Blocked for abuse. See http://att.net/blocks
E1135553{F521}85.214.xxx.xxx blocked by sbc:blacklist.mailrelay.att.net. DNSRBL: Blocked for abuse. See http://att.net/blocks
E1135604{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135206{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1226151{E421}4.7.0 Try again later, closing connection. (DATA) c5si2060561bkw.84 - gsmtp
E1135364{R554}Refused. Your IP address is listed in the RBL at cbl.abuseat.org: Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=85.214.xxx.xxx See: http://www.mastercabo.com.br/#DENIED_RBL_MATCH
E1226169{E421}4.7.0 Try again later, closing connection. (DATA) gk9si2045167bkc.236 - gsmtp
E1135681{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135205{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135593{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135697{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135632{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135148{I550}mwinf5c40 ME Adresse IP source bloquee pour incident de spam. Client host blocked for spamming issues. OFR006_101 Ref http://r.orange.fr/r/Oassistance_adresserejetee?ec=OFR006_101&ip=85.214.xxx.xxx [101]
E1135560{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135258{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1135509{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1226159{E421}4.7.0 Try again later, closing connection. (DATA) hu1si2047446bkc.213 - gsmtp
E1135358{I550}mwinf5c40 ME Adresse IP source bloquee pour incident de spam. Client host blocked for spamming issues. OFR006_101 Ref http://r.orange.fr/r/Oassistance_adresserejetee?ec=OFR006_101&ip=85.214.xxx.xxx [101]
E1226573{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html
E1226823{I421}4.7.1 : (DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.html

Über den Owner der Datei kann ich auch den "Verursacher/Domain" auf dem Server ausmachen und vermute einmal, dass es sich um ein PHP Script handelt. In den typischen Logs (mail/mail.warn/...) ist in diesem Zeitfenster nichts ungewöhnliches zu sehen.
Das eigenartige ist auch, dass in den Apache-Logs der Domain nichts wirklich aufregendes zu dem Zeitpunkt passt.

Ausser PHP ist auf dieser Domain nichts aufgeschaltet (cgi,...)

Mir ist auch klar, dass aus dem o.a. Log ersichtlich ist, dass die IP auf der CBL steht, werde aber den Unlock erst dann
beantragen, wenn die Ursache dazu gefunden wurde.
Was mir nicht in den Kopf geht, wieso steht das in einer Session Datei ??


Da es sich um einen Internetshop handelt, fällt es mir schwer, hier an der richtigen Stelle einzugreifen, um das Problem zu lösen.

Den sendmail kann ich auch nicht einfach verbieten, da er benötigt wird.


Systemdaten :
- vserver mit plesk 11.0.9 uptodate
- postfix als MTA (negativ getestet auf open relay)
- Ubuntu 12.04.1 LTS
- Apache2.2.22-1ubuntu1.2
- PHP5.3.10-1ubuntu3.5
- PostFix2.9.3-2~12.04.4




Vielen Dank für eure Vorschläge.


Gruss
Holger

 

[nexus]

Das verursachende Script finden und eliminieren.
Huschi hat auf seiner Seite schön beschrieben, wie man den Mail-Wrapper entsprechend modifiziert, um das sendende Script zu ermitteln...guckst du hier

 

[its]

Sofern du heraus gefunden hast, wer den E-Mail Versand verursacht hat, solltest du dich um die Entfernung auf den Blacklisten bemühen. Sofern die Blacklisten Einträge nur temporär sind, bleibt dir nicht viel übrig, als abzuwarten.
Sollten diese aber permanent sein, wende dich an die Blacklisten Betreiber und folge deren Entfernungs-Bedingungen.

Als Shop Betreiber gibt es nichts schlimmeres, als auf E-Mail Blacklisten zu stehen, die es einem nicht erlauben E-Mails an Kunden zu senden, da diese geblockt werden.

Überprüfe doch mal deine Prozesse, vielleicht verschickt ein Script E-Mails, mit:

ps fauxwww

oder

lsof -i

 

[hogiebaer]

Habe bereits vor ein paar Tagen der Domain im MX eine andere IP zugeordnet, so dass der "reguläre" E-Mail Versand ohne Störung funktioniert.

Ja, war riskant, denn die 2. IP zu verlieren, wäre sehr ärgerlich gewesen.
Aber eigenartigerweise gehen die Mails über die 1. (der Domain NICHT mehr zugeordneten) IP raus. Das hat mir dann etwas Luft zur Recherche verschafft. Spricht aber dafür, dass es ein Script sein muss und kein SMTP Versand.

Aber die Ursache muss erst einmal gefunden werden. Werds wohl erst einmal
mit dem Wrapper probieren, damit ich mehr sehen kann. Was mich nur wundert, ich finde NIX in den entsprechenen ApacheLogs der Domain, dass da zu dem Zeitpunkt irgendetwas sonderbares vermerkt ist

 

[hogiebaer]

Überprüfe doch mal deine Prozesse, vielleicht verschickt ein Script E-Mails, mit:

ps fauxwww

!GOTCHA!

Folgender Eintrag

10007 18101 0.0 0.2 13368 10104 ? S Feb23 0:13 []

Die UserId entspricht der FTP Logname Adresse der Domain !!!
Wie ist das möglich ?

Über lsof (in Bezug auf diese ID) ist auch keine Datei geöffnet

!Korrektur!
Unter lsof finden sich ca. 40 Handles mit der Prozessnummer 18101 vom Typ Socket


Was kann hier passiert sein am 23.feb ?
- Ausschliessen kann ich, dass der User per Shell reinkommt. Alle auf /bin/false

Selbst wenn PHP in der Lage ist, einen Prozess im Namen des Domainusers zu starten, dann doch ausschliesslich über
FastCgi o.ä. und der wäre ja auch nach einer gewissen Zeit wieder weg. Und es wäre auch ersichtlich, welche Aktion den
Prozess startet und nicht nur eine Angabe mit leeren Klammern []

Fragen über Fragen

 

[its]

Sofern du es einem FTP User zuordnen kannst, ist was was ganz normales.

Viele Leute verwenden unzureichend abgesicherte Home PC's oder Laptops, von dort aus werden die FTP Passwörter abgegriffen (Trojaner, Keylogger,etc)

Vielleicht wurde via FTP ein Spam-Skript hochgeladen, check mal die FTP Logs!

 

[hogiebaer]

Sofern du es einem FTP User zuordnen kannst, ist was was ganz normales.

Viele Leute verwenden unzureichend abgesicherte Home PC's oder Laptops, von dort aus werden die FTP Passwörter abgegriffen (Trojaner, Keylogger,etc)

Vielleicht wurde via FTP ein Spam-Skript hochgeladen, check mal die FTP Logs!

Ja, danke. Werd ich tun, aber kannst Du Dir erklären, warum die PID so viele Sockets geöffnet hat ?

Habe nun über Netstat einen der vielen offenen Sockets einmal isoliert, zeigt allerdings auch nix informatives an

unix 3 [] STREAM VERBUNDEN

 

[TerraX]

...Als Shop Betreiber gibt es nichts schlimmeres, als auf E-Mail Blacklisten zu stehen, die es einem nicht erlauben E-Mails an Kunden zu senden, da diese geblockt werden.

Das ist mit Verlaub, dass geringste Problem in diesem Falle. Wenn in dem Shop Kunden- und Transaktionsdaten gespeichert sind, ist das hier zu beachten: § 42a BDSG (Informationspflicht bei unrechtmäßiger Kenntniserlangung von Daten). Der Weiterbetrieb des komprimittierten Shops/Servers ist übrigens ob der positiven Kenntnisnahme grob fahrlässig.

Grundsätzlich ist zu empfehlen, dass ganze System zu Forensik-Zwecken sichern zu lassen und dann komplett neu aufzusetzen. Bei der Neuinstallation ist auf die Aktualität aller Komponenten inkl. der eingesetzten Scripte sowie saubere Quellen (z.B. Rückgriff auf eigenes Repository für das Shop-Script inkl. der individuellen Anpassungen) zu achten. Das einfache Einspielen eines Backups wird nicht reichen.

 

[ehrenwert]

Das ist mit Verlaub, dass geringste Problem in diesem Falle. Wenn in dem Shop Kunden- und Transaktionsdaten gespeichert sind, ist das hier zu beachten: § 42a BDSG (Informationspflicht bei unrechtmäßiger Kenntniserlangung von Daten). Der Weiterbetrieb des komprimittierten Shops/Servers ist übrigens ob der positiven Kenntnisnahme grob fahrlässig.

Grundsätzlich ist zu empfehlen, dass ganze System zu Forensik-Zwecken sichern zu lassen und dann komplett neu aufzusetzen. Bei der Neuinstallation ist auf die Aktualität aller Komponenten inkl. der eingesetzten Scripte sowie saubere Quellen (z.B. Rückgriff auf eigenes Repository für das Shop-Script inkl. der individuellen Anpassungen) zu achten. Das einfache Einspielen eines Backups wird nicht reichen.

Volle Zustimmung hierfür. Grobe Fahrlässigkeit kann zu sehr hohen Schadensersatzansprüchen etc. führen.

 

[hogiebaer]

Über die juristischen Folgen bin ich bestens informiert,
hatte mir eigentlich mehr Hilfe technischer Natur erhofft

 

[Marentis]

Die hast Du ja bereits erhalten: Du benötigst einen erfahrenen Admin, der das System forensisch untersucht. Das kann man wirklich nicht mit 1-2 Befehlen abhandeln, weil dafür Erfahrung notwendig ist, insbesondere um die Ergebnisse zu interpretieren.
Es gibt auch kein Tool, dass hier automatisch agiert und sagt: "genau das und das ist passiert".
Ich kann wirklich gut verstehen, dass Du Dir etwas in der Richtung: "tippe das, mache das" erhofft hast aber es ist einfach nicht möglich.

Du kannst zum Beispiel hier im Forum ein Gesuch einstellen, es wird Dich eben etwas kosten.

 

[TerraX]

...hatte mir eigentlich mehr Hilfe technischer Natur erhofft

Die hatte ich Dir ebenfalls gegeben. Solche Untersuchungen macht man nicht an einer Produktivmaschine im laufenden Betrieb, dass ist nur was für Profis im absoluten Not-/Ausnahmefall, weil man schlecht einzelne Sachen voneinander isolieren und einzelne Situation provozieren bzw. reproduzieren kann. Daher:

1. Gesamten Server sichern und auf einem lokalen Testsystem wiederherstellen.

2. Idealerweise hast Du ein vollständiges lokales Repository alternativ stink normales lokales Entwicklerverzeichnis, was das gesamte Script im Soll-Zustand (sauber) beinhaltet. Ein Vergleich der beiden Verzeichnisse sollte Unterschiede aufzeigen. Nach meiner Erfahrung befinden sich solche Malware Scripte oft in irgendwelchen Upload-Verzeichnissen jedenfalls meist innerhalb des Documentroots aber auch gern in /tmp. Teile Deines Scriptes könnten auch modifiziert worden sein, so dass das Schadscript ganz normal z.B. mit der index.php aufgerufen wird (include ...), weswegen Du in den Logs erstmal nix auffälliges siehst. Je nach dem, wie die Malware geschrieben ist, braucht sie deinen MTA nicht sondern bringt den selbst mit. Das würde auch die "Nutzung" der IPs erklären.

Mit nethogs (sollte es als Paket auch unter Ubuntu geben), kannst Du evtl. den Traffic verursachenden Prozess näher einkreisen.

3. Parallel dazu Produktivsystem komplett neu aufsetzen, nach Updates schauen (auch für das Script).

4. Monitoring Software wie z.B. logwatch, CSF&LFD und RKHunter (es gibt eine Unmege an Alternativen) helfen Dir kritisches und/oder abweichendes unnormales Systemverhalten frühzeitig zu erkennen.

P.S.: Last but not least ...

Die hast Du ja bereits erhalten: Du benötigst einen erfahrenen Admin, der das System forensisch untersucht. Das kann man wirklich nicht mit 1-2 Befehlen abhandeln, weil dafür Erfahrung notwendig ist, insbesondere um die Ergebnisse zu interpretieren.
Es gibt auch kein Tool, dass hier automatisch agiert und sagt: "genau das und das ist passiert".
Ich kann wirklich gut verstehen, dass Du Dir etwas in der Richtung: "tippe das, mache das" erhofft hast aber es ist einfach nicht möglich...

So ist es. So eine Untersuchung verlangt ein flexibles Vorgehen und je nach Erkenntnisstand die Änderung der Sichtweisen und Methoden. Das ist ein langsames Herantasten, mal wird's heißer mal wieder kälter.