Actor Intelligence FR

Actor Intelligence 🟣

EN | FR | 🟣 MIND | qui se cache derrière le trafic

À quoi ça sert

Actor Intelligence transforme des événements épars (une requête bloquée, un balayage de ports, une réponse DNS suspecte, un leurre touché) en acteurs et campagnes que l'on peut lire, noter et — seulement quand les preuves le permettent — contrer. La règle de la page tient dans son pied : observer, corréler, expliquer, défendre ; et un lien entre deux adresses est une « continuité de campagne probable », jamais « la même personne ».

Comment ça marche

capteurs ──► sbx-actord ──► scores + décision (proposée)
 waf · pare-feu · dns · dpi · authwatch · sentinel
                              │ échelle de réponse (publiée toutes les 30 s)
                              ▼
                  sbxwaf applique (si son mode l'autorise) ──► nft waf_ban ──► réévaluation
                  le NAC met un appareil du LAN en quarantaine

• sbx-actord (livré par secubox-waf-ng, lancé avec --shadow) observe, corrèle et propose. Il n'applique rien lui-même : c'est le mode ombre du moteur. API en lecture seule sur /run/secubox/actor.sock, atteinte par /api/v1/actor/….
• sbxwaf est celui qui applique, et seulement selon son propre mode (off / propose / auto, voir plus bas).
• Le moteur « ombre » ne veut jamais dire « sans protection » : le WAF-FR bannit avec ses propres règles pendant que le renseignement observe.

Les capteurs

Capteur	Émet	Réglage
waf	requêtes bloquées, sondes, leurres, campagnes	toujours actif dans sbxwaf
firewall	balayages de ports (paquets rejetés)	--scan-sensor, --scan-seuil (8 ports distincts en 10 min)
dns	domaines malveillants ou anormaux, détournement (réponse vers une adresse ou un ASN inattendu)	capteur DNS d'ad-guard ; alerte de détournement après 3 jours d'apprentissage
dpi	risques nDPI hostiles par adresse publique	DPI_ACTOR_SOCK dans /etc/secubox/dpi.env (DPI-Vivant)
authwatch, sentinel	échecs d'authentification, alertes de la sentinelle	leurs modules

Un capteur qui se tait abaisse la confiance, jamais le risque.

Les scores : risque et confiance

Deux mesures séparées, de 0 à 100, chacune somme de facteurs traçables qui gardent leurs références de preuve. Le risque, c'est ce que l'acteur fait ; la confiance, ce que les preuves permettent d'affirmer. La version de la politique (v2) est figée avec chaque évaluation : changer les poids ne falsifie jamais une évaluation passée.

Niveau	Condition	Ce qu'il permet
OBSERVE	sinon	journal seulement
MITIGATE	risque >= 42 et confiance >= 50	mesures réversibles (délai, défi, ralentissement)
BLOCK	risque >= 75 et confiance >= 80 et au moins 2 capteurs distincts	ban

Un niveau refusé écrit sa raison (« BLOCK refusé : un seul capteur (2 requis) »). La plupart des acteurs ne sont vus que par le WAF : leur confiance reste sous 80 et la décision plafonne à MITIGATE, c'est voulu. Principaux facteurs de risque : balayage de ports (+20), appât ou leurre visé (+20), tentative d'exploitation (+20), charges répétées (+15), corrélation multi-capteurs (+15), persistance sur plusieurs jours (+7), anomalie DNS de canal caché (+10). Les scénarios sont ordonnés : reconnaissance, sondage, exploitation, canal caché, persistance.

L'échelle de réponse

La décision dit quoi penser ; l'échelle dit que faire. Chaque cran est temporaire, réversible et porte sa raison.

Cran	Déclencheur (risque)	Effet	Durée
OBSERVE	sous 42, ou confiance sous 50	journal	—
DELAY	42–54	la requête attend 1,5 s	5 min
CHALLENGE	55–64	page de preuve de travail (JavaScript, aucun tiers), puis laissez-passer lié à l'adresse ; les requêtes d'API sont seulement ralenties	15 min
TARPIT	65–74, ou 75+ sans deux capteurs	la connexion est retenue et nourrie au compte-gouttes (60 s au plus, 64 retenues au plus)	30 min
DENY	75+, confiance 80+, deux capteurs	ban nft gradué, 1 h / 24 h / 7 j	1 h
QUARANTINE	comme DENY, pour un appareil du LAN	isolé par le NAC dans sa zone de quarantaine, libéré seulement par un administrateur	6 h

Un acteur qui insiste (10 nouveaux événements hostiles sous sa mesure) monte d'un cran. C'est ainsi qu'un acteur vu par le seul WAF finit banni sans que le moteur ait jamais bloqué sur une incertitude.

La preuve est par adresse

Le graphe peut fusionner des centaines d'adresses sans lien en un seul acteur (1 389 adresses dans un acteur ont été vues sur la box de référence). Les punir toutes toucherait des innocentes. Une mesure ne vise donc que les adresses qui ont elles-mêmes produit au moins 3 événements hostiles (gravité 40+) dans les dernières 24 heures ; un ban exige 10 événements individuels, en dessous l'adresse est seulement retenue (tarpit). Aucune adresse hostile, aucune mesure. Une vérification de moteur de recherche non terminée ne fait jamais traiter une adresse en attaquante.

Garde-fous

• Jamais une adresse privée, locale ou protégée (--actor-ban-protegees), jamais un moteur de recherche vérifié (WAF-FR), jamais /.well-known/acme-challenge/ ni /robots.txt.
• Plafonds horaires par source, durées graduées, jamais de ban permanent : une chaîne de bans ininterrompue de 30 jours est libérée.
• Réévaluation peu avant l'échéance d'un ban : RELEASE si l'adresse s'est tue ou sans compteur, EXTEND si elle a continué d'envoyer des paquets. Une ligne de preuve par transition, une ligne d'audit.
• Un fichier de mesures périmé (plus de 3 minutes) ne laisse aucune mesure active.

Modes et activation

Mode	Drapeau	Effet
PASSIVE_ONLY	off	observer, noter, afficher
SIMULATION	propose	candidats écrits (WOULD_BLOCK), rien d'appliqué
ACTIVE	auto	bans et mesures appliqués (BLOCKED)

Activer par étapes, du plus réversible au plus dur, une étape par semaine, en lisant GET /api/v1/waf/decisions, /enforcement, /reevaluations entre deux :

1. PASSIVE_ONLY (sans drapeau) ; 2. SIMULATION au moins une semaine, mesurer les faux positifs (adresses partagées, robots légitimes) et protéger les plages ;
2. ACTIVE : réévaluation, puis mesures (délai et défi d'abord), puis bans de campagne, puis bans d'acteurs, et les bans de leurre en dernier.

Retour arrière : un ban par POST /api/v1/waf/enforcement/{id}/rollback ; une fonction en remplaçant auto par propose ou off puis systemctl restart secubox-waf-ng. La procédure complète et tous les seuils sont dans docs/ACTOR-INTELLIGENCE-ACTIVATION.md du dépôt (installé sous /usr/share/doc/secubox/).

Où regarder

Vue	Contenu
Page Renseignement (/actor-intelligence/, aussi dans le SOC-FR)	acteurs, campagnes, radar, mesures par cran
Page d'administration /actor/	indicateurs, campagnes d'abord, acteurs à un clic, score de menace
Carte « Radar des acteurs » du Hall (Cartes-du-Hall)	risque et confiance de chaque acteur, sans adresse
API /api/v1/actor/…	stats, actors, campaigns, radar, mesures, robots, overview (vue réduite) ; timeline, graph, risk, events, proposals, evidence (vue complète seulement)

Les robots d'indexation connus sont comptés à part et ne sont ni critiques, ni suspects, ni observés. Les indicateurs, IOC et incidents du tableau des menaces (SOC-FR) complètent cette vue.

Limites connues

• Sans second capteur, la confiance reste sous 80 et la décision plafonne à MITIGATE.
• Le détournement DNS n'alerte qu'après 3 jours d'apprentissage.
• Les empreintes TLS JA4 ne sont pas encore remontées par le moteur DPI (DPI-Vivant).
• Une adresse partagée (CGNAT, bureau) qui héberge un attaquant ralentit aussi ses voisins pendant la mesure : d'où des durées courtes et un défi avant le refus.

Voir aussi

WAF-FR · SOC-FR · DPI-Vivant · ThreatMesh-FR · Cartes-du-Hall · Actor-Intelligence