Créer une bloque list depuis l'analyse

romain commented

2026-09-30 09:25:53 +00:00

Owner

base sur les regles Analysis, un mode à le Crowdsec qui permet de generer une liste d'IP douteuse, qui pourrait etre integre ajouter à la fonctionnalité Blocklist, il faut définir un seuil de de répetition pour boquer et aussi permettre de pas faire de remediation si on le souhaite, vu que ça tourne déjà en prod, pas defaut remediation est à false

romain added the

enhancement

label

2026-09-30 09:25:53 +00:00

romain commented

2026-09-30 11:40:41 +00:00

Author

Owner

v12.49.4 livré avec la nouvelle fonctionnalité.

Ce qui a été ajouté — une nouvelle source dans config/blocklists.yml, type: analyzer :

yaml
sources:

name: analyzer-auto
type: analyzer
threshold: 5 # nombre de déclenchements avant qu'une IP soit retenue
window_hours: 24 # fenêtre glissante de comptage
min_severity: medium # optionnel
remediation: false # false par défaut, comme demandé

Elle compte, sur /api/alerts de nginx-analyzer, combien de fois chaque IP a déclenché une règle d'Analyse (bruteforce, scan, flood, scraping, écart volumétrique, règles personnalisées) sur la fenêtre glissante, et retient celles qui dépassent le seuil — un mode "à la CrowdSec" entièrement local, sans dépendance externe.

Le point de sécurité central : remediation: false par défaut, et tant que ce n'est pas explicitement mis à true, la liste est calculée et visible (page Blocklists IP : badge "Analyse", compteur "détectées", badge "observation seule") mais ne bloque strictement rien — elle ne rejoint jamais la table geo appliquée par nginx. Une notification prévient quand même l'opérateur dès qu'une nouvelle IP franchit le seuil, pour qu'il puisse observer avant d'activer le blocage réel. Ça coexiste sans rien casser avec vos sources URL existantes, et une config actuelle sans type continue de fonctionner à l'identique.

Tests dédiés (seuil, sévérité, pagination, analyseur injoignable, remediation false→true, notification) + suite complète : TOUS LES TESTS PASSENT. Config d'exemple, README et CHANGELOG mis à jour, zip vérifié (360 fichiers, aucun fichier nouveau — tout est dans des fichiers existants).

v12.49.4 livré avec la nouvelle fonctionnalité. Ce qui a été ajouté — une nouvelle source dans config/blocklists.yml, type: analyzer : yaml sources: - name: analyzer-auto type: analyzer threshold: 5 # nombre de déclenchements avant qu'une IP soit retenue window_hours: 24 # fenêtre glissante de comptage min_severity: medium # optionnel remediation: false # false par défaut, comme demandé Elle compte, sur /api/alerts de nginx-analyzer, combien de fois chaque IP a déclenché une règle d'Analyse (bruteforce, scan, flood, scraping, écart volumétrique, règles personnalisées) sur la fenêtre glissante, et retient celles qui dépassent le seuil — un mode "à la CrowdSec" entièrement local, sans dépendance externe. Le point de sécurité central : remediation: false par défaut, et tant que ce n'est pas explicitement mis à true, la liste est calculée et visible (page Blocklists IP : badge "Analyse", compteur "détectées", badge "observation seule") mais ne bloque strictement rien — elle ne rejoint jamais la table geo appliquée par nginx. Une notification prévient quand même l'opérateur dès qu'une nouvelle IP franchit le seuil, pour qu'il puisse observer avant d'activer le blocage réel. Ça coexiste sans rien casser avec vos sources URL existantes, et une config actuelle sans type continue de fonctionner à l'identique. Tests dédiés (seuil, sévérité, pagination, analyseur injoignable, remediation false→true, notification) + suite complète : TOUS LES TESTS PASSENT. Config d'exemple, README et CHANGELOG mis à jour, zip vérifié (360 fichiers, aucun fichier nouveau — tout est dans des fichiers existants).

romain commented

2026-09-30 11:40:54 +00:00

Author

Owner

v12.50.0 livrée — le redesign complet demandé après ton retour sur la v12.49.4.

Ce qui change :

Seuil + remédiation au niveau de chaque règle, plus sur une source globale : pour les règles intégrées (bruteforce/scan/flood/scraping/volumétrique/pays), un mini-formulaire dans la modale « Règles d'analyse » (Seuil, Fenêtre en minutes, case « Bloquer réellement », Durée en minutes) ; pour les règles perso (id ≥ 100), quatre nouveaux champs YAML (blocklist_threshold, blocklist_window_minutes, blocklist_remediation, blocklist_remediation_minutes).
Fenêtre en minutes partout (plus de window_hours), comme demandé.
Temps de remédiation (blocklist_remediation_minutes) : une fois bloquée, l'IP reste bloquée cette durée-là (renouvelée si elle continue de déclencher), indépendamment de la fenêtre de comptage. Laissé vide, comportement historique (bloquée tant qu'elle dépasse le seuil).
Liste blanche globale (whitelist: dans config/blocklists.yml, IP ou CIDR) : filet de sécurité appliqué après fusion de toutes les sources — jamais bloquée, quelle que soit la source qui l'aurait incluse. Pensé pour tes plages privées.
Opt-out de remédiation par vhost : # nginx-control-analyze-no-remediation: on dans le fichier de conf — garde les alertes visibles, retire juste ce vhost du comptage de blocage. Visible dans « Hôtes & directives ».
Les exceptions par vhost déjà existantes continuent de s'appliquer automatiquement, comme confirmé.

config/blocklists.yml's source type: analyzer est maintenant réduite à name/enable — elle agrège le résultat de toutes les règles ayant opté.

Tests : 129 tests backend passent (analyzer + dashboard, suites complètes), y compris les nouveaux cas (per-règle, whitelist, opt-out vhost, TTL de remédiation, migration de l'ancien format de rule_state).

Prochaine étape naturelle si besoin : affiner l'UI de la modale Règles une fois que tu l'auras testée en conditions réelles.

v12.50.0 livrée — le redesign complet demandé après ton retour sur la v12.49.4. Ce qui change : Seuil + remédiation au niveau de chaque règle, plus sur une source globale : pour les règles intégrées (bruteforce/scan/flood/scraping/volumétrique/pays), un mini-formulaire dans la modale « Règles d'analyse » (Seuil, Fenêtre en minutes, case « Bloquer réellement », Durée en minutes) ; pour les règles perso (id ≥ 100), quatre nouveaux champs YAML (blocklist_threshold, blocklist_window_minutes, blocklist_remediation, blocklist_remediation_minutes). Fenêtre en minutes partout (plus de window_hours), comme demandé. Temps de remédiation (blocklist_remediation_minutes) : une fois bloquée, l'IP reste bloquée cette durée-là (renouvelée si elle continue de déclencher), indépendamment de la fenêtre de comptage. Laissé vide, comportement historique (bloquée tant qu'elle dépasse le seuil). Liste blanche globale (whitelist: dans config/blocklists.yml, IP ou CIDR) : filet de sécurité appliqué après fusion de toutes les sources — jamais bloquée, quelle que soit la source qui l'aurait incluse. Pensé pour tes plages privées. Opt-out de remédiation par vhost : # nginx-control-analyze-no-remediation: on dans le fichier de conf — garde les alertes visibles, retire juste ce vhost du comptage de blocage. Visible dans « Hôtes & directives ». Les exceptions par vhost déjà existantes continuent de s'appliquer automatiquement, comme confirmé. config/blocklists.yml's source type: analyzer est maintenant réduite à name/enable — elle agrège le résultat de toutes les règles ayant opté. Tests : 129 tests backend passent (analyzer + dashboard, suites complètes), y compris les nouveaux cas (per-règle, whitelist, opt-out vhost, TTL de remédiation, migration de l'ancien format de rule_state). Prochaine étape naturelle si besoin : affiner l'UI de la modale Règles une fois que tu l'auras testée en conditions réelles.

romain referenced this issue from a commit

2026-09-30 11:50:43 +00:00

12.19.0

romain referenced this issue from a commit

2026-09-30 11:50:43 +00:00

12.19.1

romain referenced this issue from a commit

2026-09-30 12:24:15 +00:00

12.19.2

Rows
Columns

Créer une bloque list depuis l'analyse #44