On 2022-02-19 at 06:43:59 UTC-0500 (Sat, 19 Feb 2022 12:43:59 +0100)
Emmanuel BILLOT <gaia45...@gmail.com>
is rumored to have said:
Hi,
We have SMTPS server with SASL auth fro posting messages from external
networks (internal xtoo). Since weeks we found a lot (very big) amount
of
SASL LOGIN authentication failed: authentication failure
in our logs.
Client IPs are foreigns and not real client.
1 - is it a brut force attack ? Or a DDOS ?
Probably neither.
DDoS using SASL auth attempts for SMTP would be extremely inefficient.
DDoS attacks usually leverage UDP reflection to avoid source detection
and amplification of higher level protocols like NTP and DNS.
There are so many leaked email+password combinations available in the
illegal market that "brute force" password guessing is rare. It is much
more likely that they are trying usernames and passwords that are known
to be good somewhere. The goal is to compromise accounts so that they
can be used for spamming and/or to leverage for more complex attacks.
This is often called "credential stuffing."
2 - what postfix directive should we use to stop it ?
There is no magic in Postfix to stop this.
You can reduce the attack surface of Postfix by only enabling SASL
authentication on ports 465 and 587, never on port 25. This allows you
to narrow the range of IP addresses you allow to contact the ports that
offer authentication at all. The most common advice for this is to use
"fail2ban," a tool which monitors logs and reacts to attacks by blocking
attackers, usually via the local packet filter (iptables, nftables,
ipfw, pf, etc., depending on your platform.) There are alternative tools
that operate in similar ways if fail2ban is not to your tastes.
We have listed all IPs. We can use a FW rule, but its heavy and hard
to
manage. A Postfix list may be easier.
On Linux, using ipsets instead of putting IPs directly in rules helps a
lot with managing large lists. Fail2ban can do its work via ipsets.
An alternative to fail2ban and its workalikes is to more manually
identify where your legitimate authentication traffic comes from and
where it will never come from. Most of the IPs used for credential
stuffing attacks are not associated with any end users or processes that
would ever do any legitimate email submission anywhere, e.g. AWS
instances, Digital Ocean Droplets, etc. You can safely refuse all port
465 and 587 traffic from huge swathes of the IPv4 space, if you are not
a global mailbox provider.
Whether you use fail2ban or do manual one-by-one blocking or use your
logs to figure out broad boundaries between networks you'll allow to try
to submit mail and ones you will not, the better place to do this is at
the network layer, not Postfix. It is unlikely for a single credential
stuffer to overwhelm your system, but they can cause resource problems
in aggregate and that's much less likely if you're not even bothering to
do a TCP session initiation.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
