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

[tlhackque]

On 16-Apr-18 07:38, Rich Kulawiec wrote:
> 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.
Good advice.� But use httpS: (and make sure the UA validates the server
certificate).
Unless you fancy experimenting with DOS attacks.
> 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.)
Yup.� And iran and afghanistan & the other former soviet countries.

But the biggest source of attacks, by far, is the US.� Unfortunately,
while some people run business that don't interact with the US, in most
cases a non-country based approach is necessary for that :-)

> 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.
If you have iptables, you also might want to look at
https://github.com/tlhackque/BlockCountries
A new release that provides better management is overdue -- but
hopefully soon.

BlockCountries manages the by-country blocking, and the next release
will support
fetching the spamhaus (and other) non-country lists.� It handles both
the "block these" and
"permit only these" paradigms, and does a fair amount of optimization of
the rulesets.� It
also handles IPv6 & has a bunch of options that let you avoid most of
the hassle of working
directly with iptables for exceptions.

You do need to be careful to balance reducing your attack surface with
your business' need for
access.� Also, be aware that the "by-country" blocking lists of ipdeny
come from the regional
registries.� They are not exact.� They don't necessarily reflect the
server's actual current
physical location for a number of reasons.� But they are a reasonable
approximation.� Just
be sure that you have an easy way to introduce exceptions when one of
your customers
is blocked.

I also recommend https://zeustracker.abuse.ch/blocklist.php
(add?download=badips for the data).

>
> 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.
The best defense for ssh is to configure it for certificate
authentication only.
The script kiddies will make their 10,000 login attempts - while they're
busy annoying
you, they're not attacking someone else.� Or so one hopes.�� fail2ban is
also useful if
you're not so civic minded...

[I'm not kidding; I do see lists of 10K+ attempts from "adam adam",
"adam password" thru "zeke password" "zeke zeke"...]

If you keep up your lists of cloud services' network blocks & have them
on a publicly accessible
website, I'll add them to my list of optional block lists.� (Hopefully
you use a standard format - e.g.
ipaddress[/netmask or length] with # or ; comments...)

> 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.
Whatever lists you use, it's really important to stay up to date.� (I
generally
recommend weekly or monthly.)� The attackers are mobile and adapt.� That
cuts both ways: if you block a specific attack today, tomorrow they may
well have
moved to another host.� Then you have to block them again.� And, the
block that they
vacate may be assigned to a legitimate use - that you don't want to block.

Be very careful not to block your customers or users; it is easy to be
overly aggressive, which
can be career limiting.

> 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
>
Sadly, this is true.� However, e-mail to abuse@<provider> can be
effective if you provide
details...

-- 
This communication may not represent my employer's views,
if any, on the matters discussed.