ne20002

Hi @theseion I've taken the same request on both my systems, one with the new CRS 4.0, one with the old 3.5.5. New log entry: `2024/03/08 18:26:50 [error] 89#89: *546...

Hi Thank you all very much. [Crowdsec](https://www.crowdsec.net/) works with parsers and scenarios to identify and block bad actors. Kind a fail2ban does. The [Crowsec parser](https://github.com/crowdsecurity/hub/blob/master/parsers/s01-parse/crowdsecurity/modsecurity.yaml) for Modsecurity works on the...

Actually looking for e.g 932160 is not that easy, as Crowdsec is parsing the Nginx **error.log**. The parser is looking for a line starting with 'modsecurity' and either critical or...

@theseion, @dune73 > There is a question where you want the CrowdSec / Fail2Ban logic to happen. Do you want (1) CrowdSec / Fail2Ban try and make sense of the...

For me I will try to manipulate my local scenario file and see if I get it working again for (2). ;)

Yes, copying is the way I go. It should fix the current problem until an official fix is available.

Actually I'm using Crowdsec and CRS/Nginx container. It logs detection rule and blocking rule to Modesc audit.log. But to error.log only the blocking rule is logged. This in version 3.3.5...

> Notice how 933160 is not being logged in the error.log.* This is how it worked since I use the modesurity-crs container. I believe implementing/restoring the logging of the triggered...

I took a look at the compose file and set the values accordingly in my setup. I still have the issue. I'm not using compose but start the container from...

It's different depending on **how** the container is started?