hackoregon / team-budget

Repo for the Budget team's backend code
MIT License
6 stars 4 forks source link

Blocking access or removing default Django endpoints in production #29

Open MikeTheCanuck opened 7 years ago

MikeTheCanuck commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

MikeTheCanuck commented 7 years ago

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 commented 7 years ago

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 commented 1 week ago

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