On 22 Sep 2019, at 18:50, Daniel Miller wrote:
On 9/22/2019 12:59 PM, Bill Cole wrote:
[...]
If you do use a manual local blacklist for this (as I do on my
personal system) it is most useful to apply it at the network level:
either in your router/firewall or in a host-local packet filter (e.g.
iptables, ipfw, etc) because rejecting auth attempts at the
application level is relatively heavy compared to dropping SYNs. If
your user population is relatively small and homogeneous (e.g. a
family or small business mail system) you can block *almost* all of
the Internet from port 587 and 465 with no damage. Even if you need
to support "road warrior" users who might log in from anywhere in the
world, there are still some very large networks that host lots of
credential-stuffers and no legitimate mail submission or IMAP users
than can be blocked safely to good effect: AWS, Azure, GCP, Digital
Ocean, etc.
I totally concur that if an IP deserves blocking for one service it
generally does so for all - anyone attempting to brute-force any
service on my server has no need to ever touch it again.
I wasn't actually saying that and it's surprisingly not always true.
Often the machines that are used for high-volume auth attacks are
compromised machines with legitimate functions, such as web servers.
I was hoping to make a much narrower point: that services which are
strictly for your own users don't need to be accessible from anywhere on
the Internet, but only from the networks your users are on. The obvious
examples are geographic. For example, if your users never travel to
Russia, you can safely block port 587 & 465 traffic from Russia, even if
you still want to be able to accept email from Russia to your users
(i.e. on port 25 SMTP.)
Is there a "simple" table of such "credential-stuffer" network
addresses I can load on my router for blocking?
Unfortunately, no. There is an additional problem that some networks
with a substantial number of credential-stuffing machines (e.g. Comcast,
AT&T, Deutsche Telekom, Orange, etc.) are the same sorts of networks
that a mail system could have legitimate users on. So while I can block
mail client ports from a Comcast /11 network and an AT&T /8 on my
personal system, I cannot do that for the business systems I support
because they have users on those retail connection providers. On the
bright side, there's not a lot of churn in the networks that are
significant problems, so once you have identified the sources of garbage
traffic for your system, you shouldn't have much ongoing maintenance to
do.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
