Mail Attake über AOL

[velo]

Hallo,

mein Server wurde heute den ganzen Tag attakiert, jedoch ist mir nicht so klar was eigentlich passiert ist und bitte um eure Erfahrung.

Hier mal alles was ich darüber berichten kann. Ach ja, zunächst: Ich bin mir da ziemlich sicher, dass ich kein offenes Relay habe ... wer es testen will (Bitte keine dummen Sachen machen) ... meine IP: 217.160.134.195

Und nun ein Teil meiner mail -log:

Code: Select all

Jan 20 02:16:41 p15113597 postfix/smtpd[11492]: connect from outbd-m02.icq.aol.com[64.12.164.38]
Jan 20 02:16:41 p15113597 postfix/smtpd[11492]: 77D1E39821E: client=outbd-m02.icq.aol.com[64.12.164.38]
Jan 20 02:16:41 p15113597 postfix/cleanup[11645]: 77D1E39821E: message-id=<200401200116.i0K1GtCb001828@outbd-m02.icq.aol.com>
Jan 20 02:16:41 p15113597 postfix/smtpd[11492]: disconnect from outbd-m02.icq.aol.com[64.12.164.38]
Jan 20 02:16:42 p15113597 postfix/cleanup[11645]: 07024398243: message-id=<200401200116.i0K1GtCb001828@outbd-m02.icq.aol.com>
Jan 20 02:16:42 p15113597 postfix/smtp[11020]: 1007939824B: to=<news@newsletter.icq.com>, relay=inbd-vip-m.icq.aol.com[64.12.164.56]
, delay=0, status=sent (250 2.0.0 i0K1GFfH016909 Message accepted for delivery)
Jan 20 02:16:42 p15113597 postfix/smtp[11021]: 04602398242: to=<news@newsletter.icq.com>, relay=inbd-vip-m.icq.aol.com[64.12.164.56]
, delay=1, status=sent (250 2.0.0 i0K1GU20027140 Message accepted for delivery)

Wieso steht das "Message accepted" oder "sent"? Ich muss zugeben dass ich nicht der Meister im Lesen dieses Logs bin.

Mit netstat konnte ich sehen, dass sehr viele Verbindungen auf "WAIT" standen (smtp), von eben dieser AOL-IP (Waren insgesammt 3 verschiedene).

Das ganze konnte ich dann mit iptables blockieren, aber da ich nicht weiss, was eigentlich das Problem ist, kann es jederzeit wieder geschehen.

Was sagt euch dieses log? Was wurde da gemacht? (Spam versendet?, aber wie?)

danke!

--- Nachtrag ---
Habe in einem Artikel hier was mit mod_proxy gefunden, jedoch ist eine solche Aktivität zu diesem Zeitpunkt in access_log nicht zu erkennen. Dumerweise funktioniert SSL nicht ohne das Modul.(?)

Ich hab noch folgenden tcpdump (der trotz iptables was anzeigt (?)):

Code: Select all

01:46:40.479847 64.12.164.38.55881 > 217.160.134.195.smtp: S 1296920106:1296920106(0) win 5840 <mss 1460,sackOK,timestamp 130086647 0,nop,wscale 0> (DF)

...Für mich sieht das aus wie ein Zugriff auf smtp, aber wie kommt da jemand rein, wenns doch kein Open Relay ist?

[dodolin]

Laut meinen bisherigen (nicht vollständigen) Tests, hast du kein offenes Relay oder offenen Proxy. Ebenso bist du auf keiner gebräuchlichen Blackliste gelistet. Was diese Logs genau besagen, kann ich dir leider nicht sagen, da ich kein Postfix-Spezi bin...

[velo]

Danke dodolin! Habe deinen Besuch schon bemerkt ;-)

Ã?brigens: Der "Angriff" dauert noch an, nur blockt iptables alles. Ich verstehe halt nicht, wieso er auf smtp zugreift und wie er damit Erfolg haben kann?

Code: Select all

64.12.164.38.59754 > 217.160.134.195.smtp

...kann man irgendwie sehen als was er sich einlogt?

[dodolin]

..kann man irgendwie sehen als was er sich einlogt?

Das wäre ne gute Frage!
Da dein Server SMTP AUTH anbietet, könnte es durchaus sein, dass der Typ ein Passwort für einen gültigen Account kennt oder einen Account gefunden hat, der ohne Passwort funktioniert (gern benutzte Spammermethode inzwischen). Kommt wohl drauf an, wie du dein SMTP AUTH konfiguriert hast. Irgendwo sollte er das ja loggen - ansonsten wäre das Setup irgendwie nicht so der Hit, IMHO. ;)

Edit: z.B. benutzt du PAM zur Auth, wird wohl der Loggen, benutzt du saslauthd, wird der loggen, usw.

[velo]

Das habe ich nun gemacht mit dem log und den Bösen mal kurz wieder reingelassen.

Aber der Witz ist: Er verzeichnet keinen login (!?) ... Dennoch wird fleißig versendet. ... /var/log/messages bewegt sich überhaupt nicht.

[velo]

Ich habe es gefunden (glaub ich):

Das war gar kein Spam-Mißbrauch sondern die Folge von einem Autorespnder bei einem User.

Folgendes: Der User hat in Confixx einen Autoresponder angelegt ("Mail-Adresse existiert nicht mehr ...") und die Mail an eine ungültige Mail-Adresse weitergeleitet.

Scheinbar hat nun ICQ über AOL irgendeinen Newsletter gesendet und damit den Autoresponder zurückbekommen + Mail nicht zustellbar (Aber nicht mit Code "User existiert nicht") ... Also 2 unsinnige Antworten.

Daraufhin hat deren Autoresponder wieder geantwortet (warum auch immer).

So ging das hin und her und legte den Server fast lahm.

Interessant für andere ist vielleicht wie ich das rausbekommen habe:

einen Netzwerkdump erzeugt mit

Code: Select all

tcpdump -w /tmp/dump

und das dann mit etereal angesehen.

Die IP vom AOL-relay lass ich erst mal gesperrt, da die nicht aufhören mails zu senden.

... nun ich hoffe das wars wirklich.

[dodolin]

Hört sich so an, als wäre der Autoresponder von Confixx ziemlich Sch.eiße.

[cobrabbs]

hi , das kenn ich .
Das ist leider ein "ping-pong" effeckt , schalte den Autoresponder aus , das der datenaustausch , richtig hochgeschauckelt werden kann.
Die Mail wird immer grösser und der Provider ( in dem fall Aol) wird dich irgendwan sperren.
Hatten das auf der Arbeit , ein User hat seine Mails weitergleitet und seine Mailbox bei GMX war voll , so das der eine geantwortet hat "mailbox voll" und der andere "ihre mail ...... blub,blub".

[velo]

Sagt mal, gibt es da nicht eine Lösung für so was? Ich meine Mails und Autoresponder sind ja keine neue Erfindung und irgendwie selbstverständlich.

[velo]

Ich habe gemerkt dass ICQ/AOL immer noch fleißig versucht die Mails zuzustellen (wird halt durch Firewall geblockt). Hört denn sowas nicht mal auf?

Kann man da ein Aufhören nicht "erzwingen"?

--- Nachtrag ---

Hab die Regel nun von DROP auf REJECT geändert. Scheint was zu bringen.

[taurin]

Hab die Regel nun von DROP auf REJECT geändert. Scheint was zu bringen.

Is klar :)
Im Normalfall versucht ein Mailserver mails bei nicht Erreichen des Empfängers 2-5 Tage lang zuzustellen, versucht es also immer wieder. Wenn Du die Anfragen dieser IP drops ist das nichts andere wie keine Antwort zu senden, der AOL-Server denkt also, dass der Host down ist und versucht es immer wieder.
Wenn Du rejectest passiert was anderes. Der AOL-Server schickt ein SYN-Paket (startet den Verbindungsaufbau, "3way-Handshake" oder "TCP-Handshake" genannt), Dein Server schickt ein RST-Paket. Ã?bersetzt heißt das, der AOL-Server sagt "Hallo, lass uns reden" und Dein Server sagt "Verpiss Dich, mit Dir will ich nicht reden" :)
Daraufhin lässt er Dich in Ruhe, zumindest für diese eMail und schickt dem eigentlichen Sender eine Nachricht, dass der Empfänger nicht zu erreichen ist bzw. die Verbindung abgelehnt wurde.

Da zeigt sich mal wieder dass manche Leute einfach recht haben, wenn sie sagen, dass Pakete dropen ganz arg pöhse ist. Hättest Du brav rejected, wär das nicht so lang gegangen :)

[velo]

Ja danke. Im eifer des Gefechts war halt die erste Reaktion "DROP" ... weil ich auch dachte, dass es ein aktiver Angriff auf meinen SMTP ist und ich wollte den "Hacker" etwas lähmen indem ich keine sauberen Pakete als Antwort gebe.

[taurin]

Ahso, na das hab ich Deiner Antwort nicht entnehmen können, also nix für ungut für die überflüssge Lehrstunde ;)

[velo]

Iwo, lesen ja auch andere die das noch nicht wissen.