Actor Intelligence 🟣

EN | FR | 🟣 MIND | who is behind the traffic

What it is for

Actor Intelligence turns scattered events (a blocked request, a port scan, a suspicious DNS answer, a decoy touched) into actors and campaigns that can be read, scored and — only when the evidence allows it — answered. The rule of the page is in its footer: observe, correlate, explain, defend; and a link between two addresses is a "probable campaign continuity", never "the same person".

How it works

sensors ──► sbx-actord ──► scores + decision (proposed)
 waf · firewall · dns · dpi · authwatch · sentinel
                              │ response ladder (published every 30 s)
                              ▼
                  sbxwaf applies (if its mode allows) ──► nft waf_ban ──► re-evaluation
                  NAC quarantines a LAN device

• sbx-actord (shipped by secubox-waf-ng, run with --shadow) observes, correlates and proposes. It applies nothing itself: this is the shadow mode of the engine. API read-only on /run/secubox/actor.sock, reached as /api/v1/actor/….
• sbxwaf is the one that enforces, and only according to its own mode (off / propose / auto, see below).
• The shadow engine never means "unprotected": the WAF bans with its own rules while the intelligence layer observes.

Sensors

Sensor	Emits	Setting
waf	blocked requests, probes, decoys, campaigns	always on in sbxwaf
firewall	port scans (rejected packets)	--scan-sensor, --scan-seuil (8 distinct ports in 10 min)
dns	malicious or abnormal domains, hijack (answer to an unexpected address or ASN)	ad-guard DNS sensor; hijack alerts after 3 days of learning
dpi	hostile nDPI risks per public address	DPI_ACTOR_SOCK in /etc/secubox/dpi.env (DPI-Vivant)
authwatch, sentinel	authentication failures, sentinel alerts	their own modules

A sensor that goes quiet lowers confidence, never risk.

Scores: risk and confidence

Two separate measures, 0 to 100, each the sum of traceable factors that keep their evidence references. Risk is what the actor does; confidence is what the evidence lets us claim. The policy version (v2) is frozen with each evaluation, so changing weights never falsifies a past one.

Level	Condition	What it allows
OBSERVE	otherwise	journal only
MITIGATE	risk >= 42 and confidence >= 50	reversible measures (delay, challenge, slow-down)
BLOCK	risk >= 75 and confidence >= 80 and at least 2 distinct sensors	ban

A refused level writes its reason ("BLOCK refused: a single sensor (2 required)"). Most actors are seen by the WAF alone, so their confidence stays below 80 and the decision stops at MITIGATE: this is intended. The main risk factors: port scan (+20), bait or decoy targeted (+20), exploitation attempt (+20), repeated payloads (+15), multi-sensor correlation (+15), persistence over several days (+7), covert-channel DNS anomaly (+10). Scenarios are ordered: reconnaissance, probing, exploitation, covert channel, persistence.

The response ladder

The decision says what to think; the ladder says what to do. Each rung is temporary, reversible and carries its reason.

Rung	Trigger (risk)	Effect	Duration
OBSERVE	below 42, or confidence below 50	journal	—
DELAY	42–54	the request waits 1.5 s	5 min
CHALLENGE	55–64	proof-of-work page (JavaScript, no third party), then a pass bound to the address; API requests are only slowed	15 min
TARPIT	65–74, or 75+ without two sensors	the connection is held and fed slowly (60 s max, 64 held at most)	30 min
DENY	75+, confidence 80+, two sensors	graduated nft ban, 1 h / 24 h / 7 d	1 h
QUARANTINE	as DENY, for a LAN device	isolated by the NAC in its quarantine zone, released only by an administrator	6 h

An actor that insists (10 new hostile events under its measure) goes up one rung. That is how an actor seen by the WAF alone ends up banned without the engine ever blocking on an uncertainty.

Proof is per address

The graph can merge hundreds of unrelated addresses into one actor (1,389 addresses in a single actor were seen on the reference box). Punishing them all would hit innocent addresses. So a measure only targets addresses that themselves produced at least 3 hostile events (severity 40+) in the last 24 hours; a ban needs 10 individual events, below which the address is only held (tarpit). No hostile address, no measure. A search-engine check that is not finished never treats an address as an attacker.

Safeguards

• Never a private, local or protected address (--actor-ban-protegees); never a verified search engine (WAF); never /.well-known/acme-challenge/ nor /robots.txt.
• Hourly ceilings per source, graduated durations, never a permanent ban: a chain of bans unbroken for 30 days is released.
• Re-evaluation shortly before a ban expires: RELEASE if the address went quiet or no counter exists, EXTEND if it kept sending packets. One evidence line per transition, one audit line.
• A stale measures file (over 3 minutes) leaves no measure active.

Modes and activation

Mode	Flag	Effect
PASSIVE_ONLY	off	observe, score, display
SIMULATION	propose	candidates written (WOULD_BLOCK), nothing applied
ACTIVE	auto	bans and measures applied (BLOCKED)

Activate in steps, the most reversible first, one step a week, reading GET /api/v1/waf/decisions, /enforcement, /reevaluations between steps:

1. PASSIVE_ONLY (no flag); 2. SIMULATION for at least a week, measure false positives (shared addresses, legitimate robots) and protect ranges; 3. ACTIVE: re-evaluation, then measures (delay and challenge first), then campaign bans, then actor bans, and decoy bans last.

Rollback: one ban with POST /api/v1/waf/enforcement/{id}/rollback; one function by replacing auto with propose or off and systemctl restart secubox-waf-ng. The full procedure and all thresholds are in docs/ACTOR-INTELLIGENCE-ACTIVATION.md of the repository (installed under /usr/share/doc/secubox/).

Where to look

View	Content
Intelligence page (/actor-intelligence/, also in the SOC)	actors, campaigns, radar, measures per rung
Admin page /actor/	KPIs, campaigns first, actors a click away, threat score
Hall card "Actor radar" (Cartes-du-Hall)	risk and confidence of each actor, no address
API /api/v1/actor/…	stats, actors, campaigns, radar, mesures, robots, overview (reduced view); timeline, graph, risk, events, proposals, evidence (full view only)

Known search-engine robots are counted apart and are not critical, suspect or observed actors. Indicators, IOCs and incidents of the Threat Dashboard (SOC) complete this view.

Known limits

• Without a second sensor, confidence stays under 80 and the decision stops at MITIGATE.
• DNS hijack only alerts after 3 days of learning.
• TLS JA4 fingerprints are not yet reported by the DPI engine (DPI-Vivant).
• An address shared by many people (CGNAT, office) that hosts an attacker slows its neighbours during the measure: hence short durations and a challenge before a refusal.

See also

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