[postfix-users] postfix spambot abwehr mit rsyslog iptables recent blog
Hi, fuer alle die es interesiert, ich habe einen kleinen Blog geschrieben ueber eine Moeglichkeit zur Spambot Abwehr mit iptables recent und rsyslog
http://sys4.de/de/blog/tags/postfix/
Best Regards MfG Robert Schetterer
Hallo Robert,
* Robert Schetterer rs@sys4.de:
ich habe einen kleinen Blog geschrieben ueber eine Moeglichkeit zur Spambot Abwehr mit iptables recent und rsyslog
gab es denn außer dem Wunsch, die Logs kleiner zu halten, noch einen anderen Grund für diese Lösung? So wie ich den Blog-Beitrag verstehe, lief da ja sowieso schon postscreen, was ja für die Bot-Abwehr recht gut funktioniert. Hattet ihr da z.B. Last- oder Latenzprobleme?
Ciao Stefan
Am 02.02.2013 14:14, schrieb Stefan Förster:
Hallo Robert,
- Robert Schetterer rs@sys4.de:
ich habe einen kleinen Blog geschrieben ueber eine Moeglichkeit zur Spambot Abwehr mit iptables recent und rsyslog
gab es denn außer dem Wunsch, die Logs kleiner zu halten, noch einen anderen Grund für diese Lösung? So wie ich den Blog-Beitrag verstehe, lief da ja sowieso schon postscreen, was ja für die Bot-Abwehr recht gut funktioniert. Hattet ihr da z.B. Last- oder Latenzprobleme?
Ciao Stefan _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hallo Stefan, es ging dabei tatsaechlich nicht darum Spam besser zu filtern, aber man muss sich vorstellen das wir hier von einer domain mit ca 15 mailadressen sprechen deren Verbindungslogs taeglich manchmal in die Gb gingen.
Im Grunde war der Server ( der sicher nicht "zu klein" ist fuer seine Aufgabe ) nicht mehr zb fuer eine schnelle log Analyse zu gebrauchen , und legitimer Mailverkehr wurde behindert, da die Anzahl der freien smtp slots naturgemaess nicht beliebig steigerbar ist. ( auch eine smtp Ablehnung , warum auch immer, muss immer erstmal generiert werden )
Man koennte es einen ddos Angriff auf smtp nennen.
Die Situation dazu hat sich bis heute dazu auch nicht veraendert, das wird sofort deutlich wenn man das script deaktiviert.
Wie im Blog beschrieben ist das sicher ein aussergewoehnlicher Fall an dem sich aber sehr gut die Loesung mit adaptiver Firewall ueber rsyslog demonstrieren laesst.
Letzendlich kann man so , oder so aehnlich auch andere Applikationen mit aehnlichen Problemen schuetzen, fuer weniger harte Faelle reicht zb fail2ban auch aus.
Im konkreten Fall habe ich sogar nachtraeglich noch fail2ban fuer andere Fehler wieder integriert, jetzt wo die logs wieder in einem vernuenftigen Zeitfenster parsbar sind, funktioniert fail2ban wieder sehr gut.
An diesem Haertefall lassen sich aber sehr deutlich durch Analyse der logs ablesen, dass zb die Spambots ( dieser Domain ) in aufstrebende Laender wie Indien, Brasilien abgewandert sind ( vorher Usa, Italien, Frankreich) dass es wohl hauptsaechlich gehackte Windows Rechner sind ( eher keine Ueberraschung ) , und dass man im Zweifelsfall die Bots mit keiner Massnahme ueberzeugen kann von einer Domain abzulassen.
Best Regards MfG Robert Schetterer
Hallo Robert,
vielen Dank für die Klarstellung. Ich will nur einen Punkt nochmal rausgreifen, weil ich mir nicht sicher bin, ob ich ihn richtig verstanden habe, wenn das OK ist:
* Robert Schetterer rs@sys4.de:
und legitimer Mailverkehr wurde behindert, da die Anzahl der freien smtp slots naturgemaess nicht beliebig steigerbar ist. ( auch eine smtp Ablehnung , warum auch immer, muss immer erstmal generiert werden )
War das jetzt mit oder ohne postscreen? Wenn mit, dann muß ich sagen: Ich bin froh, daß das nicht mein Mailserver ist, das wäre mir dann doch zuviel Traffic ;-)
Ciao Stefan
Am 02.02.2013 15:25, schrieb Stefan Förster:
Hallo Robert,
vielen Dank für die Klarstellung. Ich will nur einen Punkt nochmal rausgreifen, weil ich mir nicht sicher bin, ob ich ihn richtig verstanden habe, wenn das OK ist:
- Robert Schetterer rs@sys4.de:
und legitimer Mailverkehr wurde behindert, da die Anzahl der freien smtp slots naturgemaess nicht beliebig steigerbar ist. ( auch eine smtp Ablehnung , warum auch immer, muss immer erstmal generiert werden )
War das jetzt mit oder ohne postscreen? Wenn mit, dann muß ich sagen: Ich bin froh, daß das nicht mein Mailserver ist, das wäre mir dann doch zuviel Traffic ;-)
postscreen wurde configuriert, als es in den stable Version von Postfix verfuegbar wurde, ueber die Jahre habe ich mit dieser Domain wirklich alles ausprobiert dessen ich habhaft werden konnte, letztendlich war aber nur die gebloggte Loesung "erfolgreich" wobei erfolgreich in diesem Fall ja nicht heisst dass ich das Problem losgeworden bin ,sondern nur einen Weg gefunden habe ,damit umzugehen.
Es gibt sicher auch andere Loesungen dazu ( firewallbasierend etc ) aber fuer ca 15 Mailadressen ( auf die man bedauerlicherweise nicht verzichten kann ) will man den technischen und monitaeren Aufwand ja nicht "in den Himmel" schrauben.
Ciao Stefan _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Am Sa, 02.02.13 um 11:51:55 Uhr schrieb Robert Schetterer rs@sys4.de:
irgendwie kann ich da leider mit chrome keinen Kommentar hinterlassen, der Klick führt immer nur wieder an den Start des Blogposts.
Daher mal hier eine Idee/Frage...
Erstmal: Schick, die Lösung gefällt und man kann sie sicherlich gut auf weitere Dienste ausweiten, und man ist auch schön flexibel was die Behandlung angeht - nicht wie die unsäglichen hosts.allow und .deny Dateien.
'Aber', was mich bei der Lösung 'stört' ist, dass ein einliefernder MTA der möglicherweise unbegründet auf der Liste landet, fortan in timeouts läuft und der admin dort auch nicht viel zum debuggen hat.
Vielleicht ist er ja Opfer eines Hacks geworden, der direkt SMTP nach draußen spricht, so dass sein maillog leer ist, etc.
Wurde mal ausprobiert statt eines DROP ein DNAT auf einen lokal laufenden Prozess zu machen, der einfach ein passendes SMTP-Banner ausliefert, also sowas wie 550 - You have been blocked due to excessive SPAM from your side! direkt nach dem connect auf den port.
Ja, das belastet den IP-Stack und bindet wieder Ressourcen, aber nicht so viele wie der postfix der hier seine Regeln durchlaufen muss. Ein simples netcat oder so reicht hier ja vollkommen aus, dsa man auch per xinetd laufen lassen kann.
Grüße, Florian
Am 02.02.2013 16:56, schrieb Florian Streibelt:
Am Sa, 02.02.13 um 11:51:55 Uhr schrieb Robert Schetterer rs@sys4.de:
irgendwie kann ich da leider mit chrome keinen Kommentar hinterlassen, der Klick führt immer nur wieder an den Start des Blogposts.
sorry werde ich weitergeben
Daher mal hier eine Idee/Frage...
Erstmal: Schick, die Lösung gefällt und man kann sie sicherlich gut auf weitere Dienste ausweiten, und man ist auch schön flexibel was die Behandlung angeht - nicht wie die unsäglichen hosts.allow und .deny Dateien.
'Aber', was mich bei der Lösung 'stört' ist, dass ein einliefernder MTA der möglicherweise unbegründet auf der Liste landet, fortan in timeouts läuft und der admin dort auch nicht viel zum debuggen hat.
das ist hier tatsaechlich einkalkuliert, konkret kannst du aber in postscreen auch whitelisten, dann schlaegt das script nicht zu
Vielleicht ist er ja Opfer eines Hacks geworden, der direkt SMTP nach draußen spricht, so dass sein maillog leer ist, etc.
Wurde mal ausprobiert statt eines DROP ein DNAT auf einen lokal laufenden Prozess zu machen, der einfach ein passendes SMTP-Banner ausliefert, also sowas wie 550 - You have been blocked due to excessive SPAM from your side! direkt nach dem connect auf den port.
durchaus auch eine idee, man koennte aus rsyslog heraus im Prinzip jede Aktion ausloesen die man will, in meinem Fall will ich aber tatsaechlich droppen ( "Opfer" nehme ich bewusst in Kauf ) , steht ja auch im blog, es ist eine absolute Einzelfall loesung, nicht einfach nachmachen ohne nachdenken ,defakto hatte ich aber noch keinen relevanten false postive, man muss das aber auch in Relation setzen, die 15 Mailadressen erhalten nicht wirklich viel legale mail von "aussen", und sein "Pappenheimer" kennt man ueber die Jahre.
Der wirkliche Vorteil ist die Geschwindigkeit mit der man reagieren kann, verglichen mit zb fail2ban etc, welche Faelle man filtert und ob man whitelists etc zusaetzlich verwendet ist der Kreativitaet des Admins ueberlassen
Ja, das belastet den IP-Stack und bindet wieder Ressourcen, aber nicht so viele wie der postfix der hier seine Regeln durchlaufen muss. Ein simples netcat oder so reicht hier ja vollkommen aus, dsa man auch per xinetd laufen lassen kann.
du kannst es ja mal so testen und feedback geben, wuerde mich freuen
ein Kollege hat mir uebrigens auch noch ein paar Verbesserungen geschickt , die werde ich als Kommentar ungeprueft mal drunter posten bei Gelegenheit
Grüße, Florian _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Am 02.02.2013 11:51, schrieb Robert Schetterer:
Hi, fuer alle die es interesiert, ich habe einen kleinen Blog geschrieben ueber eine Moeglichkeit zur Spambot Abwehr mit iptables recent und rsyslog
http://sys4.de/de/blog/tags/postfix/
Best Regards MfG Robert Schetterer
Gefällt mir gut und passt auch ziemlich genau zu meiner Lösung mit syslog-ng. Auch wenn ich dabei keine Pipe brauche, sondern die IP direkt die Firewall eintragen kann. K.A. ob rsyslog das auch kann.
Mal schauen, wenn ich es zeitlich schaffe, publiziere ich meinen Ansatz am Montag.
Ich blocke solche IP aber für max. 6 Stunden über die Firewall. Das reicht hier in den meisten Fällen.
Gruß Florian
Am 03.02.2013 14:05, schrieb system@ra-schaal.de:
Am 02.02.2013 11:51, schrieb Robert Schetterer:
Hi, fuer alle die es interesiert, ich habe einen kleinen Blog geschrieben ueber eine Moeglichkeit zur Spambot Abwehr mit iptables recent und rsyslog
http://sys4.de/de/blog/tags/postfix/
Best Regards MfG Robert Schetterer
Gefällt mir gut und passt auch ziemlich genau zu meiner Lösung mit syslog-ng. Auch wenn ich dabei keine Pipe brauche, sondern die IP direkt die Firewall eintragen kann. K.A. ob rsyslog das auch kann.
Hi Florian, direkt ist natuerlich der Koenigsweg wir haben das damals aus Zeitmangel nicht getestet wobei ein script das eine pipe liest evtl auch noch die Moeglichkeit gibt zusaetzlich etwas einzubinden ,wenn gewuenscht
Mal schauen, wenn ich es zeitlich schaffe, publiziere ich meinen Ansatz am Montag.
wuerde mich sehr freuen, mir ist voellig klar das mein Ansatz bei weitem nicht perfekt war , aber er ist fuer diesen Einzelfall gut genug gewesen
Ich blocke solche IP aber für max. 6 Stunden über die Firewall. Das reicht hier in den meisten Fällen.
ist bei mir nicht der Fall, ich hatte das schon vorher getestet, nicht mal 24 h waren genug, im Einzelfall, wobei bei mir die pure Masse das Hauptproblem darstellt, ich konnte eigentlich nur eine Besonderheit feststellen, die Bots werden regelmaessig noch massiver am Freitag relativ punktlich zum Ende der europaeischen Buerozeit, warum auch immer
Gruß Florian _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Hallo Robert,
Am 03.02.2013 17:14, schrieb Robert Schetterer:
Gefällt mir gut und passt auch ziemlich genau zu meiner Lösung mit syslog-ng. Auch wenn ich dabei keine Pipe brauche, sondern die IP direkt die Firewall eintragen kann. K.A. ob rsyslog das auch kann.
Hi Florian, direkt ist natuerlich der Koenigsweg wir haben das damals aus Zeitmangel nicht getestet wobei ein script das eine pipe liest evtl auch noch die Moeglichkeit gibt zusaetzlich etwas einzubinden ,wenn gewuenscht
Ich verwende Scripts nur für andere Bans, um dadurch eine Whitelist realisieren zu können. Das läuft dann aber nicht über eine Pipe, sondern ein Script wird dazu von syslog-ng aufgerufen. Einen Grund gibts dafür allerdings nicht, das ist historisch so gewachsen. ;)
Der Vorteil an der Lösung syslogd/recent ist m.E. dass sich darüber schneller als über fail2ban blocken lässt. Zumal f2b doch arg Last produziert, wenn zu viele Logeinträge auflaufen. Ich verwende fast nur noch recent.
Mal schauen, wenn ich es zeitlich schaffe, publiziere ich meinen Ansatz am Montag.
wuerde mich sehr freuen, mir ist voellig klar das mein Ansatz bei weitem nicht perfekt war , aber er ist fuer diesen Einzelfall gut genug gewesen
Unsere Ansätze unterscheiden sich m.E. nicht wesentlich.
Ich hab das mal hier gepostet: http://blog.schaal-24.de/?p=1626
Ich blocke solche IP aber für max. 6 Stunden über die Firewall. Das reicht hier in den meisten Fällen.
ist bei mir nicht der Fall, ich hatte das schon vorher getestet, nicht mal 24 h waren genug, im Einzelfall, wobei bei mir die pure Masse das Hauptproblem darstellt, ich konnte eigentlich nur eine Besonderheit feststellen, die Bots werden regelmaessig noch massiver am Freitag relativ punktlich zum Ende der europaeischen Buerozeit, warum auch immer
Ich hab das noch in zeitliche Relationen gesetzt. Das wäre wohl auch eher ein nice-to-know. Ich kann ja schlecht die Firewall o.ä. in Abhängigkeit irgendwelcher Bots gestalten - das wäre ja ein Fass ohne Boden.
Gruß Florian
* Florian Schaal mailinglist@schaal-24.de:
Hallo Robert,
Am 03.02.2013 17:14, schrieb Robert Schetterer:
Gefällt mir gut und passt auch ziemlich genau zu meiner Lösung mit syslog-ng. Auch wenn ich dabei keine Pipe brauche, sondern die IP direkt die Firewall eintragen kann. K.A. ob rsyslog das auch kann.
Hi Florian, direkt ist natuerlich der Koenigsweg wir haben das damals aus Zeitmangel nicht getestet wobei ein script das eine pipe liest evtl auch noch die Moeglichkeit gibt zusaetzlich etwas einzubinden ,wenn gewuenscht
Ich verwende Scripts nur für andere Bans, um dadurch eine Whitelist realisieren zu können. Das läuft dann aber nicht über eine Pipe, sondern ein Script wird dazu von syslog-ng aufgerufen. Einen Grund gibts dafür allerdings nicht, das ist historisch so gewachsen. ;)
Der Vorteil an der Lösung syslogd/recent ist m.E. dass sich darüber schneller als über fail2ban blocken lässt. Zumal f2b doch arg Last produziert, wenn zu viele Logeinträge auflaufen. Ich verwende fast nur noch recent.
Ein anderer Vorteil ist IMO die Klarheit der Lösung. f2b ist - persönliche Meinung - ein ganz schöner Haufen zusammengeworfener Code den Programmierer für Programmierer gemacht haben. Für Admins, die eher ein Konfigurationsinterface mit Optionen, die sie an und ausschalten bzw. kombninineren können, ist f2b nicht wirklich geeignet.
Christian (Rößner) und ich, wollten mal f2b mal um die Fähigkeit erweitern ARF-Reports zu generieren. Das haben wir nach einem Code-Review dann mal schön sein lassen. Wir haben uns damals vorgenommen - sollte uns mal richtig langweilig sein - f2b von Grund auf neu zu bauen. Dann würde es auch besser skalieren UND es hätte ein brauchbares und dokumentiertes (!) interface.
Und damit einen guten Start in die Woche ;)
p@rick
Am 04.02.2013 08:38, schrieb Florian Schaal:
Unsere Ansätze unterscheiden sich m.E. nicht wesentlich.
Ich hab das mal hier gepostet: http://blog.schaal-24.de/?p=1626
ah schoen, ich werde das evtl mal querverweisen
Ich blocke solche IP aber für max. 6 Stunden über die Firewall. Das reicht hier in den meisten Fällen.
ist bei mir nicht der Fall, ich hatte das schon vorher getestet, nicht mal 24 h waren genug, im Einzelfall, wobei bei mir die pure Masse das Hauptproblem darstellt, ich konnte eigentlich nur eine Besonderheit feststellen, die Bots werden regelmaessig noch massiver am Freitag relativ punktlich zum Ende der europaeischen Buerozeit, warum auch immer
Ich hab das noch in zeitliche Relationen gesetzt. Das wäre wohl auch eher ein nice-to-know. Ich kann ja schlecht die Firewall o.ä. in Abhängigkeit irgendwelcher Bots gestalten - das wäre ja ein Fass ohne Boden.
nun zunaechst war ich froh , erstmal wieder logs zu haben bei der Analyse in einer vernuenftigen Zeitspanne ueberhaupt wieder moeglich ist.
Ausserdem interesiert mich es natuerlich schon, mal dahinter zukommen warum ausgerechnet diese Domain so beschossen wird, aber ganz ehrlich ausser die zeitlichen Abhaengigkeiten und die Standortverteilung konnte ich nichts konkretes belegen, dazu muesste man wohl den raw traffic ueber laengere Zeit mitschneiden um diesen dann nach bot signaturen zu scannen, das lohnt dann wiederum auch nur wenn man daraus weitere adaptive Firewall regeln ableiten kann, das geht aber mehr in Richtung intruder detection usw.
Was zeitabhaengige Firewall drops angeht wuerde ich sowas nicht grundsaetzlich ablehnen zb ( dyn Indien Netze Freitag 15-19 Uhr immer smtp droppen etc ), gerade bei mail waere das evtl verkraftbar dazu muesste sich eine eindeutige periode belegen lassen und diese muesste wiederum auch immer neu verfiziert werden. Sicher hoher Aufwand der wie immer im Verhaeltnis stehen muss.
Das eigentlich Anwendungs Problem der iptables recent syslog Methode ist meiner Meinung nach die Komplexitaet der syslog templates ,filter usw hier waere ein framework zum editieren ( evtl fuer alle gaengigen syslog varianten ) sicher hilfreich, damit die Methode breiter angewendet werden wuerde
Gruß Florian
Best Regards MfG Robert Schetterer
participants (6)
-
Florian Schaal -
Florian Streibelt -
Patrick Ben Koetter -
Robert Schetterer -
Stefan Förster -
system＠ra-schaal.de