[postfix-users] Externe Adressen autom. sperren

[Robert Schetterer]

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 at 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...

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria