MikroTik Router Hardening

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

Mikrotik routers straight out of the box require security hardening like any Arista, Cisco, Juniper, or Ubiquiti router. Some very basic configuration changes can be made immediately to reduce attack surface while also implementing best practices, and more advanced changes allow routers to pass compliance scans and formal audits. Almost all of the configuration changes below are included in requirements for PCI-DSS and HIPAA compliance, and the best-practice steps are also included in CIS security benchmarks and DISA STIGs.

Router Configuration

Interface	IP	In Use	Description
ether1	192.168.88.181/24	Yes	WAN
ether2	10.1.157.1/24	Yes	Management
ether3	192.168.0.1/24	Yes	LAN
ether4	None	No	N/A
ether5	None	No	N/A

This is a typical branch office configuration with Inside, Outside, and Management network "zones". It could very easily be an RB-751 in a home office, or an RB-951 or hAP in a branch office. The Management network isn't strictly necessary in organizations without applicable compliance requirements but it's a best practice.

For organizations that do have compliance standards in place, having a separate management network statisfies Infrastructure Router STIG Finding V-5611:

The network devices must only allow management connections for administrative access from hosts residing in the management network.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-5611

Navigation

1. Securing Interfaces
   1. Show Interfaces
   2. Disable Unused Interfaces
2. Discovery Scan
   1. Discovered Ports
   2. Discovered Services
   3. Scan Summary
3. Managing Services
   1. View Services
   2. Disable Services
4. Strong Crypto
5. Firewalling
6. Managing Credentials
   1. Default Admin Account
   2. Additional Accounts
   3. Adverse Accounts
7. Neighbor Discovery
   1. IPv4 ND
   2. IPv6 ND
8. Reverse Path Filtering
9. Banner Configuration
10. NTP Clock Synchronization
11. SNMP Configuration
12. Configuration Backup
13. Additional Configurations
14. Summary

Securing Interfaces

The first step we'll take is disabling any physical network interfaces that aren't in use, denying an intruder access to the device if they somehow got into the wiring closet or server room. To plug into the router they'd have to disconnect a live connection and draw attention.

Show Interfaces

First list all the interfaces, making note of the numbers associated with each interface (refer to the table above for the interfaces in this exercise):

/interface print

Disable Unused Interfaces

Then shut off all the interfaces that aren't live so they can't be used to access the device. In our case interfaces 1, 2, and 3 are in use, and we're not using interfaces 4 and 5:

/interface set 4,5 disabled=yes

Once your network interfaces have been secured and the rest of this guide is complete also take a look at segment your networks with VLANs.

Discovery Scan

Next we'll do an Nmap scan of the stock router from the WAN side to get a baseline of open ports and services. This will our starting point, shown below:

nmap -A -T4 -Pn -v 192.168.88.181

If you want to learn more about using Nmap check out the Network Scanning With Nmap write-up that will get you going. The relevant portions of the port scan output are shown in the following sections. For any port scan we pay particular attention to the open ports that are found, and the services that are running on those ports.

Discovered Ports

These are the open ports that were discovered during the port scan:

Scanning 192.168.88.181 [1000 ports]
Discovered open port 21/tcp on 192.168.88.181
Discovered open port 53/tcp on 192.168.88.181
Discovered open port 23/tcp on 192.168.88.181
Discovered open port 80/tcp on 192.168.88.181
Discovered open port 22/tcp on 192.168.88.181
Discovered open port 2000/tcp on 192.168.88.181
Discovered open port 8291/tcp on 192.168.88.181

Knowing your basic ports and protocols is very helpful when looking at port scan results, spend some time learning them if you haven't already.

Discovered Services

These are the services running on the open ports that were discovered during the port scan:

Host is up (0.012s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE        VERSION
21/tcp   open  ftp            MikroTik router ftpd 6.37.1
22/tcp   open  ssh            MikroTik RouterOS sshd (protocol 2.0)
| ssh-hostkey:
|   1024 68:22:e5:37:be:d9:7f:76:e9:44:b8:7b:03:0b:07:66 (DSA)
|_  2048 5e:1c:a0:82:e7:a7:e8:bb:ba:a7:f4:0b:b6:b5:f5:eb (RSA)
23/tcp   open  telnet         Linux telnetd
53/tcp   open  domain         MikroTik RouterOS named or OpenDNS Updater
80/tcp   open  http           MikroTik router config httpd
| http-methods:
|_  Supported Methods: GET HEAD
| http-robots.txt: 1 disallowed entry
|_/
|_http-title: RouterOS router configuration page
2000/tcp open  bandwidth-test MikroTik bandwidth-test server
8291/tcp open  winbox         MikroTik WinBox
Service Info: OSs: Linux, RouterOS; Device: router; CPE: cpe:/o:mikrotik:routeros, cpe:/o:linux:linux_kernel

Scan Summary

Nmap found a number of issues, and it's clear we have some work to do. The router is running multiple unencrypted protocols, and services that aren't necessary at all. The FTP service also gives an attacker doing reconnaissance the exact version of RouterOS that's running. We also see the result of using the factory default credentials. If this router was connected to the Internet just like it is right now it would almost certainly be exploited shortly after coming online.

Services

Like in most production networks we assume the router will only be administered through SSH and Secure-mode Winbox. Both SSH and Winbox sessions are encrypted so we don't have to worry about plaintext information leaking. First we'll view running services on the router then shut off all services except SSH and Winbox. Lastly we'll scan again, just to make sure the changes are in place.

View Services

List services running on the router:

/ip service print

Services like Telnet, FTP, and WWW are inherently unsecure and shouldn't be used in production environments given secure alternatives like SSH and HTTPS.

Disable Services

The following commands turn off Telnet, FTP, HTTP, and SOCKS services, and the bandwidth test server that is enabled by default, as well as disabling remote DNS requests relayed through the router:

/ip service disable [find name=telnet]
/ip service disable [find name=ftp]
/ip service disable [find name=www]
/ip service disable [find name=www-ssl]
/ip service disable [find name=api]
/ip service disable [find name=api-ssl]
/tool bandwidth-server set enabled=no
/ip dns set allow-remote-requests=no
/ip socks set enabled=no

Disabling HTTP specifically statisfies Infrastructure Router STIG Finding V-3085:

Network devices must have HTTP service for administrative access disabled.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-3085

FTP must be disabled per Infrastructure Router STIG Finding V-14668:

FTP servers on the device must be disabled.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-14668

Verify that the basic services have been disabled (shown with an "X" by the service name) by running the following:

/ip service print

We'll also shut off the MAC Telnet and MAC Winbox servers. These are used to give administrators access to a router without an IP address assigned, but by default are turned on and running on ALL interfaces - even WAN interfaces. A user inside your LAN could connect to the device via one of the MAC services, and that access needs to be restricted both from internal and external networks. We'll disable these services entirely, and it's suggested re-enabling them only on dedicated management interfaces.

/tool mac-server set [find] disabled=yes
/tool mac-server mac-winbox set [find] disabled=yes
/tool mac-server ping set enabled=no

Verify that the other services have been disabled (shown with an "X" by the service name) by running the following:

/tool mac-server print
/tool mac-server mac-winbox print
/tool mac-server ping print

We'll also disable the new RoMON feature, assuming that you aren't using it. If you're using RoMON for device management then leave it on, but if you aren't using it then disable it to reduce the attack surface:

/tool romon set enabled=no

Strong Crypto

Stronger crypto for SSH is available as of RouterOS 6.30, so we'll enable that. SSH clients like Putty that can utilize the stronger crypto will default to that, and leave the weaker algorithms unused. As of November 2016 there is no way to explicitly disable the weaker crypto algorithms in the Mikrotik for purposes of SSH. Turn on the SSH strong crypto:

/ip ssh set strong-crypto=yes

Routers should only be administered via secure protocols, and those protocols should use robust ciphers per Infrastructure Router STIG Finding V-3069:

Management connections to a network device must be established using secure protocols with FIPS 140-2 validated cryptographic modules.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-3069

Firewall

Despite the configurations already changed an attacker could still attempt to login with the default Mikrotik admin credentials across the Internet using SSH or Winbox and would succeed. We'll disable access (input) from the WAN side by adding some basic firewall rules, then create a firewall address list for blocking Bogons. Bogons are network addresses that have no business being routed over the Internet, and normally they aren't unless someone is trying to spoof traffic and make it appear as though it came from your own network. Team Cymru maintains a really fantastic list of Bogons that you should be blocking.

If you're not already familiar with how firewall chains and rules operate take a look at the Mikrotik Firewall article that breaks it all down in simple terms.

Here's an abbreviated Bogon address list:

/ip firewall address-list
add address=192.168.0.0/16 list=Bogon
add address=10.0.0.0/8 list=Bogon
add address=172.16.0.0/12 list=Bogon
add address=127.0.0.0/8 list=Bogon
add address=0.0.0.0/8 list=Bogon
add address=169.254.0.0/16 list=Bogon

Now, the firewall rules:

/ip firewall filter
add chain=input comment="Accept Established / Related Input" connection-state=established,related

add chain=input comment="Allow Management Input" src-address=10.1.157.0/24

add action=drop chain=input comment="Drop Input" log=yes log-prefix="Input Drop"

add action=fasttrack-connection chain=forward comment="Fast Track Established / Related Forward" connection-state=established,related

add chain=forward comment="Accept Established / Related Forward" connection-state=established,related

add chain=forward comment="Allow client LAN traffic out WAN" out-interface=ether1-gateway src-address=192.168.0.0/24

add action=drop chain=forward comment="Drop Bogon Forward -> Ether1" in-interface=ether1-gateway log=yes log-prefix="Bogon Forward Drop" src-address-list=Bogon

add action=drop chain=forward comment="Drop All Forward"

Logging is turned on for a couple rules: Drop Input and the Drop Bogon Forward. If someone is trying to get in repeatedly we want the source logged so investigation and remediation can happen.

Input is allowed to the router from the management subnet, and everything else should be dropped on the Input chain. The only people who should be trying to access the router directly, instead of just forwarding traffic through it, should be the network administrators whose workstations are on the management subnet. If this router was taking part in GRE, EoIP, or IPSEC tunnels then additional input rules would need to be added to allow those tunnels to be established, but that's covered in other articles. See the Mikrotik Firewall write-up for more in-depth explanations of Rules, Actions, Chains, and more.

Credentials

Now that we're (relatively) secure from the outside let's secure a couple things inside the router.

Default Admin Account

First, let's set a password on the default admin user, then change the admin username to something other than the factory default "admin". This is required per Infrastructure Router STIG Finding V-3143:

Network devices must not have any default manufacturer passwords.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-3143

Just like renaming the Administrator account on Windows servers it's a good idea to rename the Mikrotik admin user to something other than a known default (admin):

/user set 0 password=mygreatpassword
/user set 0 name=tikadmin comment="Default account - BACKUP ONLY"

Additional Accounts

All router administrators should have their own logins for the purpose of non-repudation, and only use those logins to administer the device. The default login that cannot be deleted should only be used for emergency login purposes. Using individual accounts is required per Infrastructure Router STIG Finding V-3056:

Group accounts must not be configured for use on the network device.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-3056

Create a user for each administrator accessing the device:

/user add name=tyler password=myawesomepassword group=full comment="Tyler @ Manito Networks"

The user we just renamed should only be used for backup access purposes if other credentials somehow were lost or forgotten. This also allows quick disabling of an administrator's access when they leave the organization without affecting other administrative access.

Adverse Accounts

When an administrator leaves the organization their access to the router should be removed so they are unable to change any configurations. If an administrator goes on a leave of absence or is put on some manner of "legal hold" it can also be a good idea to temporarily disable their access, depending on the company's compliance requirements and legal counsel input.

To disable an account (can be re-enabled later):

/user disable [find name=tyler]

To delete an account (cannot be undone):

/user remove [find name=tyler]

Proactively managing accounts on your routers satisfies Infrastructure Router STIG Finding V-3058:

Unauthorized accounts must not be configured for access to the network device.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-3058

Neighbor Discovery

Another best practice is to disable neighbor discovery, which will stop the router from being discovered by other devices running Mikrotik Neighbor Discovery Protocol (NDP) or Cisco Discovery Protocol (CDP).

IPv4 ND

First we'll turn it off by default for IPv4, so when new interfaces come online they won't participate:

/ip neighbor discovery settings set default=no default-for-dynamic=no

Then we'll shut it off on each individual IPv4 interface that's already running, because out of the box it's enabled on interfaces by default (even the WAN). This is especially important for WISP organizations who are using Mikrotik devices as CPE's. Not turning off ND on the WAN side can disclose information about one customer's equipment to another.

/ip neighbor discovery set [find] discover=no

All other ports are turned off, so no discovery is going to happen there. Once that's done if you have an interface on a management subnet / VLAN it wouldn't hurt to allow discovery protocols to run just on that interface.

IPv6 ND

Neighbor discovery can be turned off for IPv6 as well:

/ipv6 nd set [find] disabled=yes

This may have adverse effects on the performance of your IPv6 network - test before implementing in production.

Reverse Path Filtering

We'll also turn on Reverse Path Filtering (RPF), also known as Reverse Path Forwarding. This feature drops packet traffic that appears to be spoofed, i.e. a packet coming from an internal LAN subnet heading outbound but with a different source IP address than the local network's. This is very common when a workstation has been infected with a virus and is now participating in a DDoS attack. We'll turn on RPF in the IP > Settings menu:

/ip settings set rp-filter=strict

It has been noted the the Reverse Path Filter feature can cause issues if a router is multi-homed. Unfortunately Mikrotik's implementation of this feature doesn't allow Reverse Path Filtering to be enabled on specific interfaces - only for the entire device - so watch out for that if your device is multi-homed.

Implementing RPF satisfies Infrastructure Router STIG Finding V-14707:

The network element must be configured from accepting any outbound IP packet that contains an illegitimate address in the source address field via egress ACL or by enabling Unicast Reverse Path Forwarding in an IPv6 enclave.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-14707

Assuming you can implement RPF please do so. It could help limit the impact of future large-scale DDoS attacks if your internal hosts are co-opted into a botnet, and it's part of being a good Internet citizen. This kind of filtering is also documented as Best Common Practice (BCP) #38, as well as RFC #2827.

Banner

We should also set a login banner that is displayed when someone logs (or attempts to log) into the router. This is required by a number of compliance standards, and is also defined in a STIG. Depending on the country and jurisdiction you're in this banner statement may or may not be legally relevant, but it certainly doesn't hurt to have a banner displayed on login. First, set the banner to be displayed at login:

/system note set show-at-login=yes

Then set the contents of the banner message. This should be something that clearly states that access to the router is for authorized administrators only, and that access is monitored.

/system note set note="Manito Networks, LLC - Authorized administrators only. Access to this device is monitored."

Now when an administrator (or anyone else) logs into the router remotely via SSH or Telnet this banner will appear. It will also appear when a terminal is opened in Winbox. For organizations like the US DoD this type of banner is required per Infrastructure Router STIG Finding V-3013:

Network devices must display the DoD-approved logon banner warning.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-3013

NTP Clock Synchronization

We should also set the router to pull updated time from an NTP server, so the router (and hopefully all other routers in the organization) remain in sync with an accurate clock. When a router's clock isn't correct any log analysis or log correlation becomes very difficult because the timestamps can't be trusted. Set the NTP client up to use the pool.ntp.org project:

/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org

Many organizations set their infrastructure device timezones to UTC so that all timestamps match across devices and don't have to be adjusted for local time individually when doing log analysis. This isn't required, but it does help if your organization spans multiple timezones - for more information see the Mikrotik NTP article.

Setting multiple NTP servers satisfies Infrastructure Router STIG Finding V-23747:

Network devices must use at least two NTP servers to synchronize time.

https://www.stigviewer.com/stig/infrastructure_router/2016-07-07/finding/V-23747

SNMP Configuration

The SNMP protocol allows for robust monitoring, but there is more to configuring SNMP than can be outlined here quickly. See the SNMP Monitoring write-up for a complete walkthrough of configuring SNMP on MikroTik.

Configuration Backup

Last but certainly not least, we'll create a backup copy of the new config that can be downloaded from the router and stored with other backups in case the router fails and needs to be replaced:

export compact file=backup_config_router01

Additional Configuration

The configuration changes in this article are "quick wins" that secure devices quickly and against typical attacks. Beyond these changes there are a number of things you can do to secure your organization overall. Once your devices are configured and stable take a look at the following solutions to take you further:

1. Centralize device logging and monitoring with Syslog
2. Monitor network flows with Netflow and IPFIX
3. Configure wireless client isolation
4. Filter P2P Traffic
5. Segment networks with VLANs

Summary

Long-term device security and risk management means not only putting these settings in place, but also monitoring your devices and auditing the settings that are in place regularly. Security isn't something that you do once and then never think about again - it's an evolving process that has to become part of your organization's culture.