599915 - Disable public access to input.m.c/admin

Status: RESOLVED FIXED

(Input :: General, defect)

Description

[David Chan [:dchan]]

(Copy-paste from other bugs mcoates has filed.)

The django admin page is publicly accessible at the following url:

https://input.mozilla.com/admin/

An attacker could attempt to guess or brute force the credentials to this page.
If successful the admin page provides the ability to modify files that could
result in site instability or the introduction of attacks for other users.


Recommended Remediation

Restrict access to /admin/ to internal Mozilla connections only.

Comment 1

[Fred Wenzel [:wenzel]]

CCing oremj who can tell us if this is feasible.

Comment 2

[Reed Loden [:reed]]

wait, you can modify files from the admin panel? As in, files that are executed by the web server? If so, that sounds like a huge problem in itself, though separate from this bug.

As for this bug, in general, I'm against such outright blocks like what is proposed in comment #0. It's very anti-community, as community members who are trusted wouldn't be able to access admin panels. One example of this is crash-stats, which is used by multiple products and requires non-MoCo people to have admin access to it.

Comment 3

[Fred Wenzel [:wenzel]]

(In reply to comment #2)
> wait, you can modify files from the admin panel?

Not that I know of, no.

Comment 4

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to comment #2)
 
> As for this bug, in general, I'm against such outright blocks like what is
> proposed in comment #0. It's very anti-community, as community members who are
> trusted wouldn't be able to access admin panels. One example of this is
> crash-stats, which is used by multiple products and requires non-MoCo people to
> have admin access to it.

The purpose is not to prevent community members access to sites that they need. There is no question that trusted individuals should have access to necessary admin panels.  The problem is publicly exposing an admin panel that uses a single factor of authentication.  

The simplest way to minimize the threat of external brute force attacks is to not publicly expose the admin login to the internet.  This is my preferred approach.  Trusted community members that need admin access could then vpn in as needed to access this page.

Comment 5

[Fred Wenzel [:wenzel]]

(In reply to comment #4)
> The simplest way to minimize the threat of external brute force attacks is to
> not publicly expose the admin login to the internet.

I'm on board. Which is why I CCed IT to find out if that's even possible to limit distinct paths to VPN-only.

If so, we should probably do it for all our Django apps.

Comment 6

[Jeremy Orem [:oremj]]

If VPN users are hitting the public IP it won't be possible to identify them.

Comment 7

[Reed Loden [:reed]]

(In reply to comment #4)
> Trusted community members that need admin access could then vpn in
> as needed to access this page.

Except community members are rarely (if ever?) given VPN access. That solution just won't work.

So, I'm all for better security (it's my day job and passion after all), but if *everything* starts getting put behind VPN without some process in place to allow community members access to stuff, you're just going to cause even more tension between the two groups (MoCo and the community). Maybe IT should look into setting up a community VPN that would allow non-MoCo folks access to things while still protecting the rest of the Mozilla network, especially if this is going to start being commonplace for all our apps.

Comment 8

[matthew zeier [:mrz]]

I'm not interested in supporting a larger community of users with openvpn.  It's difficult to support just internally.  

What's the solution if you still need external access to that URL and I don't what it VPN-only?

Comment 9

[David Chan [:dchan]]

Sorry for the confusion in the bug. I didn't read closely enough when copying the bug over. As far as I can tell, the specific admin view for input allows the admin to "recluster" the search groups and view certain non-sensitive django configuration settings. In this case, I don't believe there is any need for the admin page to be externally accessible.

Another approach to consider is implementing a django library that can handle access controls to the admin interface. There would have to be logging features and account lockout policies. If you guys believe this is worthwhile, I can look at what is out there and work toward improving/implementing this library.

Comment 10

[Chris Lyon [:clyon]]

Can we add in logging and intelligence to the admin side of django to detect and prevent brute force attempts? 

It seems if this is our concern, we should be able to reduce this risk if we add in some intelligence. 

So +1 on lock out but if we don't have any tie into ArcSight, this would be pointless.

Comment 11

[David Chan [:dchan]]

iirc, the admin page needs to be externally accessible. In that case, I think we can close this bug since a VPN solution won't work.

Comment 13

[Will Kahn-Greene [:willkg] ET needinfo? me]

We fixed this in bug #831132. The admin/ pages are all behind an LDAP auth now.

Comment 14

[Will Kahn-Greene [:willkg] ET needinfo? me]

These bugs are all resolved, so I'm removing the security flag from them.