MikroTik Firewalls
You can now get MikroTik training direct from Manito Networks. MikroTik Security Guide and Networking with MikroTik: MTCNA Study Guide by Tyler Hart are both available in paperback and Kindle!
Preface
The Mikrotik firewall, based on the Linux iptables firewall, is what allows traffic to be filtered in, out, and across RouterOS devices. It is a different firewall implementation than some vendors like Cisco, but if you have a working knowledge of iptables, or just firewalls in general, you already know enough to dive in. Understanding the RouterOS firewall is critical to securing your devices and ensuring that remote attackers can't successfully scan or access your network.
We'll discuss firewall design, chains, actions, rules, and overall best practices.
Navigation
Firewall Design
The general idea of firewalling is that traffic you need should be allowed, and all other traffic should be dropped. By putting firewalls in place a network can be divided into untrusted, semi-trusted, and trusted network enclaves. Combined with network separation using VLANs, this creates a robust, secure network that can limit the scope of a breach if one occurs.
Traffic that is allowed from one network to another should have a business or organizational requirement, and be documented. The best approach is to whiteboard out your current network design, and draw the network connections that should be allowed. Allowed traffic will have a rule that allows the traffic to be passed, then a final rule acts as a "catch-all" and drops all other traffic. Sometimes this is referred to as the "Deny All" rule, and those coming from a Cisco background often call it the "Deny Any-Any" rule. Allowing what you need and dropping everything else keeps firewall rules simple, and the overall rule count to a minimum.
The first concept to understand is firewall chains and how they are used in firewall rules.
Firewall Chains
Firewall Chains match traffic coming into and going out of interfaces. Once traffic has been matched you can take action on it using rules, which fire off actions - allow, block, reject, log, etc. Three default Chains exist to match traffic - Input, Output, and Forward. You can create your own chains, but that is a more advanced topic that we'll cover in another article.
Input Chain
The Input Chain matches traffic headed inbound towards the router itself, addressed to an interface on the device. This could be Winbox traffic, SSH or Telnet sessions, or an administrator pinging the router directly. Typically most Input traffic to the WAN is dropped in order to stop port scanners, malicious login attempts, etc. Input traffic from inside local networks is dropped as well in some organizations, because Winbox, SSH, and other administrative traffic is limited to a Management VLAN.
Not all organizations use a dedicated Management VLAN, but it is considered a best practice overall. This helps ensure that a malicious insider or someone who gains internal access can't access devices directly and attempt to circumvent organizational security measures.
Output Chain
The Output Chain matches traffic headed outbound from the router itself. This could be an administrator sending a ping directly from the router to an ISP gateway to test connectivity. It could also be the router sending a DNS query on behalf of an internal host, or the router reaching out to mikrotik.com to check for updates. Many organizations don't firewall Output traffic, because traffic that matches the Output chain has to originate on the router itself. This is generally considered to be "trusted" traffic, assuming the device has not been compromised somehow.
Forward Chain
The Forward Chain matches traffic headed across the router, from one interface to another. This is routed traffic that the device is handing off from one network to another. For most organizations the bulk of their firewalled traffic is across this chain. After all we're talking about a router, whose job it is to push packets between networks.
An example of traffic matching the Forward chain would be packets sent from a LAN host through the router outbound to a service provider's gateway via the default route. In one interface and out another, directed by the routing table.
Firewall Actions
Firewall rules can do a number of things with packets as they pass through the firewall. There are three main actions that RouterOS firewall rules can take on packets - Accept, Drop, and Reject. Other actions exist and will be covered in different articles as they apply, but these three are the mainstay of firewalling.
Accept
Rules that "Accept" traffic allow matching packets through the firewall. Packets are not modified or rerouted, they are simply allowed to travel through the firewall. Remember, we only should allow the traffic that we need, and block all the rest.
Reject
Rules that "Reject" traffic block packets in the firewall, and send ICMP "reject" messages to the traffic's source. Receiving the ICMP reject shows that the packet did in fact arrive, but was blocked. This action will safely block malicious packets, but the rejection messages can help an attacker fingerprint your devices during a port scan. It also lets the attacker know that there is a device running on that IP, and that they should probe further. During a security assessment, depending on the auditor and the standards you're being audited against it may or may not become an audit finding if your firewall is rejecting packets. It is not recommended as a security best practice to reject packets, instead you should silently "drop" them.
Drop
Rules that "Drop" traffic block packets in the firewall, silently discarding them with no reject message to the traffic source. This is the preferred method for handling unwanted packets, as it doesn't send anything back that a port scanner could use to fingerprint the device. When drop rules are configured correctly a scanner would get absolutely nothing back, appearing as though nothing is actually running on a particular IP address. This is the desired effect of good firewall rules.
Firewall Rules
Firewall rules dictate which packets are allowed to pass, and which will be discarded. They are the combination of chains, actions, and addressing (source / destination). Good firewall rules allow traffic that is required to pass for a genuine business or organizational purpose, and drops all other traffic at the end of each chain. By using a blanket "deny all" rule at the end of each chain we keep firewall rule sets much shorter, because there don't have to be a bunch of "deny" rules for all other traffic profiles.
Chains
Each rule applies to a particular chain, and assigning a chain on each rule is not optional. Packets match a particular chain, and then for that chain firewall rules are evaluated in descending order. Since the order matters, having rules in the correct sequence can make a firewall run more efficiently and securely. Having rules in the wrong order could mean the bulk of your packets have to be evaluated against many rules before hitting the rule that finally allows it, wasting valuable processing resources in the meantime.
Actions
All firewall rules must have an action, even if that action is only to log matching packets. The three typical actions used in rules are Accept, Reject, and Drop as described previously.
Addressing
This tells the firewall for each rule what traffic matches the rule. This part is optional - you can simply block an entire protocol without specifying its source or destination. There are a couple options for addressing traffic coming into or across the router. You can specify the Source or Destination IP addresses, including individual host IPs or subnets using CIDR notation (/24, /30, etc). Interfaces can also be used to filter traffic in or out of a particular interface, which can by a physical interface like an Ethernet port or a logical interface like those created by GRE tunnels. This is often done when blocking traffic where the source or destination of the traffic isn't always known. A good example of this is traffic inbound to the router via your service provider - that traffic could originate from Asia, Europe, or anywhere else. Since you don't know what that traffic is a deny rule is used inbound on the WAN interface to just drop it.
Comments
It's so important to add a comment to your firewall rules, for your own sanity and that of your network team. It takes almost no time to do when you create firewall rules, and it could save significant time when troubleshooting. It could also save you from making a mistake when tweaking firewall rules down the line as networks change and evolve. If you haven't created a comment at the time the rule was made just add a comment like this, using firewall number 4 as an example:
ip firewall filter set 4 comment="New firewall comment"Firewall Best Practices
A number of best practices are widely implemented across the networking industry, and it's a good idea to familiarize yourself with what they are, why they are implemented, and the impact they have on your organization's security.
Only allow necessary traffic
This has been mentioned a couple times already, but it's worth mentioning again. Only allow traffic that's necessary in and out of the network. This reduces the attack surface that's exposed to attackers, and helps limit the damage of a breach. With that being said, restricting network traffic too much can limit functionality or productivity, so some amount of balance and testing is required.
Allow trusted external addresses only
Opening up (or "pinholing") the firewall is an acceptable and necessary practice, but you should only allow inbound connections from outside the network via trusted addresses. This could be other offices or datacenter locations, or connections to internal resources via VPN tunnels.
Use a "deny all" rule at the end of each chain
Instead of putting in many "deny" rules to drop traffic, rely on the final "deny all" rule in each chain to handle unwanted traffic. Adding additional "deny" rules to monitor for certain traffic profiles or to help in troubleshooting is good practice, but adding deny rules on top of the final rule bloats the firewall and uses up resources long-term.
Scan your own firewalls
Periodically scanning your own firewalls and other devices for open ports and services is a vital part of any network security program. It isn't hard to do at all and you can use open source tools. Having devices connected to the internet means that you are now virtually guaranteed to be scanned by threat actors looking for soft targets and devices with poor or missing configurations. Nmap is the typical tool for port and service scanning, and a tutorial on Nmap scanning is posted on our Security blog.
