[postfix-users] Spam-Relay via gekapertem Useraccount

[Jakob-Matthias Böttger]

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 at 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 at 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-attacken-auf-smtp-sasl-mit-xymon/
>
> 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-modul-abwehren/
>
>
> 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 at de.postfix.org
>> http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
>>
>
>
> Best Regards
> MfG Robert Schetterer
>