Am 22.06.23 um 19:18 schrieb Steffen Nurpmeso:
Robert Schetterer wrote in
<be751a1d-5dbe-46d2-75d3-b0df9c8e2...@sys4.de>:
|Am 22.06.2023 um 13:58 schrieb André Rodier via Postfix-users:
...
|> Shortly after it has been setup, I see brute force attacks (not
|> surprising) from a whole /24 network (more surprising).
...
|> Is there any way, with postfix, to run a script on authentication
|> failure, with information like the IP address and the
|> username passed, for instance.
Have a look at blacklistd (now in parts blocklistd) as written by
Christos Zoulas of NetBSD, and also used on FreeBSD.
They maintain a postfix patch to hook in calls to bl[ao]cklistd.
It does exactly that.
...
|> What are you using on your side ?
I only use a combi of an awk script that parses logs, and firewall
rules that add penalties based on connection count (and data
transfer). This is suboptimal, especially in your scenario. (Ie,
i would claim it would make sense to block or limit entire IP
ranges, for which the awk script would need to hold state.)
...
|postfix/dovecot uses syslog so action can be taken
|
|see
|
|https://blog.schaal-24.de/firewall/postfix-postscreen-ip-in-die-firewall\
|-eintragen/
|
|thinkable spread the action via ssh on other servers in your cluster
|
|you can also use iptables recent to be faster
This has a low default limit, and you need a kernel tunable to
overcome it, for example i have
xt_recent.ip_list_tot=250 xt_recent.ip_pkt_list_tot=32
I had 10000 in the list, no problem
to make this a bit better. (For my purpose; i found with the
default 100 that too many "rejectors" come in, so the overflowing
of the table effectively moves IPs to the "super aliens" table,
which was also overcrowded then. With 250 my default traffic
is levelled off nicely. But peaks cause "havoc" again. This is
all suboptimal, for one all servers should offer some kind of
blacklistd interface for more than login requests, and the
firewall -- at least the xt_recent code -- should also reach out;
likely the latter could be done with inotifyd on the xt_recent
directories, yet i never tried it.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
back to the subject, checking auth should be done very late
its "cheaper" to use ip based stuff before.
so it depends what is the exact goal, just fixing brute force
quick and dirty or develop some kind of reputation framework
with tagging div clients behave like spamassassin
to force some action when some limit has reached
you can also include compare log history data about an email address /
domain to rise intruder alert, i.e ( like greylist ) positve triplets
good auth from ip/net vs sudden bad/brute auth from new ip/net
i think such framework exists but are not open source
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
