Add a new datasource that:
- Receives HTTP requests from remediation components
- Apply rules on them to determine whether they are malicious or not
- Rules can be evaluated in-band (the remediation component will block the request directly) or out-band (the RC will let the request through, but crowdsec can still process the rule matches with scenarios)
The PR also adds support for 2 new hub items:
- appsec-configs: Configure the Application Security Engine (which rules to load, in which phase)
- appsec-rules: a rule that is added in the Application Security Engine (can use either our own format, or seclang)
---------
Co-authored-by: alteredCoder <kevin@crowdsec.net>
Co-authored-by: Sebastien Blot <sebastien@crowdsec.net>
Co-authored-by: mmetc <92726601+mmetc@users.noreply.github.com>
Co-authored-by: Marco Mariani <marco@crowdsec.net>
* use go 1.21.1, require 1.21
* import "slices" from stdlib
* allow codeql to set version number from tags
* codeql: custom WASM build - the automated one can silently fail
For cscli: it should provide a terse output, not nag users with configuration details. Although it's usually important that cscli and crowdsec have the same enabled features, having it list them every time the command is invoked can be too much.
For crowdsec: when features are set from the environment, it's too early to log where we should. So we can use log.Debug at activation time, and list them again once logging is configured.
- wrap some functions in csconfig for convenience and DRY
- for each enabled feature, log.Debug
- log all enabled features once as Info (crowdsec) or Debug (cscli)
- file does not exist -> log.Trace
Package fflag provides a simple feature flag system.
Feature names are lowercase and can only contain letters, numbers, undercores
and dots.
good: "foo", "foo_bar", "foo.bar"
bad: "Foo", "foo-bar"
A feature flag can be enabled by the user with an environment variable
or by adding it to {ConfigDir}/feature.yaml
I.e. CROWDSEC_FEATURE_FOO_BAR=true
or in feature.yaml:
```
---
- foo_bar
```
If the variable is set to false, the feature can still be enabled
in feature.yaml. Features cannot be disabled in the file.
A feature flag can be deprecated or retired. A deprecated feature flag is
still accepted but a warning is logged. A retired feature flag is ignored
and an error is logged.
A specific deprecation message is used to inform the user of the behavior
that has been decided when the flag is/was finally retired.