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

Ich möchte der Community eine einfache und funktionierende Möglichkeit vorstellen, wie Sie Mikrotik verwenden können, um Ihr Netzwerk und die Dienste, die dahinter „hervorschauen“, vor Angriffen von außen zu schützen. Nämlich nur drei Regeln, um einen Honeypot auf Mikrotik zu organisieren.

Stellen wir uns also vor, wir hätten ein kleines Büro mit einer externen IP, hinter der sich ein RDP-Server befindet, über den Mitarbeiter aus der Ferne arbeiten können. Die erste Regel besteht natürlich darin, den Port 3389 der externen Schnittstelle auf einen anderen zu ändern. Dies wird jedoch nicht lange anhalten; nach ein paar Tagen werden im Prüfprotokoll des Terminalservers mehrere fehlgeschlagene Autorisierungen pro Sekunde von unbekannten Clients angezeigt.

Eine andere Situation, Sie haben Asterisk hinter Mikrotik versteckt, natürlich nicht auf dem 5060-UDP-Port, und nach ein paar Tagen beginnt auch die Passwortsuche ... ja, ja, ich weiß, fail2ban ist unser Alles, aber wir müssen es trotzdem tun daran arbeiten ... zum Beispiel habe ich es kürzlich auf Ubuntu 18.04 installiert und war überrascht, dass fail2ban standardmäßig keine aktuellen Einstellungen für Asterisk aus derselben Box derselben Ubuntu-Distribution enthält ... und schnelle Einstellungen gegoogelt Denn vorgefertigte „Rezepte“ funktionieren nicht mehr, die Zahlen der Veröffentlichungen steigen mit den Jahren, und Artikel mit „Rezepten“ für alte Versionen funktionieren nicht mehr und neue erscheinen fast nie... Aber ich schweife ab...

Kurz gesagt, was ist ein Honeypot? Es ist ein Honeypot, in unserem Fall jeder beliebte Port auf einer externen IP. Jede Anfrage an diesen Port von einem externen Client sendet die Quelladresse an die Blacklist. 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 Schnittstelle ether4-wan sendet die „Gast“-IP an die „Honeypot Hacker“-Liste (Ports für SSH, RDP und Winbox werden im Voraus deaktiviert oder auf andere geändert). Der zweite macht dasselbe auf dem beliebten UDP 5060.

Die dritte Regel in der Pre-Routing-Phase verwirft Pakete von „Gästen“, deren SRS-Adresse im „Honeypot Hacker“ enthalten ist.

Nachdem ich zwei Wochen lang mit Mikrotik zu Hause gearbeitet hatte, umfasste die „Honeypot Hacker“-Liste etwa eineinhalbtausend IP-Adressen derjenigen, die meine Netzwerkressourcen gerne „am Euter festhalten“ (zu Hause gibt es meine eigene Telefonie, E-Mail, nextcloud, rdp). Brute-Force-Angriffe hörten auf, Glückseligkeit kam.

Bei der Arbeit war nicht alles so einfach, dort wird der RDP-Server weiterhin durch Brute-Force-Passwörter beschädigt.

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 etwas Ähnliches im Internet gesehen, aber es sind noch einige zusätzliche Ergänzungen und Feinabstimmungen erforderlich:

Regeln für die Konfiguration 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=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

In 4 Minuten darf der Remote-Client nur 12 neue „Anfragen“ an den RDP-Server stellen. Ein Anmeldeversuch umfasst 1 bis 4 „Anfragen“. Bei der 12. „Anfrage“ - Sperrung 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 machen es jetzt sehr langsam, eine solche Auswahlgeschwindigkeit reduziert die Wirksamkeit des Angriffs auf Null. Den Mitarbeitern des Unternehmens entstehen durch die getroffenen Maßnahmen nahezu keine Unannehmlichkeiten am Arbeitsplatz.

Noch ein kleiner Trick
Diese Regel schaltet sich nach einem Zeitplan um 5 Uhr morgens ein und um XNUMX Uhr morgens wieder aus, wenn echte Menschen definitiv schlafen und automatische Pflücker weiterhin wach sind.

/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

Bereits bei der 8. Verbindung wird die IP des Angreifers für eine Woche auf die schwarze Liste gesetzt. Schönheit!

Zusätzlich zum oben Gesagten füge ich einen Link zu einem Wiki-Artikel mit einem funktionierenden Setup zum Schutz von Mikrotik vor Netzwerkscannern hinzu. wiki.mikrotik.com/wiki/Drop_port_scanners

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

UPD: Wie in den Kommentaren vorgeschlagen, wurde die Paket-Drop-Regel auf RAW verschoben, um die Belastung des Routers zu reduzieren.

Source: habr.com