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

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
   1. Discovered Ports
   2. Discovered Services
   3. Scan Summary
   1. View Services
   2. Disable Services
   1. Default Admin Account
   2. Additional Accounts
   3. Adverse Accounts
   1. IPv4 ND
   2. IPv6 ND

   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:

   FTP must be disabled per Infrastructure Router STIG 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:

   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:

   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:

   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:

   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:

   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.