Discussion:
Blocking access before SASL
(too old to reply)
CBL
2015-06-13 16:26:46 UTC
Permalink
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
Wietse Venema
2015-06-13 23:02:35 UTC
Permalink
Post by CBL
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?
There is no smtpd_sasl_restictions feature, and it is unlikely to
be implemented.

Instead, use postscreen. It blocks clients before they are allowed
to talk to a Postfix SMTP server.

/etc/postfix/main.cf:
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = ...your DNSBL server here...

You can use rbldnsd to run your own DNSBL server.

Wietse
Benny Pedersen
2015-06-13 23:33:37 UTC
Permalink
Post by Wietse Venema
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = ...your DNSBL server here...
could postscreen be extended to sqlite dnsbl sites ?, to slow ?

i thinking fail2ban update sqlite based on auth on port 25 fails, saves
running rbldns
Post by Wietse Venema
You can use rbldnsd to run your own DNSBL server.
why when postfix supports so many good db backends ?
Noel Jones
2015-06-14 04:06:49 UTC
Permalink
Post by Benny Pedersen
Post by Wietse Venema
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = ...your DNSBL server here...
could postscreen be extended to sqlite dnsbl sites ?, to slow ?
The postscreeen_access_list can use any supported DB type, but not
all types make sense here. Speed is a primary concern, but not the
only concern. CIDR tables are (strongly) recommended, but not required.
Post by Benny Pedersen
i thinking fail2ban update sqlite based on auth on port 25 fails,
saves running rbldns
Post by Wietse Venema
You can use rbldnsd to run your own DNSBL server.
why when postfix supports so many good db backends ?
The question was about sharing blacklist data among several servers.
A local DNSBL is by far the easiest and likely best performing of
the available choices. A DNSBL also allows a custom reject message
-- another of the OP's requests, and not supported with
postscreen_access_list.



-- Noel Jones
CBL
2015-06-14 05:17:20 UTC
Permalink
Post by Wietse Venema
Instead, use postscreen. It blocks clients before they are allowed
to talk to a Postfix SMTP server.
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = ...your DNSBL server here...
You can use rbldnsd to run your own DNSBL server.
Any easy way of expiring individual entries in the postscreen cache? My
concern is if I add the SASL abuser to a custom DNSBL after they've already
been checked by postscreen from the original attempt(s), it'd still "PASS
OLD" them until their entry in the cache expires.

Thanks.
Wietse Venema
2015-06-14 13:18:44 UTC
Permalink
Post by CBL
Post by Wietse Venema
Instead, use postscreen. It blocks clients before they are allowed
to talk to a Postfix SMTP server.
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = ...your DNSBL server here...
You can use rbldnsd to run your own DNSBL server.
Any easy way of expiring individual entries in the postscreen cache? My
concern is if I add the SASL abuser to a custom DNSBL after they've already
been checked by postscreen from the original attempt(s), it'd still "PASS
OLD" them until their entry in the cache expires.
postscreen_dnsbl_ttl = 60s

Wietse

Loading...