DDoS auf qmail


Discogalaxy

Discogalaxy

Registered User
Moin zusammen.
Seit gestern Abend wird meine Büchse heftigst angespammt:

Code: 
Jul 31 07:09:00 h4742 relaylock: /var/qmail/bin/relaylock: mail from 64.19.175.30:2028 (exch.burntforest.net)
Jul 31 07:09:02 h4742 relaylock: /var/qmail/bin/relaylock: mail from 216.54.1.132:2889 (ip-216-54-1-132.coxfiber.net)
Jul 31 07:09:03 h4742 relaylock: /var/qmail/bin/relaylock: mail from 24.172.201.80:35168 (rrcs-24-172-201-80.central.biz.rr.com)
Jul 31 07:09:04 h4742 relaylock: /var/qmail/bin/relaylock: mail from 63.204.147.3:4734 (mta.victron.com)
Jul 31 07:09:07 h4742 relaylock: /var/qmail/bin/relaylock: mail from 204.10.37.130:35885 (ns1.247x.net)
Jul 31 07:09:12 h4742 relaylock: /var/qmail/bin/relaylock: mail from 206.239.111.130:18788 (cccfs.capconcorp.com)
Jul 31 07:09:15 h4742 relaylock: /var/qmail/bin/relaylock: mail from 69.93.187.90:39343 (5a.bb.5d45.static.theplanet.com)
Jul 31 07:09:19 h4742 relaylock: /var/qmail/bin/relaylock: mail from 216.55.165.135:34558 (216-55-165-135.dedicated.abac.net)
Jul 31 07:09:20 h4742 relaylock: /var/qmail/bin/relaylock: mail from 70.103.39.102:32808 (not defined)
Jul 31 07:09:24 h4742 relaylock: /var/qmail/bin/relaylock: mail from 65.216.196.53:39097 (vastrelay.vastera.com)
Jul 31 07:09:27 h4742 relaylock: /var/qmail/bin/relaylock: mail from 68.127.151.47:3334 (adsl-68-127-151-47.dsl.pltn13.pacbell.net)
Jul 31 07:10:00 h4742 relaylock: /var/qmail/bin/relaylock: mail from 74.92.35.242:32675 (exchange.hybricon.com)
Jul 31 07:10:05 h4742 relaylock: /var/qmail/bin/relaylock: mail from 212.227.60.139:58254 (peejoeserver.de)
Jul 31 07:10:05 h4742 relaylock: /var/qmail/bin/relaylock: mail from 212.216.176.134:43487 (vsmtp104.tin.it)
Jul 31 07:10:08 h4742 relaylock: /var/qmail/bin/relaylock: mail from 63.205.154.1:27905 (mail.thingap.com)

und meine Load steigt ins Jenseits.
Da aber alles Andere problemlos läuft, nur ein wenig langsamer, und die Versuche augenscheinlich ins Leere laufen, sprich wenn ich das richtig verstanden habe die Mails ja nicht weitergeleitet werden von meinem Server, mache ich mir nicht sooo grosse Sorgen.

Um dem ganzen Abhilfe zu schaffen wollte ich ganz schlau sein und habe fail2ban auf den Regex und mail.warn angepasst.
Hat auch prima funktioniert heute Nacht. Ca. 700 IPs gesperrt.
Aber mir ist dann mal aufgefallen das ich mich dadurch auch selber aussperre, bzw. wenn ich eine eMail verschicke auch erstmal im relaylock lande.
Code: 
Jul 31 06:55:26 h4742 relaylock: /var/qmail/bin/relaylock: mail from 80.136.74.130:1278 (p50884a82.dip.t-dialin.net)
Jul 31 06:55:26 h4742 smtp_auth: SMTP connect from [email protected] [80.136.74.130]
Jul 31 06:55:26 h4742 smtp_auth: smtp_auth: SMTP user [email protected] : /var/qmail/mailnames/xxx.de/xxx logged in from [email protected] [80.136.74.130]
Also wenn ich, oder ein User, innerhalb der findtime 2 eMails verschicke wird auch auf Port 25 geblockt.
Testweise habe ich die findtime für dieses jail auf 120 gesetzt, was aber nicht wirklich der Lösung genug tut.

Hat vielleicht jemand Vorschläge was ich gegen diese Attacken machen könnte? Irgendeine Blacklist implementieren wie z.B. Nixspam?
 
Beachte das relaylock einen missverständlichen Namen trägt. Es hat nichts mit aussperren oder ähnliches zu tun sondern dient nur dem SMTP-after-POP. Es schreibt seit Plesk 8.2 lediglich einen unnötigen Eintrag im Maillog.

Wenn Dein Logfile wirklich nur mit relaylock voll war, sagt das leider auch nicht viel. Denn qmail-smtpd loggt nichts. Hier kann es aber zu gewaltigen Spam-Versuchen gekommen sein. (Vgl. ein Open-Relay-Test mit eigenem Logfile)

Die Idee mit fail2ban ist schon nicht schlecht. Müßte aber bei erfolgreicher Emaileinlieferung den 'ban' wieder aufheben.

huschi.
 
Code: 
Relay test result
All tests performed, no relays accepted by remote host.

Soweit so gut.

Was aber weniger gut ist:
Code: 
load average: 144.34, 138.80, 125
Und 308 Prozesse, hauptsächlich qmail-smtpd
:D

Die Idee mit fail2ban ist schon nicht schlecht. Müßte aber bei erfolgreicher Emaileinlieferung den 'ban' wieder aufheben.
Click to expand...
Schön wäre es, aber ist leider nicht so einfach zu realisieren, zumindest für mich nicht.

Was könnte ich noch machen?
 
Du sollst nicht Qmail killen sondern die "qmail-smtpd"-Prozesse.
Die werden von (x)inetd gestartet. Ist ein kleiner aber gewaltiger Unterschied.

Der zweite Befehl setzt einen Timeout von 60 Sekunden für qmail-smtpd. Std. ist nämlich 5 Minuten (=> 300 Sek.). Bei einem Portscan oder unsauberen Schließen der Verbindung bleibt ein Thread solange im Speicher hängen.

huschi.
 
Du sollst nicht Qmail killen sondern die "qmail-smtpd"-Prozesse.
Click to expand...
Das wollte ich ja damit sagen, kille qmail-smtpd.

Das Timeout habe ich nun mal auf 50 gesetzt und eine leichte besserung ist abzusehen.

Ob das jemals wieder aufhört?
Ich bin ja schon einige Attacken mittlerweile gewöhnt.
Bei dieser jedoch funktioniert eigentlich alles noch, nicht wie bei Angriffen auf den Apachen z.B.
Was mich nur langsam annervt sind die ständigen eMails von Cacti, bzw. Thold davon :-)

Ich grüble gerade wirklich was ich noch machen könnte ausser warten und ab und an qmail-smtpd zu killen.
Ob ein Kill via Cronjob alle 15 Minuten was bringen würde, oder ist dann die Gefahr zu gross echte Mails zu killen?
Was ist mit einem noch kürzerem Timeout?
 
Du kannst ja auch den SMTP über Nacht ganz abschalten. (Z.B. den (x)inetd beenden.) Echte Emails werden Dir später nochmal zugestellt.

huschi.
 
Die Lage hat sich "normalisiert"
Es sind zwar immer noch vermehrt Versuche, aber es hält sich im Rahmen.
Ich habe zusätlich in der config von qmaild noch die verbindungen auf 6 gesetzt.
 
You must log in or register to reply here.

Back
Top