Eine einfache Möglichkeit, Ihre Mikrotik vor Angriffen zu schützen

Ich möchte der Community auf einfache und funktionierende Weise mitteilen, wie Mikrotik verwendet wird, um mein Netzwerk und die Dienste, die aufgrund dessen vor externen Angriffen „Ausschau halten“, zu schützen. Organisieren Sie mit nur drei Regeln einen Honigtopf auf Mikrotik.

Stellen wir uns also vor, wir haben ein kleines Büro, eine externe IP, hinter der sich ein RDP-Server befindet, damit die Mitarbeiter remote arbeiten können. Die erste Regel ist natürlich, Port 3389 auf der externen Schnittstelle auf einen anderen zu ändern. Dies dauert jedoch nicht lange. Nach einigen Tagen werden im Überwachungsprotokoll des Terminalservers mehrere erfolglose Berechtigungen pro Sekunde von unbekannten Clients angezeigt.

Eine andere Situation, Sie haben ein Sternchen hinter Mikrotik versteckt, natürlich nicht auf dem 5060 udp-Port, und nach ein paar Tagen beginnt auch das Erraten von Passwörtern ... ja ja, ich weiß, fail2ban ist unsere ganze Sache, aber ich muss immer noch darüber pusten ... zum Beispiel habe ich es kürzlich auf Ubuntu gehoben Am 18. April stellte ich überrascht fest, dass fail2ban standardmäßig nicht die tatsächlichen Einstellungen für Sternchen aus derselben Box derselben Ubuntu-Distribution enthält. Google kann jedoch keine schnellen Einstellungen für vorgefertigte "Rezepte" googeln, die Anzahl der Veröffentlichungen wächst im Laufe der Jahre und Artikel mit " Rezepte “für die alten Versionen funktionieren nicht mehr, aber fast keine neuen ... Aber etwas, das ich abschweife ...

Also, was ist Honeypot auf den Punkt gebracht - ist ein Köder, in unserem Fall ein beliebter Port auf einer externen IP, jede Anfrage an diesen Port von einem externen Client sendet die src-Adresse an die schwarze Liste. Alle.

/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"

Die erste Regel für die beliebten TCP-Ports 22, 3389, 8291 der externen ether4-wan-Schnittstelle sendet die Gast-IP an die Honeypot-Hacker-Liste (Ports für ssh, rdp und winbox werden im Voraus deaktiviert oder in andere geändert). Der zweite macht dasselbe mit dem beliebten UDP 5060.

Die dritte Regel in der Phase vor dem Routing verwirft Pakete der "Gäste", deren srs-Adresse in den "Honeypot Hacker" gelangt ist.

Nach zweiwöchiger Arbeit bei mir zu Hause in Mikrotik enthielt die Honeypot-Hacker-Liste ungefähr eineinhalbtausend IP-Adressen von euterfreundlichen Fans meiner Netzwerkressourcen (Heimtelefonie, Mail, nextcloud, rdp). Brute-Force-Angriffe wurden gestoppt, Glückseligkeit folgte.

Bei der Arbeit stellte sich nicht alles als so einfach heraus, dass der RDP-Server weiterhin mit Brute-Force-Passwörtern beschädigt wird.

Anscheinend wurde die Portnummer lange vor dem Einschalten des Honeypots vom Scanner ermittelt, und während der Quarantäne ist es nicht so einfach, mehr als 100 Benutzer neu zu konfigurieren, von denen 20% über 65 Jahre alt sind. Für den Fall, dass der Port nicht geändert werden kann, gibt es ein kleines Arbeitsrezept. Ich habe mich im Internet ähnlich getroffen, aber es gibt eine fertige und Feinabstimmung:

Regeln zum Konfigurieren von 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

Innerhalb von 4 Minuten darf der Remote-Client nur 12 neue "Anforderungen" an den RDP-Server senden. Ein Anmeldeversuch besteht aus 1 bis 4 "Anfragen". Bei der 12. "Anfrage" - eine Sperre für 15 Minuten. In meinem Fall haben die Angreifer nicht aufgehört, den Server zu hacken, sie haben sich an die Timer angepasst und jetzt tun sie dies sehr langsam. Eine solche Auswahlgeschwindigkeit reduziert die Angriffseffizienz auf Null. Die Mitarbeiter des Unternehmens haben praktisch keine Unannehmlichkeiten bei der geleisteten Arbeit.

Noch ein kleiner 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 . !

Zusätzlich zu den oben genannten Informationen werde ich einen Link zum Wiki-Artikel hinzufügen, der die Arbeitseinstellung zum Schutz von Mikrotik vor Netzwerkscannern enthält. wiki.mikrotik.com/wiki/Drop_port_scanners

Auf meinen Geräten funktioniert diese Einstellung mit den oben beschriebenen Honeypot-Regeln und ergänzt sie gut.

UPD: Wie in den Kommentaren vorgeschlagen, wurde die Paketverwertungsregel in RAW verschoben, um die Belastung des Routers zu verringern.

All Articles