mit dem milter-greylist ist sicherlich eine Option. In diesem Fall müssten die Restrictions dann aber so konfiguriert werden, dass auch erfolgreiche SASL logins durch den milter laufen, was meiner Meinung nach Ressourcen verschwendung ist. Sollte sich einer der User in der Ukraine aufhalten, könnte man noch das Webmail oder ein VPN nutzen. Aber es stimmt, das ein GeoIP basiertes SASL filtering problem Potential mit sich bringt. Gerade in einem großen Setup. Je nach Setup könnte man noch reject_unlisted_sender in die smtpd_sender_restrictions aufnehmen. Damit würde man dann die Senderadressen gegen die im System vorhandenen Mailadressen verifizieren. Aber ACHTUNG das geht nur bei richtig konfigurierten Lookups der Adressen. Z.B. über die Virtual umgebung.
VG Jakob
Am 21.08.2014 um 11:48 schrieb Robert Schetterer:
Am 21.08.2014 um 11:26 schrieb Matthias Schmidt:
Am 21.08.2014 um 18:12 schrieb Robert Schetterer rs@sys4.de:
Am 21.08.2014 um 10:27 schrieb Peter Heitzer:
Wäre es nicht einfacher, das mit Access Policy Delegation zu erledigen und z.B. in main.cf unter "smtpd_recipient_restrictions" check_policy_service xxx einzutragen? So ein policy server ist recht einfach zu implementieren. Ausserdem könnte man eine Verifizierung einbauen, ob die "From:" Adresse überhaupt dem Benutzer zugeordnet ist.
Desweiteren könnte man auch die Anzahl der Empfänger/Zeiteinheit in Abhängigkeit von der Herkunft (IP-Bereich) reglementieren.
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
das hier koennte helfen
http://milter-greylist.wikidot.com/geoip
implementieren nur fuer Submission ohne greylist, nur geoip ( wenn das geht )
totally untested, iptables geoip sollte auch funktionieren , ich bitte aber zu bedenken das Kunden auch mal beruflich und/oder privat im Urlaub im Ausland sein konnten, diese Loesung ist also sicher nicht in jedem Setup zu gebrauchen, grundsaetzlich wuerde ich eher darauf setzen "Anomalien" aus den Logs erkennen zu koennen und daraus einen Alarm zu triggern und dann daraus gegebenfalls eine „Auto Action“ loszutreten
Das mit dem Submission port funktioniert jetzt wie vorgeschlagen. Danke :-)
wie stell ich denn sowas an, Anomalien im Log zu erkennen um mir dann z.Bsp. eine Alarm-Mail zu schicken. Ich nehm mal an mit php und regex oder vergleichbares. Das ist nun leider nicht so ganz mein Gebiet :(
das ist nicht ganz trivial, und meines wissens gibt es dafuer auch nichts "out of the box"
vorfiltern im syslog ist schon mal nicht schlecht zb nach sasl
nur so als Ideengeber
https://sys4.de/de/blog/2013/04/17/monitoren-und-alarmierung-von-brute-force...
wenn man geschickt ist kann man die filterung auch gleich von zb rsyslog erledigen lassen und auch von dort aus auch gleich eine action ausfuehren lassen zb passwort aendern oder account deaktivieren usw
auch nur fuer Ideen Sammlung
https://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-m...
https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/
ich hab mich schon an sowas versucht bin aber aus Zeitmangel noch nicht sehr weit, technisch geht da auf jeden Fall einiges , nur "einfach" ist es eben nicht
Einige Intruder Detection Systeme sollten auch aehnliche Moeglichkeiten haben
Danke jedenfalls für die Hilfe hier auf der Liste Grüsse Matthias
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer