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

[tlhackque]

On 19-Apr-18 23:33, Stephen J. Turnbull wrote:
> tlhackque via Mailman-Users writes:
>
>  > I'm not sure what you are looking for.
>
> I'm looking for anything that will help block swaths of Chinese
> spammers and possibly attacks, while allowing me to do a better job of
> serving students vacationing at home in China than treating them the
> way the Chinese government does.  A unicorn, or failing that, a pony.
So you know exactly who your users are, and can pre-register them while
they are
not in China.

Geographic IP address is the wrong hammer for this nail.
Block the country, open pinholes for the users.

> No, I want to identify good actors and block the rest.  The problem
> I've had in the past is that I can't depend on static IPs because I'm
> dealing with people using telephones, mostly.
GeoIP will never get you down to the level of granularity and accuracy
that you want.
Even if it did, people with phones move - apartment, coffee shop, etc. 
>  > One option is to provide a website for registering your users, then
>  > allow them access via some convenient token.
>
> I'm not sure what you're suggesting.  That's what is being attacked
> here.
If you're seeing webserver attacks, you'll also see mailserver AUTH
attacks. I assumed both.

It's easier to protect a website than a mailserver.  Plus, registration
is a one-time activity.
And in your scenario, you can block all of China, since you can register
your students while
they are at your school (which presumably is not in China).

So use the registration website to issue an X.509 certificate, register
a hardware token, issue fwknop
key - whatever you choose as your token (credential).  Then use that
token to protect routine access to the mailman web ui AND mail servers.

Even if you allow registration from China, you can make the registration
website available
at limited times.  E.g. odd days of the month from 1341 to 1417.  This
drastically reduces
your attack surface.  You tell your users the algorithm for when they
can use it to register,
or more likely, invalidate a lost key & get a new one, etc.  Change it
every semester.


>  > Or provide a VPN (with just your web or email server as an
>  > endpoint).
>
> I believe the Chinese have outlawed VPNs, I assume they allow TLS
> still, though, given the size of ecommerce there.
I believe you are correct.  They may use spoofing on TLS, so unless you
use some form of pinning, assume MITM. 
>  > Or use X.509 client authentication  - note that you can use this
>  > with your mailserver.
>
> That's an interesting idea, but again my users will be mostly using
> phones, so I don't think this will work with mail very well, and I'm
> not sure how to set that up on a phone.
Mobile MUAs not my area of expertise, but it ought to be possible.  Both
sendmail and postfix allow it to be configured.
Even if you don't have a native MUA, you can provide a web-based e-mail
account on your server for your users - e.g. squirrelmail, roundcube,
etc.  Put client auth on that (easy); allow that server access to your
e-mail server, perhaps just on localhost.  Mobile web browsers certainly
support x.509 client auth.  If you go this route, you only need to open
a TLS port; you don't need IMAP/POP3/SMTP/Submission.  You will still
get kiddie script attempts, but TLS will block them for lack of a
(valid) client certificate.  These are less common, and combined with
fail2ban should work reasonably well.

From your revised description, fwknop seems to be a good choice.  It's
cheap, transparent, easy to setup, and should traverse the great
firewall.  (No direct experience, but the technology is hard to block,
especially if you overlay it on a web or mail server.)  You can use it
to protect both. 

Issue their keys before they go home, and you're done.  Optionally,
provide some form of recovery/reissue for the "I lost my phone" case. 
Or just say "don't lose your phone; if you do, you're out of luck for
the rest of your trip."

Providing an e-mail service as outlined above is more expensive, but
provides an additional service for your users.

In any case, I think we've probably exhausted the patience of
mailman-users since we're off into the general problem of keeping our
servers alive in the jungle...

Good luck.