Am 16.09.2011 23:43, schrieb Driessen:
On Behalf Of Robert Schetterer
Am 16.09.2011 18:51, schrieb Benjamin Fromme:
Hallo Liste,
letzte Nacht hat einer unserer Kunden mehrere hundert E-Mails, an eine nicht existente Adresse bei T-Online gesendet. Aus diesem Grund hat T- Online dann freundlicherweise unsere Relays für 24 Stunden gesperrt, was unsere anderen Kunden natürlich nicht besonders gefreut hat... Daher meine Frage: Gibt es eine Möglichkeit eine externe Adresse, nach einer bestimmten Anzahl an Fehlversuchen, bereits zu blocken, bevor es zu weiteren Zustellungsversuchen kommt? Vielen Dank im voraus!
Fail2ban wird dein Freund sein wenn du nur Fehlversuche sanktionieren möchtest und nicht alle Kunden reglementieren
Mit dieser Lösung würde ich ja den gesamten Kunden sperren, und das ist
leider nicht möglich, nur weil irgendein Mitarbeiter Mist baut. Oder habe ich was übersehen? Ich kenne fail2ban primär aus dem ssh und iptables Bereich.. Ich würde halt gerne etwas bauen, was weitere Zustellungsversuche, nach einer gewissen Anzahl von Fehlversuchen unterbindet. Sprich es wird eine E-Mail an eine externe Adresse xyz@xyz.de eingeliefert. Wenn unser Relay dann feststellt das 100 Versuche fehlgeschlagen sind, an diese Adresse zu versenden, soll es keine weiteren Mails für diese Adressen annehmen und somit verhindern das sich die Gegenstelle, wie in diesem Fall t-online, belästigt fühlt..
Sorry das geht zuerst mal auf die einliefernde IP, Ob der Client in einem ganzen Netzwerk von Firmenrechnern sitzt und alle über eine Leitung/IP senden wäre mir in dem Fall egal.
Ist das ein Rechner eines Mitarbeiters dann sperre ich doch lieber den ganzen Kunden bzw. die IP über den der Scheiß passiert wie das ich es riskiere auf irgendeiner Blacklist zu landen. Der Kunde bzw. sein Mitarbeiter hat Mist gebaut und derjenige hat die Sperre verschuldet. Ich schütze nur meine anderen Kunden und mein Netzwerk. Der Kunde der seine Rechner nicht im Griff hat und andere damit schädigt haftet. Es fällt dann auch schneller in der Firma auf das eben etwas nicht funktioniert und der zuständige Admin wird sich schon melden und nachfragen was denn los ist. Er hat dann die Möglichkeit loszugehen und kann dem Verursacher mal freundlich auf die Schulter klopfen.
das wuerde ich auch sagen, aber man kann die regex in fail2ban ja selber bauen, evtl gehts damit , nur welche action soll man dann anwerfen , im prinzip muesste man den zb sasl smtp zugang sperren ( evtl das passwort aendern etc ), weil ip sperren bei dynmischen ips ja nicht viel bringen wuerden
Auch DIALIN ändert sich in der Regel nur einmal alle 24 Stunden. In den Kabelnetzen so gut wie nie.
Ich bin nur gerade am Überlegen wie der Filter aussehen müsste..... Bei der Einlieferung weis ich ja noch nicht das die Mail nicht abgeliefert werden kann. Also muß der Match auf die bounce Meldung und an wen es zurückgeht (sofern die Kunden auch wirklich unter Ihrer eigenen Mailadresse den Mist bauen) filtern. Bei 5 Bounces wird dann das PW wo auch immer geändert oder aber auch gleich die ganze IP.
Zähler hat Fail2ban auch drin inkl. automatischer Sperre und Entsperrung. Außerdem kann mit Fail2ban alles Mögliche an action gesetzt werden nicht nur IPtables (das kennt jeder von fail2ban).
Da gibt es sogar so was wie
actionban = ADDRESSES=`whois <ip> | perl -e 'while (<STDIN>) { next if /^changed|@(ripe|apnic).net/io; $m += (/abuse|trouble:|report|spam|security/io?3:0); if (/([a-z0-9_-.+]+@[a-z0-9-]+(.[[a-z0-9-]+)+)/io) { while (s/([a-z0-9_-.+]+@[a-z0-9-]+(.[[a-z0-9-]+)+)//io) { if ($m) { $a{lc($1)}=$m } else { $b{lc($1)}=$m } } $m=0 } else { $m && --$m } } if (%%a) {print join(",",keys(%%a))} else {print join(",",keys(%%b))}'` IP=<ip> if [ ! -z "$ADDRESSES" ]; then (printf %%b "<message>\n"; date '+Note: Local timezone is %%z (%%Z)'; grep '<ip>' <logpath>) | <mailcmd> "Abuse from <ip>" $ADDRESSES
<mailargs> Fi
In den .conf dateien als action
Also theoretisch frei definierbar was im Falle eines Falles gemacht werden soll. Auch script aufruf der nachträglich nach der einliefernden IP grept und sperrt per ipset
z.B. sowas ähnliches wie das hier : egrep -i "$LASTHOUR.*No such file" $LOGS | \ $AWK '{ split($1, mydate, "/"); print(mydate[1] "/" mydate[2] "/" mydate[3] "." substr($2, 1, 6) ".*[" substr($3, 2, length($9)-3) ".*rsync.on"); }'|\ sort | uniq > $LIST/spat.regexp
for pat in $(cat $LIST/spat.regexp) do $AWK '/'$pat'/ { split($1, mydate, "/"); print(substr($9, 2, length($9)-2) "\t" mydate[1] mydate[2] mydate[3] " " substr($2, 1, 2)); }' $LOGS | \ sort -b -t. -k1,1n -k2,2n -k3,3n -k4,4n | uniq >> $LIST/msrbl.rsync done
waere auf jeden Fall ziemlich kompliziert und nicht out of the box zu haben ( es sei denn jemand hat das schon mal so oder aehnlich geloest mit fail2ban )
So was ähnliches *g
boh respekt !
ich glaube ein besserer Ansatz waere ueberhaupt eine Limitierung mit ein policy server
Eine limitierung würde dann aber praktisch jeden Kunden betreffen nicht nur den der da gerade mist baut.
noe nicht zwangslaeufig, aber es waere in jedem Fall zu pflegen, ziemlicher Aufwand
Mit freundlichen Grüßen
Drießen
ich sehe das Problem aber vom Prinzip her auch eher beim Kunden egal welchen automatismus man einbaut , mann kann damit nicht jede moegliche Tollerei abfangen, schlieslich kanns ja beliebige Gruende geben ( berechtigt oder unberechtigt ) warum eine ip irgendwo gesperrt wird, im uebrigen hats die telekom grad noetig, deren server sind grade zur Zeit massive spamschleudern, wie auch immer das ist eben ein Tagesgeschaeft , bei dem man immer am Ball bleiben muss, ob sich der Aufwand im Einzeln lohnt eine bestimmten "Fehler" automatisch abzuhandeln muss jeder selbst herausfinden durch mehr oder weniger taegliche Analyse. Ich bin mittlerweile soweit, das wenn ein Kunde sich als unbelehrbar erweist , ihn einfach vom sharedmail ausschliesse, er kann ja immer seinen eigenen root server haben, da is es mir dann wurst, bzw dann muss er seine dummheit dann halt bezahlen sowas diszipliniert dann schon...