On 24/05/24 01:42, Bill Cole via Postfix-users wrote:
Likely brute force.
Not exactly.
"Brute force" password cracking is almost never seen today, as it has
been replaced by a practice commonly called "credential stuffing" where
the attacker has some large collection of known-good username+password
combinations from another source (e.g. one of the many "breaches" of
online systems) and is simply trying the same combinations on your
system. This is a much more targeted attack and so can be slow enough to
evade rate-limit based protections.
I appreciate the differences you point out and they are relevant, but I
do still consider it a type of brute force attack.
This means that you need more prevention than was needed with classic
brute force. An attacker may not be working from a list of random names
and passwords or from common names and passwords, but from some smaller
list of names and passwords specific to your domain and users, so the
chances of a hit are based on whether your users use the same passwords
everywhere.
Indeed this is a problem that is very difficult to police. At the end
of the day it is extremely difficult to tell if your users share
passwords from an email administration POV and probably not worth the
effort it takes to even come close to preventing it. Trying to educate
your users could be worthwhile, but beyond that ...
All the other suggestions are good, and I would add that in addition to
using Geo-IP data for excluding by country or region, you can
proactively exclude other large blocks at the packet level quite
broadly. The Spamhaus DROP list of criminal-controlled ranges would be
the first step, as you can rely on nothing you want coming from those
ranges. Next, you can look at the IPs which are doing the authentication
probes and find large blocks of cheap hosting from which none of your
users will ever be logging in. For example, you can count on never
seeing legitimate traffic on ports 465 or 587 (or any of the POP and
IMAP ports) from AWS, GCP, Linode, Digital Ocean, OVH, Alibaba, or Azure
network ranges.
This is a good suggestion, but do keep in mind that there can be
legitimate connections from a VPS. It is, however, unlikely that one of
your users would do that and if they do you can always deal with the
situation when it arises.
It is also helpful as a matter of system design to decouple user email
addresses from their login usernames. For example, all of the email
addresses I give to companies are aliases, so none of them are at all
useful if compromised in a breach. The username I use to authenticate to
my mail server cannot be mailed from anywhere but the mail server
itself. This assures that no matter how many systems get breached where
I've got an account, none of those usernames and passwords are useful to
the thieves. I set this up almost 30 years ago as a spam control
measure, but the greatest benefit has been in basic account security.
This is good advice for the email admin personally but increases the
complexity for other users to a point where it's probably not worth it,
imo. To elaborate aliases are great, but trying to reject email to the
primary mailbox address, or trying to force users to pick a different
username to their primary mailbox email address can be problematic.
Peter
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
