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

[Lindsay Haisley]

On Mon, 2018-04-16 at 11:06 -0700, Mark Sapiro wrote:
> On 04/16/2018 10:45 AM, Lindsay Haisley wrote:
> > 
> > Apache will log the access, with IP addresse, but to the best of my
> > knowledge it won't log a Web UI login failure since this is an internal
> > matter for Mailman.
> 
> 
> As I said in my prior reply,

Sorry, Mark. I've been running about and missed your reply.

>  all Mailman login failures return a 401
> status. Just look in the Apache logs for Mailman URLs with a 401 status.

In which case, fail2ban should be able to parse these from log files
quite reliably. It's a very effective security tool which parses log
files of your choice, looking for strings (by regular expression) of
your choice, and writes rules to the system firewall (via iptables in
the case of Linux). Your challenge with fail2ban is writing the search
rules. fail2ban allows very flexible criteria for determining what
constitutes an attack, how long a blocking rules should last, etc. I
use it for many kinds of attacks and probes such as ssh brute force
attacks, Apache attempts to access non-existent pages, WordPress login
failures (via the "Fail2ban Redux" plugin), FTP login failures, and a
couple of others. As along as there's a log file which provides a basic
unique failure string, and an IP address source for the failure,
fail2ban will manage blocking. 

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

On 04/16/2018 10:45 AM, Lindsay Haisley wrote:
> 
> Apache will log the access, with IP addresse, but to the best of my
> knowledge it won't log a Web UI login failure since this is an internal
> matter for Mailman.


As I said in my prior reply, all Mailman login failures return a 401
status. Just look in the Apache logs for Mailman URLs with a 401 status.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[tlhackque via Mailman-Users]

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 

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

[Lindsay Haisley]

On Mon, 2018-04-16 at 13:26 -0400, Robert Heller wrote:
> > > Is there anything / feature that Mailman has that can be used to
> > > watch/monitor it?
> > 
> > A related question would be whether there's any way to correlate failed
> > web UI login attempts with IP addresses. It doesn't appear that at
> > present Mailman 2 logs failed web UI attempts at all, although I may be
> > missing something.
> 
> They might be in Apache's logs.

Apache will log the access, with IP addresse, but to the best of my
knowledge it won't log a Web UI login failure since this is an internal
matter for Mailman.

The connecting IP address is available in the environment to any web
application and it shouldn't be difficult to set up logging for login
failures.

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Robert Heller]

At Mon, 16 Apr 2018 09:46:21 -0500 fmo...@fmp.com wrote:

> 
> On Sun, 2018-04-15 at 22:53 +, Steven Jones wrote:
> > We are currently under brute force attack on our mailman server's web
> > ui.
> > 
> > 
> > Is there anything / feature that Mailman has that can be used to
> > watch/monitor it?
> 
> A related question would be whether there's any way to correlate failed
> web UI login attempts with IP addresses. It doesn't appear that at
> present Mailman 2 logs failed web UI attempts at all, although I may be
> missing something.

They might be in Apache's logs.

> 
> If this were possible, a system-level utility such as fail2ban could be
> used to monitor logs and establish kernel filter rules to block these
> IPs.
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

On 04/16/2018 07:46 AM, Lindsay Haisley wrote:
> 
> A related question would be whether there's any way to correlate failed
> web UI login attempts with IP addresses. It doesn't appear that at
> present Mailman 2 logs failed web UI attempts at all, although I may be
> missing something.


Mailman responds to invalid login attempts from the admin, admindb,
options and private CGIs with a 401 Unauthorized status. These are (or
should be) logged by the web server along with the IP address and other
info.

In addition, if a list's membership is private, i.e. available only to
members or the admin, failed attempts to log in to the options page or
obtain a password reminder are logged by Mailman in the mischief log,
but only login failures have the IP address.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Lindsay Haisley]

On Sun, 2018-04-15 at 22:53 +, Steven Jones wrote:
> We are currently under brute force attack on our mailman server's web
> ui.
> 
> 
> Is there anything / feature that Mailman has that can be used to
> watch/monitor it?

A related question would be whether there's any way to correlate failed
web UI login attempts with IP addresses. It doesn't appear that at
present Mailman 2 logs failed web UI attempts at all, although I may be
missing something.

If this were possible, a system-level utility such as fail2ban could be
used to monitor logs and establish kernel filter rules to block these
IPs.

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[David Gibbs]

On 4/15/2018 5:53 PM, Steven Jones wrote:

We are currently under brute force attack on our mailman server's web
ui.

Is there anything / feature that Mailman has that can be used to
watch/monitor it?


Can you elaborate on how they are attacking?

If it's a detectable pattern, I suggest you investigate fail2ban (as Christian 
suggested).

david

--
IBM i on Power Systems: For when you can't afford to be out of business!

I'm riding 615 miles (Yes, you read that right) in the American Diabetes 
Association's Tour de Cure to raise money for diabetes research, education, 
advocacy, and awareness.  You can make a tax deductible donation to my ride by 
visiting https://gmane.diabetessucks.net.

You can see where my donations come from by visiting my interactive donation 
map ... https://gmane.diabetessucks.net/map (it's a geeky thing).

I may have diabetes, but diabetes doesn't have me!

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [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 

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

[mailman-admin]

Hi

Am 16.04.2018 um 00:53 schrieb Steven Jones:
> Hi,
> 
> We are currently under brute force attack on our mailman server's web ui.
> Is there anything / feature that Mailman has that can be used to 
> watch/monitor it?
> Sadly I think we'll have to remove it off the Internet.
> 
> 

This is not a mailman specific problem.

Brute Force attempts can only be mitigated by e.g. fail2ban.
It monitors your log files and will block access for IPs that try to
login too often with invalid credentials for a short time.
This will only catch IPs which try multiple times.
A DDoS with constantly changing IPs will still hurt you.


Kind regards,
Christian Mack
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org