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

Reply via email to