qmail - Spammer benutzen meinen MTA!

Tschan

Well-Known Member
Hallo!

Seit gestern verschickt mein Server 2 Emails pro Sekunde SPAM in die ganze Welt.
Ich habe aber SMTP-AUTH installiert, sodass ein unbefugtes Nutzen meines SMTP`s nicht möglich sein sollte. Ich habe testhalber die Option SMTP_after_POP in meinen MUA kurz deaktiviert und konnte dann auch richtiger Weise keine Mail verschicken.

Aber irgendwie haben diese SPAMMER einen Weg gefunden meinen MTA zu missbrauchen, ich weiss bloss nicht wie. Die Spam-Mails haben den Absender "anonymous@meinserver.de" (wobei 'meinserver' fiktiv ist).

Habt Ihr eine Idee wie die das machen, bzw. wie ich das unterbinden kann?

Besten Dank und viele Grüße,
Andy
 
Das Weiterleiten ist verboten, in der rcpthosts stehen nur meine lokalen Domains. Aber als Absender wird ja anonymous@meinserver.de benutzt.

Die IP-Adresse sperren geht nicht, da es mehrere sind. Ausser dem ist es keine akzeptable Lösung, ich will das Sicherheitsloch stopfen.

Über deinen Link bin ich heute auch schon beim googlen gestolpert, hat mir aber nicht geholfen.

Trotzdem danke.
 
Poste doch mal maßgebliche Logfiles. Irgendwo muß ja detailliert dargestellt werden, was auf Deinem Server passiert.

Auf jeden Fall würde ich den Server aber erstmal vom Netz nehmen (mindestens Port 25 sperren), solange Du den Fehler nicht gefunden hast.
 
Hier mal ein kleiner Mitschnitt aus /var/qmail/service/smtpd/log/main/current:

Code:
@40000000433825321af17fc4 tcpserver: status: 1/200
@400000004338253e12b131c4 tcpserver: status: 2/200
@400000004338253e12b851fc tcpserver: pid 65105 from 65.161.2.16
@400000004338253e12dd79b4 tcpserver: ok 65105 mein.server.de:213.239.xxx.xxx:25 :65.161.2.16::34885
@400000004338253e33206ac4 tcpserver: end 65105 status 0
@400000004338253e332475ec tcpserver: status: 1/200

Ist es eigentlich normal das die anderen Server von unterschiedlichen Ports senden?
 
Das ist alles? Sorry, ich bin kein qmail-Experte, aber ich sehe da überhaupt keine Informationen, was
z.B. den Authentifizierungsvorgang angeht. Anhand der o.g. Daten ist es für mich nicht möglich, eine (Fehl-)Konfiguration zu erkennen.

Nenn doch mal Ross und Reiter (Deine Domain und/oder IP), dann kann man wenigstens mal gucken, ob Relaying wirklich nicht erlaubt ist.
 
Mitschnitt aus /var/log/qmail/current:


Code:
@400000004337e3f33045335c new msg 99205
@400000004337e3f33064c564 info msg 99205: bytes 11501 from <anonymous@mein.server.de> qp 23840 uid 80
@400000004337e3f729930b24 delivery 2096536: deferral: Connected_to_129.219.10.34_but_connection_died._(#4.4.2)/
@400000004337e3f7299948cc status: local 0/10 remote 19/20
@400000004337e3f72999680c starting delivery 2096824: msg 89066 to remote skullology@aol.com
@400000004337e3f729997f7c status: local 0/10 remote 20/20
@400000004337e3f735ba8634 delivery 2096824: deferral: Connected_to_64.12.137.184_but_greeting_failed./Remote_host_said:_554_(RLY:B1)_http://postmaster.info.aol.com/errors/554rlyb1.html/
@400000004337e3f735c0db4c status: local 0/10 remote 19/20
@400000004337e3f735c0f6a4 starting delivery 2096825: msg 89066 to remote cowens1996@aol.com
@400000004337e3f735c111fc status: local 0/10 remote 20/20
@400000004337e3f806128314 delivery 2096825: deferral: Connected_to_205.188.155.89_but_greeting_failed./Remote_host_said:_554_(RLY:B1)_http://postmaster.info.aol.com/errors/554rlyb1.html/
@400000004337e3f80619fd24 status: local 0/10 remote 19/20
@400000004337e3f8061a1494 starting delivery 2096826: msg 89066 to remote afro98@aol.com
@400000004337e3f8061a33d4 status: local 0/10 remote 20/20
@400000004337e3f811ed784c delivery 2096826: deferral: Connected_to_205.188.155.89_but_greeting_failed./Remote_host_said:_554_(RLY:B1)_http://postmaster.info.aol.com/errors/554rlyb1.html/
@400000004337e3f811f33cdc status: local 0/10 remote 19/20
@400000004337e3f811f35834 starting delivery 2096827: msg 89066 to remote stedut@hotmail.com
@400000004337e3f811f3738c status: local 0/10 remote 20/20
@400000004337e3f8127428c4 delivery 2096827: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
@400000004337e3f8127a954c status: local 0/10 remote 19/20
@400000004337e3f8127ab0a4 starting delivery 2096828: msg 89066 to remote ripd@aol.com
@400000004337e3f8127ac814 status: local 0/10 remote 20/20
@400000004337e3f81ea42b6c delivery 2096828: deferral: Connected_to_205.188.159.57_but_greeting_failed./Remote_host_said:_554_(RLY:B1)_http://postmaster.info.aol.com/errors/554rlyb1.html/
@400000004337e3f81eaa170c status: local 0/10 remote 19/20
@400000004337e3f81eaa3264 starting delivery 2096829: msg 89066 to remote djjne143@aol.com
@400000004337e3f81eaa4dbc status: local 0/10 remote 20/20
@400000004337e3f82a97965c delivery 2096829: deferral: Connected_to_205.188.156.249_but_greeting_failed./Remote_host_said:_554_(RLY:B1)_http://postmaster.info.aol.com/errors/554rlyb1.html/
@400000004337e3f82a9d10b4 status: local 0/10 remote 19/20
@400000004337e3f82a9d2c0c starting delivery 2096830: msg 89066 to remote aaron_ott@msn.com
@400000004337e3f82a9d437c status: local 0/10 remote 20/20
@400000004337e3f82b428044 delivery 2096830: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
@400000004337e3f82b486be4 status: local 0/10 remote 19/20
@400000004337e3f82b488354 starting delivery 2096831: msg 89066 to remote popsmimi2@aol.com
@400000004337e3f82b48a294 status: local 0/10 remote 20/20

Wenn ich diese Datei mit tail -F laufen lasse, kann man sie nicht mehr lesen, so schnell wächst sie.
 
Tschan schrieb:
IP: 213.239.204.19
sv01.actiweb.de
Zumindestens ist ein prinzipielles Relaying schonmal nicht möglich. Ich weiß jetzt nicht genau, wie Du die Karre konfiguriert hast, aus der Fehlermeldung würde ich erkennen, dass Du nur Mails an bestimmte Domains zuläßt.

Du hast offensichtlich aber noch keine Mails versandt, da der Empfänger offensichtlich alles blockt.

Aus dem Logfile kann ich aber immer noch nicht erkennen, wo und wie der Eindringling ins System kommt. Ich sehe nach wie vor keine erfolgreiche Authentifizierung (die ist zum Mailversenden nach Extern erforderlich?). Und Du hast sicher geprüft, dass nicht irgendein Skript auf localhost läuft?
 
Ich hab streng nach folgenden HOWTO installiert:
http://www.pofo.de/HOWTO/qmail/

Alle Mails werden nicht geblockt, ich bekomm schon einige Abuse-Mails von meinem Provider und AOL blockt uns schon komplett. Ein Abschalten des MTA`s wäre für uns auch mit negativen Folgen, da wir Ebay-Powerseller sind und mit einem eigenen Kaufabwicklungs-Tool arbeiten, welches mit den Emails von Ebay arbeitet.
 
auweija

Naja, wie schon erwähnt, ich bin kein qmail-Kenner, da müßte jemand ran, der etwaige Probleme schneller erkennt, oder wenigstens sagen kann, in welchen Logfiles Du genau suchen kannst. Die o.g. Logfiles helfen (mir) jedenfalls nicht wirklich weiter.
 
Sorry, aber so geht's wirklich nicht

Tschan schrieb:
Ein Abschalten des MTA`s wäre für uns auch mit negativen Folgen, da wir Ebay-Powerseller sind und mit einem eigenen Kaufabwicklungs-Tool arbeiten, welches mit den Emails von Ebay arbeitet.

Wenn ich Dein Ursprungsposting richtig verstanden habe, dann laesst Du deinen MTA seit ueber 19 Stunden laufen, obwohl Du weisst, dass er Spams verschickt. Das macht dann bei zwei Stueck pro Sekunde also schon mehr als 136800 Spams, und Du beklagst Dich ueber negative Folgen fuer Dich?

Tut mir leid, aber das ist nicht nur fahrlaessig, das ist einfach nur noch asozial.

Nimm den Server bitte ASAP vom Netz und sieh zu, dass Du das Problem findest und behebst.
 
Wenn ich heute Abend keine Lösung finde, werde ich das auch machen müssen. Primäres Ziel ist es aber nach wie vor ASAP das Problem zu lösen, wobei mir dein Beitrag nur Zeit gekostet hat.
 
Hi,

was mir -als altem sendmail-User- aufällt

> @400000004337e3f33064c564 info msg 99205: bytes 11501 from <anonymous@mein.server.de> qp 23840 uid 80

ist die User-ID 80. Das sieht doch so aus, als ob die was via Webserver 'reinkommt? Ist da evtl. was offen oder ist das nur Zufall?

Hast du mal einen chkrootkit laufen lassen um zu sehen, ob sich jemand in deinem Rechner eingenistet hat?

_ralf_
 
Tschan schrieb:
Ein Abschalten des MTA`s wäre für uns auch mit negativen Folgen, da wir Ebay-Powerseller sind und mit einem eigenen Kaufabwicklungs-Tool arbeiten, welches mit den Emails von Ebay arbeitet.
Nein, wenn Du den Server erstmal dicht machst (Port 25), dann kann eBay die Mails erstmal nicht zustellen. Der entfernte Server wird aber noch ein paar Tage lang versuchen, seine Mails bei Euch loszuwerden. Erst nach einiger Zeit geht die Mail wirklich als unzustellbar zurück. So hast Du wenigstens ein paar Stunden Zeit, um den Fehler zu finden und z.B. den Webserver als Einfallstor auszuschließen oder gar hohldrehende Skripte zu reparieren.
 
also, wenn der spammer so tut, als kommen die mails von dir, dann sorg doch einfach dafuer, dass dein qmail keine mails mehr versendet, sondern nur empfaengt?
 
Tschan schrieb:
Wenn ich heute Abend keine Lösung finde, werde ich das auch machen müssen. Primäres Ziel ist es aber nach wie vor ASAP das Problem zu lösen, wobei mir dein Beitrag nur Zeit gekostet hat.

*sigh*

Also dann halt etwas "konstruktiver": gewoehne Deinem MTA erstmal ab, die Mails zu delivern, notfalls durch blockieren von Port 25 *ausgehend* (ich kenne qmail nicht, sonst wuerde ich Dir jetzt sagen, wie das richtig geht).

Dann solltest Du versuchen, herauszufinden, was die Spammer, die Deinen MTA exploiten, exakt so reden. Also in den gequeuten Mails nachsehen, was da drinsteht, maximales Debugging anschalten, um den kompletten SMTP-Dialog mitzubekommen (falls so etwas bei qmail geht), schlimmstenfalls mit tcpdump(8) draufsehen.

Interessant ist hier vor allem, mit welchem RCPT TO: die es schaffen, Deinen MTA zum Relayen zu ueberreden.
 
Tschan schrieb:
Primäres Ziel ist es aber nach wie vor ASAP das Problem zu lösen, wobei mir dein Beitrag nur Zeit gekostet hat.
Was soll man dazu sagen... Stellt einen unsicheren Server auf, der enorm geschätsschädigende Auswirkungen für die betreibende Firma hat, unternimmt 19 Stunden NICHTS und beschwert sich dann noch, dass ihn ein Beitrag Zeit gekostet hat.
Vielleicht solltest Du, bevor Du über andere meckerst, einfach mal anfangen, die Grundlagen zu lernen? Die kannst Du ja schon gar nicht verstanden haben, da Du SMTP_AUTH mit SMTP_AFTER_POP gleichsetzt.
 
Jetzt haltet euch fest, damit Ihr nicht vor Lachen vom Stuhl fallt.
Der Spamer benutzt ein formmail.cgi, welches ein Kunde von uns in seinem cgi-bin zu liegen hat.

Danke an alle!
Besonderen Dank an "rfolkerts", der mich in die richtige Richtung getreten hat.
 
Ca. 1x / Minute findet ein Zugriff statt. Dabei werden ca. 200 Mailadressen im Bcc angegeben, immer wieder neue. Jedes mal kommt der Zugriff von einer anderen IP, einmal aus den USA, einmal aus Polen usw. Es ist aber immer der gleiche Text in der Mail.

Nur mal so, falls es wen interessiert.
 
Naja, wenn Dein Server erstmal für derart heftige Attacken mißbraucht worden ist, kannst Du den sowieso erstmal knicken. Vermutlich bist Du schon längst so heftig geblacklistet, dass Du mit der Karre nicht mehr vernünftig arbeiten kannst. Es dürfte ein mächtiges Stück Arbeit werden, die Möhre zu rehabilitieren.

Und festhalten? Nein, da gibts nichts zum Festhalten, dass ist eigentlich eine der klassischen Varianten. Und zum Lachen ist das auch nicht, sondern es kann für einen Hoster zum echten Problem werden (wie in Deinem Fall), wenn Kunden auf der Karre unsichere CGI-Skripts laufen lassen.
 
woah!

das klingt so, als willst du jetzt erstmal geld ausgeben.
ich denke nicht, dass es sich hierbei um ein hardwareproblem handelt!

guck dir lieber naechste woche mal an, wie gross der schaden wirklich war, indem du mal probehalber ein paar mails an kumpels bei aol, hotmail, gmx etc verschickst,
und guckst welche davon in deren spamfiltern haengenbleiben.
 
solche leute sind es schuld warum es soviel spam gibt. ehrlichgesagt wenn du nix davon verstehst dann lass es doch einfach sein. erst recht bei so einer heiklen geschichte wie mta.
und was soll das bringen wenn du dir jetzt einen neuen server kaufst? :huth:
ich benutze den ja wirklich nicht gern, weil er abstossend und beleidigend ist, aber hier wär es wohl angebracht.
 
Zurück
Oben