Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking access or removing default Django endpoints in production #29

Open
MikeTheCanuck opened this issue Feb 28, 2017 · 6 comments
Open

Comments

@MikeTheCanuck
Copy link
Collaborator

MikeTheCanuck commented Feb 28, 2017

Let's assume for the moment that we enable the default Django endpoints (by running the python3 manage.py migrate command during Docker build , which enables for example the /admin endpoint).

Assuming these are not desired or secure to run in cloud (Integration/Production), it would be good to have an actual strategy for mitigating their exposure.

Ideally disabling them entirely in Django would be good. If that can't be done (and so far Django's docs aren't helping), then blocking access from the Internet is next best - either by putting a routing filter in place in the container (gunicorn?), or some kind of container policy if possible, or EC2 security policy that blocks requests from even getting into the container.

@mxmoss
Copy link
Contributor

mxmoss commented Feb 28, 2017

Hi,
It looks like the recommended way to disable Django's admin is to
a) disable the admin module in settings.py
b) remove or redirect the /admin URL

Here's an example of a)
---settings.py---
INSTALLED_APPS = [
# 'django.contrib.admin', <== admin is commented out
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'myapp',
]
---settings.py---

Here's an example of b)
---urls.py---
#ADMIN_ENABLED is in settings.py
if settings.ADMIN_ENABLED:
urlpatterns += patterns('',
(r'^admin/(.*)', include(admin.site.urls)), <== admin is only accessible when enabled
# ..maybe other stuff you want to be dev-only, etc...
)
---urls.py---

Sources:
http://stackoverflow.com/questions/4845239/how-can-i-disable-djangos-admin-in-a-deployed-project-but-keep-it-for-local-de
https://www.reddit.com/r/django/comments/3tluxf/is_it_advisable_to_disable_the_admin_module_in/
https://docs.djangoproject.com/en/1.10/ref/contrib/admin/

Here's an article on allowing admin, but keeping the URL obscure
http://www.jw.pe/blog/post/security-through-obscurity-django-admin-interface/
The best takeaway from this? create a honey pot /admin/ endpoint to catch potential intruders

Again, I'd suggest that we should migrate the database extensions for admin.

@hassanshamim
Copy link
Collaborator

hassanshamim commented Feb 28, 2017

Assuming these are not desired or secure to run in cloud

It is secure - though a quick way to make it 100% secure without writing/deleting any code is to simply not create any admin users.

Also I'm fine with changing the /admin/ route but security through obscurity is an antipattern

@mxmoss
Copy link
Contributor

mxmoss commented Mar 1, 2017

@hassanshamim yeah, I'm not supporting the security through obscurity. The only reason I included that article was because of the honeypot idea.

@MikeTheCanuck
Copy link
Collaborator Author

MikeTheCanuck commented Mar 1, 2017

Every piece of added functionality is secure...until someone finds another exploit for it. https://cve.mitre.org/

I come at these things from the perspective of "if we don't have an actual, present need for the functionality in the target environment, get rid of it and resurrect it when we need it". Secure by Default. Let's find out if removing it breaks anything now, before we run out of runway to see the implications of these changes. And when we identify a real usage for the functionality, it's always possible to reconfigure the build to turn stuff back on.

To me that's the beauty of the devops model (infrastructure as code) - just remove/twiddle the bits that made the change, and revert to previous behaviour. In fact, by documenting the changes we make associated with this discussion, we can reduce the barriers to re-enabling this (and especially, for leaving a trail for those crazy folks (looks at self) who take responsibility for the change in the first place).

@smithjd
Copy link

smithjd commented Mar 1, 2017

HI guys, I wanted to thank you for your public discussions of the host of issues in this project. I know I'm not contributing much currently, but I'm watching and reading and I have to think that learning from y-all will be useful -- eventually, somehow.

@joelwembo
Copy link

You can create a custom middleware to restrict access based on IP. Place this code in a file like middleware.py in one of your apps. This setup will ensure that only requests from your VPN or allowed IP addresses can access the Django admin interface, thereby adding an extra layer of security. Hide your Django admin panel using Custom VPN from terraform

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants