-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
Hi, Here's an example of a) Here's an example of b) Sources: Here's an article on allowing admin, but keeping the URL obscure Again, I'd suggest that we should migrate the database extensions for admin. |
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 |
@hassanshamim yeah, I'm not supporting the security through obscurity. The only reason I included that article was because of the honeypot idea. |
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). |
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. |
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 |
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.
The text was updated successfully, but these errors were encountered: