Router Hardening and Network Security

Overview

I completed a project to harden a MikroTik router and improve the security of devices connected to it by restricting and filtering network traffic.

The main reason for this project was the continuous scanning and probing performed by automated bots against devices that are directly exposed to the Internet through public IP addresses. These systems are commonly targeted for service discovery, credential attacks, and attempts to exploit exposed services on the router or servers behind it.

The project also included security controls for users and devices behind the router. Services such as Remote Desktop Protocol (RDP) and Windows file sharing using SMB can become targets when they are exposed through NAT or otherwise reachable from untrusted networks. I therefore restricted access to sensitive LAN services and allowed them only from approved source networks or IP addresses.

To address these risks, I implemented strict firewall filtering, IP address allowlists, RAW firewall rules, and a VPN service for controlled remote access. I also configured the MikroTik router as a centralized DNS cache and resolver using DNS over HTTPS (DoH). I used Cloudflare's malware-filtering DoH service which was used to block domains associated with known malware and phishing.

Overall, the goal was to ensure that the router and devices behind it processed only legitimate traffic required by the network. Unwanted and clearly unauthorized traffic was dropped as early as possible, reducing both the attack surface and unnecessary processing on the router.

Objectives

The main goal was to harden the MikroTik router against unsolicited and malicious Internet traffic while applying security policies to services exposed by devices on the LAN.

The specific objectives were to:

• Secure the router against unsolicited, invalid, and probing packets.

• Reduce exposure of RouterOS management services and prevent unnecessary services from being accessible.

• Detect common port-scanning activity and block identified scanners.

• Create an IP allowlist for trusted public source addresses that required access to selected services.

• Restrict RDP and SMB-related traffic from untrusted external sources.

• Disable unnecessary RouterOS services and protocol helpers.

• Apply traffic policies using firewall rules and address lists.

• Provide controlled remote access to the LAN through a VPN service.

• Centralize DNS resolution for LAN clients and forward DNS queries through an encrypted DoH connection.

• Use a DNS resolver with malware and phishing protection for users on the network.

Network Architecture

The network was a branch-office network with a WAN connection on one side and the local LAN on the other. The LAN contained employee workstations and servers connected through switches.

The MikroTik router served as the network's edge router, firewall, DHCP server, and DNS cache/resolver. Traffic from LAN devices passed through the switches before reaching the MikroTik router.

WAN

|

|

MikroTik Router

Router | Firewall | DHCP | DNS

|

+------------------+

|              |

Switch-1      Switch-2

|              |

LAN Clients   LAN Clients / Servers

The security policies were primarily applied at the MikroTik router so that unwanted traffic could be blocked before reaching the protected devices.

Technologies Used

Because the organization did not want to deploy a separate firewall platform such as Kerio Control, I implemented the security controls directly on the MikroTik router.

RouterOS provides stateful firewall filtering, address lists, NAT, protocol helpers, and RAW filtering, which allowed the router to enforce both router-level and LAN-level security policies.

Since firewall rules add processing overhead, I also considered rule order and used RAW filtering where appropriate. RAW rules can process or drop packets before connection tracking, which can reduce CPU usage when large amounts of unwanted traffic are received.

The main technologies and features used in the project were:

• MikroTik RouterOS

• Stateful firewall filtering

• Firewall address lists

• RAW firewall rules

• NAT and destination NAT redirection

• RouterOS IP services

• RouterOS firewall service-port helpers

• DNS cache and DNS over HTTPS (DoH)

• Cloudflare malware-filtering DNS

• L2TP/IPsec VPN

• DHCP

Configurations

I divided the security configuration into two main areas:

• Hardening the router itself

• Securing the devices and services behind the router

This separation was important because the router itself could be targeted directly from the Internet, while services running on LAN devices could be targeted through NAT or other forms of external access.

Router Hardening

These configurations focused on reducing the router's attack surface, restricting incoming connections, and dropping unwanted traffic before it could consume unnecessary router resources.

IP Services

RouterOS provides several services for management and administration, including Telnet, FTP, WebFig, SSH, API, and WinBox. These services listen for incoming connections and therefore increase the router's exposed attack surface when enabled.

In this project, I disabled the unnecessary management services. WinBox was retained because it was required for administration, but I moved it from its default port to port 8200.

/ip service

set telnet disabled=yes

set ftp disabled=yes

set www disabled=yes

set ssh disabled=yes

set api disabled=yes

set winbox port=8200

set api-ssl disabled=yes

Changing the WinBox port does not provide strong security by itself. Its main purpose here was to reduce exposure to automated scans that target the default port. The actual access control was provided by the firewall rules described below.

Service Ports

RouterOS also provides protocol helpers under IP > Firewall > Service Ports. These are not management services listening on the router. Instead, they are connection-tracking/NAT helpers that assist certain protocols when they pass through the router, particularly protocols that may have difficulties operating through NAT. Examples include FTP, H.323, IRC, PPTP, SIP, TFTP, and others.

Because most of these helpers were not required by the network, I disabled them. SIP was left enabled because it was used by the local network.

/ip firewall service-port

set ftp disabled=yes

set tftp disabled=yes

set irc disabled=yes

set h323 disabled=yes

set pptp disabled=yes

set udplite disabled=yes

set dccp disabled=yes

set sctp disabled=yes

Disabling an unused helper reduces unnecessary protocol handling and prevents a protocol helper from being enabled when the corresponding service is not required.

White List IPs

I used a firewall address list as an allowlist for trusted public IP addresses. These were addresses that I had verified and that were required to access specific services.

Since the actual public IP addresses cannot be published here, I used a sample address in the configuration below:

/ip firewall address-list

add address=5.237.2.1 list="White List"

The allowlist was later referenced by firewall rules to give trusted source addresses access before the final deny rule.

Filter Rules

I then created the main firewall policies under IP > Firewall > Filter Rules.

The order of firewall rules is important because RouterOS evaluates packets against the rules in sequence. The rules below are shown in the same order in which I configured them.

The first two rules handled established and related connections and dropped invalid connections. These were placed at top of the input firewall list so that known connection states could be handled efficiently.

/ip firewall filter

add action=accept chain=input comment="Accept Es. & Rel." connection-state=\

established,related in-interface=ether1

add action=drop chain=input comment="Drop Invalid" connection-state=invalid \

in-interface=ether1

I then allowed traffic from the trusted public IP addresses in the allowlist:

/ip firewall filter

add action=accept chain=input comment="Allowed IPs" in-interface=ether1 \

src-address-list="White List"

WinBox was configured to use TCP port 8200. In this project, I allowed incoming WinBox connections from any source IP because remote administration could be required from changing public addresses:

/ip firewall filter

add action=accept chain=input comment=WinBox dst-port=8200 in-interface=\

ether1 protocol=tcp

Next, I added rules to identify common TCP and UDP port-scanning activity. When a source matched the Port Scan Detection (PSD) matcher, its address was added to the Scanner address list:

/ip firewall filter

add action=add-src-to-address-list address-list=Scanner address-list-timeout=\

none-static chain=input comment="TCP Scanner" in-interface=ether1 \

protocol=tcp psd=21,3s,3,1

add action=add-src-to-address-list address-list=Scanner address-list-timeout=\

none-static chain=input comment="UDP Scanner" in-interface=ether1 \

protocol=udp psd=21,3s,3,1

Instead of immediately dropping only the packets that matched the scanner-detection rules, I decided to place identified scanner IPs into an address list and then block subsequent traffic from those addresses.

I used the RAW table for this because the scanner address list could be matched without requiring connection-state inspection. RAW processing occurs before connection tracking and can therefore reduce the amount of work performed by the router when dropping unwanted traffic.

/ip firewall raw

add action=drop chain=prerouting comment="Drop Scanners" in-interface=ether1 \

src-address-list=Scanner

Finally, I added a default drop rule for all other incoming traffic from the WAN:

add action=drop chain=input comment="Drop All" in-interface=ether1

This rule completed the default-deny policy. Traffic that was not already explicitly permitted, such as traffic from the allowlist or traffic required for the VPN service, was dropped.

This approach was also useful during testing against high-volume unwanted traffic. By dropping traffic that did not match an explicitly allowed policy, the router did not need to continue processing the traffic as a legitimate connection.

In this project, I intentionally did not allow unsolicited ICMP traffic to the router from the public Internet because the router did not need to be publicly reachable through ICMP. Since ICMP is not simply an diagnostic protocol, but It is also used for important network functions such as supporting Path MTU Discovery. Therefore, blocking all ICMP can cause connectivity problems for some applications and network paths. To avoid these issues, I added the public IP addresses of organization’s services that required ICMP access to the allowlist. These addresses were added selectively because the allowlist was also used as part of the broader WAN access policy.

LAN Users Security

The second part of the project focused on protecting devices and services behind the router.

The main controls were centralized DNS security, restricting RDP and SMB access, and providing a controlled VPN service for remote users.

Secure DNS

I wanted LAN devices to use a centralized DNS resolver instead of communicating directly with arbitrary external DNS servers. Therefore, I configured the router to accept DNS requests from LAN clients and use Cloudflare's malware-filtering resolver through DNS over HTTPS.

/ip dns

set allow-remote-requests=yes servers=1.1.1.2,1.0.0.2 use-doh-server=\

    https://security.cloudflare-dns.com/dns-query

The regular DNS servers were configured so that the router could resolve the hostname of the DoH service itself. Once the DoH server is available and its hostname can be resolved, RouterOS uses DoH for DNS queries rather than falling back to the regular DNS servers for normal DNS resolution.

I then redirected DNS requests originating from the LAN to the router. This prevented clients from simply bypassing the centralized resolver by manually configuring another DNS server.

/ip firewall nat

add action=redirect chain=dstnat dst-port=53 protocol=udp src-address=\

192.168.0.0/16 to-ports=53

add action=redirect chain=dstnat dst-port=53 protocol=tcp src-address=\

192.168.0.0/16 to-ports=53

As a result, normal DNS requests from LAN devices were redirected to the router's DNS service, and the router resolved them through the configured DoH resolver.

This provided two security benefits: encrypted DNS communication between the router and the upstream resolver, and DNS-based filtering for domains associated with known malware and phishing.

Restrict RDP & SMB

RDP and SMB are commonly targeted services, particularly when they are exposed to untrusted networks. In this network, RDP was used for administrative access and SMB was used for file sharing between local users.

I therefore restricted these protocols so that traffic arriving from the WAN could not reach LAN devices unless it originated from the permitted local address range.

I used RAW rules so that these unwanted packets could be dropped before connection tracking:

/ip firewall raw

add action=drop chain=prerouting comment="RDP & SMB" \

dst-port=3389,135,139,445 in-interface=ether1 \

protocol=tcp src-address=!192.168.0.0/16

add action=drop chain=prerouting comment="RDP & SMB" \

dst-port=3389,135,137,138 in-interface=ether1 \

protocol=udp src-address=!192.168.0.0/16

This prevented unsolicited external traffic targeting RDP and SMB-related ports from reaching devices inside the LAN.

VPN Server

For users who needed remote access to the office network, I configured an L2TP/IPsec VPN server. I selected L2TP/IPsec because it was supported natively by the Windows clients used in the environment and did not require users to install additional VPN software or import certificates file.

I created an IP pool for VPN clients:

/ip pool

add name=VPN-Pool ranges=192.168.200.2-192.168.200.254

I then created a PPP profile for the VPN users:

/ppp profile

set *0 change-tcp-mss=default

add change-tcp-mss=yes dns-server=192.168.88.10 \

local-address=192.168.200.1 name="L2TP Server" only-one=yes \

remote-address=VPN-Pool use-compression=no use-encryption=yes

I configured the L2TP server with MS-CHAPv2 authentication and an IPsec pre-shared key:

/interface l2tp-server server

set authentication=mschap2 default-profile="L2TP Server" enabled=yes \

ipsec-secret=1234 use-ipsec=required

I then created credentials for the VPN users. The credentials shown below are only examples:

/ppp secret

add name=test password=test service=l2tp

To allow VPN clients to access the Internet through the office connection as well as internal resources, I masqueraded traffic originating from the VPN address pool:

/ip firewall nat

add action=masquerade chain=srcnat comment="Masquerade VPN" \

src-address=192.168.200.0/24

Because the WAN firewall used a default-deny policy, I also needed to explicitly allow the protocols required by L2TP/IPsec:

/ip firewall filter

add action=accept chain=input comment="L2TP 1" \

dst-port=500,4500,1701 in-interface=ether1 log=yes protocol=udp

add action=accept chain=input comment="L2TP 2" \

in-interface=ether1 protocol=ipsec-esp

This allowed external users to establish the VPN connection while keeping unrelated inbound traffic blocked.

Problems and Troubleshooting

During testing, I initially could not connect to the router's L2TP VPN server. I first checked the router logs, but they did not provide enough information to identify the cause. I also enabled logging on the affected firewall rules, but the additional information was still insufficient.

I then used another RouterOS router as the VPN client. RouterOS provided more detailed connection and authentication information during the connection attempt, but the resulting errors were still too general to identify the problem.

I therefore returned to the configuration and checked the VPN setup from the beginning. I tested values that would normally not need to be changed, including MTU settings and the security profile, and temporarily disabled the firewall to eliminate firewall filtering as the cause.

Eventually, I found that the RouterOS security-related package required for the VPN functionality had been disabled accidentally. As a result, the router could not provide the L2TP/IPsec server functionality required by the configuration.

After enabling the required package and rebooting the router, the L2TP/IPsec server started working correctly.

Testing and Verification

I tested each major configuration area separately to make sure that the security controls worked as intended and did not interfere with legitimate network traffic.

For router hardening, I attempted to access the router through the WebFig HTTP service on port 80. The connection failed as expected because the HTTP service had been disabled.

For the disabled firewall service-port helpers, I attempted to establish a PPTP connection from a LAN client. The connection did not establish because the PPTP helper had been disabled and was not required by the network.

To test the IP allowlist, I added the public IP address of a test device connected through a mobile network to the White List address list. I then generated different types of incoming traffic, including VPN connection attempts and probing traffic. The firewall counters confirmed that the allowlist rule was receiving the expected traffic.

I removed the test IP from the allowlist and repeated the tests. This time, the traffic was blocked by the final WAN drop rule, except for services that had been explicitly permitted, such as the VPN service.

I then performed a port scan against the router from the WAN side. The firewall's scanner-detection rules identified the scanning activity and added the source IP address to the Scanner address list. Subsequent packets from that address were then dropped by the RAW rule. To verify the detected attempts, I temporarily enabled logging on the relevant firewall rules. After completing the test, I disabled logging again to avoid unnecessary resource usage.

For the centralized DNS configuration, I first checked the router's DNS cache and confirmed that domains required by the organization were being resolved correctly. I also tested domains that were not already present in the cache using RouterOS:

:put [:resolve "nasa.gov"]

To verify that DNS resolution continued to work through DoH, I temporarily blocked direct DNS traffic from the LAN to the WAN on TCP and UDP port 53. The router continued resolving new domains successfully, confirming that the clients were using the router's DNS service and that the router was resolving queries through the configured DoH connection.

/ip firewall raw

add action=drop chain=output comment="Test DoH" disabled=yes dst-port=53 \

out-interface=ether1 protocol=udp

add action=drop chain=output comment="Test DoH" disabled=yes dst-port=53 \

out-interface=ether1 protocol=tcp

I then removed the temporary testing rule.

For the RDP and SMB restrictions, I attempted to connect to devices with RDP enabled from a source address outside the permitted network range. The connection failed, and the corresponding RAW firewall rule showed an increased packet counter, confirming that the traffic was being dropped before reaching the LAN devices.

Finally, I tested the L2TP/IPsec VPN server from the WAN using different public source IP addresses. After correcting the disabled RouterOS package, the VPN connection was established successfully, and the connected client was able to reach permitted local and Internet services through the VPN.

Results

The project significantly reduced the exposure of the MikroTik router and devices behind it to unsolicited and unwanted network traffic.

At the router level, the attack surface was reduced, and unwanted WAN traffic was dropped before it could be processed further. Unauthorized probing and scanning attempts were detected and blocked, while legitimate and explicitly permitted sources could still access the required resources.

At the LAN level, network traffic was subject to centralized security policies. DNS resolution was protected and controlled, while services that could be exposed to external attacks or misuse were restricted to trusted networks and users.

Overall, the network moved from a largely open traffic model to a controlled, policy-based model in which only required and authorized traffic was allowed to reach the router and internal devices.

Resources

All configurations and resources used in this project, including the fully configured and tested RouterOS environment exported in OVA format, are available on my GitHub for reference.

[Link to this project on GitHub]