Custom chains in the Mikrotik Firewall

Every network packet that firewall handles can be input, output or forwarded. In relation to this, we have the three predefined chains that handle the entire network traffic. We make a list of rules that allow or block specific traffic.

Over time, our list can grow. At one point, we may have a list with several hundred rules. Mikrotik routers can have a long list, still to operate without problems. However, each netwrok packet must be respectively compared with each rule in the list until it finds appropriate.


Benefits of user-defined chains

The firewall will take a new packet that arrives in one of the network ports. It will begin to compare it with the first, second, third rule in the list. The packet processing is actually a series of the if… then… loops. The latest rule, that will eventually reject the packet, is the final else in these loops.

Every processing of long list unnecessarily will waste CPU time on the router. Although this percentage will be relatively small, maybe 10-15% of the CPU time, any saving allows us to do some other tasks.

The solution is to use custom chains. These chains allow us to shorten the main processing list. Rather than processing the full list, that can contains a few hundred rules, it will compare it with a shorter list of the main rules.

In case the package matches with any of the main rules, we will make the jump to a new shorter list that applies only to it. The latest rule in this sub-list will be the one that rejects this kind of traffic. Therefore, the packet will be either passed or rejected with significantly fewer checks. As the result, the overall firewall operation will consume less CPU time.

As we know, no rules behind the explicit rejection all rule will be processed. In addition, we can further accelerate packet processing when the rules for passing of a traffic are placed on the beginning of list. The same can be applied for any rule that will prevent the brute force or DDoS attacks.

However, we can add the rules behind the explicit rejection rule and then jump to them when needed. You can observe these rules as a GOTO command in many programming languages.

Enough with the theory! Now is the time to see how this really works. However, in order to protect the user, all IP addresses have been modified.


My custom chains

I made the export of the configuration for the firewall filter list. You can do that with the command:

/ip firewall filter export

This list has grown over the years to over 400 rules. We will focus on the part that relates to the e-mail server. This is a good example of the application of custom chains.

FW filter list pre

It’s common practice to use two Internet links for a higher server availability. Therefore, we have two sets of very similar rules. Every set in this example has 11 rules. In addition, the packet sent to any other server enlisted below will be compared even with these 22 rules without reason.

The second example is related to the FTP server. We have lesser rules here, but again we add unnecessary checks in the list. The e-mail and FTP servers are very common to the most organizations. It’s the same principle to build the custom chain for the Web server too.

I extracted all rules related to the first e-mail server named mailman. Instead of those 22 rules, now I have only one rule.

FW filter list posle jump pravilo

I used an address list to activate this rule. In case that you have only one address, you will use the parameter dst-address instead of dst-address-list.

The action part here is designated with parameters action=jump jump-target=mailman. The first parameter is the action. Instead of usual accept or drop actions, we want to jump to the sub-list. With the second parameter, jump-target, we will choose the specific sub-list. This means that we can have more than one sub-list.

In the end of the list, below the deny rules, we will add the new block of the rules that belong to this custom chain. The latest rule with the name of this chain will terminate further processing. From the security perspective, it’s strongly recommended that the latest rule is the explicit deny.

FW filter list posle custom lista

The deny rules are marked in red and the new block is highlighted. You can see that in this block I don’t need to specify destination address. The packet is sent to this chain with the first rule containing the jump action.

Before the custom chains, firewall consumed up to 15% of the CPU time. With all these lists, the CPU load related to firewall is below 5%. These 10% are now available for other activities and processes inside the router.


Setup from the script

You can make all these settings from the WinBox GUI tool. That’s fine if you have a small site and just a few custom chains. However, if you have a larger datacenter, you will probably opted for configuration scripts.

The use of the scripts will not only speed up this process, but will also reduce the possibility of the errors. You need the plain text editor, like Windows Notepad, to type these commands. Then you can just execute the script and make configuration changes in a split second.

Your script for the e-mail server may looks like my example:

script za update FW filter liste za mailman

I added the new address list. You don’t need the address list if you’re using the single IP address.

Then I need to add action rules in the firewall filter. The yellow highlighted line is the jump line. All other lines are part of this chain.

Although I didn’t placed one explicit deny rule here, I strongly encourage you to do so. That line should be like this:

add chain=chain_name action=deny

Here is very similar script for the FTP server:

script za update FW filter liste za ftp

We used the same guidelines here. Furthermore, when you make one script, you can easily adapt it for other servers. Moreover, you can download both the mail and ftp example from my shared drive.

However, when we execute the script, all these rules will be placed on the end of the list. We need to relocate the first rule on higher position. The custom chain will not active until the first rule is not moved above the deny all rule.


The next step

Now it’s your turn. You can create your own scripts or download these examples. In either way, try at least in your lab to make a few custom chains. You will need some practice to catch the concept and become comfortable. Then, you will use them easily.

Another benefit is that you can learn something about scripts. Although these scripts are very simple, you can learn how to write them. Furthermore, you can learn how to speed up configuration process using the same script on the multiple routers.

For all of you planning to take the MTCNA exam, this can be useful information. The custom chains are part of that training and its final exam.

I opened a few topics here, like the IP address lists. We will speak more about the address lists or configuration scripts in the upcoming articles.

Stay tuned.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.