Random reactions to 901340 resulting in ban #3456
Comments
|
@Simbiat: 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 I will take a deeper look on monday, but currently I would say the CRS experience with CrowdSec is not the best. Currently the first matching rule is the id that is used for the alert, however, this means the id of As you can see the rule is stated as Just to note if you enrolled into the console using This will allow you in the console to click
|
|
Nice, i did not even know about that feature, and I would prefer to have it enabled automatically every time container is recreated/rebuilt. Guess adding flags to docker_start.sh would be the way to go. I guess I'll make a PR for that (#3457) |
What happened?
Not sure what exactly happened, but looks like 1.6.3 at some point started reacting to 901340 (which is just "Enabling body inspection") resulting in (almost) instant ban. Nothing in Crowdsec log, and since I am test-driving Caddy's module, which does not log anything unless I use debug mode, nothing there as well. But on the app.crowdsec.net the purest test I had (with just 1 HTTP request to an API endpoint) resulted in this:
The China item is valid one, the next one was a POST request with a file and nothing else. I repeat: it was 1 (one) request, but somehow you can see 12 alerts about 901340. Next request triggered alert to 941100 (which is "XSS Attack Detected via libinjection", and it does not make sense here, too, since it was the same request repeated once again), and then vpatch alert recognized Brute Force (T1110), probably because of multiple previous alerts, that passed a threshold, and that resulted in a ban. The next 2 alerts are from 2 different requests which I triggered while using a different VPN server.
At the same time it looks like before that I had 2 cases when ban was also instant, but did not have as many alerts:
And when I actually noticed it for the first time, it looked like this:
Among the failed requests here were also regular GETs without anything special, and everything was working completely fine for like 10 minutes before this, when I was going through multiple pages on my website. At the same time I see increase in these kinds of alerts starting yesterday, but there was something last Thursday as well (I did restart server last weekend, though). In fact, I did that because I was banned by Crowdsec as well, but switching to VPN solved it without any issues, so I did not pay much attention to it (the US IP is not from me, though).
Since I need to finish some stuff on website, I had to clean the decisions in the container, and assuming that this may be result of some bug, I've updated it to 1.6.5 RC7. After that it seemed to stop, but I assume that it may happen again and will monitor things. Registering the issue, in case someone has idea what may be happening here. At the least I do not think 901340 should result in any alerts at all, since, from what I understand, this is technically turning on Coraza.
What did you expect to happen?
No alerts and no bans
How can we reproduce it (as minimally and precisely as possible)?
Unfortunately, no idea at the moment
Anything else we need to know?
No response
Crowdsec version
I was stupid enough to not record this before the update :(
OS version
Enabled collections and parsers
Acquisition config
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: