Help
MikroTik Configuration
TowerOps supports read-only monitoring of MikroTik RouterOS devices over the RouterOS API. Alongside SNMP polling, TowerOps reads detailed system information over the API and creates configuration backups over SSH. TowerOps detects a MikroTik device from its SNMP discovery data, a manufacturer of MikroTik or a RouterOS system description, and only then offers the MikroTik configuration on the device.
Monitoring vs. Write Access
Monitoring stays read-only: SNMP and RouterOS API polling and configuration backup capture never change the router. Three write actions do, each behind a feature flag and a grant: configuration restore pushes a stored version back to the router under the :config_restore flag with the raw-download grant on config backups; the Device Tools tab's port bounce and RouterOS reboot run under the :device_tools flag for members holding the device edit grant and a stored write-capable login. Every write attempt is audited server-side.
Cloud or Agent-Based Connections
SNMP polling and MikroTik API polling both run on the poller the device resolves to, a cloud poller or your own remote agent, and configuration backups are queued to that same agent. For publicly accessible devices cloud polling is the simplest option; for devices on private networks, or when you prefer to keep credentials on your local network, deploy a remote agent.
Security Best Practices
Create a dedicated TowerOps account in RouterOS's built-in read group for SSH backups and API checks rather than using a full administrator account. The read group is broader than strictly read-only; review its actual policies before granting access. Storing only a read-group login keeps the write paths above unavailable to that credential.
Creating the TowerOps User
Connect as an administrator via SSH or terminal. For a new account, run this command to create towerops in the built-in read group:
/user add name=towerops group=read password=YOUR_STRONG_PASSWORD
Already created the MikroTik user?
Run this separately as an administrator on each router to change only the existing user's group. Its password, source-address restrictions, and other properties are preserved; existing custom groups are not deleted.
/user set [find where name="towerops"] group=read
Verify the account and the read group's actual policies:
/user print detail where name=towerops /user group print detail where name=read
Permissions Explained
The read group includes the permissions below, among others. TowerOps uses SSH for configuration backups, API for live checks, read for status, test for diagnostic ping, and sensitive for secret-bearing exports.
| Permission | Description |
|---|---|
| ssh | Allow SSH access to the device |
| read | Allow viewing configuration and status (read-only) |
| test | Allow executing diagnostic commands (ping, traceroute, etc.) |
| api | Allow API access for automated monitoring |
| sensitive | Allow reading sensitive values for configuration backups |
The trace page's connectivity checks rely on two of these policies: test lets TowerOps ping subscriber radios from the tower router, and read lets it read PPPoE sessions and the router log.
Important Notes
- The default read group denies write and policy changes, but also permits reboot, sniffing, sensitive-data access, and other management interfaces.
- Check the actual group policies; built-in groups may have been customized.
- Use a strong, unique password for the monitoring account
- Restrict account and service access to the source addresses of the poller that serves the device.
Configuring in TowerOps
After creating the TowerOps user, configure the credentials in TowerOps:
Organization-Level Configuration
Organization-wide defaults, the MikroTik login used for backups, live on the organization's Backups settings under Backups > Settings. Site and device credentials override them.
Site-Level Configuration
Site-level credentials are set on the site's edit form (the MikroTik API Configuration section). They override organization defaults for all devices at that location.
Device-Level Configuration
On the edit form of a detected MikroTik device you can enable MikroTik API access and give that device its own username, password, API port, and SSL preference, overriding the organization and site defaults. Leave the fields blank to inherit, and the form tells you which level the inherited credentials come from.
Security Recommendations
- Always use SSL/TLS for the RouterOS API connection (API-SSL on port 8729), it is mandatory when a cloud poller polls the device
- Store credentials at the organization or site level when possible
- Rotate passwords periodically following your security policies
- Monitor access logs for unauthorized connection attempts