Why go through the manager
A MikroTik router can send syslog to Wazuh on its own, but its default remote format has no host name. Wazuh then knows the router only by its IP address, and a router behind NAT or on a changing address is hard to tell apart from the next one.
When the manager forwards the lines, each one carries the router's name as it is in the manager. With the decoders below, Wazuh also reads the user, the source address, the way they connected, the command behind a configuration change and the interface behind a link change. Alerts then read like "MikroTik core-01: failed sign-in for admin via ssh from 203.0.113.7".
By default the manager keeps the latest 10,000 lines per device. Wazuh keeps them as long as you configure it to and can correlate them with the rest of your network, which is what an audit usually asks for.
What you need
- MikroTik Manager v2.0.0 or newer, with routers already sending syslog to it (see Logs).
- A Wazuh manager the manager can reach over UDP. The files were checked on Wazuh 4.14 with its dashboard 2.19.
- Root access on the Wazuh host, to copy files and restart the Wazuh manager.
Files
| File | Where it goes | What it does |
|---|---|---|
mikrotik_mikr_decoders.xml | /var/ossec/etc/decoders/ | Recognises a forwarded line and reads the topics, the message, user, source address, connection type, changed item and command, interface and link state. |
mikrotik_mikr_rules.xml | /var/ossec/etc/rules/ | Rules 100200 to 100213. Every line is kept, and only what needs a look raises an alert. |
mikrotik_mikr_dashboard.py | Run once on the Wazuh host | Creates the MikroTik (mikr) dashboard. Running it again replaces the dashboard with a fresh copy. |
If you already have your own rules numbered 100200 to 100213, renumber one set before you copy the file in.
Setting it up
1. Forward from the manager. In Settings → Syslog, turn on Forward to another collector, enter the Wazuh manager's address and keep port 514. Leave Forward from level at debug or info. Sign-ins and configuration changes are logged by RouterOS at the info level, so a higher setting keeps them away from Wazuh. More on these settings under Forwarding to another collector.
2. Let Wazuh listen. Add this block to /var/ossec/etc/ossec.conf on the Wazuh manager, with the manager's address in allowed-ips:
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips><MANAGER_IP></allowed-ips>
</remote>Open UDP 514 in the Wazuh host's firewall if it runs one.
3. Copy the decoders and rules, check them and restart:
cp mikrotik_mikr_decoders.xml /var/ossec/etc/decoders/
cp mikrotik_mikr_rules.xml /var/ossec/etc/rules/
chown wazuh:wazuh /var/ossec/etc/decoders/mikrotik_mikr_decoders.xml
chown wazuh:wazuh /var/ossec/etc/rules/mikrotik_mikr_rules.xml
/var/ossec/bin/wazuh-analysisd -t
systemctl restart wazuh-managerOn a host with SELinux, such as Rocky or RHEL, run restorecon on both files after copying. wazuh-analysisd -t prints nothing when the files are fine. Restart only after it passes.
4. Create the dashboard. On the Wazuh host, as root:
tar -xf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt
WAZUH_PASSWORDS_FILE=wazuh-install-files/wazuh-passwords.txt python3 mikrotik_mikr_dashboard.pyIt signs in to the Wazuh dashboard as admin, with the password the Wazuh installer saved in wazuh-install-files.tar. Without WAZUH_PASSWORDS_FILE it looks for /root/wazuh-passwords.txt. If you changed the admin password since, give it directly with WAZUH_ADMIN_PASSWORD instead. The dashboard then appears under Dashboards as MikroTik (mikr).
5. Check it. Sign in to a router over SSH with a wrong password. Within a minute the dashboard should show a failed sign-in with the router's name, the user and your address.
What raises an alert
Wazuh stores an alert from level 3 up. Its overview counts 0 to 6 as low and 7 to 11 as medium.
| Rule | Level | When |
|---|---|---|
| 100201 | 3 | Someone signed in over SSH, Winbox, the web interface and the like. Sign-ins over the API are automation, including the manager itself, and raise nothing. |
| 100202 | 7 | A failed sign-in. |
| 100203 | 10 | Six failed sign-ins from one address within two minutes: likely password guessing. |
| 100204 | 7 | Configuration changed by a person. Changes made by the scheduler or a script raise nothing. |
| 100205 | 5 | A link went down. |
| 100206 | 3 | A link came up. |
| 100207 | 7 | RouterOS reports a possible SYN flood. |
| 100210 | 10 | Any other line with the critical topic. |
| 100211 | 3 | A failed TLS handshake, mostly scanners trying an SSTP server. |
| 100212 | 5 | Any other line with the error topic. |
| 100213 | 3 | Any other line with the warning topic. |
Everything else matches rule 100200 at level 0: no alert. To keep those lines too, turn on Wazuh's archives (logall_json in ossec.conf and archives in Filebeat) and add a wazuh-archives-* index pattern.
To change a level, edit it in the rules file and restart the Wazuh manager. Keep your edits in mind when you download a newer version of the file.
The dashboard
- Counts for the period: alerts, failed sign-ins, password guessing, configuration changes, links down, errors, and everything at level 7 and up.
- Alerts over time, split by device, and a table of alerts per device.
- Failed sign-ins by device, user, source address and connection type.
- Configuration changed by a person, with who changed what.
- Links that went down, and errors and warnings.
- The latest alerts as a list.
It opens on the last 24 hours and refreshes every minute.
Limits
- There is no rule for a port that keeps going down and up. Wazuh cannot count such events per router here, so it would add up the same port name across all of them.
- Forwarding does not queue. Lines sent while Wazuh is down or unreachable do not reach it later.
- A line from an address the manager has no device for carries that address instead of a name.