[Mailman-Users] Brute force attacks on mailman web ui

[Rich Kulawiec]

On Mon, Apr 16, 2018 at 09:08:43AM +0200, mailman-admin wrote:
> Brute Force attempts can only be mitigated by e.g. fail2ban.

Nope.  There are other ways.

Brute force attacks can be pre-emptively blocked by nearly everyone
operating a Mailman instance.  (I say "nearly" for specific reasons
that will become clear below.)

1. You'll need a firewall, either in front of your Mailman instance
or onboard the same system, that can handle a significant number of
IP ranges in CIDR format.  I highly recommend "pf", which is part
of OpenBSD (among others) and is easily the best firewall available.
However, you can do this with other firewalls such as iptables just as readily.

2. Get the Spamhaus DROP (Don't Route Or Peer) list, along with the EDROP list:
	
	http://www.spamhaus.org/drop/drop.txt
	http://www.spamhaus.org/drop/edrop.txt

They're small.  Take a look at them.

The DROP/EDROP lists are well-curated and consist of blocks that are
known to be hijacked and known to belong to malicious actors.  You
should *bidirectionally* block *all* traffic to/from the networks
listed on them: HTTP, SMTP, DNS, everything.

Update them by fetching new copies once a month.

3. The next step depends on the intended audience for your mailing
lists.  If you're operating one for a bowling league in Akron, Ohio,
then you probably don't need to accept subscription attempts from
Peru, Pakistan, or Portugal.  If on the other hand you're operating
one with global reach then you'll need a different approach.

In either case, you'll want ipdeny.com's list of all network blocks
by country:

	http://ipdeny.com/ipblocks/data/countries/all-zones.tar.gz

and you may want the Okean lists of blocks for China and Korea:

	http://www.okean.com/chinacidr.txt
	http://www.okean.com/koreacidr.txt

(In theory, the list of CN and KR blocks in ipdeny's compilation
should exactly match Okean's.  In practice, there are slight differences
that tend to resolve over time.  I think if you're only configuring
for CN and KR, use the latter; if you need more, use the former.
But we'll get to that.)

By the way, if you use these, you should update them once a month
just like the DROP/EDROP lists.

3a. If your list is localized to one country or two or six, then
use the ipdeny data to configure your firewall to block *all* HTTP traffic
to your mailman instance and then only allow traffic from the countries
that you need.  This usually takes a huge bite out of incoming abuse.

3b. If your list is global or nearly so in scope, then block as many
countries as you can.  Look at your logs, see where the attacks are coming
from, see where real subscriptions are coming from, and figure out the
disjoint set. (The utility "grepcidr" is often very helpful.)
If you have, let's say, zero subscriptions from FR over the past
nine years but do have a parade of attacks: firewall it out.

I recommend, in doing this analysis, that you start by looking at CN
and KR.  Why?  Because two decades of careful logging and analysis
of data from quite a few sites indicates that these are #1 and #2 on
the hit parade of attackers.  There's no point in trying to file complaints
in the hope that some responsible professional will take remedial action
and make it stop: just firewall and forget.  (Next on the list are
RU and IN.  Same problems.)

Comment on 3a and 3b:

Yes, this is draconian.  That's a good thing.  Let me quote for you what
I think is arguably the best thing ever said on NANOG, and given the tens
of thousands of years of accumulated network experience represented
there, that's saying a lot:

	If you give people the means to hurt you, and they do it, and
	you take no action except to continue giving them the means to
	hurt you, and they take no action except to keep hurting you,
	then one of the ways you can describe the situation is "it isn't
	scaling well".
		--- Paul Vixie

You can either get to work with a firewall or you can continue to be
a victim.  Choose.

If you want to continue to allow SMTP traffic from these countries
so that users can subscribe/unsubscribe/etc. via mail that's your
call.  I've tailored my configuration to suit the lists that I run
and in some cases, that includes configuring the MTA to deny
traffic from the same ranges as the web server; in others,
it includes denying traffic from the TLD; in others, both.  The key
to all of this is understanding (a) what you need to allow in order
for your lists to function as intended and (b) what your own logs are
telling you about what attacks/abuse are coming from.

4. Supplement this by blocking operations that are unlikely to originate
any valid subscriptions but are likely to originate abuse.  For example,
Amazon's cloud -- due to the negligence and incompetence of the people
running it -- is a notorious source of nonstop brute-force attacks.
They not only refuse to do anything about it, they refuse to even
accept complaints.  So you might want to firewall AWS outright.
(By the way, you most certainly want to block it from any ssh services
you run.)  Digital Ocean is similar.  And there are others.  I have
compiled full/partial network blocks for these if you want them.

Yes, this is also draconian.  But I'm done playing around with
ignorant newbie lusers -- like the ones at Amazon --  who can't
or won't run their networks properly.  And I'm not interested
in pathetic excuses like "we're too big to watch our own network"
or even more feeble ones like "we get too many complaints".   Can't
handle Operations 101?  Shut down the systems, turn off the power,
lock the doors, and go home.  You're. Not. Good. Enough.

5. Supplement all of this with individual blocks as the need arises.
Watch your own logs and look for patterns.  If you want to drop
individual IP addresses into the firewall, sure, but since attacks
generally originate from multiple addresses on a network, it's usually
faster, easier, and more efficient to just plonk entire networks.
I have some of these compiled as well, although the ones attacking
my resources may not be the same as the ones attacking yours.
"whois -h whois.arin.net" is your friend.

Hint: if you watch your logs long enough and pay attention to what's
in them, you'll probably notice that many attack patterns are localized.
One of the quick-and-dirty approaches that is often quite effective
is to assume that each attacking IP address is part of a /24
(even though is might really be a /28 or a /16) and block the
entire putative /24.  Yes, this assumption is often wrong, BUT
it usually doesn't matter if it's wrong, because the goal here is
to stop the attacks from getting through.  (Why a /24?  Because in
some implementations, network blocks that size or larger are handled
more efficiently than smaller ones.  For example, I never block
anything smaller than a /24 in the sendmail access file.)

Folks who've never done this before and haven't looked at their
logs often think this is too much.  It's not.  If you spend enough
time looking at the data, it becomes apparent in most cases that
if you're seeing attacks from one IP address on a network, it's only
a matter of time until the second and third and forty-second show
up.  Might as well block them now and avoid the annoyance.

6. Yes, all of this can be bypassed with proxies and VPNs and Tor
and botnets and and and.  It's not a panacea.  But it does take the
edge off, and that in turn makes the remaining problem more tractable.
If you do this diligently, you'll find that you'll steadily have
less to do.  And pre-emptive blocking like this is vastly more effective
that reactive blocking like fail2ban, if for no other reason than
it makes your logs smaller and easier to deal with.

I wish none of this was necessary.  It *shouldn't* be necessary.
But a lot of operations are run by negligent, incompetent people,
and others are run by people who are deliberately allowing attackers
and abusers to use their networks.  We are well past the time when
asking either of these nicely if just maybe they'd like to show some
professional responsibility and run their networks properly: there is
no point in it.  Firewall and forget.

---rsk