18 Threat Intel Operations

Threat Intel Operations

This page explains how to operate DomNexDomain Threat Intel in production.

Core model

• Allowlist-first
• Two policy modes only
• XP/Level/Tier classification
• Consolidated New / Watched / Blocked views for high-volume traffic
• Cross-protocol signal path (HTTP/HTTPS edge + SSH bastion auth/forward denies)
• Direct trace pivot into Strategic Intel -> Investigations

Policy modes

1) Monitor only

• Detects and records threat signals.
• Updates XP/Level/Tier state.
• Does not auto-block.
• Best for baselining and tuning.

2) Auto mode

• Detects and records threat signals.
• Applies temporary soft blocks at soft-risk levels.
• Escalates high-risk level to hard block.
• Hard-blocked sources are edge-dropped (proxy.block.hard_drop).
• Feed intelligence does not directly hard-block by itself.

Enforcement behavior

Deterministic enforcement order on edge requests:

1. hard blocked IP list check
2. Threat Intel evaluation (signals -> XP/Level/Tier -> decision)
3. WAF temporary unknown-host check
4. route and policy gates

First terminal decision wins.

Soft block behavior:

• Temporary block window is applied by policy state.
• Soft block duration is an operator-controlled setting (Soft Block Duration (minutes) in Settings).
• Active soft-blocked sources are visible in Watched.

Hard block behavior:

• Source is placed in hard-block path.
• Requests are dropped at edge (connection close).
• Audit trail remains available for investigation.
• Hard blocks are operationally managed objects (visible in Blocked view) and can be reviewed/reversed by admins.
• Hard-block state is reused by SSH bastion source checks (:2222) so abusive IPs are denied before auth processing.
• Lifecycle transition: after 60 days of inactivity, a hard-blocked source is moved to watch state at Level 3 instead of staying permanently blocked forever.

Operator tuning knobs (important)

Threat Intel behavior is intentionally tunable from Settings:

• Monitor/Soft/Hard level boundaries
• Soft block duration (minutes)
• feed/signature policy inputs

This allows adapting policy to traffic reality without changing code.

Rehabilitation / Decay behavior

Current baseline decay is intentionally conservative:

• XP decay starts after idle periods and is applied in 30-minute steps.
• Level decay is slow (72-hour step-down cadence).
• Full automatic state cleanup requires sustained inactivity (>= 72h), zero XP/level, and no active block.
• While a source is actively soft-blocked or hard-blocked, decay is paused for that source.
• After hard-block watch transition, normal decay/rehabilitation resumes.

Formal state model (operator view)

States:

• monitoring
• watch
• softblock_active
• hardblock
• rehabilitated

Key transitions:

• known feed or signature hit -> watch
• level >= soft threshold in auto mode -> softblock_active
• level >= hard threshold in auto mode -> hardblock
• soft block expiry -> monitoring|watch
• hard-block idle-lifecycle downgrade -> watch
• sustained cooling (xp=0, level=0, idle window) -> rehabilitated

Feed Opt-In behavior (false-positive safe)

• External threat feeds are stored as backend intelligence, not immediate enforcement.
• A feed-listed IP is only acted on when it actually sends traffic to your edge.
• On first real access with a feed-listed or signature-matched source, the source enters watch at Level 3 rather than instant block.
• This keeps high-risk context while reducing false-positive permanent bans.

This keeps repeat high-risk sources visible longer and reduces premature rehabilitation.

SSH Bastion integration

Threat Intel is also fed by SSH bastion security events:

• ssh.bastion.auth.denied
• ssh.bastion.forward.denied

Behavior:

• Repeated SSH denies increase XP/Level for the source IP.
• Soft-block duration from Settings is applied to SSH source checks as well.
• Hard-blocked source IPs are denied on both HTTP/HTTPS edge and SSH bastion.

This gives one shared abuse state across web and SSH entry points.

UI workflow

1. Open Threat Intel.
2. Verify policy mode and sync interval.
3. Review New for low-band, newly observed sources.
4. Review Watched for Level 3 to < hard level entries.
5. Review Blocked for active hard blocks.
6. Pivot by trace into Strategic Intel -> Investigations when the exact decision path matters.
7. Use Allow overrides only for verified false positives.

View model

• New
  • Level 0 to <3
  • contains sources that are noisy enough to be tracked, but not yet in the watched band
• Watched
  • Level 3 to < hard level
  • includes watch-level sources, soft-block states, and rehabilitated hard blocks returned to Level 3
• Blocked
  • active hard blocks at the configured hard level
  • these remain visible until retention-driven rehabilitation or manual release

Sources that fully decay and rehabilitate fall out of all three lists.

Trace correlation

Every visible Threat Intel table row should be treated as an investigation entry point.

• Each list exposes at least one trace ID.
• The trace can be opened directly in Strategic Intel -> Investigations.
• Investigations then shows:
  • case summary for the current trace
  • related prior contacts from the same source IP (Escalation Chain)
  • flow entries
  • evidence entries
  • action entries

This is the recommended way to reconstruct why a source was watched, blocked, or later rehabilitated.

Recommended operating pattern

1. Start in Monitor only for baseline collection.
2. Build allowlist entries for known trusted scanners/agents.
3. Switch to Auto mode.
4. Review Watched and Blocked trends daily.
5. Keep manual hard blocks for confirmed abuse only.

Troubleshooting notes

• For LAN/hairpin tests, some detections may be intentionally bypassed as internal traffic.
• Feed-listed IPs do not create action unless they actually touch the edge.
• Trace timelines are retained for 60 days, then pruned automatically.