Spamproblem nach Extern

[hwj]

Hi,

ich bin gerade dabei einem Freund zu helfen ein Spam Problem zu beheben.
Leider bin ich mit meinem Latein am Ende.

Es ist ein Websystem mit Postfix, sendmail, apache und php, mod_php.

In den Logs vom postfix findet man nur folgende Zeilen:

Code: Select all

Jan 22 08:42:16 rooti postfix/smtp[32159]: 31B2127C8A5: to=<xxxx@xxxx.net>, relay=mail.xxxx.net[67.18.25x.x], delay=176812, status=bounced (host mail.xxxx.net[67.18.25x.x] said: 553 5.3.0 <xxxx@xxxx.net>... User unknown. Likely viral flow - Spammers must die. (in reply to RCPT TO command)) 

67.18.25x.x = eine fremd IP die sich über den Spam beschwert hat

Die apache Logs geben auf der Suche nach spam mail in der eingabezeile oder wget auch nichts aus.

Was ist zu tun bzw wie geht ihr bei einem solchen Problem vor?

Was sollte alles getan werden um spam an extern zu vermeiden.

Mir ist klar das die Situation blöd ist und der server ist bereits aus nur ist das keine langfristige Lösung.

Weiss jemand um Rat wie man externen Spam verhindern kann insbesondere mit bezug auf PHP und alles andere was relevant ist.

Danke für jede Hilfe

[daemotron]

Dein Log-Auszug ist etwas unvollständig - es fehlen Angaben, die einen Rückschluss darauf zulassen, wer denn die Nachricht mit der ID 31B2127C8A5 bei Deinem MTA eingeliefert hat (müsste ein Stück weiter oben stehen, irgendwas wie "Message accepted" in Kombination mit der ID).

Wenn sie nicht von einem lokalen User eingeliefert wurde, würde ich auf ein offenes Relay tippen... Zeig mal Deine main.cf her und such nach dem fehlenden Log-Schnipsel.

[hwj]

Code: Select all

Jan 22 08:34:47 rooti postfix/qmgr[31237]: 31B2127C8A5: from=<admin@paypal.com>, size=3775, nrcpt=50 (queue active)

Und Paypal liegt garantiert nicht auf dem Host *g

Und hier die main.cf ohne Kommentierungen

Code: Select all

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no


append_dot_mydomain = no
#delay_warning_time = 4h
body_checks = regexp:/etc/postfix/body_check
myhostname = name.des-rooti.de
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = name.des-rooti.de, name, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

### /CONFIXX POSTFIX ENTRY ###

virtual_maps = hash:/etc/postfix/confixx_virtualUsers, hash:/etc/postfix/confixx_localDomains

### /CONFIXX POSTFIX ENTRY ###

PS: Danke schonmal...

[hwj]

Habe mal folgendes probiert:

Code: Select all

=> telnet name.des-rooti.de smtp
Darauf kommt:
=> 220 name.des-rooti.de ESMTP Postifix Debian GNU Linux
Dann:
=> HELO blabla.de
Dann weisst er ab:
=> 250 name.des-rooti.de

Also eigentlich kein Relay offen, dass das versenden über die domain *@paypal.com erlauben würde oder?

[daemotron]

Dann weisst er ab:
=> 250 name.des-rooti.de

Irrtum: 200er-Antworten heißt so viel wie "alles OK, mach weiter". Du könntest den Dialog jetzt so fortsetzen:

Code: Select all

$ telnet name.des-rootie.de smtp
220 name.des-rooti.de ESMTP Postifix Debian GNU Linux
> HELO blablabla.de
250 name.des-rooti.de
> MAIL FROM:spammer@paypal.com
> RCPT TO:deinemail@freemailprovider.tld

Nach dem RCPT TO müsste er Dich rausschmeissen, weil er für deinemail@freemailprovider.tld nicht zuständig ist.

[hwj]

Ok gut zu wissen.

Was mach ich nun um das Problem zu lösen? Also wie schaff ich es das der Postfix bei Eingabe einer Domain die IP überprüft und wenn dies nicht passt blockt.

Lief also der Postfix die ganze Zeit als offenes Relay über das jeder Mails verschicken konnte wie er lustig ist?

[hwj]

Ich habs mal überprüft:
Nach der Eingabe von

Code: Select all

.
.
.
=> RCPT TO:<user@domain.tld>
Folgt ein:
=>  554 <test@blabla.com>: Relay Access denied

Insofern scheint der Mailserver nicht als Relay zu fungieren.

Aber wo zum Teufel kommt der Spam her, es ist zum durchdrehen mit dem Zeug.

[daemotron]

Lief also der Postfix die ganze Zeit als offenes Relay über das jeder Mails verschicken konnte wie er lustig ist?

Das kann ich von hier leider nicht bestätigen, da die Firewall meines Arbeitgebers mir keine Kommnukation mit Deinem Port 25 erlaubt

Du kannst aber selbst auf Open Relay testen lassen: http://www.abuse.net/relay.html

Code: Select all

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

ist grundsätzlich schon mal nicht schlecht. Du kannst allerdings auch noch mit

Code: Select all

smtpd_client_restrictions = ...
smtpd_helo_required = yes
smtpd_helo_restrictions = ...
smtpd_sender_restrictions = ...

ein bisschen nachsetzen. Schau Dir einfach mal die Beispiel-Konfiguration unter http://www.rootforum.org/wiki/howto/gen ... er/postfix an - da findest Du weitere Anregungen.

[daemotron]

Aber wo zum Teufel kommt der Spam her, es ist zum durchdrehen mit dem Zeug.

Da haben wir uns wohl überschnitten... Ich tippe mal, dass die Mail von localhost eingereicht wird (auch Dein nachgeliefertes Log-Stückchen verrät noch nichts über die Mail-Annahme... die Zeilen davor müssten mehr Aufschluss geben).

Grundsätzlich hochverdächtig sind PHP-Skripte oder CGIs, die Mails versenden können (Kontaktforumlare, Gästebücher etc.) - die sind häufig anfällig für Header-Injections (wie z. B. Eingabe von CC- oder BCC-Adressen im Nachrichtenfeld, manipulierte GET- oder POST-Parameter etc.), besonders Eigenkonstruktionen neigen dazu, nicht so ganz Spam-dicht zu sein. Da hat Spammer sich flugs ein kleines Perl-Skript gezimmert, dass eine Verbindung zu Deinem httpd aufmacht und Dein Mailskript mit den versaubeutelten POST- oder GET-Parametern aufruft.

[lord_pinhead]

Also so wie ich das lese schickt euer Server Spam raus. Läuft vielleicht ein Perlscript?

[hwj]

Also so wie ich das lese schickt euer Server Spam raus. Läuft vielleicht ein Perlscript?

Nein Fremd Software hab ich nicht gefunden.
Wie gesagt der Rootserver ist im Rescue System und ich hab den Live leider nicht erlebt da mein kumpel den schon vorher ausgeknipst hatte aufgrund von E-Mails die nicht gerade nett waren (was auch verständlich ist)

In den apache Logs hab ich weder ein wget noch sonstige Linux Commands entdecken können die per PHP eingeschleust worden sein könnten.

Ich denke zwar auch wie jfreund schon gesagt hat das es von PHP aus kommt aber ich bin ratlos wie ich die lücke finden solll.... :(

[lord_pinhead]

schonmal nach sagen gegreppt wie "=http" oder "=[1-9]"?

[daemotron]

wget im HTTP-Request wirst Du nur finden, wenn jemand versucht haben sollte, Dir eine Remote Shell o. ä. unterzujubeln. Spam kann er auch schon verschickt haben, indem er eine tatsächlich bestehende PHP-Seite mit selbst gewählten Parametern aufgerufen hat (z. B. Kontaktformular o. ä.). Ein Ansatz wäre, mal nach HTTP-Requests zu fahnden, die mit POST gearbeitet haben anstelle von GET... Wenn das nihts bringt, hat das betreffende Skript eventuell doch mit GET gearbeitet. Am einfachsten kommst Du voran, wenn Du dir aus dem Mail-Log erst mal die Zeitpunkte rausarbeitest und dann mal das Apache-Log quercheckst, welche Seiten zu diesem Zeitpunkt aufgerufen wurden.

[hwj]

Mein kleines Problem ist das ich keine Mail Logs auf dem System sehe, da PHP mit sendmail arbeitet aber der eigentliche MTA Postfix ist.

Ich werd die Punkte mal versuchen durczuarbeiten aber sehe auch hier leidergottes schwarz.

Der erste Verdächtige war ein Script welches extern von einem Cronjob aufgerufen wurde, aber das ist nur ein php mailverteiler der sicher arbeitet so wie er soll.

Das zweite waren die Logs im postfix mit der E-Mail adresse admin@paypal.com aber das waren nur Rückläufer von E-Mails die nit ankamen o.ä.

Das einzige was ich habe ist eine nicht aussagekräftige sendmail queue mit 2500 mails die nich zustellbar sind.

Relays sind auch nicht offen und leidergottes ist diese spam methode sehr sehr intelligent. Ich bin mir jetzt schon sicher dass ich ausser einem eventuellen Zufallstreffer nichts finden werde.

Hat jemand Erfahrungswerte mit solche ausgetüffelten PHP Exploit und Spamattacken die er mir mit auf den Weg geben kann?

[lord_pinhead]

Im Forum gibt es ein paar Tipps wie man ein Script sicherer macht, dort steht auch wie man es nicht machen soll. Sehr beliebt sind new-line Angriffe, damit schleusst der Angreifer beim Abschicken von den Daten nach seiner Mailadresse mittels nBCC: hans@wurst.de einfach ein zweiten Empfänger ein. Sowas ist bei Bots recht beliebt, kannst ja mit zgrep und grep mal in den Logs suchen ob du nen Klammeraffen findest.

Alternativ, was besser wäre als die Nadel im Heuhaufen zu suchen, wäre einfach mod_security zu installieren mit den Regeln von gotroot.com, dort sind solche Angriffe glaub ich von Haus aus blockiert.

[daemotron]

da PHP mit sendmail arbeitet aber der eigentliche MTA Postfix ist

Das sendmail-Binary auf Deinem System ist ein sog. sendmail-wrapper und wird mit Postfix mitgeliefert. Aus Deinem Postfix-Log müsstest Du eigentlich herauslesen können, wann und von wem eine Mail eingegangen ist und was Postfix weiter damit angestellt hat...

[hwj]

da PHP mit sendmail arbeitet aber der eigentliche MTA Postfix ist

Das sendmail-Binary auf Deinem System ist ein sog. sendmail-wrapper und wird mit Postfix mitgeliefert. Aus Deinem Postfix-Log müsstest Du eigentlich herauslesen können, wann und von wem eine Mail eingegangen ist und was Postfix weiter damit angestellt hat...

Da hast du absolut Recht.

Nur leider reden wir ja hier von ausgehendem Spam und da ist garnix geloggt, denn es geht weder über ein Postfach raus, noch von E-Mail adresse die sich vorher anmeldet.

Und da liegt das Problem. Eingehend ist alles super dokumentiert aber ausgehend über PHP so gut wie garnix.

[Roger Wilco]

Und da liegt das Problem. Eingehend ist alles super dokumentiert aber ausgehend über PHP so gut wie garnix.

Wer sagt denn, dass die Mails tatsächlich über deinen Server verschickt wurden und es nicht nur ein Joe-Job ist? Hat der Mensch, der sich beschwert hat, wenigstens die kompletten Mailheader mitgeschickt?

Alles, was über deinen MTA läuft, wird auch in den Logs dokumentiert (außer jemand hat die Einträge gelöscht. Dann hast du aber ganz andere Probleme).

[daemotron]

Wer sagt denn, dass die Mails tatsächlich über deinen Server verschickt wurden

Code: Select all

Jan 22 08:42:16 rooti postfix/smtp[32159]: 31B2127C8A5: to=<xxxx@xxxx.net>, relay=mail.xxxx.net[67.18.25x.x], delay=176812, status=bounced (host mail.xxxx.net[67.18.25x.x] said: 553 5.3.0 <xxxx@xxxx.net>... User unknown. Likely viral flow - Spammers must die. (in reply to RCPT TO command))

Das sieht für mich schon so aus, als würde sein Server versuchen, jemand anderem eine überflüssige Mail anzudrehen :) Frage bleibt nur: Wo hat der MTA des OP diese Nachricht her... :?:

[Roger Wilco]

Das sieht für mich schon so aus, als würde sein Server versuchen, jemand anderem eine überflüssige Mail anzudrehen

Das könnte auch einfach eine gebouncete Bouncenachricht sein, sozusagen eine Bounce-Bounce-Mail. ;)

1. $Spammer verschickt E-Mail mit gefälschtem Envelope-From an $MTA
2. $MTA macht Sender Verification Callout und bekommt "User nicht gefunden" zurückgeliefert.
3. $MTA liefert Bouncemail an MX Host der Domain, die im Envelope-From steht. Der nimmt die Mail vielleicht erstmal an, weil er schlecht konfiguriert ist oder sonstwas ist. Irgendwann merkt er dann, dass er die Mail nicht zustellen kann und will einen Bounce an $MTA schicken.
4. $MTA sagt dann wieder "User nicht gefunden".

Kurzum: Ohne die kompletten Header einer solchen Mail (oder einer E-Mail, die der Beschwerdeführer bekommen hat) lässt sich nur schwer genaueres sagen.

[identify]

So,

da ich schon gespannt dieses Thema hier verfolge, hab ich an dieser Stelle auch noch ein paar Fragen, weil ich nämlich glaube, dass ich ein ähnliches Problem habe.

Vorerst mal schauen, ob ich den letzten Post soweit verstanden habe:

$Spammer = der Böse :twisted:
$MTA = der MTA des Empfängers (irgendeine Zieladresse)
MX Host der Domain, die im Envelope-From steht = mein Host, meine Domain

soweit richtig?

Der nimmt die Mail vielleicht erstmal an, weil er schlecht konfiguriert ist oder sonstwas ist. Irgendwann merkt er dann, dass er die Mail nicht zustellen kann und will einen Bounce an $MTA schicken.

Wie kann ich dann sowas abstellen?
Ich hab bei mir den schon oft genannten Relay-Test gemacht und eine positive Antwort erhalten (positiv im Sinne von: ist KEIN Open Relay). Soweit so gut. Dennoch erhalte ich immer wieder mal ne Mail zurück, wo dann drin steht, dass z.B. GMX meine Mail nicht annimmt, weil ich auf einer Greylist stehe. Da kann ich mich dann austragen, so oft ich will - irgendwie bringts das nicht. Ich vermute eben auch, dass da der Envelope-From gefälscht wird.
Frage von oben also: wie kann ich das in meinem MTA abstellen?

(MTA = Postfix)

Ciao
Mario

[daemotron]

Gar nicht. GMX könnte mit einem reverse lookup prüfen, ob der sendende Server wirklich der ist, der als MX für die Domain in Envelope-From eingetragen ist. Solche Lookups sind aber einigermaßen aufwändig und führen bei MTAs mit hohem Mailaufkommen zur Verstopfung der Eingangs-Queue...

Wenn Dein Server wirklich nur greylisted ist, bedeutet das, die Mails werden nach Ablauf einer bestimmten Frist angenommen, wenn Dein Server erneute Zustellversuche unternimmt. So kann man einen Spam-Bot von einem richtigen MTA unterscheiden; der Spambot wertet meist die Antwort nicht aus und versucht deshalb auch keine erneute Zustellung einer abgewiesenen Nachricht.