🥇An Easy Way to Protect Your Mikrotik from Attacks

I want to share with the community a simple and effective method to protect your network and the services exposed through it using Mikrotik from external attacks. Specifically, by implementing three rules to set up a honeypot on your Mikrotik.

Let’s imagine we have a small office with an external IP behind which an RDP server is located for remote work employees. The first rule is, of course, to change the port 3389 on the external interface to another one. However, this solution won’t last long; after a couple of days, the terminal server’s audit log will start showing several failed authorization attempts per second from unknown clients.

In another scenario, let’s say you have an Asterisk hidden behind Mikrotik, naturally not on port 5060 UDP, and after a few days, password brute-forcing starts again… Yes, I know, fail2ban is our salvation, but you will still need to configure it… For example, I recently set it up on Ubuntu 18.04 and was surprised to find that out of the box, fail2ban doesn’t contain current settings for Asterisk from the same box of the same Ubuntu distribution… and quick recipes from Google searches aren’t yielding results either; version numbers are rising over the years, while articles with recipes for older versions are becoming obsolete, and new ones are hardly appearing… But I digress...

So, what is a honeypot in a nutshell? It’s a bait; in our case, it’s a popular port on an external IP. Any request to this port from an external client adds the source address to a blacklist. That’s it.

/ip firewall filter
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment="block honeypot ssh rdp winbox" 
    connection-state=new dst-port=22,3389,8291 in-interface=
    ether4-wan protocol=tcp
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment=
    "block honeypot asterisk" connection-state=new dst-port=5060 
    in-interface=ether4-wan protocol=udp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
    "Honeypot Hacker"

The first rule for popular TCP ports 22, 3389, 8291 on the external interface ether4-wan sends the IP of the "guest" to the "Honeypot Hacker" list (ports for SSH, RDP, and Winbox are deliberately disabled or changed to other ports). The second rule does the same for the popular UDP 5060 port.

The third rule drops packets from "guests" whose source address has appeared on the "Honeypot Hacker" list in the prerouting stage.

After two weeks of my home Mikrotik running, the "Honeypot Hacker" list included about fifteen hundred IP addresses of those who enjoyed "testing my network resources" (I have my telephony, email, Nextcloud, RDP at home). Brute-force attacks ceased, resulting in bliss.

At work, things turned out to be more complicated; the RDP server continues to be attacked by password brute-forcing.

It seems that the port number was determined by a scanner long before the honeypot was activated, and during quarantine, it isn't so easy to reconfigure over 100 users, of whom 20% are over 65 years old. In cases where the port cannot be changed, there’s a small workable recipe. I've seen something similar online, but it includes some adjustments and fine-tuning:

Rules for Setting Up Port Knocking

 /ip firewall filter
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=15m chain=forward comment=rdp_to_blacklist 
    connection-state=new dst-port=3389 protocol=tcp src-address-list=
    rdp_stage12
add action=add-src-to-address-list address-list=rdp_stage12 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage11
add action=add-src-to-address-list address-list=rdp_stage11 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage10
add action=add-src-to-address-list address-list=rdp_stage10 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage9
add action=add-src-to-address-list address-list=rdp_stage9 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage8
add action=add-src-to-address-list address-list=rdp_stage8 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage7 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage6
add action=add-src-to-address-list address-list=rdp_stage6 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
rdp_blacklist

Over a span of 4 minutes, a remote client is allowed to make only 12 new 'requests' to the RDP server. One login attempt consists of 1 to 4 'requests'. Upon the 12th 'request', the IP is blocked for 15 minutes. In my case, the attackers have not stopped trying to breach the server; rather, they have adjusted to the timers and are now doing it very slowly, such a slow pace renders the attack ineffective. The company's employees hardly experience any inconveniences due to these measures.

Another little trick
This rule is activated on a schedule at 1 AM and deactivated at 5 AM, when real people are definitely asleep, while automated scanners continue to stay awake.

/ip firewall filter 
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=1w0d0h0m chain=forward comment=
    "night_rdp_blacklist" connection-state=new disabled=
    yes dst-port=3389 protocol=tcp src-address-list=rdp_stage8

Already on the 8th connection attempt, the attacker's IP is blacklisted for a week. How nice!

Additionally, I’ll include a link to a Wiki article with a working setup to protect Mikrotik from network scanners. wiki.mikrotik.com/wiki/Drop_port_scanners

On my devices, this setting works together with the aforementioned honeypot rules, complementing them quite well.

UPD: As suggested in the comments, the packet drop rule has been moved to RAW to reduce the load on the router.

Source: habr.com

An easy way to protect your Mikrotik from attacks