Purpose
This guide explains how to configure the Mikrotik Response integration in Logsign USO, so that Incidents and Alarms can automatically, or an analyst can manually, block or unblock an IP via a firewall address list, add or remove a blackhole (null) route, and inspect the router's firewall address list and routing table on a MikroTik RouterOS device. This is a Response (action) integration, configured under Settings > Integrations > Responses > +Device; it is unrelated to the separate "Mikrotik Integration via Syslog" log collection guide.
Prerequisites
- A MikroTik RouterOS device with its API (typically the RouterOS API service, not the syslog output) reachable from the Logsign server.
- A RouterOS user account with permission to modify firewall address lists and routes.
- Use least privilege. Create a dedicated RouterOS user for this integration with a policy group scoped to write, test, and the specific firewall/route permissions needed, rather than the full-access default admin account.
Step 1: Prepare RouterOS for API Access
- Log in to the MikroTik router (via Winbox, WebFig, or the CLI) with an administrator account.
- Create a dedicated user with a restricted policy group for Logsign to use, and confirm the RouterOS API service is enabled (Services in RouterOS).
- Note the router's IP address and the username/password for the account.
Step 2: Configure the Integration in Logsign USO
In Logsign USO, go to Settings > Integrations > Responses, search for MikroTik, click Configure then +Device, and fill in:
| Field | Required | Description |
|---|---|---|
| Device Name | Yes | Free-text label identifying this MikroTik device in Logsign. |
| Host | Yes | IP address of the router. |
| Username | Yes | The RouterOS account username from Step 1. |
| Password | Yes | Password for that account. Stored encrypted at rest. |
| Insecure Skip Verify | Yes | Disables TLS certificate validation on Logsign's outbound calls to the router when enabled, if the RouterOS API is configured with TLS. Leave off unless you have a specific reason to keep it on. |
Click Create to save the device.
Available Methods
- firewall_address_list (Analysis) — lists entries in a firewall address list.
- block_ip (Containment) — adds an IP to a named firewall address list, to be matched by a corresponding drop/block rule already configured on the router.
- unblock_ip (Recovery) — removes an IP from the named firewall address list.
- list_route_table (Analysis) — lists the router's current routing table.
- add_blackhole_route (Containment) — adds a null route for an IP, dropping its traffic at the routing layer rather than via a firewall rule.
- delete_blackhole_route (Recovery) — removes a previously added blackhole route.
Note that block_ip only adds the IP to an address list; actual blocking depends on a firewall rule on the router that matches traffic against that address list and drops/rejects it. Confirm such a rule exists before relying on block_ip for containment. add_blackhole_route does not have this dependency, since a blackhole route drops matching traffic by itself.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| 401/Connection refused | Wrong Username/Password, or the RouterOS API service is not enabled. | Re-enter the Username and Password fields, and confirm the API service is enabled under Services on the router. |
| 403 / permission denied on the router | The account's policy group does not include the required permissions (write, firewall, route). | Confirm the account's policy group in RouterOS includes the permissions needed for firewall and route management. |
| block_ip succeeds but traffic is not actually blocked | No firewall rule matches against the address list used by block_ip. | Confirm a drop/reject firewall rule referencing the same address list exists and is active on the router. |
Notes and Limits
- This is a separate integration from the "Mikrotik Integration via Syslog" log collection guide; that guide brings MikroTik logs into Logsign, this one lets Logsign act on a MikroTik router. Both can be configured independently and are not required together.
- The exact RouterOS user/policy-group setup for a least-privilege account was not independently verified against a live router during this research (not independently verified); the field names and method behavior above are taken directly from Logsign's integration code.