Get best of the week

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 my network and services that “look out” because of it from external attacks. Namely, with just three rules, organize a honeypot on Mikrotik.

So, let's imagine that we have a small office, an 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. But this is not for long, after a couple of days, the terminal server audit log will begin to show several failed authorizations per second from unknown clients.

Another situation, you have asterisk hidden behind Mikrotik, of course, not on the 5060 udp port, and after a couple of days password guessing also starts ... yes yes, I know, fail2ban is our whole thing, but I still have to puff over it ... for example, I recently lifted it to ubuntu On April 18, I 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 ... but Google can’t google quick settings of ready-made “recipes”, the numbers of releases grow over the years, and articles with “ recipes ”for the old versions no longer work, but almost no new ones ... But something I digress ...

So, what is honeypot in a nutshell - is a decoy, 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 black list. 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 external ether4-wan 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 pre-routing stage drops packets of the "guests" whose srs-address got into the "Honeypot Hacker".

After two weeks of work at my home Mikrotik, the Honeypot Hacker list included about one and a half thousand IP addresses of udder-friendly fans of my network resources (home telephony, mail, nextcloud, rdp). Brute-force attacks stopped, bliss ensued.

At work, not everything turned out to be so simple, they continue to break the rdp server with 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 similar on the Internet, but there is a 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=2m 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=2m 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=2m 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=2m 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=2m 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 allowed to make only 12 new “requests” to the RDP server. One login attempt is from 1 to 4 “requests”. At the 12th “request” - a lock for 15 minutes. In my case, the attackers didn’t stop hacking the server, they adapted to the timers and now they do it very slowly, this selection speed reduces the attack efficiency to zero. The employees of the enterprise practically do not experience any inconvenience in the work taken.

Another little trick
5, , .

/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

8 IP . !

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

On my devices, this setting works in conjunction with the honeypot rules described above, complementing them well.

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

More articles:


All Articles