@usex/mikrotik-mcp 4.24.0 → 5.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@usex/mikrotik-mcp",
-  "version": "4.24.0",
+  "version": "5.0.0",
   "description": "MCP server for MikroTik RouterOS — 780+ tools over SSH for firewall, NAT, routing, DHCP, DNS, WireGuard, wireless, QoS and more.",
   "keywords": [
     "ai",
@@ -30,6 +30,7 @@
   "workspaces": [],
   "files": [
     "dist",
+    "policies",
     "prompts",
     "schemas"
   ],
@@ -108,7 +109,7 @@
     "clsx": "^2.1.1",
     "gsap": "^3.15.0",
     "license-checker": "^25.0.1",
-    "lucide-react": "^1.27.0",
+    "lucide-react": "^1.28.0",
     "radix-ui": "^1.6.7",
     "react": "^19.2.8",
     "react-dom": "^19.2.8",

package/policies/baseline.yaml

@@ -0,0 +1,180 @@
+version: 1
+name: MikroTik baseline hardening
+# The bundled starter pack. Every rule here is drawn from a check the Security
+# Hardening and Compliance Auditor modules already make, restated in the policy
+# language so the file doubles as a worked example of the schema.
+#
+# Copy it, edit it, and point `policy.paths` at your own copy — these are a
+# starting position, not a standard.
+policies:
+  # ── Management plane ─────────────────────────────────────────────────────
+  - id: telnet-disabled
+    severity: critical
+    description: Telnet must be disabled — it carries credentials in clear text.
+    remediation: /ip service set telnet disabled=yes
+    match: { section: /ip/service, where: { name: telnet } }
+    assert: { field: disabled, equals: "yes" }
+    tags: [management, cis]
+
+  - id: ftp-disabled
+    severity: high
+    description: The FTP service must be disabled unless a device genuinely serves files.
+    remediation: /ip service set ftp disabled=yes
+    match: { section: /ip/service, where: { name: ftp } }
+    assert: { field: disabled, equals: "yes" }
+    tags: [management]
+
+  - id: ssh-strong-crypto
+    severity: high
+    description: SSH must use strong crypto (disables the legacy ciphers and 1024-bit DH).
+    remediation: /ip ssh set strong-crypto=yes
+    match: { section: /ip/ssh, settings: true }
+    assert: { field: strong-crypto, equals: "yes" }
+    tags: [management, crypto]
+
+  - id: ssh-forwarding-off
+    severity: medium
+    description: SSH TCP forwarding turns a router into a tunnel endpoint; leave it off unless a jump host needs it.
+    remediation: /ip ssh set forwarding-enabled=no
+    match: { section: /ip/ssh, settings: true }
+    assert:
+      none_of:
+        - { field: forwarding-enabled, equals: both }
+    tags: [management]
+
+  - id: no-default-admin
+    severity: critical
+    description: The stock `admin` account must be renamed or removed.
+    remediation: Create a named account with full policy, then /user remove admin
+    match: { section: /user, where: { name: admin } }
+    # Reaching this rule at all means an account literally named `admin` exists.
+    assert: { count: { exactly: 0 } }
+    on_empty: pass
+    tags: [accounts]
+
+  - id: users-have-comments
+    severity: low
+    description: Every account should say who it belongs to.
+    remediation: /user set <name> comment="owner"
+    match: { section: /user }
+    assert: { field: comment, present: true }
+    tags: [accounts, hygiene]
+
+  # ── Discovery & neighbour exposure ───────────────────────────────────────
+  - id: neighbor-discovery-scoped
+    severity: medium
+    description: Neighbour discovery must be limited to an interface list, not left on all interfaces.
+    remediation: /ip neighbor discovery-settings set discover-interface-list=LAN
+    match: { section: /ip/neighbor/discovery-settings, settings: true }
+    assert: { field: discover-interface-list, not_in: [all, none] }
+    tags: [discovery]
+
+  - id: mac-server-scoped
+    severity: medium
+    description: MAC-Telnet must be restricted to a management interface list.
+    remediation: /tool mac-server set allowed-interface-list=LAN
+    match: { section: /tool/mac-server, settings: true }
+    assert:
+      none_of:
+        - { field: allowed-interface-list, equals: all }
+    tags: [discovery, management]
+
+  - id: bandwidth-server-off
+    severity: low
+    description: The bandwidth-test server should be disabled when not actively testing.
+    remediation: /tool bandwidth-server set enabled=no
+    match: { section: /tool/bandwidth-server, settings: true }
+    assert: { field: enabled, equals: "no" }
+    tags: [services]
+
+  # ── Firewall ─────────────────────────────────────────────────────────────
+  - id: input-chain-has-drop
+    severity: critical
+    description: The input chain must end in an explicit drop — an implicit accept is not a firewall.
+    remediation: /ip firewall filter add chain=input action=drop comment="default deny"
+    match: { section: /ip/firewall/filter, where: { chain: input, action: drop } }
+    assert: { count: { min: 1 } }
+    tags: [firewall, default-deny]
+
+  - id: no-bare-input-accept
+    severity: critical
+    description: An input-chain accept must be scoped by address-list, interface list or connection state.
+    remediation: Add src-address-list=, in-interface-list= or connection-state= to the rule.
+    match: { section: /ip/firewall/filter, where: { chain: input, action: accept } }
+    assert:
+      any_of:
+        - { field: src-address-list, present: true }
+        - { field: in-interface-list, present: true }
+        - { field: connection-state, contains: established }
+        - { field: in-interface, present: true }
+    tags: [firewall]
+
+  - id: no-disabled-firewall-rules
+    severity: low
+    description: A disabled firewall rule is dead weight that hides intent — delete it or enable it.
+    remediation: Remove the rule, or enable it if it is still needed.
+    match: { section: /ip/firewall/filter }
+    # `none_of` rather than `not_equals`: a missing field fails every value
+    # predicate, and most rules simply omit `disabled=`. "must not be yes"
+    # (absent counts as fine) is `none_of`; "present and different" is
+    # `not_equals`. This is the single most common authoring mistake.
+    assert:
+      none_of:
+        - { field: disabled, equals: "yes" }
+    tags: [firewall, hygiene]
+
+  - id: ipv6-firewall-present
+    severity: high
+    description: A device with IPv6 addresses must also filter IPv6 — an IPv4-only firewall is half a firewall.
+    remediation: /ipv6 firewall filter add chain=input action=drop
+    match: { section: /ipv6/firewall/filter, where: { chain: input, action: drop } }
+    assert: { count: { min: 1 } }
+    on_empty: fail
+    tags: [firewall, ipv6]
+
+  # ── Kernel & routing ─────────────────────────────────────────────────────
+  - id: rp-filter-enabled
+    severity: high
+    description: Reverse-path filtering must be on, so spoofed source addresses are dropped.
+    remediation: /ip settings set rp-filter=strict
+    match: { section: /ip/settings, settings: true }
+    assert: { field: rp-filter, in: [strict, loose] }
+    tags: [kernel, anti-spoof]
+
+  - id: no-ip-forwarding-of-source-routes
+    severity: medium
+    description: Source-routed packets must not be accepted.
+    remediation: /ip settings set accept-source-route=no
+    match: { section: /ip/settings, settings: true }
+    assert:
+      none_of:
+        - { field: accept-source-route, equals: "yes" }
+    tags: [kernel]
+
+  # ── Time & logging ───────────────────────────────────────────────────────
+  - id: ntp-client-enabled
+    severity: medium
+    description: NTP must be enabled — every log timestamp and certificate check depends on it.
+    remediation: /system ntp client set enabled=yes servers=...
+    match: { section: /system/ntp/client, settings: true }
+    assert: { field: enabled, equals: "yes" }
+    tags: [time]
+
+  - id: remote-logging-configured
+    severity: medium
+    description: At least one logging action must ship logs off the device; local logs die with the router.
+    remediation: /system logging action add name=remote target=remote remote=<syslog-host>
+    match: { section: /system/logging/action, where: { target: remote } }
+    assert: { count: { min: 1 } }
+    on_empty: fail
+    tags: [logging]
+
+  - id: dns-not-open-resolver
+    severity: high
+    description: Remote DNS requests must be off, or the router becomes an open resolver for amplification attacks.
+    remediation: /ip dns set allow-remote-requests=no (or firewall port 53 on the WAN)
+    match: { section: /ip/dns, settings: true }
+    assert:
+      none_of:
+        - { field: allow-remote-requests, equals: "yes" }
+    tags: [dns, amplification]

package/prompts/backup-and-document.md

@@ -14,24 +14,34 @@ change is creating a backup/export.
    written on the router's flash. Give it a descriptive `label` (e.g. `pre-audit`).
 2. **Device restore point** — `create_backup` (binary, for full restore) and
    `create_export` (text `.rsc`, for review/diff). List them with `list_backups`.
-3. **Inventory** — gather the configuration with read tools and organize it:
-   - System: `get_system_identity`, `get_system_resources`, `get_routerboard`,
-     `get_installed_packages`.
-   - L2/L3: `list_interfaces`, `list_vlan_interfaces`, `list_bridges`,
-     `list_ip_addresses`, `list_ip_pools`.
-   - Services: `list_dhcp_servers`, `get_dns_settings`, `list_dns_static`,
-     `list_ip_services`.
-   - Routing: `list_routes`, `get_routing_table`.
-   - Security: `list_filter_rules`, `list_nat_rules`, `list_address_lists`,
-     `list_users`, `list_certificates`.
-   - VPN/QoS: `list_wireguard_interfaces` + `list_wireguard_peers`,
-     `list_simple_queues`, `list_queue_trees`.
-   - Containers: `list_containers` (if the container feature is enabled).
-   - Automation: `list_schedulers`, `list_scripts`.
+3. **The write-up** — call `explain_device`. It analyses the configuration on the
+   MCP host and returns a finished architecture document: inferred role with the
+   signals behind it, topology with a Mermaid diagram, addressing and DHCP
+   scopes, the internet path, what each firewall chain does, what is exposed to
+   the internet, tunnels, management services, and an explicit list of anything
+   it did not recognise.
 
-Produce a structured Markdown report: a one-paragraph overview, a table of
-interfaces and addressing, the firewall posture, and a "things worth reviewing"
-section (defaults left in place, disabled-but-present rules, expiring certs —
-check `list_certificates` for any expiring within 30 days).
+   Do **not** pull `/export` into the conversation to write this by hand. The
+   tool's output is a fraction of the size, already analysed, and identical
+   across runs — which is what lets `diff_explanations` compare two dates later.
+   Use `explain_section` when the user asks about one area rather than the whole
+   router.
+
+4. **Fill the gaps `explain_device` deliberately leaves.** A configuration export
+   describes what is _defined_, never what is _running_, so add the live facts it
+   cannot know:
+   - `get_system_resources`, `get_routerboard`, `get_installed_packages` — uptime,
+     hardware, what is actually installed.
+   - `list_certificates` — flag anything expiring within 30 days.
+   - `get_wireguard_status`, `list_ipsec_active_peers` — which tunnels are up
+     right now, as opposed to merely configured.
+   - `list_schedulers`, `list_scripts` — scheduled automation.
+5. **Things worth reviewing** — run `firewall_audit` and
+   `run_security_hardening_audit` and summarise their findings rather than
+   re-deriving them by eye. Read the narrative's "what this document does not
+   cover" section aloud to the user: that is the part nobody understood, and it
+   is where the surprises live.
+
+Present the narrative first, then the live facts, then the review section.
 Reference the snapshot id and backup/export filenames you created so the user
 knows their restore points.

package/prompts/build-tunnel-transactionally.md

@@ -0,0 +1,74 @@
+---
+name: build-tunnel-transactionally
+title: Build a site-to-site tunnel as one cross-device transaction
+description: Configure both ends of a tunnel under coordinated Safe Mode — verified while still uncommitted, then committed everywhere or rolled back everywhere. Never a half-built tunnel.
+arguments:
+  - name: site_a
+    description: Configured device name of the first router (one end of the tunnel).
+    required: true
+  - name: site_b
+    description: Configured device name of the second router (the other end).
+    required: true
+  - name: tunnel
+    description: What to build (e.g. "WireGuard 10.99.0.0/30", "GRE over the existing WAN", "IPsec site-to-site"). If omitted, WireGuard is a good default.
+    required: false
+---
+
+Build a tunnel between **{{site_a}}** and **{{site_b}}** as a single
+cross-device transaction, so it either works on both ends or exists on neither.
+
+Tunnel to build: {{tunnel}}
+
+The failure this avoids: configured end-by-end, a tunnel whose second half fails
+leaves the first half live — and if the failing change was a firewall rule, a
+router you can no longer reach. Under a transaction each device stages its
+changes in its own Safe Mode session; nothing persists until every end has been
+verified.
+
+Follow these steps:
+
+1. **Look before you write.** Read both ends: `list_interfaces`,
+   `list_ip_addresses`, and for WireGuard `list_wireguard_interfaces` /
+   `list_wireguard_peers`. Pick addresses and a port that do not collide with
+   anything already configured, and note which device you reach the other
+   THROUGH (that one must commit last).
+
+2. **Open the transaction.** Call `begin_transaction` with
+   `devices=["{{site_a}}", "{{site_b}}"]`, a `label`, and — this is the part that
+   makes it safe — `assertions` that prove the tunnel actually works:
+   - `{"kind": "ping", "from": "{{site_a}}", "to": "<{{site_b}} tunnel address>"}`
+   - `{"kind": "wireguard-peer-handshake", "device": "{{site_a}}", "peer": "<{{site_b}} public key>"}`
+     (WireGuard only)
+   - `{"kind": "reachable", "device": "{{site_b}}"}` — cheap insurance that the
+     far end is still answering after its own changes.
+     Set `jump_host` if one router is reached through the other; the tool warns
+     when it is not committed last.
+
+3. **Queue every command.** One `add_transaction_step` per RouterOS command,
+   naming the participant it runs on. Nothing executes yet. Cover both ends
+   completely: interface, addresses, peer/keys, the firewall rule that permits
+   the tunnel port, and the route(s) over it.
+
+4. **Prepare and verify.** Call `verify_transaction`. This snapshots each device,
+   applies its steps inside Safe Mode, and runs the assertions against the
+   still-uncommitted fleet. If anything fails, everything is rolled back
+   automatically and the result is `ABORTED` — nothing changed anywhere. Report
+   which assertion failed and fix the plan before retrying.
+
+5. **Commit.** Only after a clean verify, call `commit_transaction`. Read the
+   terminal state out loud:
+   - `COMMITTED` — both ends persisted; confirm with a final `ping` and
+     `get_wireguard_status`.
+   - `ABORTED` — nothing changed; safe to retry.
+   - `PARTIAL` — **tell the user immediately and stop**. Name each device's state
+     and the snapshot id in the report; the fix is a manual restore
+     (`diff_config_snapshots <id> live`, then `config_reconcile` or
+     `restore_backup`), not another blind attempt.
+
+6. **If you need to back out** at any point before commit, call
+   `abort_transaction` — it closes every Safe Mode session and RouterOS reverts
+   the staged changes.
+
+Be explicit about the limits when you report: this is a best-effort distributed
+commit, not a database transaction. Commits are sequential, so there is a
+seconds-long window where one end is committed and the other is not.

package/prompts/fleet-rollout.md

@@ -0,0 +1,68 @@
+---
+name: fleet-rollout
+title: Roll one change out across the fleet, safely
+description: Apply the same change to many routers as canary → wave → fleet, with a health gate and soak between waves and automatic revert of everything already changed on the first failure.
+arguments:
+  - name: change
+    description: What to change on every device (e.g. "set the NTP servers to 10.0.0.1 and 10.0.0.2", "add the management address-list entry", "disable the telnet service").
+    required: true
+  - name: targets
+    description: Which devices — a list of names, "all", or a tag (e.g. "branch"). If omitted, ask before selecting anything.
+    required: false
+---
+
+Roll this change out across the fleet: **{{change}}**
+
+Targets: {{targets}}
+
+This is the highest-blast-radius thing in the toolbox: one mistake, applied
+automatically to every router. The structure that makes it safe is
+canary → wave → fleet with a health gate between waves — use it, and show your
+work before executing.
+
+Follow these steps:
+
+1. **Turn the request into exact commands.** Work out the RouterOS commands for
+   the change and check them against one device's current config first (a `get_*`
+   or `list_*` read). A rollout applies the same commands everywhere, so a
+   command that depends on a device-specific name (an interface, a list) is a
+   trap — say so rather than rolling it out.
+
+2. **Preview with `plan_rollout`.** It contacts nothing. Show the human:
+   - which devices matched (and, for a selector, which were excluded and why),
+   - the wave split — the canary is the device that will find the problem,
+   - the exact commands, and the estimated duration.
+     Order matters for an explicit list: put the router you reach the others
+     THROUGH **last**, so a change that severs its path cannot strand the rest.
+
+3. **Get agreement before executing.** Do not call `start_rollout` on your own
+   initiative for a fleet-wide change. Present the plan and ask.
+
+4. **Execute with `start_rollout confirm=true`.** Defaults worth stating out
+   loud when you do:
+   - `soakSeconds=30` — the wait after each wave's health check. A change that
+     breaks connectivity ten seconds later must not already be on every router.
+   - `onFailure=halt-and-revert` — the first failed gate stops the rollout and
+     restores every device it already changed, newest first.
+     Raise the soak for anything touching routing, firewall or interfaces; those
+     break with a delay.
+
+5. **Read the terminal state out loud.** Each one means something different:
+   - `COMPLETED` — every device applied the change.
+   - `HALTED and REVERTED` — a gate failed; the fleet is back where it started.
+     Report WHICH device and why, especially if the failure was on an untouched
+     device (that means the change broke something fleet-wide).
+   - `HALTED` (`halt-and-hold`) — changed devices are still changed, on purpose,
+     for inspection.
+   - `COMPLETED WITH FAILURES` — `continue` was set; list what failed.
+   - `NEEDS ATTENTION` — **stop and tell the user immediately.** A revert itself
+     failed; the report names the device and the snapshot id. The fix is a manual
+     restore (`diff_config_snapshots <id> live`, then `config_reconcile`), not
+     another rollout.
+
+6. **Verify a sample afterwards.** Read the changed setting back from the canary
+   and from one device in the last wave. A rollout that reports success and a
+   device that actually has the setting are two different facts.
+
+To stop a rollout in flight: `abort_rollout` — it reverts everything this
+rollout changed, regardless of `onFailure`.

package/prompts/setup-traffic-flow.md

@@ -0,0 +1,68 @@
+---
+name: setup-traffic-flow
+title: Set up continuous traffic analytics (NetFlow/IPFIX)
+description: Enable /ip traffic-flow, point the router at this host's collector, and start answering "who is using my bandwidth" continuously — cheap flow metadata, no packet payload.
+arguments:
+  - name: collector_address
+    description: The IP address of THIS MCP host as the router sees it (e.g. 192.168.88.50). If omitted, work it out from the router's neighbour/ARP table or ask.
+    required: false
+  - name: interfaces
+    description: Which interfaces to sample (e.g. "ether1", "bridge"). Defaults to all.
+    required: false
+---
+
+Set up continuous traffic-flow analytics for this MikroTik device.
+
+Collector address: {{collector_address}}
+Interfaces to sample: {{interfaces}}
+
+**Explain this before you do it.** Traffic Flow makes the router export a
+continuous stream of flow records — source and destination address, ports,
+protocol, byte and packet counts — to a collector over UDP. It carries **no
+packet payload**, which is exactly why it is cheap and privacy-preserving next
+to the packet sniffer, but it is still a description of who on the network talks
+to whom, sent continuously to a host. Say where it will be sent, and confirm the
+address is one the user controls.
+
+Follow these steps:
+
+1. **Look before you write.** `get_traffic_flow_settings` and
+   `list_traffic_flow_targets` — flow export may already be on and pointed
+   somewhere. If a target already exists that is NOT this host, mention it
+   rather than silently adding a second.
+
+2. **Work out the collector address.** It must be this MCP host's address _as
+   the router sees it_ — not `127.0.0.1`, which would make the router export to
+   itself. If it was not supplied, look at the router's `/ip address` and
+   neighbour tables to find the management subnet, and confirm the choice with
+   the user rather than guessing.
+
+3. **Start the receiver first.** `start_flow_collector` (default UDP 2055).
+   Starting the exporter before the collector just throws the first minutes of
+   data away.
+
+4. **Point the device at it.** `add_traffic_flow_target` with
+   `dst_address=<collector>`, `port=2055`, `version=9`. Use **9 or ipfix** —
+   v5 is IPv4-only and has no template mechanism, so IPv6 flows would be missing
+   entirely. A short `v9_template_timeout` (e.g. `30s`) makes the first decoded
+   flows appear sooner.
+
+5. **Enable export.** `set_traffic_flow_settings` with `enabled=true` and the
+   requested `interfaces` (default all). Mention the two timeouts:
+   `active_flow_timeout` (default 30m) is how long a long-lived flow is held
+   before being reported — lower it if the user wants fresher numbers and can
+   accept more export traffic.
+
+6. **Wait for the first template, then verify.** v9/IPFIX exporters send the
+   template periodically and data records are undecodable until it arrives, so
+   the first minute or two can legitimately be empty. Then run
+   `flow_top_talkers` — if it is still empty, its output names the reason
+   (collector not running, nothing received, templates pending, decode errors);
+   act on that rather than guessing.
+
+7. **Report what they now have.** Top talkers for the last window, and where to
+   look next: `analyze_flows` for the full report, the dashboard's **Flows**
+   page for the live view.
+
+To undo all of this later: `remove_traffic_flow_target`,
+`set_traffic_flow_settings enabled=false`, `stop_flow_collector`.

package/schemas/README.md

@@ -7,7 +7,7 @@ edit by hand — regenerate instead.
 | File                 | Contents                                                                                   |
 | -------------------- | ------------------------------------------------------------------------------------------ |
 | `config.schema.json` | The runtime configuration object (env vars / CLI flags).                                   |
-| `tool-catalog.json`  | Every one of the 833 tools: `name`, `risk`, `title`, `description`, and input JSON Schema. |
+| `tool-catalog.json`  | Every one of the 885 tools: `name`, `risk`, `title`, `description`, and input JSON Schema. |
 | `tools/<name>.json`  | The input JSON Schema for a single tool.                                                   |
 
 `risk` is derived from the MCP tool annotations: