[GH-ISSUE #5773] Add Retention Period / Cap for Proxy Events Logs #11959

Open
opened 2026-08-05 01:31:53 -04:00 by saavagebueno · 5 comments
Owner

Originally created by @shaban00 on GitHub (Apr 1, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5773

Is your feature request related to a problem? Please describe.
The Proxy Events log has no retention limit or cleanup mechanism. When the Reverse Proxy authentication is subjected to repeated requests (e.g., from a brute force script cycling through all 6-digit PIN combinations from 000000 to 999999), every single attempt generates a Proxy Event entry. This results in up to 1,000,000 log entries from a single attack session, making the log extremely noisy and effectively useless for monitoring legitimate activity.

Describe the solution you'd like
Add a retention period for Proxy Events logs, so that old entries are automatically purged after a set time (e.g., 30 or 90 days). Optionally, also add a maximum entry cap to prevent unbounded growth regardless of time. This would keep the logs useful and meaningful for administrators.

Describe alternatives you've considered

  • Manually clearing logs — not practical for administrators who rely on event history for auditing.
  • Filtering events in the UI — this would reduce visual noise but wouldn't address the underlying storage growth problem.

Additional context
This issue was discovered while testing the Reverse Proxy authentication feature. A script cycling through all possible 6-digit PINs generated 150,863+ Proxy Events in a single session. While rate limiting on authentication (tracked in a separate issue) would reduce the attack surface, a retention policy is still needed independently to ensure log hygiene under normal and abnormal usage.

Originally created by @shaban00 on GitHub (Apr 1, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5773 **Is your feature request related to a problem? Please describe.** The Proxy Events log has no retention limit or cleanup mechanism. When the Reverse Proxy authentication is subjected to repeated requests (e.g., from a brute force script cycling through all 6-digit PIN combinations from 000000 to 999999), every single attempt generates a Proxy Event entry. This results in up to **1,000,000 log entries** from a single attack session, making the log extremely noisy and effectively useless for monitoring legitimate activity. **Describe the solution you'd like** Add a **retention period** for Proxy Events logs, so that old entries are automatically purged after a set time (e.g., 30 or 90 days). Optionally, also add a **maximum entry cap** to prevent unbounded growth regardless of time. This would keep the logs useful and meaningful for administrators. **Describe alternatives you've considered** - Manually clearing logs — not practical for administrators who rely on event history for auditing. - Filtering events in the UI — this would reduce visual noise but wouldn't address the underlying storage growth problem. **Additional context** This issue was discovered while testing the Reverse Proxy authentication feature. A script cycling through all possible 6-digit PINs generated 150,863+ Proxy Events in a single session. While rate limiting on authentication (tracked in a separate issue) would reduce the attack surface, a retention policy is still needed independently to ensure log hygiene under normal and abnormal usage.
saavagebueno added the feature-request label 2026-08-05 01:31:53 -04:00
Author
Owner

@twocoolbeans commented on GitHub (Apr 2, 2026):

Pruning logs (Audit Events and Traffic Events) is the reason that deployed Pangolin over NetBird for the time being. With NetBird there is no way to purge activity entries short of going into the database where they located. There is also an issue with NetBird where the log on Linux grows exponentially. If this feature is added, would consider deploying NetBird.

<!-- gh-comment-id:4179200902 --> @twocoolbeans commented on GitHub (Apr 2, 2026): Pruning logs (Audit Events and Traffic Events) is the reason that deployed Pangolin over NetBird for the time being. With NetBird there is no way to purge activity entries short of going into the database where they located. There is also an [issue ](https://github.com/netbirdio/netbird/issues/3576)with NetBird where the log on Linux grows exponentially. If this feature is added, would consider deploying NetBird.
Author
Owner

@pascal-fischer commented on GitHub (Apr 9, 2026):

In the reverse proxy section of you management.json you can set retention and cleanup interval.

"ReverseProxy": {
  "AccessLogRetentionDays": 7,
   "AccessLogCleanupIntervalHours": 24
},

This was actually supposed to be the default. I will be creating a PR to set this as default for future versions

<!-- gh-comment-id:4214974943 --> @pascal-fischer commented on GitHub (Apr 9, 2026): In the reverse proxy section of you management.json you can set retention and cleanup interval. ``` "ReverseProxy": { "AccessLogRetentionDays": 7, "AccessLogCleanupIntervalHours": 24 }, ``` This was actually supposed to be the default. I will be creating a PR to set this as default for future versions
Author
Owner

@shaban00 commented on GitHub (Apr 9, 2026):

@pascal-fischer I am using the combined method so I don't have management.json. Is there a way to do that in config.yaml?

<!-- gh-comment-id:4215002550 --> @shaban00 commented on GitHub (Apr 9, 2026): @pascal-fischer I am using the combined method so I don't have `management.json`. Is there a way to do that in `config.yaml`?
Author
Owner

@pascal-fischer commented on GitHub (Apr 9, 2026):

Good catch, this is not exposed on the combined version. I will add this as well.

<!-- gh-comment-id:4215131118 --> @pascal-fischer commented on GitHub (Apr 9, 2026): Good catch, this is not exposed on the combined version. I will add this as well.
Author
Owner

@shaban00 commented on GitHub (Apr 13, 2026):

@pascal-fischer I realized that in that PR, you didn't update the config.yaml.example to include those fields. Most people check that config example to know which configurations are allowed.

<!-- gh-comment-id:4236451452 --> @shaban00 commented on GitHub (Apr 13, 2026): @pascal-fischer I realized that in that PR, you didn't update the `config.yaml.example` to include those fields. Most people check that config example to know which configurations are allowed.
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11959