An easy way to protect your Mikrotik from attacks

I want to share with the community a simple and working way how to use Mikrotik to protect your network and services β€œpeeping out” from behind it from external attacks. Namely, with just three rules to organize a honeypot on Mikrotik.

So, let's imagine that we have a small office, the external IP behind which is an RDP server, for employees to work remotely. The first rule is of course to change port 3389 on the external interface to another one. But this is not for long, after a couple of days the terminal server audit log will start showing several unsuccessful authorizations per second from unknown clients.

Another situation, you have asterisk hidden behind Mikrotik, naturally not on 5060 udp port, and after a couple of days, password enumeration also begins ... yes, yes, I know, fail2ban is our everything, but you still have to puff on it ... for example, I recently raised it to ubuntu 18.04 and was surprised to find that out of the box fail2ban does not contain the actual settings for asterisk from the same box of the same ubuntu distribution kit ... and google quick settings of ready-made "recipes" is no longer possible, the numbers of releases are growing over the years, and articles with " recipes" for old versions no longer work, and there are almost no new ones ... But I digress ...

So, what is a honeypot in a nutshell - this is a bait, in our case, some popular port on an external IP, any request to this port from an external client sends the src address to the blacklist. All.

/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 on the popular TCP ports 22, 3389, 8291 of the ether4-wan external interface sends the "guest" IP to the "Honeypot Hacker" list (ports for ssh, rdp and winbox are disabled in advance or changed to others). The second does the same on the popular UDP 5060.

The third rule at the prerouting stage drops packages of "guests" whose srs-address is in "Honeypot Hacker".

After two weeks of operation of my home Mikrotik, the "Honeypot Hacker" list included about one and a half thousand IP addresses of those who like to "hold the udder" of my network resources (at home my own telephony, mail, nextcloud, rdp) Brute-force attacks stopped, bliss came.

At work, not everything turned out to be so simple, there the rdp server continues to be broken by brute force passwords.

Apparently, the port number was determined by the scanner long before the honeypot was turned on, and during quarantine it is not so easy to reconfigure more than 100 users, of which 20% are over 65 years old. In the case when the port cannot be changed, there is a small working recipe. I met something similar on the Internet, but here there is finished and fine-tuning:

Rules for configuring 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

In 4 minutes, the remote client is only allowed to make 12 new "requests" to the RDP server. One login attempt is from 1 to 4 "requests". At the 12th "request" - blocking for 15 minutes. In my case, the attackers did not stop hacking the server, they adjusted to the timers and now they are doing it very slowly, such a selection speed reduces the effectiveness of the attack to zero. Employees of the enterprise practically do not experience any inconvenience in their work from the measures taken.

Another little trick
This rule is scheduled to turn on at 5 am and turn off at XNUMX am, when the living people are definitely asleep and the automated pickers are still 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, the attacker's IP is blacklisted for a week. Beauty!

Well, in addition to the above, I will add a link to the Wiki article, with a working setting for protecting Mikrotik from network scanners. wiki.mikrotik.com/wiki/Drop_port_scanners

On my devices, this setting works together with the honeypot rules described above, complementing them nicely.

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

Add a comment