@usex/mikrotik-mcp 3.51.0 → 3.52.0

package/prompts/setup-port-knocking.md

@@ -0,0 +1,53 @@
+---
+name: setup-port-knocking
+title: Hide management behind port knocking
+description: Conceal SSH/Winbox/API behind a secret port-knock sequence that temporarily opens access from the knocking IP.
+arguments:
+  - name: services
+    description: Which services to protect (comma-separated, e.g. "ssh,winbox,api"). Default is SSH and Winbox.
+    required: false
+  - name: knock_ports
+    description: Comma-separated port sequence for the knock (e.g. "1234,5678,9012"). If omitted, random ports are chosen.
+    required: false
+---
+
+Set up port knocking on this MikroTik device to hide management services behind a
+secret port sequence. Only IPs that complete the knock sequence get temporary
+access — everyone else sees the ports as closed.
+
+Services to protect: {{services}}
+Knock port sequence: {{knock_ports}}
+
+Steps:
+
+1. **Check current access.** Call `list_ip_services` to see which management
+   services are enabled. Call `list_filter_rules` with `chain=input` to review
+   existing access rules.
+
+2. **Set up the knock sequence.** Call `setup_port_knock` with the services to
+   protect and the port sequence (or let it generate random ports). This creates:
+   - Firewall address-lists that track the knock progress per source IP.
+   - Filter rules that move an IP through the stages as it hits each port.
+   - A final rule that allows access to the protected services for IPs that
+     complete the full sequence (with a timeout, typically 15 minutes).
+   - A drop rule for the protected services from all other IPs.
+
+3. **Verify the knock.** Test that:
+   - Without knocking, the protected ports are unreachable.
+   - After sending packets to the knock ports in order, access opens.
+   - After the timeout, access closes again.
+
+4. **Document.** Present the knock sequence clearly so administrators can save it
+   somewhere secure. Include example commands to knock from a client:
+
+   ```
+   nmap -Pn --host-timeout 100 -p PORT1 ROUTER_IP
+   nmap -Pn --host-timeout 100 -p PORT2 ROUTER_IP
+   nmap -Pn --host-timeout 100 -p PORT3 ROUTER_IP
+   ```
+
+5. **Safety warning.** Remind the user to keep a backup access method (e.g.
+   MAC-Telnet from a local network, or a trusted IP that bypasses the knock)
+   to avoid being locked out.
+
+Do not apply changes without user approval.

package/prompts/setup-threat-feeds.md

@@ -0,0 +1,47 @@
+---
+name: setup-threat-feeds
+title: Subscribe to threat intelligence feeds
+description: Import external threat-intel IP blocklists into firewall address-lists with automatic scheduled updates.
+arguments:
+  - name: feed_url
+    description: URL of the threat feed (one IP per line). If omitted, a well-known public feed will be suggested.
+    required: false
+  - name: list_name
+    description: Firewall address-list name to populate (e.g. "threat-blocklist"). Default is chosen automatically.
+    required: false
+---
+
+Subscribe this MikroTik device to an external threat intelligence feed that
+automatically imports malicious IPs into a firewall address-list and keeps it
+updated on a schedule.
+
+Feed URL: {{feed_url}}
+Address-list name: {{list_name}}
+
+Steps:
+
+1. **Choose the feed.** If {{feed_url}} is not provided, suggest a well-known
+   public feed (e.g. Spamhaus DROP, Emerging Threats, or abuse.ch). Explain what
+   the feed contains and its update frequency.
+
+2. **Subscribe.** Call `subscribe_threat_feed` with the feed URL and address-list
+   name. This creates a scheduled script that periodically fetches the feed and
+   imports the IPs into the specified address-list.
+
+3. **Verify the import.** Call `list_address_lists` and check that the list exists
+   and contains entries. Report the count.
+
+4. **Create firewall rules.** Add drop rules referencing the address-list:
+   - `create_filter_rule` in the `forward` chain: drop traffic with
+     `src-address-list={{list_name}}` or `dst-address-list={{list_name}}`.
+   - `create_filter_rule` in the `input` chain: drop incoming connections from
+     the list.
+     Use Safe Mode (`enable_safe_mode`) before adding firewall rules.
+
+5. **Confirm the schedule.** Call `list_schedulers` to verify the update script
+   is scheduled (e.g. every 6 or 24 hours).
+
+6. **Report.** The feed URL, address-list name, number of entries imported,
+   firewall rules created, and the update schedule.
+
+To remove a feed later, use `remove_threat_feed`.

package/prompts/setup-vlan-network.md

@@ -0,0 +1,47 @@
+---
+name: setup-vlan-network
+title: Design and deploy VLAN segments
+description: Create isolated VLAN segments with gateway addressing, DHCP, and inter-VLAN firewall policy — previewed before apply.
+arguments:
+  - name: vlans
+    description: Describe the VLANs you need — e.g. "management=10, staff=20, IoT=30, guest=40" (name=VLAN-ID).
+    required: true
+  - name: trunk_interface
+    description: The interface to use as a VLAN trunk (e.g. "ether1", "bridge"). If omitted, the main bridge is used.
+    required: false
+---
+
+Design and deploy a VLAN-segmented network on this MikroTik device. Each VLAN
+gets its own subnet, gateway IP, DHCP server, and firewall isolation. All changes
+are previewed before applying.
+
+VLANs requested: {{vlans}}
+Trunk interface: {{trunk_interface}}
+
+Follow these steps — confirm the plan before applying any changes:
+
+1. **Understand the current layout.** Call `list_interfaces`, `list_bridges`,
+   `list_ip_addresses`, and `list_dhcp_servers` to understand what exists.
+
+2. **Design each VLAN segment.** For each VLAN in {{vlans}}, call
+   `design_network_segment` in **preview mode** with:
+   - VLAN ID and name.
+   - A subnet (auto-assigned or specified — e.g. 10.10.{vlan_id}.0/24).
+   - Gateway address (.1 in the subnet).
+   - DHCP pool range.
+   - Isolation policy (whether this VLAN can reach others).
+
+3. **Review the plan.** Present a summary table:
+   - VLAN ID, name, subnet, gateway, DHCP range.
+   - Firewall rules that will be created for inter-VLAN isolation.
+   - Bridge/trunk configuration changes.
+
+4. **Apply.** With user approval, run `design_network_segment` again with apply
+   mode for each VLAN.
+
+5. **Verify.** Call `list_vlan_interfaces` to confirm VLANs are created,
+   `list_ip_addresses` for gateway IPs, `list_dhcp_servers` for DHCP, and
+   `list_filter_rules` for the isolation firewall rules.
+
+Report the complete VLAN map and any follow-ups (e.g. switch port VLAN
+assignments, wireless SSID-to-VLAN mappings).

package/prompts/troubleshoot-network.md

@@ -0,0 +1,45 @@
+---
+name: troubleshoot-network
+title: Intelligent root-cause diagnosis
+description: Autonomously investigate a network problem across connectivity, routing, firewall, NAT, DHCP, DNS, and system resources — ranked hypotheses with fix commands.
+arguments:
+  - name: symptom
+    description: Describe the problem in plain language (e.g. "users on VLAN 20 can't reach the internet", "BGP session to 10.0.0.1 keeps dropping").
+    required: true
+  - name: scope
+    description: Limit investigation to specific dimensions (comma-separated). Options — connectivity, interfaces, routing, firewall, nat, dhcp, dns, resources, logs, vpn. Omit for full investigation.
+    required: false
+---
+
+Investigate a network problem on this MikroTik device using the intelligent
+root-cause analyzer. It autonomously probes across up to 10 dimensions and
+correlates evidence into ranked hypotheses.
+
+Symptom: {{symptom}}
+Investigation scope: {{scope}}
+
+Follow this workflow:
+
+1. **Automated diagnosis.** Call `diagnose` with the symptom description (and
+   optional scope). It will autonomously investigate connectivity, interfaces,
+   routing (BGP/OSPF), firewall, NAT, ARP/DHCP, DNS, CPU/memory, logs, and VPN —
+   then return ranked root-cause hypotheses with confidence levels.
+
+2. **Review hypotheses.** Present each hypothesis with:
+   - Confidence level (high/medium/low).
+   - The evidence that supports it.
+   - The specific fix command(s) provided.
+
+3. **Deep-dive if needed.** For the top hypothesis:
+   - If routing is involved, call `trace_path` for hop-by-hop path analysis.
+   - If logs suggest cascading failures, call `correlate_events` to surface the
+     chain (e.g. interface down → OSPF neighbor lost → route withdrawn).
+
+4. **Quick fix option.** Call `suggest_fix` for a condensed list of actionable
+   commands with one-line explanations — useful when you just need the fix
+   without the full diagnostic report.
+
+5. **Apply fix (with approval).** Present the recommended fix commands and apply
+   only after the user approves. Use Safe Mode for firewall changes.
+
+Do not apply any changes without user approval.

package/prompts/upgrade-firmware.md

@@ -0,0 +1,48 @@
+---
+name: upgrade-firmware
+title: Upgrade RouterOS firmware safely
+description: Check for updates, capture a health baseline, stage packages, and apply the upgrade with automatic rollback on failure.
+arguments:
+  - name: channel
+    description: Update channel — "stable", "long-term", or "testing". Default is the device's current channel.
+    required: false
+---
+
+Upgrade this MikroTik device's RouterOS firmware safely. The upgrade pipeline
+captures a health baseline before upgrading so you can verify the device is
+healthy afterwards — and RouterOS will automatically fall back to the previous
+version if the upgrade fails.
+
+Update channel: {{channel}}
+
+Follow these steps in order:
+
+1. **Check for updates.** Call `firmware_check` to discover available versions,
+   compare against the current version, and assess upgrade readiness (CPU load,
+   free memory, version jump size). If no update is available, report that and
+   stop.
+
+2. **Capture a restore point.** Call `capture_config_snapshot` with
+   `label=pre-upgrade` to store the current `/export` locally. This is your
+   rollback reference — zero footprint on the device's flash.
+
+3. **Review the upgrade plan.** Present: current version → target version, the
+   version jump (major/minor/patch), and any readiness warnings from step 1.
+   Confirm with the user before proceeding.
+
+4. **Stage the packages.** Call `firmware_stage` to pre-download the update
+   packages without rebooting. This lets you verify the download succeeds before
+   committing to the reboot.
+
+5. **Apply the upgrade.** Call `firmware_upgrade` to install and reboot. The
+   device will come back on the new version. If it fails to boot, RouterOS
+   automatically falls back to the previous version.
+
+6. **Verify post-upgrade health.** Call `firmware_status` — it compares the
+   current system health against the pre-upgrade baseline and reports any
+   regressions (CPU, memory, package changes, RouterBOARD firmware status).
+
+7. **Confirm.** Report the old version, new version, health comparison, and
+   whether the RouterBOARD firmware also needs upgrading (if applicable).
+
+Do not proceed past step 3 without user approval.