Shipping Mikrotik firewall logs to vRealize Log Insight

Share on:

Recently I installed a Mikrotik router at home and since I'm in my lab environment are running vRealize Log Insight (vRLI) and I'm using this as my Syslog server I wanted to push logs from the firewall to vRLI.

Since I couldn't find any content packs for Mikrotik I thought I'd take the opportunity to do a walkthrough of how to extract fields from syslog messages to get some value from them.

The first part of this blog will be how I've configured my Mikrotik router (yours might be different so you might have to adjust accordingly), the second part how I've extracted fields from the Syslog messages. Feel free to jump over either part.

Mikrotik remote syslog setup

To specify a remote Syslog server in the Mikrotik router we'll first create an action where we specify the Remote type and the details for our remote server.

Note that there are a few ways to do this. I know that vRLI supports RFC3164 syslog messages and that is what we'll get if we specify the BSD syslog option here. We're a bit ahead of things here, but the difference when outputted to vRLI isn't huge. In my case I like the latter so that's what we'll work with.

Here's a message without the BSD option selected. Hostname uses _gateway as the hostname

Syslog message without BSD option

Here's a message with the BSD option selected, and a prefix specified in the rule (more on this later). Notice the hostname and appname fields. Hostname is now what I have as the identity of my router.

Syslog message with BSD option selected

So let's create an action that points to our remote server and select the BSD option. I've set syslog as the facility and info as the severity (I haven't look at the rfc specification to see if this is correct, don't shoot me..)

Set Mikrotik remote syslog server

Second we need to create a rule that uses this action. Here we'll set Firewall as the topic and then select the newly created action. Note that we can prefix our messages here and I'll set fw as my prefix which eventually set this as the appname in the syslog message.

Create remote logging action

Mikrotik firewall rules

Now to tell our router to push logs to vRLI we have to specify the individual rules to log the action and we can add a prefix to the log entry

Let's see an example with this default rule that will drop all input that doesn't come from our LAN (and which has not been hit by a previous rule)

Default drop input rule

Down in the action section this is set to drop so we'll check the log checkbox and we'll set a prefix. I have my own kind of semi-standard for this where I start with the action, DROP in this case, then I have a short descriptive part to understand the rule. Here we might have i.e. the rule number or some other description, but for now I'm fine with this approach. The important part here is that we will use this later on in vRLI so we need to have some kind of a standard thinking about it.

Log the action and set a prefix

Let's also add an example from an accept rule so we can work with different log entries. We'll use the an ICMP accept rule for this which uses a different chain than before (forward)

Default ICMP accept rule

And we'll log the action and specify a prefix for it

Log action with a prefix

That's all that is needed in Mikrotik. Now, let's head over to vRLI and see if we have som log entries there.

vRLI log entries

In vRLI should start seeing message like the following

Log entry in vRLI

With the hostname and the appname we can filter on these messages

Filter events

Extracting fields

The ability to filter on the router hostname and the firewall messages is good, but I would also want to filter on more specific things (like the IP addresses, the interfaces and so forth) and eventually build some graphs. To be able to do this we need to extract fields

What I want to extract is the following: The log prefix, chain, in and out interfaces, protocol, source and destination ip and ports

Note that the extraction is done by parsing the log events and look for specific text based on the structure of the message. This means that if you for instance have a different standard for your prefix'es you might need to adjust the following examples

The log prefix will be split in two parts. The first part will be the action, and the second part will be the rule identifier

Extract field

Note that the field extractor will suggest how to extract a field with the specific text and the specific place in the structure based on this very event

Field extractor suggestion

I'll adjust this by doing some regex'ing. I'm specifying that the field can have either the text ACCEPT or DROP as this is what I'll use for my rule prefix. I've also set the post context to accept any word after the dash

Field extractor for the action field

Note that I'm giving the field my custom name and that I'm also setting this to be available for all users.

By hitting Save in the field extractor the field gets created and we can use it in our filter

Field extracted

I'll do the same for extracting the description from the prefix. Here I'll specify again that it's preceded by either ACCEPT or DROP and then a dash. After the field there should be a whitespace character, then a word that should be either input, output or forward. This will map to the chain the traffic is coming from.

Field extractor for the rule descriptive text

The chain field will match input, output or forward. And should be preceeded by a word separated by a dash and then followed by a whitespace character. The field should be followed by ": in"

Field extractor for the chain field

Note that we could also make use of the Additional context to further filter the entries to match by searching for i.e. appname contains fw

Additional field filter

We're starting to get a few fields available to us and hopefully you get the point on how to extract them

More fields available

I won't detail the rest of the fields, but after extracting what I want my list of extracted fields looks like this

All extracted fields

Note that when I grabbed this screenshot I see that I haven't been paying enough attention to the whitespaces in the regex extractions. Even though the queries work I like to specify whitespace with \s

Charting

Now with the fields in place we can use them to filter the events, but also by building some meaningful charts with them.

A simple example would be this pie chart that shows Accept rule hits vs Drop rule hits (obviously for logged traffic only)

Accepted vs Dropped chart

Going forward I'll build a dashboard based for our Mikrotik firewall messages so stay tuned for an upcoming blog post about that

This page was modified on January 21, 2022: mikrotik vrli post