MikroTik Daymare. Protecting MikroTik equipment from hacker attacks

To ensure the security of your network, you have to understand its structure and integrate security features so that they operate correctly and don’t disrupt the business process. Overall, network security is a pretty complicated matter. Networks form the basis of any organization nowadays and require a cautious approach.

Idle interfaces

One of the main rules of etiquette is to disable unused interfaces, which reduces the chance of unauthorized connections. This rule is very easy to implement:

Discovery Protocols

Discovery Protocols (DPs) are vulnerable to two offensive vectors:

• Information Gathering – an attacker can extract sensitive information about the equipment broadcasting DP to its ports; and 
• Neighbor Table Overflow – an attacker can overflow the neighbor table in the context of the CDP/LLDP protocols. This overloads the device’s processor resulting in DoS. The attack involves the generation of rogue DP frames and their mass broadcasting targeting the RouterOS port.

The best solution is to restrict the use of these protocols (i.e. leave them only on those interfaces where it’s really necessary). As a result, the equipment won’t broadcast sensitive information where it’s not required.

WinBox Security at L2

WinBox can operate at L2 (i.e. a network engineer can access RouterOS bypassing the network layer). MAC WinBox Server is responsible for this procedure making it possible to connect to WinBox without IP addressing.

By default, MAC WinBox Server is available on all interfaces, which isn’t good. For better security, I recommend to allow its use only on certain interfaces.

An example: I allow MAC WinBox Server only on the internal LAN list where the LAN bridge for internal network operations is located.

To summarize: allow MAC WinBox Server only where you really need it!

DHCP Snooping

DHCP Snooping is a security function that prevents DHCP spoofing attacks. During such an attack, the malefactor deploys a rogue DHCP server inside the network for a subsequent MITM attack. The default gateway address can be transmitted over DHCP, and this address can be the attacker’s host.

DHCP Snooping is based on the principle of trusted and untrusted ports. On untrusted ports, all DHCP messages are monitored to verify whether they have been generated by a valid DHCP server. Needless to say: if you see messages like DHCPLEASEQUERY, DHCPOFFER, or DHCPACK in the user segment, this is definitely an anomaly, and a DHCP server is present on the user network. On trusted ports, all DHCP messages are considered legitimate. Connections between switches and routers are usually set as trusted ports; while ports connected to end stations (e.g. computers, printers, access points, and VoIP), as untrusted ones.

In RouterOS, DHCP Snooping is enabled on bridges, and all device ports on such bridges become untrusted. But to change the status of a specific port, you have to go to the interface settings. Overall, DHCP Snooping requires thoughtful configuring taking into account specifics of the infrastructure.

Enabling DHCP Snooping on the bridge:

Setting a trusted port in the DHCP Snooping context:

Voila! DHCP Snooping has been configured, and from now on, service DHCP messages normally used by the DHCP server will be blocked on untrusted ports. During an attack, the attacker’s address has to be imposed as a gateway using the DHCPOFFER message, and the above settings completely prevent this. However, be careful when you configure the settings to avoid an unintentional DoS.

Firewall setup

In RouterOS, firewall is a subsystem that handles and filters all packets. In my humble opinion, firewall setup requires special attention since both the device performance and security level depend on it.

A detailed overview of numerous firewall features in RouterOS is beyond the scope of this article: these extremely useful and powerful functions are described in countless articles and guides.

Instead, let’s focus on the most important aspects critical for protection against advanced attacks.

Correct traffic handling

RouterOS routes all traffic in accordance with the following concept: everything that isn’t prohibited is allowed. Traffic is processed from top to bottom pursuant to certain rules. The best practice is to set rules in INPUT/Forward chains (that allow Established/Related connections and reject Invalid connections) at the beginning of the firewall rules list. The Connection Tracking mechanism makes it possible to keep track of all connections based on their states.

Cautious approach to ICMP

I recommend to enable the ICMP protocol, but slightly limit the number of packets per second to avoid potential DDoS over ICMP. In many cases, all ICMP traffic is blocked at the external perimeter, but this can affect the PMTUD operation that helps to overcome excessive fragmentation caused by nonstandard MTU values.

TTL shift

If your equipment acts as a proxy server, and its IP address has to be hidden from tracing, you can shift TTL in the Mangle table (the PREROUTING chain) with an increment of +1:

DNS flood risk

Make sure that no DNS protocol ports are exposed to the outside since they can be used for a potential DDoS attack. In many cases, DDoS attacks on MikroTik are delivered via DNS. The Allow Remote Requests option in DNS settings on MikroTik is often checked, which allows RouterOS to act as a DNS server. This is normal for the internal infrastructure, but a DNS port can also be present on the external interface facing the Internet.

Drop All Other

At the end of the firewall rules list, there should always be a Drop All Other ban for the external RouterOS interface (the one facing the Internet; RouterOS doesn’t distinguish between internal and external interfaces). It will reject all unauthorized connections to the router. Important: make sure that all the rules required for your protocols are on top; in this case, the final rule won’t disrupt network connectivity. The Drop All Other rule should be at the end of the rules list for any firewall!

Dynamic routing

The security of dynamic routing protocols (DRP) is of special importance: even the slightest impact on the AS partially paralyzes the internal network. In addition, various attacks can be delivered against the dynamic routing domain – be prepared! Let’s examine the security of the OSPF (Open Shortest Path First) protocol supported by RouterOS in more detail.

Passive interfaces

Configuring passive interfaces in the dynamic routing context enables the router to prohibit sending advertisements via some interfaces. By default, passive interfaces aren’t configured, and it sends advertisements to all interfaces, which exposes the routing domain to great risks.

The passive parameter below indicates a passive interface.

Cryptographic authentication

The use of authentication in routing domains ensures that only authorized legitimate routers can log on. However, authentication is configured using passwords. If you want to protect your routing domain with authentication, make sure that your passwords are strong enough. They are hashed using cryptographic hash functions, and an attacker can read their hash values ​​from a traffic dump and brute-force your passwords. After cracking a password, an attacker can easily connect to the routing domain.

The setting below uses SHA-384. By the way, Ettercap can extract any MD5/SHA hash, and the attacker can try to brute-force the password to the OSPF domain. Make sure that the pass phrase is strong enough.

VRRP security

The VRRP (Virtual Router Redundancy Protocol) hot standby system can be at risk since an attacker can perform FHRP Master spoofing and deliver a MITM attack. Due to certain VRRP specifics, it’s impossible to set the priority to 255; therefore, you have to take more stern measures. Two effective techniques can be used.

The first technique involves cryptographic authentication. It protects the VRRP domain with a special pass phrase; without it, the attacker won’t be able to spoof. Again, you have to make sure that the authentication key is resistant to brute-forcing. To protect VRRP, RouterOS uses the AH protocol from the IPSec suite. According to RouterOS developers, its implementation in RouterOS is based on HMAC-MD5.

The second technique is firewall filtering. Authentication is no longer supported for VRRPv3, but you still have to do something about it. Using the Mangle and Raw tables, you can preemptively allow VRRP from legitimate VRRP routers and then block all other VRRP packets. This solution ensures the lowest processor load. Since the allowed rules don’t include the attacking host’s address, any attempts to attack the VRRP domain will fail.

Pseudo balancing issue

VRRP ensures fault tolerance, but in fact, only one router in the logical group is working; while the others remain in the standby mode.

If your network includes several RouterOS devices and several VLAN segments, you can put to work all RouterOS devices in your network, for instance:

• RouterOS1 acts as MASTER for VLAN 120 and VLAN 140 and as BACKUP for VLAN 180 and VLAN 220; and 
• RouterOS2 acts as MASTER for VLAN 180 and VLAN 220 and as BACKUP for VLAN 120 and VLAN 140 (i.e. its configuration mirrors RouterOS1).

This technique is called pseudo balancing. Of course, it doesn’t use the round robin algorithm, but at least all routers in the VRRP domain are working. For MASTER, the priority is set to 200; for BACKUP, to 90. The numbers and VLAN ID are fictitious, just to simulate a demo scenario.

Configuring RouterOS1:

Configuring RouterOS2:

This is how pseudo balancing is implemented. Two RouterOS are configured in mirrored ways, and both of them are ready to replace the MASTER router if it fails. Importantly, this configuration ensures that all processing powers within the segment are in use, and secondary equipment isn’t idle. Also note that PREEMPT mode in RouterOS is enabled by default: it allows the failed MASTER router to regain its role when it’s substituted by one of the BACKUP routers. Accordingly PREEMPT for backup routers should be disabled.

STP security

STP (Spanning Tree Protocol) is an L2 protocol that protects a computer network from broadcast storms by blocking redundant physical connections. The point is that Ethernet frames don’t have a TTL field, and broadcast traffic could endlessly flow along channel connections if a switching loop occurs. The protocol operates exclusively at the data link layer, and BPDU 802.3 frames are used for communication. On managed switches, STP is usually enabled by default.

However, an attacker can send a BPDU frame with the lowest priority value towards the STP switch to seize the root switch role. Such a trick results either in a partial MITM attack or DoS.

To protect against spoofing in the spanning tree, use BPDU Guard. This mechanism blocks a port if it receives a BPDU frame that is normally used only for interaction between switches in the STP domain. By sending BPDU frames with the lowest priority values, an attacker can seize the role of the root switch, thus, delivering a partial MITM attack.

BPDU Guard is configured on ports that are ‘underneath’ the bridge.

That’s it! BPDU Guard configuring doesn’t cause any problems.

Choose STP root carefully

Under normal conditions, the switch with the lowest MAC address becomes the STP root switch. This must be taken into account: if some old D-Link becomes the root switch, this can affect network performance. Sometimes STP blocks links to FHRP Master routers; as a result, traffic starts to flow along a nonoptimal path. Configure the STP root switch (and STP root secondary) taking into account the specifics of your infrastructure.

MGMT security

The abbreviation MGMT applies to special management interfaces enabling you to configure devices. In RouterOS, the following services are used for this purpose:

• Telnet (TCP/23);
• API (TCP/8728);
• API-SSL (TCP/8729);
• SSH (TCP/22);
• HTTP (TCP/80);
• HTTPS (TCP/443); and 
• WinBox (TCP/8291).

Access to control panels should be limited to the admin subnet only. This prevents attempts to brute-force credentials from other subnets since all connections from other networks will be rejected.

However, if one of the admin’s computers is infected with a Trojan, a brute-forcing probability cannot be ruled out even within the admin subnet. To prevent this, you can further strengthen the protection as follows:

• add rule chains to prevent brute-forcing in Mangle/Raw tables;
• use only the SSH protocol and key authentication;
• change port numbers (of course, this isn’t a comprehensive security measure, but it can complicate searches for equipment control ports); and 
• if API/API-SSL aren’t in use, it’s better to disable them since they can also be used for brute-forcing.

Protect accounts on equipment

Use the principle of least privilege on your equipment; restrict the use of full accounts on the hardware; and keep track of privileges (i.e. access to equipment and configuring capacity) assigned to each engineer. Also, to optimize account management, you can deploy an AAA server to store accounts in a centralized way.

Conclusions

That’s all for now. As said above, this isn’t a comprehensive manual on MikroTik security, but I tried to focus on critical protection mechanisms that require special attention in corporate networks. In my experience, most problems originate from incorrect security settings inside the network. Apparently, this is due to the negligence of network engineers, which is understandable: some networks don’t change for decades, and people simply forget about critical settings that might be misconfigured.

In addition, the RouterOS and SwitchOS systems used in MikroTik equipment are far from perfection. They lack such mechanisms as DAI, RA Guard, SAVI, and Port Security. MikroTik products are very popular, but their developers still have a vast room for improvement.

In the near future, I expect to publish the second part of this research; it will address other aspects of MikroTik security.