Je souhaite partager avec la communauté une méthode simple et efficace pour protéger votre réseau et les services exposés à l'extérieur contre les attaques, en utilisant Mikrotik. En trois règles, vous pouvez organiser un honeypot sur Mikrotik.
Imaginons que nous avons un petit bureau, avec un IP externe derrière lequel se trouve un serveur RDP pour le travail des employés à distance. La première règle est évidemment de changer le port 3389 sur l'interface externe pour un autre. Mais cela n'est que temporaire, après quelques jours, le journal d'audit du serveur de terminal commencera à montrer plusieurs échecs d'authentification par seconde venant de clients inconnus.
Dans une autre situation, si vous avez un asterisk caché derrière Mikrotik, bien sûr pas sur le port UDP 5060, et après quelques jours, cela commence également à provoquer des tentatives de mot de passe… oui, je sais, fail2ban est notre solution, mais il faudra encore travailler un peu dessus… Personnellement, j'ai récemment installé fail2ban sur Ubuntu 18.04 et j'ai été surpris de découvrir qu'il ne contient pas par défaut des configurations actuelles pour asterisk de la même version d'Ubuntu… et il est difficile de trouver des réglages rapides et des 'recettes', les numéros de versions augmentent avec les années, mais les articles sur les 'recettes' pour les anciennes versions ne fonctionnent plus, et il y a peu de nouveaux… Mais je m'égare.
Alors, qu'est-ce qu'un honeypot en deux mots - c'est un appât, dans notre cas, un port populaire sur une IP externe, toute requête sur ce port provenant d'un client externe envoie l'adresse source dans une liste noire. Voilà.
/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'IP du 'client' dans la liste 'Honeypot Hacker' (les ports pour ssh, rdp et winbox étant préalablement désactivés ou changés). La deuxième fait la même chose pour le populaire UDP 5060.
La troisième règle, au stade du pré-routage, bloque les paquets des 'clients' dont l'adresse source a été ajoutée à la liste 'Honeypot Hacker'.
Après deux semaines de fonctionnement de mon Mikrotik domestique, la liste 'Honeypot Hacker' comptait environ une quinzaine de centaines d'adresses IP de ceux qui ont essayé de 'tirer sur la tétine' de mes ressources réseau (j'ai ma propre téléphonie, mail, nextcloud, rdp). Les attaques par force brute ont cessé, c'est le bonheur.
Au travail, ce n'est pas si simple, là, le serveur rdp continue d'être attaqué par des tentatives de mot de passe.
Il semble que le numéro de port ait été déterminé par le scanner bien avant que le honeypot ne soit activé, et pendant le confinement, il n'est pas si facile de reconfigurer plus de 100 utilisateurs, dont 20 % ont plus de 65 ans. Dans les cas où il est impossible de changer le port, il existe une petite recette fonctionnelle. J'ai rencontré cela sur Internet, mais ici il y a des améliorations et un réglage fin :
Règles pour configurer le 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, un client distant n'est autorisé à faire que 12 nouvelles « demandes » au RDP serveur. Une tentative de connexion équivaut à 1 à 4 « demandes ». À la 12ème « demande » – blocage pendant 15 minutes. Dans mon cas, les malfaiteurs ont continué à pirater le serveur, s'adaptant aux minuteurs et le faisant maintenant très lentement, cette vitesse de tentative réduit l'efficacité de l'attaque à néant. Les employés de l'entreprise n'éprouvent pratiquement aucun inconvénient au travail en raison des mesures prises.
Encore une petite astuce
Cette règle est activée par un horaire à une heure du matin et se désactive à 5 heures, quand les gens dorment sûrement et que les bots de tentative de connexion 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'agresseur est mise sur liste noire pour une semaine. Magnifique !
Et pour faire écho à ce qui a été dit, je vais ajouter un lien vers l'article Wiki, avec une configuration fonctionnelle pour protéger le Mikrotik contre les scanners de réseau.
Sur mes appareils, ce réglage fonctionne en conjonction avec les règles de honeypot décrites ci-dessus, les complétant bien.
UPD : Comme suggéré dans les commentaires, la règle de suppression des paquets a été déplacée dans RAW, afin de réduire la charge sur le routeur.
Source : habr.com
