1. Les décisions #
Consulter, ajouter, supprimer.
Le quotidien #
sudo cscli decisions list
sudo cscli decisions list --origin cscli
sudo cscli decisions add --ip 192.0.2.5 --duration 1h --reason "test manuel"
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. Les profils #
De l’alerte à la décision.
Le fonctionnement #
Le fichier /etc/crowdsec/profiles.yaml contient une suite de profils, séparés par ---. Le premier dont le filtre correspond s'applique, et on_success: break arrête la lecture. Par défaut : un ban de 4 h pour une IP ou une plage.
Bannir plus longtemps les récidivistes #
name: ban_progressif
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
- type: ban
duration: 4h
# 4 h la première fois, puis 8 h, 12 h… à chaque récidive
duration_expr: Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)
on_success: breakL'ordre compte. Placez vos profils personnalisés avant les profils par défaut, sinon ils ne seront jamais atteints.
Un captcha pour le web #
name: captcha_http
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip" && Alert.GetScenario() startsWith "crowdsecurity/http-"
decisions:
- type: captcha
duration: 1h
on_success: breakVérifiez que votre bouncer sait appliquer le captcha : un bouncer pare-feu ne le peut pas.
3. Les faux positifs #
Protéger les adresses de confiance.
Les allowlists #
Une allowlist déclare des adresses à ne jamais bloquer. C'est la méthode à privilégier, et elle agit tout de suite : à l'ajout, les décisions existantes sur ces adresses sont supprimées.
sudo cscli allowlists create bureau -d "IP de confiance"
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.60Une décision manuelle sur une adresse autorisée est refusée, sauf avec --bypass-allowlist.
Tutoriels à corriger. Certains articles proposent cscli decisions add --type whitelist. Ce n'est pas le bon mécanisme : le type d'une décision décrit la remédiation à appliquer. Utilisez une allowlist.Autres leviers #
- La simulation, pour observer un scénario sans bloquer.
- Les whitelists de parsers, pour ignorer des événements selon leur contenu, par exemple un outil de supervision.
- Le filtre
scenarios_not_containingdu bouncer pare-feu, pour écarter certains scénarios.
4. AppSec : le WAF #
Bloquer une requête avant qu’elle n’arrive.
Le principe #
Les scénarios analysent les logs : ils réagissent après les requêtes. AppSec, lui, reçoit chaque requête du bouncer avant qu'elle n'atteigne l'application et répond allow ou ban.
sudo cscli collections install crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rulesCréez /etc/crowdsec/acquis.d/appsec.yaml :
source: appsec
listen_addr: 127.0.0.1:7422
path: /
appsec_configs:
- crowdsecurity/appsec-default
labels:
type: appsecCe que nous avons observé #
| Requête | Réponse d’AppSec |
|---|---|
/index.html | 200 allow |
/.env | 403 ban, règle vpatch-env-access |
/?id=1' OR 1=1-- | 200 allow |
Ne vous y trompez pas. Le virtual patching cible des failles connues et des cas précis. Lors de notre test, une injection SQL générique est passée avec ces deux collections. AppSec complète votre sécurité applicative, il ne la remplace pas.
sudo cscli metrics show appsecSources #
Commandes et résultats vérifiés sur CrowdSec 1.8.2.
