Je souhaite partager avec la communauté une manière simple et efficace d'utiliser Mikrotik pour protéger votre réseau et les services qui « apparaissent » derrière lui contre les attaques externes. A savoir, seulement trois règles pour organiser un pot de miel sur Mikrotik.
Imaginons donc que nous ayons un petit bureau, avec une IP externe derrière laquelle se trouve un serveur RDP permettant aux employés de travailler à distance. La première règle est bien entendu de changer le port 3389 de l’interface externe par un autre. Mais cela ne durera pas longtemps : après quelques jours, le journal d'audit du serveur de terminaux commencera à montrer plusieurs échecs d'autorisation par seconde provenant de clients inconnus.
Autre situation, vous avez un astérisque caché derrière Mikrotik, bien sûr pas sur le port udp 5060, et après quelques jours la recherche du mot de passe commence également... oui, oui, je sais, fail2ban est notre tout, mais nous devons quand même travailler dessus... par exemple, je l'ai récemment installé sur Ubuntu 18.04 et j'ai été surpris de découvrir que fail2ban prêt à l'emploi ne contient pas les paramètres actuels pour l'astérisque de la même boîte de la même distribution Ubuntu... et googler les paramètres rapides les « recettes » toutes faites ne fonctionnent plus, le nombre de sorties augmente au fil des années, et les articles avec « recettes » pour les anciennes versions ne fonctionnent plus, et les nouvelles n'apparaissent presque jamais... Mais je m'éloigne du sujet...
Alors, qu'est-ce qu'un pot de miel en un mot - c'est un pot de miel, dans notre cas, n'importe quel port populaire sur une IP externe, toute demande sur ce port provenant d'un client externe envoie l'adresse src à la liste noire. Tous.
/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"
La première règle sur les ports TCP populaires 22, 3389, 8291 de l'interface externe ether4-wan envoie l'adresse IP « invité » à la liste « Honeypot Hacker » (les ports pour ssh, rdp et winbox sont désactivés à l'avance ou remplacés par d'autres). Le second fait la même chose sur le populaire UDP 5060.
La troisième règle au stade du pré-routage supprime les paquets des « invités » dont l'adresse SRS est incluse dans le « Honeypot Hacker ».
Après deux semaines de travail avec mon Mikrotik maison, la liste « Honeypot Hacker » comprenait environ un millier et demi d'adresses IP de ceux qui aiment « tenir par la mamelle » mes ressources réseau (à la maison, il y a ma propre téléphonie, mon courrier, nextcloud, rdp). Les attaques par force brute se sont arrêtées, le bonheur est venu.
Au travail, tout ne s'est pas avéré si simple, là-bas, ils continuent de casser le serveur RDP en forçant brutalement les mots de passe.
Apparemment, le numéro de port a été déterminé par le scanner bien avant l'activation du pot de miel, et pendant la quarantaine, il n'est pas si facile de reconfigurer plus de 100 utilisateurs, dont 20 % ont plus de 65 ans. Dans le cas où le port ne peut pas être modifié, il existe une petite recette de travail. J'ai vu quelque chose de similaire sur Internet, mais il y a quelques ajouts et ajustements supplémentaires impliqués :
Règles de configuration de 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
En 4 minutes, le client distant n'est autorisé à effectuer que 12 nouvelles « requêtes » au serveur RDP. Une tentative de connexion correspond à 1 à 4 « requêtes ». A la 12ème "demande" - blocage pendant 15 minutes. Dans mon cas, les attaquants n'ont pas arrêté de pirater le serveur, ils se sont adaptés aux minuteries et le font maintenant très lentement, une telle vitesse de sélection réduit l'efficacité de l'attaque à zéro. Les salariés de l'entreprise ne subissent pratiquement aucun inconvénient au travail suite aux mesures prises.
Encore une petite astuce
Cette règle s'active selon un horaire à 5 heure du matin et s'éteint à XNUMX heures du matin, lorsque de vraies personnes sont définitivement endormies et que les sélecteurs automatisés continuent d'être éveillés.
/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_stage8Dès la 8ème connexion, l’adresse IP de l’attaquant est blacklistée pendant une semaine. Beauté!
Eh bien, en plus de ce qui précède, j'ajouterai un lien vers un article Wiki avec une configuration fonctionnelle pour protéger Mikrotik des scanners réseau.
Sur mes appareils, ce paramètre fonctionne avec les règles du pot de miel décrites ci-dessus, les complétant bien.
UPD : Comme suggéré dans les commentaires, la règle de suppression de paquets a été déplacée vers RAW pour réduire la charge sur le routeur.
Source: habr.com