1. Decisions #
View, add, delete.
Day to day #
sudo cscli decisions list
sudo cscli decisions list --origin cscli
sudo cscli decisions add --ip 192.0.2.5 --duration 1h --reason "manual test"
sudo cscli decisions add --range 192.0.2.128/25 --duration 1h
sudo cscli decisions add --ip 192.0.2.6 --duration 1h --type captcha
sudo cscli decisions delete --ip 192.0.2.5
sudo cscli alerts list
sudo cscli alerts inspect 32. Profiles #
From alert to decision.
How it works #
The /etc/crowdsec/profiles.yaml file holds a series of profiles, separated by ---. The first one whose filter matches applies, and on_success: break stops reading. By default: a 4 h ban for an IP or range.
Banning repeat offenders longer #
name: progressive_ban
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
- type: ban
duration: 4h
# 4 h the first time, then 8 h, 12 h… for each repeat offense
duration_expr: Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)
on_success: breakOrder matters. Place your custom profiles before the default ones, otherwise they will never be reached.
A captcha for the web #
name: captcha_http
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip" && Alert.GetScenario() startsWith "crowdsecurity/http-"
decisions:
- type: captcha
duration: 1h
on_success: breakCheck that your bouncer can enforce a captcha: a firewall bouncer cannot.
3. False positives #
Protecting trusted addresses.
Allowlists #
An allowlist declares addresses that must never be blocked. It is the preferred method and acts immediately: when added, existing decisions on these addresses are deleted.
sudo cscli allowlists create bureau -d "Trusted IPs"
sudo cscli allowlists add bureau 203.0.113.60 198.51.100.0/24 -d "VPN"
sudo cscli allowlists inspect bureau
sudo cscli allowlists check 198.51.100.7
# 198.51.100.7 is allowlisted by item 198.51.100.0/24 from bureau (VPN)
sudo cscli allowlists remove bureau 203.0.113.60A manual decision on an allowed address is refused, unless using --bypass-allowlist.
Tutorials to correct. Some articles suggest cscli decisions add --type whitelist. This is not the right mechanism: a decision type describes the remediation to apply. Use an allowlist.Other levers #
- Simulation, to observe a scenario without blocking.
- Parser whitelists, to ignore events based on their content, such as a monitoring tool.
- The firewall bouncer's
scenarios_not_containingfilter, to exclude some scenarios.
4. AppSec: the WAF #
Blocking a request before it arrives.
The principle #
Scenarios analyze logs: they react after requests. AppSec, on the other hand, receives each request from the bouncer before it reaches the application and answers allow or ban.
sudo cscli collections install crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rulesCreate /etc/crowdsec/acquis.d/appsec.yaml:
source: appsec
listen_addr: 127.0.0.1:7422
path: /
appsec_configs:
- crowdsecurity/appsec-default
labels:
type: appsecWhat we observed #
| Request | AppSec response |
|---|---|
/index.html | 200 allow |
/.env | 403 ban, vpatch-env-access rule |
/?id=1' OR 1=1-- | 200 allow |
Make no mistake. Virtual patching targets known flaws and specific cases. In our test, a generic SQL injection passed with these two collections. AppSec complements your application security, it does not replace it.
sudo cscli metrics show appsecSources #
Commands and results verified on CrowdSec 1.8.2.
