Using Splunk to Analyse MikroTik Logs

Using Splunk to Analyse MikroTik Logs

Splunk is a widely used log aggregation and analytics platform that can ingest RouterOS syslog and SNMP data to provide security monitoring, network health dashboards, and operational analytics. RouterOS forwards logs via standard syslog (RFC3164) and exposes metrics via SNMP, both of which Splunk can consume directly.

Overview

RouterOS supports two primary integration paths with Splunk:

• Syslog forwarding — RouterOS pushes log events to Splunk in real time. This is the primary method for security and operational event analysis.
• SNMP polling and traps — Splunk polls RouterOS for interface counters, system metrics, and can receive SNMP traps for immediate alerting.

Most deployments use syslog forwarding for log analysis and optionally add SNMP for metric collection.

Prerequisites

On RouterOS:

• RouterOS 6.x or 7.x
• Network reachability from the router to the Splunk server on UDP port 514 (syslog) and/or UDP port 161/162 (SNMP)

On Splunk:

• A Splunk Universal Forwarder configured to receive syslog, or a Splunk Heavy/Indexer with a UDP data input on port 514
• For SNMP: the Splunk Add-on for SNMP or the SNMP modular input (verify the current Splunkbase version for your Splunk deployment)
• MikroTik MIB files loaded into Splunk for readable OID names (download from mikrotik.com/download under “Extra packages”)

Firewall considerations:

• Ensure the router’s firewall input chain allows traffic from the Splunk server on the required ports
• If using a Splunk syslog listener on a dedicated host, ensure routing exists between that host and the router’s source address

Configuration

Part 1: Syslog Forwarding

Syslog is the primary integration method. RouterOS sends log events to Splunk in real time using the remote logging action.

Step 1: Create a remote logging action

/system logging action
add name=to-splunk \
    target=remote \
    remote=10.10.20.50 \
    remote-port=514 \
    src-address=10.10.1.1 \
    syslog-facility=local0 \
    syslog-severity=auto \
    bsd-syslog=yes

Replace 10.10.20.50 with your Splunk syslog listener IP and 10.10.1.1 with the router interface address to use as the source.

Setting bsd-syslog=yes enables RFC3164-format headers, which most Splunk syslog parsers expect. syslog-facility=local0 separates MikroTik events from other syslog sources in Splunk.

Step 2: Assign log topics to the action

Select topics based on what you want to analyse. Start with this baseline:

/system logging
add action=to-splunk topics=firewall,warning  prefix=FW_WARN
add action=to-splunk topics=firewall,error    prefix=FW_ERR
add action=to-splunk topics=interface,info    prefix=IF_EVT
add action=to-splunk topics=dhcp,info         prefix=DHCP_EVT
add action=to-splunk topics=ppp,info          prefix=PPP_EVT
add action=to-splunk topics=ppp,warning       prefix=PPP_WARN
add action=to-splunk topics=account,info      prefix=ACCOUNT_EVT
add action=to-splunk topics=system,error      prefix=SYS_ERR
add action=to-splunk topics=script,error      prefix=SCRIPT_ERR

The prefix field appears at the start of each log message. Using consistent prefixes makes Splunk field extraction significantly easier and allows sourcetype routing via transforms.conf.

Topic selection guide:

Topic	What it captures	Recommended level
firewall	Packet matches with log=yes set	warning or error to reduce noise
interface	Link state changes (up/down)	info
dhcp	Lease assignments, conflicts, expirations	info
ppp	PPP/L2TP/PPTP session auth and lifecycle	info, warning
account	Admin logins, failed logins, config changes	info
system	System-level events, reboots, kernel messages	error
script	Events from scheduled scripts and automation	error

Avoid debug and raw topics for production Splunk forwarding — they generate very high volume with minimal analytical value.

Step 3: Configure firewall logging with parse-friendly prefixes

For firewall analysis, add log=yes and a log-prefix to rules you want to track in Splunk:

/ip firewall filter
add chain=input action=drop protocol=tcp dst-port=22 \
    src-address-list=!trusted log=yes log-prefix=FW_DROP_SSH \
    comment="Block SSH from untrusted"

add chain=forward action=drop connection-state=invalid \
    log=yes log-prefix=FW_DROP_INVALID \
    comment="Drop invalid state"

add chain=input action=drop protocol=tcp dst-port=23,2323 \
    log=yes log-prefix=FW_DROP_TELNET \
    comment="Block Telnet"

Use a consistent prefix naming scheme (e.g., FW_DROP_, FW_ACCEPT_, FW_SUSPECT_) so Splunk can categorise events with a simple search.

Step 4: Structured logging from scripts (optional)

Scripts can emit structured events that Splunk can parse as key-value pairs:

/system script
add name=wan-monitor source={
    :local status [/interface get ether1 running]
    :if ($status = false) do={
        :log warning "event=wan_down iface=ether1 status=down"
    }
}

Using key=value format in :log messages allows Splunk to auto-extract fields.

---

Part 2: SNMP Integration

SNMP allows Splunk to poll RouterOS for interface statistics, system uptime, CPU/memory usage, and receive traps for immediate alerting.

Step 1: Enable SNMP and set identity metadata

/snmp set enabled=yes contact="NOC <[email protected]>" location="DC1-Rack3"

Step 2: Configure an SNMPv2c community for the Splunk collector

/snmp community
add name=splunk-ro \
    addresses=10.10.20.50/32 \
    read-access=yes \
    write-access=no \
    security=none

Restrict addresses to your Splunk collector IP to limit SNMP exposure.

Step 3: Configure SNMP traps (optional)

Traps send immediate notifications to Splunk when events occur (interface down, system restart):

/snmp set \
    trap-version=2 \
    trap-community=splunk-ro \
    trap-target=10.10.20.50 \
    trap-generators=start-trap,interfaces

Step 4: Allow SNMP through the firewall

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=161 \
    src-address=10.10.20.50 comment="Allow SNMP poll from Splunk"

If using SNMP traps, ensure UDP port 162 is open on the Splunk server.

Step 5: SNMPv3 (recommended for production)

For environments requiring authentication and encryption:

/snmp community
add name=splunkv3 \
    addresses=10.10.20.50/32 \
    security=private \
    authentication-protocol=SHA1 \
    authentication-password=<strong-auth-pass> \
    encryption-protocol=AES \
    encryption-password=<strong-priv-pass> \
    read-access=yes \
    write-access=no

Configure the matching security level (authPriv) in the Splunk SNMP add-on. Protocol and security level mismatches are the most common cause of silent SNMPv3 polling failures.

---

Part 3: Splunk Configuration

Configure a UDP syslog data input

In Splunk Web, navigate to Settings → Data inputs → UDP and add a new input:

• Port: 514
• Sourcetype: syslog (or create a custom sourcetype mikrotik)
• Index: your network log index (e.g., network)

For parsing consistency across RouterOS versions, create a custom sourcetype in props.conf:

[mikrotik]
SHOULD_LINEMERGE = false
TIME_PREFIX = ^
TIME_FORMAT = %b %d %H:%M:%S
MAX_TIMESTAMP_LOOKAHEAD = 20
TRANSFORMS-mikrotik_topics = extract_mikrotik_topics

Add field extraction in transforms.conf:

[extract_mikrotik_topics]
REGEX = ^\w{3}\s+\d+\s+\d+:\d+:\d+\s+\S+\s+(?<mtk_topics>[^:]+):\s+(?<mtk_message>.*)
FORMAT = mtk_topics mtk_message

Load MikroTik MIBs for SNMP

Download the MikroTik MIB package from mikrotik.com/download and place the .mib files in your Splunk SNMP add-on MIB directory. This enables readable OID names (e.g., mtxrInterfaceStatsRxBytes) instead of numeric OIDs in Splunk events.

---

Verification

Verify syslog is being received by RouterOS

Check that the logging action is active and rules are applied:

/system logging action print
/system logging print

Generate a test log entry to confirm delivery:

:log info "splunk-test: syslog connectivity check"

Check the Splunk search interface for the test message:

index=network sourcetype=syslog "splunk-test"

Verify SNMP polling

From the Splunk server, poll the router manually to confirm connectivity:

snmpwalk -v2c -c splunk-ro 10.10.1.1 sysDescr

A successful response returns the RouterOS version string.

/snmp print

Confirm enabled: yes and that trap-target is set correctly.

---

Useful SPL Queries

Once data is flowing, use these searches as a starting point. Replace index=network sourcetype=syslog with your environment.

Top firewall drops by source IP:

index=network sourcetype=syslog "FW_DROP"
| rex field=_raw "src(?:-address)?=(?<src_ip>\d{1,3}(?:\.\d{1,3}){3})"
| stats count by src_ip
| sort - count
| head 20

Admin login failures:

index=network sourcetype=syslog ("login failure" OR "authentication failed")
| stats count min(_time) as firstSeen max(_time) as lastSeen by host
| convert ctime(firstSeen) ctime(lastSeen)
| sort - count

Configuration changes:

index=network sourcetype=syslog "ACCOUNT_EVT" ("changed" OR "added" OR "removed" OR "logged in")
| timechart span=1h count by host

Interface flaps:

index=network sourcetype=syslog "IF_EVT" ("link down" OR "link up")
| rex field=_raw "(?<iface>(ether|sfp|lte|wlan)\S+)"
| transaction host, iface maxspan=5m startswith="link down" endswith="link up"
| eval flap_duration_s=round(duration, 1)
| table _time host iface flap_duration_s eventcount
| sort - _time

Potential brute-force attempts:

index=network sourcetype=syslog ("login failure" OR "invalid user" OR "authentication failed")
| rex field=_raw "from (?<src_ip>\d{1,3}(?:\.\d{1,3}){3})"
| bucket _time span=5m
| stats count dc(host) as target_hosts by _time src_ip
| where count >= 10 OR target_hosts >= 3
| sort - count

System errors trend:

index=network sourcetype=syslog ("SYS_ERR" OR "critical" OR "kernel")
| timechart span=15m count by host

---

Troubleshooting

No events appearing in Splunk

1. Confirm the logging action target IP and port are correct with /system logging action print.
2. Check that a firewall rule on the router is not blocking outbound UDP 514.
3. Verify the Splunk UDP input is listening: netstat -ulnp | grep 514 on the Splunk server.
4. Use /system logging print to confirm topics are assigned to the to-splunk action.
5. Check RouterOS can reach the Splunk host with /tool traceroute 10.10.20.50.

Events arriving but timestamps are wrong

RouterOS sends syslog with local time. Ensure the router’s clock is correct and that NTP is configured:

/system ntp client print
/system clock print

If the Splunk server and router are in different timezones, configure Splunk’s TZ setting in props.conf for the MikroTik sourcetype to match the router’s timezone.

RouterOS v7 timestamp format differences

RouterOS 7 changed the syslog timestamp and header format. If Splunk shows incorrect timestamps or fails to parse events, adjust the TIME_FORMAT in your props.conf and test with:

index=network sourcetype=mikrotik
| eval parsed_time=strptime(_raw, "%b %d %H:%M:%S")
| table _time parsed_time _raw

SNMP polling returns no data

1. Confirm SNMP is enabled: /snmp print — check enabled: yes.
2. Verify the community addresses field matches the Splunk poller IP exactly.
3. Check the firewall input chain allows UDP 161 from the Splunk server.
4. For SNMPv3, verify security level and protocols match exactly between RouterOS and the Splunk SNMP add-on configuration.

High log volume overwhelming Splunk

Remove broad low-value topics (especially firewall,info or firewall,debug) and replace with targeted rules using firewall,warning or specific firewall rules with log=yes. Use the topic negation syntax to exclude debug:

/system logging
add action=to-splunk topics=firewall,!debug prefix=FW

See Also

• RouterOS System Logging
• RouterOS SNMP
• Hardware Health Monitoring
• The Dude Network Monitor
• RouterOS Firewall Logging