CBL
2015-06-13 16:26:46 UTC
Having a lot of dictionary attacks working on guessing login details. I'm
wondering if there's an easy way to block access to specific IPs prior to
SASL authentication?
I can grab the IP easy enough via fail2ban and block it on the firewall of
the local machine, but I run a cluster of multiple inbound servers and
would like to block the IP on all four of them. I could script something to
login to each and run the firewall block there too, but there has to be a
simpler way. Even better, I'd prefer to return a REJECT reason so if a
legitimate user gets blocked, they'd see a useful error as to why they were
blocked.
Appears the "smtpd_client_restrictions" are ran after the SASL is complete.
It works as expected and prohibits the user from sending a message (even
returns my custom REJECT reason), but tells the bot that the AUTH worked,
so they could just try again from another IP.
Using an RBL wouldn't really work in this situation as we use postscreen
and the IP would have already been found good and marked as "PASS OLD" on
the server in question. It could work on the other mail servers, but we
share postscreen caches between them.
Using "smtpd_sasl_exceptions_networks" sort of works for this as it doesnt
advertise the AUTH capability, but it'll still accept it and tell the user
if the login credentials worked if they attempt to use AUTH.
Any other suggestions for returning useful REJECT reasons while restricting
SASL authentication?
Thanks,
-c
wondering if there's an easy way to block access to specific IPs prior to
SASL authentication?
I can grab the IP easy enough via fail2ban and block it on the firewall of
the local machine, but I run a cluster of multiple inbound servers and
would like to block the IP on all four of them. I could script something to
login to each and run the firewall block there too, but there has to be a
simpler way. Even better, I'd prefer to return a REJECT reason so if a
legitimate user gets blocked, they'd see a useful error as to why they were
blocked.
Appears the "smtpd_client_restrictions" are ran after the SASL is complete.
It works as expected and prohibits the user from sending a message (even
returns my custom REJECT reason), but tells the bot that the AUTH worked,
so they could just try again from another IP.
Using an RBL wouldn't really work in this situation as we use postscreen
and the IP would have already been found good and marked as "PASS OLD" on
the server in question. It could work on the other mail servers, but we
share postscreen caches between them.
Using "smtpd_sasl_exceptions_networks" sort of works for this as it doesnt
advertise the AUTH capability, but it'll still accept it and tell the user
if the login credentials worked if they attempt to use AUTH.
Any other suggestions for returning useful REJECT reasons while restricting
SASL authentication?
Thanks,
-c