-
Notifications
You must be signed in to change notification settings - Fork 490
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
Crowdsec creates new/stale remediation when the machine or container does not have static IP #3422
Comments
@mgrimace: Thanks for opening an issue, it is currently awaiting triage. In the meantime, you can:
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
Hey thank you for a detailed report, I will update the title to reflect the actual issue. The issue is when the remediation connects using an API key the original key is tied to the IP address, when using docker (without static address) or not having static DHCP within your LAN, when the remediation connects to next time we check if the IP address has changed and if so we generate a new entry with the IP since the original key is tied to the older IP address. Also I will take the time to go in detail with the report, but the details above should give an indication of what is happening. |
Hey we discussed this yesterday as a team, we will mark this as intended behavior moving forward as typically remediations will have static IP addresses on bare metal (webserver / firewalls) and will revise our documentation and example use cases to assign a static subnet. We did explore if there was a way we could have it so CrowdSec could detect if the original remediation has stopped pulling then merge the newly created back to the original, however, with metrics this will cause alot of issues so we will not proceed with this. |
Thank you for putting so much thought into this. I can appreciate that this is the intended behavior for a bare-metal setup. Specific to docker: Do you have any advice for a docker setup where docker networking would be the preferred/intended (or at least user-friendliest) method of linking Crowdsec to a remediation component (i.e., vs setting static internal docker IPs)? Messing with docker’s internal networking adds a layer of complexity that can be avoided (ideally) with simply putting both containers on a docker network. Alternatively, would it be valid to rephrase this issue as [Feature Request] for docker networking support for remediation components to simplify setup? I know many ‘official’ guides (e.g., Swag) that I’ve referenced don’t speak to setting static internal docker IPs for their reverse proxies/remediation components and doing so may make docker support/etc easier in the long term. Understandable however you want to proceed, I don’t have the skill to contribute what I’m suggesting myself. If that is not possible, would the workaround be as follows?:
Thanks again for all your work, |
What happened?
When using docker, and and the bouncer's container restarts (e.g., NPM, swag) or updates, Crowdsec spawns a new bouncer for it resulting in inactive bouncers that slowly accumulate. This occurs when the bouncer and Crowdsec are on the same docker network (e.g., 'homelab').
In my use, this happens with both NPM and Swag as bouncers in my two homelab environments, for example:
As far as I understand, Crowdsec is seeing that the bouncer has a new docker IP, and erroneously 'assumes' it is a new bouncer with a shared key, and automatically creates a new bouncer. Unfortunately, this leaves behind inactive bouncers. Also, deleting the inactive bouncer deletes all bouncers.
What did you expect to happen?
How can we reproduce it (as minimally and precisely as possible)?
bouncername@dockerIP
, and an inactive bouncer withbouncername
Anything else we need to know?
No response
Crowdsec version
OS version
Enabled collections and parsers
Acquisition config
filenames:
labels:
type: nginx-proxy-manager
On Windows:
C:> Get-Content C:\ProgramData\CrowdSec\config\acquis.yaml
paste output here
Config show
Prometheus metrics
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.
The text was updated successfully, but these errors were encountered: