{"id":79489,"date":"2020-04-27T19:41:58","date_gmt":"2020-04-27T17:41:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/legkij-sposob-zashhitit-svoj-mikrotik-ot-atak"},"modified":"2020-04-27T19:41:58","modified_gmt":"2020-04-27T17:41:58","slug":"legkij-sposob-zashhitit-svoj-mikrotik-ot-atak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/legkij-sposob-zashhitit-svoj-mikrotik-ot-atak","title":{"rendered":"An easy way to protect your Mikrotik from attacks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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. <\/p>\n

Let\u2019s 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\u2019t last long; after a couple of days, the terminal server\u2019s audit log will start showing several failed authorization attempts per second from unknown clients. <\/p>\n

In another scenario, let\u2019s say you have an Asterisk hidden behind Mikrotik, naturally not on port 5060 UDP, and after a few days, password brute-forcing starts again\u2026 Yes, I know, fail2ban is our salvation, but you will still need to configure it\u2026 For example, I recently set it up on Ubuntu 18.04 and was surprised to find that out of the box, fail2ban doesn\u2019t contain current settings for Asterisk from the same box of the same Ubuntu distribution\u2026 and quick recipes from Google searches aren\u2019t 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\u2026 But I digress...
\n<\/a><\/noindex>
\nSo, what is a honeypot in a nutshell? It\u2019s a bait; in our case, it\u2019s a popular port on an external IP. Any request to this port from an external client adds the source address to a blacklist. That\u2019s it.<\/p>\n

\/ip firewall filter\nadd action=add-src-to-address-list address-list="Honeypot Hacker" \n    address-list-timeout=30d0h0m chain=input comment="block honeypot ssh rdp winbox" \n    connection-state=new dst-port=22,3389,8291 in-interface=\n    ether4-wan protocol=tcp\nadd action=add-src-to-address-list address-list="Honeypot Hacker" \n    address-list-timeout=30d0h0m chain=input comment=\n    "block honeypot asterisk" connection-state=new dst-port=5060 \n    in-interface=ether4-wan protocol=udp \n\/ip firewall raw\nadd action=drop chain=prerouting in-interface=ether4-wan src-address-list=\n    "Honeypot Hacker"\n<\/code><\/pre>\n
\nThe 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.<\/p>\n
The third rule drops packets from \"guests\" whose source address has appeared on the \"Honeypot Hacker\" list in the prerouting stage.<\/p>\n
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. <\/p>\n
At work, things turned out to be more complicated; the RDP server continues to be attacked by password brute-forcing.<\/p>\n
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\u2019s a small workable recipe. I've seen something similar online, but it includes some adjustments and fine-tuning: <\/p>\n
                        Rules for Setting Up Port Knocking<\/b><\/p>\n
 \/ip firewall filter\nadd action=add-src-to-address-list address-list=rdp_blacklist \n    address-list-timeout=15m chain=forward comment=rdp_to_blacklist \n    connection-state=new dst-port=3389 protocol=tcp src-address-list=\n    rdp_stage12\nadd action=add-src-to-address-list address-list=rdp_stage12 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage11\nadd action=add-src-to-address-list address-list=rdp_stage11 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage10\nadd action=add-src-to-address-list address-list=rdp_stage10 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage9\nadd action=add-src-to-address-list address-list=rdp_stage9 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage8\nadd action=add-src-to-address-list address-list=rdp_stage8 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage4\nadd action=add-src-to-address-list address-list=rdp_stage7 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage6\nadd action=add-src-to-address-list address-list=rdp_stage6 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage5\nadd action=add-src-to-address-list address-list=rdp_stage5 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=\n    3389 protocol=tcp src-address-list=rdp_stage4\nadd action=add-src-to-address-list address-list=rdp_stage4 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=\n    3389 protocol=tcp src-address-list=rdp_stage3\nadd action=add-src-to-address-list address-list=rdp_stage3 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage2\nadd action=add-src-to-address-list address-list=rdp_stage2 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp src-address-list=rdp_stage1\nadd action=add-src-to-address-list address-list=rdp_stage1 \n    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 \n    protocol=tcp \n\/ip firewall raw\nadd action=drop chain=prerouting in-interface=ether4-wan src-address-list=\nrdp_blacklist\n<\/code><\/pre>\n
\nOver a span of 4 minutes, a remote client is allowed to make only 12 new 'requests' to the RDP server<\/a>. 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. <\/p>\n
                        Another little trick<\/b>
\n                         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.<\/p>\n
\/ip firewall filter \nadd action=add-src-to-address-list address-list=rdp_blacklist \n    address-list-timeout=1w0d0h0m chain=forward comment=\n    "night_rdp_blacklist" connection-state=new disabled=\n    yes dst-port=3389 protocol=tcp src-address-list=rdp_stage8<\/code><\/pre>\n
\nAlready on the 8th connection attempt, the attacker's IP is blacklisted for a week. How nice!<\/p>\n
Additionally, I\u2019ll include a link to a Wiki article with a working setup to protect Mikrotik from network scanners. wiki.mikrotik.com\/wiki\/Drop_port_scanners<\/a><\/noindex><\/p>\n
On my devices, this setting works together with the aforementioned honeypot rules, complementing them quite well.<\/p>\n
UPD: As suggested in the comments, the packet drop rule has been moved to RAW to reduce the load on the router.
\n
Source: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0425\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0441 \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e\u043c \u043f\u0440\u043e\u0441\u0442\u044b\u043c \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u043c \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u043c, \u043a\u0430\u043a \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 Mikrotik \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u0441\u0432\u043e\u044e \u0441\u0435\u0442\u044c \u0438 \u00ab\u0432\u044b\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u044e\u0449\u0438\u0435\u00bb \u0438\u0437-\u0437\u0430 \u043d\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u043e\u0442 \u0432\u043d\u0435\u0448\u043d\u0438\u0445 \u0430\u0442\u0430\u043a. \u0410 \u0438\u043c\u0435\u043d\u043d\u043e \u0432\u0441\u0435\u0433\u043e \u0442\u0440\u0435\u043c\u044f \u043f\u0440\u0430\u0432\u0438\u043b\u0430\u043c\u0438 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u041c\u0438\u043a\u0440\u043e\u0442\u0438\u043a\u0435 honeypot. \u0418\u0442\u0430\u043a, \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043c, \u0447\u0442\u043e \u0443 \u043d\u0430\u0441 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043e\u0444\u0438\u0441, \u0432\u043d\u0435\u0448\u043d\u0438\u0439 IP \u0437\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0441\u0442\u043e\u0438\u0442 RDP \u0441\u0435\u0440\u0432\u0435\u0440, \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u043e\u0432 \u043f\u043e \u0443\u0434\u0430\u043b\u0435\u043d\u043a\u0435. \u041f\u0435\u0440\u0432\u043e\u0435 \u043f\u0440\u0430\u0432\u0438\u043b\u043e \u044d\u0442\u043e \u043a\u043e\u043d\u0435\u0447\u043d\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-79489","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47An Easy Way to Protect Your Mikrotik from Attacks | ProHoster","description":"I want to share with the community a simple and effective way to use Mikrotik to protect your network and the services 'peeking' from it from external attacks.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/legkij-sposob-zashhitit-svoj-mikrotik-ot-atak","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041b\u0435\u0433\u043a\u0438\u0439 \u0441\u043f\u043e\u0441\u043e\u0431 \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u0441\u0432\u043e\u0439 Mikrotik \u043e\u0442 \u0430\u0442\u0430\u043a | ProHoster","og:description":"\u0425\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0441 \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e\u043c \u043f\u0440\u043e\u0441\u0442\u044b\u043c \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u043c \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u043c, \u043a\u0430\u043a \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 Mikrotik \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u0441\u0432\u043e\u044e \u0441\u0435\u0442\u044c \u0438 \u00ab\u0432\u044b\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u044e\u0449\u0438\u0435\u00bb \u0438\u0437-\u0437\u0430 \u043d\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u043e\u0442 \u0432\u043d\u0435\u0448\u043d\u0438\u0445 \u0430\u0442\u0430\u043a.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/legkij-sposob-zashhitit-svoj-mikrotik-ot-atak","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-27T17:41:58+00:00","article:modified_time":"2020-04-27T17:41:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"79489","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:37:23","updated":"2026-02-09 21:41:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/79489","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=79489"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/79489\/revisions"}],"predecessor-version":[{"id":160157,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/79489\/revisions\/160157"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=79489"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=79489"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=79489"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}