(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.
CCing oremj who can tell us if this is feasible.
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.
(In reply to comment #2) > wait, you can modify files from the admin panel? Not that I know of, no.
(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.
(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.
If VPN users are hitting the public IP it won't be possible to identify them.
(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.
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?
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.
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.
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.
We fixed this in bug #831132. The admin/ pages are all behind an LDAP auth now.
These bugs are all resolved, so I'm removing the security flag from them.