$ cscli hub list -o raw
Loaded: 159 parsers, 11 postoverflows, 773 scenarios, 9 contexts, 5 appsec-configs, 176 appsec-rules, 159 collections
name,status,version,description,type
crowdsecurity/dateparse-enrich,enabled,0.2,,parsers
crowdsecurity/geoip-enrich,enabled,0.5,"Populate event with geoloc info : as, country, coords, source range.",parsers
crowdsecurity/public-dns-allowlist,enabled,0.1,Allow events from public DNS servers,parsers
crowdsecurity/sshd-logs,enabled,3.1,Parse openSSH logs,parsers
crowdsecurity/sshd-success-logs,enabled,0.1,Parse successful ssh logins,parsers
crowdsecurity/syslog-logs,enabled,1.0,,parsers
crowdsecurity/whitelists,enabled,0.3,Whitelist events from private ipv4 addresses,parsers
crowdsecurity/cdn-whitelist,enabled,0.4,Whitelist CDN providers,postoverflows
crowdsecurity/rdns,enabled,0.3,Lookup the DNS associated to the source IP only for overflows,postoverflows
crowdsecurity/seo-bots-whitelist,enabled,0.5,Whitelist good search engine crawlers,postoverflows
crowdsecurity/ssh-bf,enabled,0.3,Detect ssh bruteforce,scenarios
crowdsecurity/ssh-cve-2024-6387,enabled,0.2,Detect exploitation attempt of CVE-2024-6387,scenarios
crowdsecurity/ssh-generic-test,enabled,0.2,Crowdsec Generic Test Scenario: SSH brute force trigger,scenarios
crowdsecurity/ssh-refused-conn,enabled,0.1,Detect sshd refused connections,scenarios
crowdsecurity/ssh-slow-bf,enabled,0.4,Detect slow ssh bruteforce,scenarios
crowdsecurity/ssh-time-based-bf,enabled,0.2,Detect time-based ssh bruteforce attempts that evade rate limiting (with false positive reduction),scenarios
crowdsecurity/bf_base,enabled,0.1,,contexts
crowdsecurity/linux,enabled,0.3,core linux support : syslog+geoip+ssh,collections
crowdsecurity/sshd,enabled,0.8,sshd support : parser and brute-force detection,collections
crowdsecurity/whitelist-good-actors,enabled,0.2,Good actors whitelists,collections
What happened?
While trying to add the Core Rule Set plugin for Google OAuth, I noticed that the rule below was never fully executed as expected:
When displaying the debug log, here is the line corresponding to this rule:
This means that coraza is counting two elements for each URL parameter, while the condition expects only 1. However, I have double-checked and confirmed that my request contains exactly one
codeargument and onescopeargument, no duplicates.What did you expect to happen?
This rule is known to work; I already use it with ModSecurity. It should work here as well.
How can we reproduce it (as minimally and precisely as possible)?
Set up any rule with a condition like
SecRule &ARGS_GET:whatever "@eq 1"and use the URL http://example.com?whatever. The count (argin the log line) will be 2 instead of 1.Anything else we need to know?
Yes, I’ve read the code and I think I know where the issue comes from.
In the
processRequest()function (inappsec_runner.go), the code calls coraza functionAddGetRequestArgument()for each URL parameter, and then theProcessURI()function is called:However, in Coraza,
ProcessURI()also callsAddGetRequestArgument()for each URL parameter: see here then here.If you comment out the for loop in
processRequest()(the one copied above), the argument count performed by coraza is correct, and the Google OAuth rule works perfectly as expected.Crowdsec version
Details
OS version
Details
KubernetesEnabled collections and parsers
Details
Acquisition config
Details
Config show
Details
Prometheus metrics
Details
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.
Details