Monitoring MikroTik RouterOS with Wazuh

Monitoring MikroTik RouterOS with Wazuh

Posted on September 21, 2025
12 min read
wazuh mikrotik siem security routeros
index

Network security monitoring has become increasingly critical as cyber threats continue to evolve and target network infrastructure. When you combine MikroTik’s powerful RouterOS with Wazuh’s robust security information and event management (SIEM) capabilities, you create a formidable defense system that can detect, analyze, and respond to security incidents in real-time.

In this guide, I’ll walk you through the process of configuring MikroTik RouterOS to send its logs to a Wazuh server, then create custom decoders and rules to make sense of that data and get alerts that the security teams can act on.

If you are interested in the complete decoders and ruleset, you can find them in this note’s GitHub repository:

https://github.com/root-security-eu/notes-monitor-mikrotik-with-wazuh

Section titled Understanding%20the%20Foundation

As a MikroTik router usually sits at a critical point in your network, seeing all traffic that flows in and out, it generates logs about connection attempts, firewall actions, and routing decisions. However, these logs are only useful if they’re properly collected, parsed, and analyzed.

Wazuh, an open-source SIEM solution, excels at taking raw log data and transforming it into actionable security intelligence. By connecting these two systems, we’re essentially giving the security team the ability to monitor and respond in realtime to network-level threats.

Section titled Prerequisites%20and%20Environment%20Setup

To perform this integration, you’ll need several components in place. First, ensure you have a MikroTik device running RouterOS version 7.x or later, as earlier versions may have limited syslog functionality. Your Wazuh server should be running version 4.12 or newer to take advantage of the latest parsing capabilities.

From a network perspective, verify that your MikroTik router can reach your Wazuh server on the network. This might seem obvious, but firewall rules or network segmentation can sometimes block the communication path. You’ll also need administrative access to both systems to make the necessary configuration changes.

Section titled Configuring%20RouterOS%20for%20Centralized%20Logging

We’ll begin by configuring your MikroTik router to send logs to your Wazuh server. RouterOS uses a syslog mechanism for this purpose, which is a standardized way of sending log messages across networks.

First, connect to your MikroTik router using Winbox, WebFig, or SSH. The method you choose doesn’t matter, as I’ll provide RouterOS commands that work across all these access methods.

The initial step involves configuring a syslog action, which tells RouterOS where to send the logs and in what format:

Terminal window
/system logging action add name=wazuhserver target=remote remote=192.168.1.100 remote-port=514 remote-log-format=syslog\
    remote-protocol=udp syslog-facility=daemon syslog-severity=auto syslog-time-format=bsd-syslog

Note: Replace 192.168.1.100 with your actual Wazuh Manager server or Wazuh load balancer IP address. The standard syslog port is 514 using UDP, but you can change this to any other port and protocol if needed.

The command above creates a logging destination called wazuhserver that will send logs to the Wazuh Manager server using the standard BSD-syslog format, including with it the timestamps, host, and other useful information that Wazuh can use to properly categorize and process the logs.

Next, we need to configure which types of logs should be sent to Wazuh.

RouterOS categorizes logs into different topics, and we should be selective about what we send to avoid pushing to the SIEM unnecessary information:

Terminal window
# These are some of the security-relevant categories I used


# For firewall events
/system logging add topics=firewall prefix="MKT[001][FW]" action=wazuhserver
# For system config events
/system logging add topics=system prefix="MKT[001][SYS]" action=wazuhserver
# For DHCP events
/system logging add topics=dhcp,info prefix="MKT[001][DHCP]" action=wazuhserver

Each of these rules tells RouterOS to send logs from specific categories to the Wazuh server. The firewall topic is particularly valuable as it captures all firewall rule matches, including blocked connections and allowed traffic that you’ve specifically configured to log.

For more granular visibility into what traffic is being allowed or blocked, we might also want to enable logging for specific firewall rules:

Terminal window
/ip firewall filter set [find chain=input comment~"my-security-rule"] log=yes log-prefix="[SEC] INPUT-RULE"

I am using the prefix and log-prefix to help target the log lines when decoding them within Wazuh. By using this following format: MKT[DEVICE_ID][LOG_TYPE] it will help optimize the Wazuh decoding processing, thus reducing resources.

Section titled Preparing%20Wazuh%20to%20Receive%20RouterOS%20Logs

Once we have configured the RouterOS, let’s shift our focus to the Wazuh server configuration. Wazuh can automatically ingest BSD syslog format logs without additional tools. But if your environment is larger, you might want to set up a separate syslog machine, using rsyslog or syslog-ng. And this will give you the option of using Wazuh’s own agent to collect these events which can have many benefits, like ingest rate limiting, caching, etc.

In this guide we’ll just use Wazuh for simplicity.

To ensure that Wazuh is configured to accept syslog messages edit the Wazuh manager configuration file, typically located at /var/ossec/etc/ossec.conf on the Wazuh manager, or from the UI at Server Management > Settings > Edit Configuration:

<!-- Add this configuration block to enable syslog reception -->
<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.1.0/24</allowed-ips>
</remote>

The allowed-ips parameter restricts which IP addresses can send logs to your Wazuh server - increasing security and minimizing the risk of compromising the Wazuh instance. Adjust this to match your network topology, being as restrictive as possible while still allowing your MikroTik devices to send the logs.

After making this change, we need to restart the Wazuh manager service:

Terminal window
sudo systemctl restart wazuh-manager

We can verify that Wazuh is listening for syslog connections by checking the open ports:

Terminal window
sudo netstat -tulnp | grep 514

We should see output indicating that Wazuh is listening on UDP port 514, similar to this:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:55000           0.0.0.0:*               LISTEN      116118/python3
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2832/sshd: /usr/sbi
tcp        0      0 0.0.0.0:1516            0.0.0.0:*               LISTEN      116480/python3
tcp        0      0 0.0.0.0:1515            0.0.0.0:*               LISTEN      116169/wazuh-authd
tcp        0      0 0.0.0.0:1514            0.0.0.0:*               LISTEN      116283/wazuh-remote
tcp6       0      0 :::55000                :::*                    LISTEN      116118/python3
tcp6       0      0 :::22                   :::*                    LISTEN      2832/sshd: /usr/sbi
udp        0      0 0.0.0.0:514             0.0.0.0:*                           116284/wazuh-remote

Section titled Creating%20Custom%20Decoders%20for%20RouterOS%20Logs

Decoders are Wazuh’s way of understanding and parsing log messages. While Wazuh includes some basic syslog parsing capabilities, we need to build custom decoders to extract the information from MikroTik’s RouterOS specific log format.

Create a new decoder file specifically for RouterOS logs. This file should be placed in /var/ossec/etc/decoders/ and named something descriptive like 001-mikrotik_decoders.xml:

<!-- MikroTik RouterOS Custom Decoders -->
<decoder name="mikrotik">
    <prematch>^MKT[\d+][\S+]</prematch>
    <type>syslog</type>
</decoder>


<!--DHCP Logs-->
<decoder name="mikrotik_dhcp">
    <parent>mikrotik</parent>
    <use_own_name>true</use_own_name>
    <prematch type="pcre2"> (assigned|deassigned) </prematch>
    <regex type="pcre2">(\S+) (assigned|deassigned) (\S+) for (\S+)\s*(\S*)</regex>
    <order>vlan,act,assigned_ip,mac_addr,device</order>
</decoder>
<!--END DHCP Logs-->


<!--AUTH Logs-->
<decoder name="mikrotik_auth_login">
    <parent>mikrotik</parent>
    <use_own_name>true</use_own_name>
    <prematch>logged in from</prematch>
    <regex>user (\S+) (logged in) from (\S+) via (\S+)</regex>
    <order>user,act,srcip,service</order>
</decoder>


<!-- The full decoders can be found in this note's GitHub repository -->

Let’s review how these decoders work, as understanding the process will help modify them for specific needs. The parent decoder (mikrotik) serves as a filter to identify logs that came from RouterOS systems. It looks for the MKT[number][string] format in the syslog header. Remember the format I mentioned earlier? This is where we use it for targeting.

The child decoders then parse specific types of RouterOS messages. The mikrotik_dhcp decoder, for example, extracts information like vlan, action performed, assigned IP, MAC address and device name if sent. The regular expressions might look complex, but they’re designed to match the specific format that RouterOS uses for its log messages.

The order parameter tells Wazuh which parts of the regex correspond to which fields, allowing the system to create structured data from the log text.

Section titled Developing%20Custom%20Rules%20and%20Alerts

With decoders in place to parse the logs, we now need rules that define what constitutes a security event worthy of an alert. Create a custom rules file at /var/ossec/etc/rules/mikrotik_rules.xml:

<group name="mikrotik">


    <!--Alert when an IP in restricted range is assigned-->
    <rule id="109011" level="12">
        <decoded_as>mikrotik_dhcp</decoded_as>
        <field name="assigned_ip" type="pcre2">^10\.140\.[0-9]{1,2}\.22[0-9]$</field>
        <field name="act">assigned</field>
        <description>CRITICAL: DHCP $(act) address in restricted range: $(assigned_ip) to $(mac_addr) [$(device)]</description>
    </rule>


    <!--    ...    -->


    <!--Alert when an auth failure occurs-->
    <rule id="109014" level="10">
        <decoded_as>mikrotik_auth_failure</decoded_as>
        <description>$(username) has failed to login $(subject) via $(access_method)</description>
    </rule>


    <!--Alert when multiple failures occur in short succession    -->
    <rule id="109015" level="12" frequency="3" timeframe="300">
        <if_matched_sid>109014</if_matched_sid>
        <same_source_ip />
        <description>$(username) has failed to login $(subject) via $(access_method) multiple times. Possible brute force attack.</description>
        <group>authentication_failures,brute_force,pci_dss_11.4,</group>
    </rule>


    <!--  ...  You can find the complete ruleset in the note's GitHub repository  -->
</group>

These rules demonstrate several important concepts in Wazuh rule creation. Rule levels determine the severity of alerts, with higher numbers indicating more serious events. The frequency and timeframe parameters allow you to create rules that trigger only when events occur repeatedly within a specified time window, which is perfect for detecting patterns like brute force attacks or port scans. The same_source_ip condition ensures that frequency-based rules only count events from the same source, preventing false positives when multiple legitimate users are active simultaneously.

Section titled Testing%20and%20Validating%20Your%20Configuration

Before finishing, thorough testing is essential to ensure everything works as expected. Start by restarting the Wazuh manager to load the new decoders and rules:

Terminal window
sudo systemctl restart wazuh-manager

To generate test logs from the MikroTik router, try and attempt to log in with incorrect credentials. The events should appear in the Wazuh dashboard within a few seconds.

Decoders can also be tested manually using Wazuh’s built-in testing tools:

Terminal window
echo "Sep 16 13:09:19 mkt-01.root-security.eu MKT[001][DHCP]: vlan1_dhcp assigned 10.140.19.225 for AA:BB:CC:00:11:22 " | /var/ossec/bin/wazuh-logtest


Starting wazuh-logtest v4.12.0
Type one log per line


**Phase 1: Completed pre-decoding.
  full event: 'Sep 16 13:09:19 mkt-01.root-security.eu MKT[001][DHCP]: vlan1_dhcp assigned 10.140.19.225 for AA:BB:CC:00:11:22 '
  timestamp: 'Sep 16 13:09:19'
  hostname: 'mkt-01.root-security.eu'


**Phase 2: Completed decoding.
  name: 'mikrotik_dhcp'
  parent: 'mikrotik'
  act: 'assigned'
  assigned_ip: '10.140.19.225'
  mac_addr: 'AA:BB:CC:00:11:22'
  vlan: 'vlan1_dhcp'

This command will show you exactly how Wazuh parses the log line and which rules it matches, helping you troubleshoot any issues with your configuration.

Section titled Tips%20%26%20Tricks%20for%20Debugging

Section titled Selective%20firewall%20logging%20rules

Once the basic integration is working, you might want to consider some advanced configurations to enhance the security monitoring capabilities. For instance, implementing log filtering on the RouterOS side can help to reduce the volume of logs sent to Wazuh. This is particularly important in high-traffic environments where firewall logs could overwhelm your SIEM:

Terminal window
/ip firewall filter add chain=input action=drop log=yes log-prefix="[SEC] EXTERNAL-DROP" \
    src-address-list=!internal comment="Log only external drops"

For compliance environments, consider enabling logging for all firewall rules that allow traffic, not just those that drop it. This provides a complete audit trail of network activity:

Terminal window
/ip firewall filter set [find action=accept dynamic=no] log=yes log-prefix="[SEC] ALLOW"

Section titled Debugging%20decoder%20config

During the testing and debugging process, we might encounter something that initially seems confusing: when examining which decoder processed the logs, Wazuh will often display the name of the parent decoder rather than the specific child decoder that actually parsed the message. This behavior is intentional.

This design choice offers significant advantages, particularly when creating rules that need to match multiple related decoder types. For instance, we can write a single rule that triggers on any MikroTik firewall event, regardless of whether it was parsed by the basic firewall decoder or the more advanced ports-aware version.

However, when we’re deep in troubleshooting mode, this inherited naming can create frustration as we try to understand exactly which parsing logic was applied to the logs.

If you need more granular visibility, at least during development and debugging, Wazuh provides a simple solution. Adding the <use_own_name>true</use_own_name> tag to the child decoders instructs Wazuh to display both the child and parent decoder names. This gives the detailed visibility we need during development while preserving the flexibility of the hierarchical structure.

Section titled Leveraging%20the%20Wazuh%20Web%20Interface%20for%20Testing

While this guide has primarily focused on command-line snippets and configuration, which provides the most direct control and understanding of the underlying processes, Wazuh also offers UI testing tools that can streamline the development workflow.

We can access these through the Wazuh dashboard by navigating to the Ruleset test feature under Server Management > Rules or the Decoders test tool under Server Management > Decoders.

However, there’s an important quirk to be aware of when using the UI tools. The interface maintains an active session in the background, which means that after making changes to the decoders or rules, the testing interface won’t automatically reflect the modifications. This can lead to confusion when the tests don’t behave as expected after making changes.

The solution is simple but not immediately obvious: after each modification and save operation, we will need to click the Clear session button to force the interface to reload the updated configurations.

Understanding this behavior will save considerable debugging time and prevent the frustration of wondering why the perfectly crafted decoder modifications aren’t being recognized by Wazuh.

Section titled Conclusion

By integrating MikroTik RouterOS logs into Wazuh, we’ve created a powerful security monitoring system that provides visibility into network-level threats and activities.

The custom decoders and rules we created will automatically parse RouterOS logs and generate alerts for suspicious activities like port scans, brute force attempts, and system configuration changes.

Remember that this integration is not a set-and-forget solution! As your network evolves and new threat patterns emerge, you’ll need to refine your decoders and rules to maintain effective security monitoring. Regular review of your Wazuh alerts will help you identify patterns that might require new rules or adjustments to existing ones.

The foundation we’ve built here can be extended to monitor other network devices, like switches and access points, and other security events, creating a comprehensive security operations center that gives you real-time visibility into your entire network infrastructure. This proactive approach to security monitoring will help detect and respond to threats before they can cause significant damage to any organization.