Security Hardening

A Security Hardening module (Security group) that turns a manual RouterOS security review into repeatable, evidence-based tooling. It ships one audit_* (read-only) + harden_*/fix_* (scoped write) pair per risk category, plus an orchestrator that runs every category and applies fixes by ID.

The checks were distilled from a manual audit of a real production router (hAP ax3, dual-WAN, RouterOS 7.23) but are written to run against any RouterOS 7.x device this MCP manages.

• Engine (pure, no device I/O): src/core/security-hardening.ts
• Tools: src/tools/security-hardening.ts
• Tests: tests/core/security-hardening.spec.ts

Safety modelCopy Anchor Link

Every tool in the suite obeys the same contract:

• Read-only audits. audit_* and run_security_hardening_audit issue only print/export-class commands. They never add/set/remove.
• Explicit scoped writes. Every fix tool takes specific finding_ids (from a prior audit) plus confirm: true. There is no "fix everything" flag; a fix tool can never widen its own scope.
• Dry-run default. confirm=false (the default) returns the exact commands and writes nothing — it is silently ignored, never an error.
• Snapshot before write. Every apply captures a pre-change configuration snapshot (same local store as capture_config_snapshot) and returns the snapshot_id so you can diff_config_snapshots from=<id> to=live or roll back.
• Safe Mode. Any write that could cut management access (firewall/NAT/IP service/SSH/DNS/IPv6) runs inside enable_safe_mode → commit_safe_mode, so a rule that drops your own session auto-reverts. MAC-Telnet devices (no SSH) skip Safe Mode.
• Evidence-based findings. Every finding carries the exact .id/rule signature it applies to, the literal current value, the proposed action, and a confidence: proven (settled by static config) vs needs_live_verification (latent, or dependent on runtime chain/NAT interaction the config can't fully prove). The two are never blended.

The audit → apply lifecycleCopy Anchor Link

run_security_hardening_audit / audit_<category>        (read-only: print/export)
        │
        ▼   findings[]  — each with a stable finding_id + fix[]
        │
        ▼   caller picks finding_ids
apply_security_hardening_fixes(finding_ids, confirm)  /  harden_<category>(finding_ids, confirm)
        │
        ├─ confirm=false ─▶ DRY RUN: echo commands, write nothing
        │
        └─ confirm=true
               │
               ▼  capture snapshot   → snapshot_id (rollback point)
               ▼  enable Safe Mode   (SSH devices; skipped for MAC-Telnet)
               ▼  execute each finding's fix[] in safe order
               │       ├─ a command errors ─▶ rollback Safe Mode, report partial
               │       ▼
               ▼  commit Safe Mode
               │       └─ commit fails ─▶ changes revert; report NOT saved
               ▼
          per-finding results + snapshot_id

Apply order is fixed and safe: firewall default-deny and address-list enforcement land before service-exposure changes before helper/hygiene changes, so structural protection is in place before anything narrows reachability.

CategoriesCopy Anchor Link

OrchestratorCopy Anchor Link

• run_security_hardening_audit — runs every category (or a categories subset), returns one severity-ranked report with a summary count. Pure read.
• apply_security_hardening_fixes — applies explicit finding_ids in safe order inside one snapshot + Safe-Mode session; returns per-finding results and the snapshot_id. Requires confirm: true; never accepts a blanket flag.

Confidence: proven vs needs_live_verificationCopy Anchor Link

Some findings are unambiguous from static config (tcp-syncookies=no). Others are latent or depend on runtime behaviour: an IPv6 stack that forwards but has no address assigned yet, a reverse-proxy whose per-interface reachability a static config can't settle, or whether a firewall rule actually shadows a service. Those are labelled needs_live_verification in both the finding output and the code, and are never presented with the same certainty as a proven finding. Verify them against the live device before acting.

ExampleCopy Anchor Link

run_security_hardening_audit
# → findings, each with a finding_id, e.g.:
#   [CRIT] disabled_enforcement:input:3   (re-enable a disabled Winbox drop)
#   [HIGH] unenforced_list:port scanners  (list populated but never dropped)
#   [MED ] kernel:rp-filter               (rp-filter=no → loose on this multi-WAN box)

apply_security_hardening_fixes finding_ids=["unenforced_list:port scanners","kernel:rp-filter"]
# → DRY RUN preview (confirm defaulted false)

apply_security_hardening_fixes finding_ids=["unenforced_list:port scanners","kernel:rp-filter"] confirm=true
# → snapshot captured, Safe Mode enabled, fixes applied in safe order, committed
#   diff_config_snapshots from=<snapshot_id> to=live   # to review/rollback

Relationship to the other Security toolsCopy Anchor Link

• firewall_audit — shadowed/broad/duplicate/dead rule analysis + risk score.
• run_compliance_audit — scored A+–F posture across SSH/services/users/etc.
• harden_firewall (Security Shield) — applies a chosen preset of protective firewall rules.

Security Hardening is the granular, per-finding, remediate-by-ID layer: it tells you exactly which specific misconfiguration to fix and lets you apply just that one, safely.