starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Login rate limits to prevent bruteforce #4664

New Issue
Closed
opened 2025-12-29 19:19:17 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:19:17 +01:00
Owner
Copy Link

Originally created by @anthonyryan1 on GitHub (Mar 16, 2021).

NetBox version

2.10.6

Feature type

New functionality

Proposed functionality

Introduce the use of django-axes and some basic configuration
options to rate limit invalid logins. By default we are going
to have a 6 hour login ban after 3 failed attempts.

Use case

Rate limiting invalid logins will protect netbox from possible login brute force attacks.

Database changes

Migration automatically introduces the django axes rate limiting tables.

External dependencies

django-axes

I have a pull request ready to go pending approval.

Originally created by @anthonyryan1 on GitHub (Mar 16, 2021). ### NetBox version 2.10.6 ### Feature type New functionality ### Proposed functionality Introduce the use of django-axes and some basic configuration options to rate limit invalid logins. By default we are going to have a 6 hour login ban after 3 failed attempts. ### Use case Rate limiting invalid logins will protect netbox from possible login brute force attacks. ### Database changes Migration automatically introduces the django axes rate limiting tables. ### External dependencies django-axes I have a pull request ready to go pending approval.
adam added the type: featurepending closure labels 2025-12-29 19:19:17 +01:00
adam closed this issue 2025-12-29 19:19:17 +01:00
adam commented 2025-12-29 19:19:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 17, 2021):

The additional complexity and risk this would introduce would appear to outweigh the limited benefit, particularly considering that most NetBox deployments are not publicly accessible and therefore far less vulnerable to brute force attacks. Further, where this is needed, it can likely be sufficiently addressed in the HTTP frontend server configuration.

@jeremystretch commented on GitHub (Mar 17, 2021): The additional complexity and risk this would introduce would appear to outweigh the limited benefit, particularly considering that most NetBox deployments are not publicly accessible and therefore far less vulnerable to brute force attacks. Further, where this _is_ needed, it can likely be sufficiently addressed in the HTTP frontend server configuration.
adam commented 2025-12-29 19:19:18 +01:00
Author
Owner
Copy Link

@anthonyryan1 commented on GitHub (Mar 17, 2021):

While you are certainly correct that most NetBox deployments will not be publicly accessible, I believe there is still merit to developing precautions for all instances.

With more people working remotely, there is a higher risk of companies making the decision to expose their NetBox instances to the public internet. Companies expose similar django applications to the public internet every day without incident, and may expect NetBox to be similarly prepared.

For the companies that place NetBox behind a company VPN or similar, there still remains an argument that the overall system is more secure if there are multiple redundant layers of protection. That way if a flaw or misconfiguration leaves one layer of protection inert there are additional layers before sensitive company information is at risk. Defense in depth.

In terms of new complexity for NetBox, I believe the amount of complexity I would be introducing to NetBox is relatively small. django-axes is a popular middleware for adding this functionality into any django application with only a couple of lines in settings.py. A working patch is available here for you to check the line count and complexity: 660d5e4e8a

@anthonyryan1 commented on GitHub (Mar 17, 2021): While you are certainly correct that most NetBox deployments will not be publicly accessible, I believe there is still merit to developing precautions for all instances. With more people working remotely, there is a higher risk of companies making the decision to expose their NetBox instances to the public internet. Companies expose similar django applications to the public internet every day without incident, and may expect NetBox to be similarly prepared. For the companies that place NetBox behind a company VPN or similar, there still remains an argument that the overall system is more secure if there are multiple redundant layers of protection. That way if a flaw or misconfiguration leaves one layer of protection inert there are additional layers before sensitive company information is at risk. Defense in depth. In terms of new complexity for NetBox, I believe the amount of complexity I would be introducing to NetBox is relatively small. django-axes is a popular middleware for adding this functionality into any django application with only a couple of lines in settings.py. A working patch is available here for you to check the line count and complexity: https://github.com/anthonyryan1/netbox/commit/660d5e4e8aa5ddf7b849f60370de7e5db1ae249d
adam commented 2025-12-29 19:19:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 17, 2021):

You didn't address my second point: Why not simply rate limit calls to the /login URL via the HTTP frontend? This requires zero modifications to NetBox and avoids the introduction of a new dependency.

@jeremystretch commented on GitHub (Mar 17, 2021): You didn't address my second point: Why not simply rate limit calls to the `/login` URL via the HTTP frontend? This requires zero modifications to NetBox and avoids the introduction of a new dependency.
adam commented 2025-12-29 19:19:18 +01:00
Author
Owner
Copy Link

@anthonyryan1 commented on GitHub (Mar 17, 2021):

My objection to addressing this at the webserver is that it increases the likelihood of legitimate login activity being blocked by mistake.

The webserver lacks the knowledge of whether or not a password is valid or not, it merely forwards requests to the application.

My patch using django-axes will allow no more than 3 invalid passwords within a 6 hour window.

If you tried to implement a similar precaution at the webserver level, it would allow a maximum of 3 login POSTs per 6 hour window whether they were successful or not. That makes it possible for a legitimate user to lock themselves out while never submitting an incorrect password. This is much less likely to ever been seen by a legitimate user if we only count invalid passwords towards rate limiting.

@anthonyryan1 commented on GitHub (Mar 17, 2021): My objection to addressing this at the webserver is that it increases the likelihood of legitimate login activity being blocked by mistake. The webserver lacks the knowledge of whether or not a password is valid or not, it merely forwards requests to the application. My patch using django-axes will allow no more than 3 invalid passwords within a 6 hour window. If you tried to implement a similar precaution at the webserver level, it would allow a maximum of 3 login POSTs per 6 hour window whether they were successful or not. That makes it possible for a legitimate user to lock themselves out while never submitting an incorrect password. This is much less likely to ever been seen by a legitimate user if we only count invalid passwords towards rate limiting.
adam commented 2025-12-29 19:19:19 +01:00
Author
Owner
Copy Link

@dreng commented on GitHub (Mar 20, 2021):

Such functionality should always be implemented within the authentication backend which may pass an error state. Does your solution consider that LDAP authentication is a supported method in netbox?

Furthermore, 3 attempts and a 6 hours ban seems to be a bit arbitrary. As this opinion varies from case to case it should be an individual option in the preferences.

@jeremystretch I generally agree to your point, but it is never a good idea to not consider a security risk because of being non public. There are many reasons why an employee would want to break into a local system.

@dreng commented on GitHub (Mar 20, 2021): Such functionality should always be implemented within the authentication backend which may pass an error state. Does your solution consider that LDAP authentication is a supported method in netbox? Furthermore, 3 attempts and a 6 hours ban seems to be a bit arbitrary. As this opinion varies from case to case it should be an individual option in the preferences. @jeremystretch I generally agree to your point, but it is never a good idea to not consider a security risk because of being non public. There are many reasons why an employee would want to break into a local system.
adam commented 2025-12-29 19:19:19 +01:00
Author
Owner
Copy Link

@anthonyryan1 commented on GitHub (Apr 17, 2021):

Such functionality should always be implemented within the authentication backend which may pass an error state. Does your solution consider that LDAP authentication is a supported method in netbox?

I haven't explored the interaction with LDAP (yet). My research so far indicates that the LDAP server is generally responsible for implementing all login security so I would need to verify that django-axes can be set to not apply to LDAP logins.

Furthermore, 3 attempts and a 6 hours ban seems to be a bit arbitrary. As this opinion varies from case to case it should be an individual option in the preferences.

It is arbitrary, but intended to provide a sane default. I believe I have already made it configurable by adding AXES_FAILURE_LIMIT and AXES_COOLOFF_TIME in settings.py

I have also rebased my patch today: fc1731606a

Finally, and not specific to your comment. I'm a little surprised by the response here. I can certainly respect wanting to keep the dependency list small, but this feels like an outright knee-jerk reaction against a rather unobtrusive login security improvement. If you can provide me with some suggestions how to make this improvement agreeable to the netbox team I'm happy to make all changes requested (including ensuring LDAP concerns are addressed).

If the stance is final and unanimous, I would appreciate someone on this team closing this issue.

For my own usage I will implement web-server rate limiting, but I remain convinced it's an inferior solution. I will either have to set lax rate limits or risk legitimate employees being locked out of netbox if all logins (as opposed to just failures) contribute to activity rate limits.

@anthonyryan1 commented on GitHub (Apr 17, 2021): > Such functionality should always be implemented within the authentication backend which may pass an error state. Does your solution consider that LDAP authentication is a supported method in netbox? I haven't explored the interaction with LDAP (yet). My research so far indicates that the LDAP server is generally responsible for implementing all login security so I would need to verify that django-axes can be set to not apply to LDAP logins. > Furthermore, 3 attempts and a 6 hours ban seems to be a bit arbitrary. As this opinion varies from case to case it should be an individual option in the preferences. It is arbitrary, but intended to provide a sane default. I believe I have already made it configurable by adding AXES_FAILURE_LIMIT and AXES_COOLOFF_TIME in settings.py I have also rebased my patch today: https://github.com/anthonyryan1/netbox/commit/fc1731606a47eb52eb32d6db22f0e8e3e5e3d7f8 -------- Finally, and not specific to your comment. I'm a little surprised by the response here. I can certainly respect wanting to keep the dependency list small, but this feels like an outright knee-jerk reaction against a rather unobtrusive login security improvement. If you can provide me with some suggestions how to make this improvement agreeable to the netbox team I'm happy to make all changes requested (including ensuring LDAP concerns are addressed). If the stance is final and unanimous, I would appreciate someone on this team closing this issue. For my own usage I will implement web-server rate limiting, but I remain convinced it's an inferior solution. I will either have to set lax rate limits or risk legitimate employees being locked out of netbox if all logins (as opposed to just failures) contribute to activity rate limits.
adam commented 2025-12-29 19:19:19 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 17, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 17, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4664
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?