Jeux de règles de détection

Vue d’ensemble — à quoi sert cet écran

Jeux de règles de détection (/security/rulesets) est la bibliothèque canonique qui normalise chaque règle de détection observée et évaluée par InfraGuard en 44 jeux de règles répartis sur 11 catégories. L’écran fait trois choses au même endroit :

1. Panorama — dispose les cartes de jeux de règles dans des sections par catégorie et affiche, pour la fenêtre temporelle sélectionnée (1h/6h/24h), le nombre réel d’événements et l’horodatage de dernière observation de chaque jeu de règles.
2. Explication — décrit chaque jeu de règles en trois étapes (ce qu’il détecte · pourquoi il se déclenche · pire scénario).
3. Rejeu — un clic sur une carte ouvre une fenêtre modale contenant les événements récents réellement mis en correspondance par ce jeu de règles, dans un tableau propre au moteur.

La clé de la conception est la séparation entre la structure de classification et le texte explicatif. La structure (catégories, clés de jeux de règles, règles de correspondance par moteur) réside dans la SOT statique et indépendante de la locale App\Support\SecurityRulebook (compatible avec la mise en cache), tandis que le texte explicatif (nom, signification, indices, risque) réside dans resources/lang/{ko,en}/secrules.php. Le frontend fusionne les deux par key+category pour le rendu.

Cet écran est strictement en lecture seule. Il n’active, ne désactive, ne modifie ni ne supprime aucun jeu de règles. C’est un catalogue de référence qui répond à la question « qu’observe-t-on dans cette organisation en ce moment, et qu’est-ce que cela signifie ? ». L’endroit qui modifie réellement les constantes de détection (seuils/fenêtres) est Règles et seuils (Administration ▸ Règles).

Les 44 jeux de règles sont câblés à de la télémétrie réelle

Les jeux de règles ne sont pas des règles abstraites : chacun est lié à une table de collecte réelle par une règle de correspondance (match). Toutes les sources se trouvent sur la connexion legacy_glory (la base de données héritée alimentée par la flotte de collecteurs).

Quand l’utiliser

• Obtenir du contexte avant le tri — lorsque vous tombez sur une signature inconnue dans Menaces ou Détections · IA JA3, confirmez à quelle famille de jeux de règles elle appartient et ce qu’elle implique.
• Balayer le paysage d’observation — voyez d’un coup d’œil quelles catégories se déclenchent sur les dernières 24h, et si les attaques web en sont au niveau de la reconnaissance ou ont déjà escaladé vers du sondage RCE.
• Intégration et reporting — un support pédagogique et de reporting qui explique « ce que nous détectons », par catégorie et par moteur.
• Rejouer des événements — inspectez les IP de requête, les URL et les codes de statut réellement mis en correspondance récemment par un jeu de règles donné (par exemple web_secret_scan), puis basculez les suspects vers Réputation d’IP ou Liste de blocage.

Disposition

Indicateurs du haut

En interne, il calcule aussi des sommes par moteur (totaux d’événements kitsune et suricata) afin que les chiffres restent cohérents avec l’étape « jeux de règles » de l’entonnoir de défense de Sécurité.

Contrôles

• Sélecteur de fenêtre — 1h (60 min) · 6h (360 min) · 24h (1440 min). Par défaut 24h.
• Rafraîchissement automatique (LIVE) — interroge /security/rulesets/live pour actualiser les compteurs (peut être mis en pause).
• Plein écran — masque la navigation supérieure pour un mode tableau de bord immersif (ÉCHAP pour quitter).

Sections par catégorie et cartes de jeux de règles

Les 11 catégories forment des sections dans l’ordre d’affichage, et à l’intérieur de chaque section les jeux de règles sont disposés dans une grille de cartes minmax(600). Chaque carte affiche le nom du jeu de règles, une icône MDI, un badge de sévérité (crit/warn/info), le nombre d’événements dans la fenêtre, l’horodatage de dernière observation et [Open]. Sans événement, elle affiche « calme / rien d’observé dans la fenêtre ».

Comment l’utiliser

1) Choisissez une fenêtre → lisez le paysage

Choisissez d’abord la fenêtre qui vous intéresse (1h/6h/24h). Utilisez active (jeux de règles observés) et le compteur d’événements de chaque carte pour voir ce qui se déclenche actuellement. Notez que le badge de sévérité est une sévérité implicite : la plupart des événements du moteur Suricata sont de sev3 (informatifs), mais leur implication diffère (bruit / scan / exploitation). Le badge du jeu de règles reflète ce ton d’implication, et non le sev brut.

2) Cliquez sur une carte → fenêtre modale des événements récents

Un clic sur une carte appelle /security/rulesets/events?key=<rulesetKey>&range=<window> et ouvre une fenêtre modale contenant :

• Explication en trois étapes — ce qu’il détecte · pourquoi il se déclenche · pire scénario.
• Agrégats — nombre d’événements · sources uniques (IP src distinctes).
• Puces de signatures correspondantes (Suricata uniquement) — les chaînes de signature réellement capturées par la correspondance de sous-chaîne sig de ce jeu de règles, chacune avec son compteur et son sev minimal (les 12 premières).
• Tableau d’événements propre au moteur (60 lignes récentes).
• IP source → réputation — un bouton pop-up AbuseIPDB par IP src. Les IP du réseau interne enregistrées reçoivent un badge internal et le bouton de réputation est masqué (afin d’éviter de prendre nos propres serveurs pour des attaquants).

Colonnes du tableau d’événements propre au moteur :

3) Priorité de classification des attaques web (disjointe)

Les 8 jeux de règles web (nginx) sont mutuellement disjoints. Une requête is_suspicious=1 est parcourue dans l’ordre de définition du catalogue et attribuée à exactement un jeu de règles, le premier qui correspond ; si aucune ne correspond, elle retombe sur le fourre-tout (web_suspicious_other). Ainsi, une même requête n’est jamais comptée deux fois entre deux jeux de règles web.

Pour des raisons de performance, la classification web agrège sur un échantillon des 6,000 lignes les plus récentes (plafond du dépôt : 8,000). Lors de scans intenses, les événements hors échantillon peuvent ne pas être reflétés — lisez les chiffres comme une distribution/tendance, non comme des compteurs absolus.

4) Ce qu’implique la correspondance par sous-chaîne de Suricata

Les jeux de règles Suricata se déclenchent sur une correspondance de sous-chaîne en minuscules de la chaîne de signature. Par exemple, stream_invalid_ts additionne tous les événements dont la signature contient invalid timestamp. Un seul jeu de règles peut regrouper plusieurs signatures réelles (visibles sous forme de puces « signatures correspondantes » dans la fenêtre modale), et les mots-clés sig de jeux de règles différents sont conçus pour ne pas se chevaucher.

5) Exemple mesuré (à titre de référence)

Un instantané illustratif sur 24h : 37 jeux de règles sur 44 se déclenchent, stream_invalid_ts 10,243, web_secret_scan 3,304 (majoritairement des 404 de la famille .env), srct_heuristic 126,252, ja3_rotation 300 (variété 307/307). Les valeurs varient selon l’organisation et la période.

Sources de données

Toutes les sources sont la connexion legacy_glory (lecture seule), atteinte uniquement via config('database.connections.legacy_glory') — aucun identifiant codé en dur.

Performance et mise en cache

• Le panorama de cartes (build) est mis en cache pendant 30 secondes (infr:sec:rulebook:<range>). Suricata récupère l’histogramme des signatures une seule fois et additionne les correspondances de sous-chaîne sur les 44 jeux de règles afin d’éviter le N+1.
• JA3 exclut le réseau propre (IP /24 des instances enregistrées) via le NOT LIKE de SecurityScope::excludePrefixes(), et ne compte comme contrevenantes que les IP source ayant ja3_variety >= 2.
• Les événements de la fenêtre modale sont plafonnés à 60 lignes par fenêtre. Chaque requête du dépôt utilise une fenêtre temporelle étroite + LIMIT + liaison de paramètres.

Accès

• Lecture seule. Le contrôle du contrôleur est level≥1 pour les lectures, et l’entrée dans l’espace de rôle Sécurité lui-même est protégée par le min_req=2 du sitemap (opérations de sécurité) — en pratique, y accèdent les profils staff (=5), admin (=10) ou les utilisateurs dont la portée couvre la sécurité.
• Comme il n’existe aucun chemin d’écriture, il n’y a ni reconfirmation par élévation, ni journal d’audit. /rulesets, /rulesets/live et /rulesets/events sont toutes des lectures pures.
• La key du point de terminaison events n’est admise que depuis la liste blanche du catalogue. Les clés hors liste renvoient 404 unknown_ruleset (les consultations de tables arbitraires sont impossibles).

Convention de niveaux : demo=1 · staff=5 · admin=10. Certains espaces sont en outre protégés par le middleware infr.level:N. Voir Niveaux RBAC pour le barème complet.

Dépannage et FAQ

Toutes les cartes affichent « calme »

Soit il n’y a aucun événement correspondant dans la fenêtre sélectionnée (24h par défaut), soit la connexion legacy_glory est injoignable. Le service absorbe proprement les erreurs de source et affiche des compteurs vides (0) — les cartes ne disparaissent pas. Élargissez la fenêtre ou vérifiez la connexion.

Les compteurs des jeux de règles web diffèrent de [Menaces] / [Détections]

La classification web est un agrégat de distribution sur un échantillon des 6,000 lignes les plus récentes (et non un compteur absolu). Elle est aussi disjointe : une requête est donc attribuée à exactement un jeu de règles. La source d’événements faisant autorité suit la requête propre à chaque écran.

Une signature précise n’est capturée par aucun jeu de règles

La correspondance Suricata se fait par sous-chaîne de mot-clé. Les signatures nouvelles ou personnalisées que le catalogue ne couvre pas ne sont additionnées dans le compteur d’aucun jeu de règles. Pour les classer et les expliquer, ajoutez le mot-clé de la signature au tableau sig de SecurityRulebook — c’est une modification de code, pas un réglage à l’exécution.

Les contrevenants JA3 sont à 0 alors que le trafic TLS est important

Le jeu de règles JA3 ne compte comme contrevenantes que les IP source ayant ja3_variety >= 2 (rotation d’empreinte). Sans rotation, une source est considérée comme normale et n’est pas comptée. Les IP du réseau propre sont également exclues.

Une IP affiche un badge internal dans la fenêtre modale des événements

Il s’agit d’une IP de réseau interne enregistrée, déterminée par SecurityScope::internalMatchers(). Cela évite de prendre pour des attaquants nos propres serveurs — que la directionnalité de Suricata peut étiqueter comme « source » — et masque le bouton de réputation. La définition du réseau interne se gère sous internal_networks dans Politique d’exploitation.

Voir aussi

• Détections · Analyse de séquences JA3 — l’écran parent (Détections) ; une heuristique déterministe dérive de nouveaux jeux de règles à partir des séquences JA3.
• Menaces — tri des entités de menace IDS et explication des signatures.
• Vue d’ensemble de la sécurité — cohérente avec l’étape « jeux de règles » de l’entonnoir de défense.
• Réputation d’IP — vérifiez une IP source de la fenêtre modale auprès d’AbuseIPDB.
• Liste de blocage — basculez une source suspecte vers un blocage.
• Règles et seuils (Administration ▸ Règles) — ajustez réellement les constantes des collecteurs de détection (seuils/fenêtres).