🥇Ein einfacher Weg, um Ihr MikroTik vor Angriffen zu schützen

Ich möchte der Community eine einfache und funktionierende Methode vorstellen, wie man mit Mikrotik sein Netzwerk und die „herausblickenden“ Dienste davor vor externen Angriffen schützen kann. Mit nur drei Regeln kann man auf dem Mikrotik einen Honeypot einrichten.

Angenommen, wir haben ein kleines Büro, hinter dem eine RDP-Server steht, der für die Remote-Arbeit der Mitarbeiter genutzt wird. Die erste Regel ist natürlich, den Port 3389 auf der externen Schnittstelle auf einen anderen zu ändern. Doch das hält nicht lange an – nach ein paar Tagen wird das Audit-Protokoll des Terminalservers zeigen, dass es mehrere fehlgeschlagene Authentifizierungsversuche pro Sekunde von unbekannten Kunden gibt.

Eine andere Situation ist, wenn hinter Ihrem Mikrotik ein Asterisk versteckt ist, natürlich nicht am UDP-Port 5060, und nach ein paar Tagen beginnt auch hier das Durchprobieren von Passwörtern… ja, ich weiß, fail2ban ist unsere Rettung, aber da muss man noch ein bisschen daran arbeiten… Ich habe kürzlich einen auf Ubuntu 18.04 installiert und war überrascht zu entdecken, dass fail2ban standardmäßig keine aktuellen Einstellungen für Asterisk aus derselben Ubuntu-Version enthält… und schnelles Googeln nach „Rezepten“ für die Konfiguration funktioniert nicht mehr, die Versionsnummern steigen mit den Jahren, und die Artikel mit „Rezepten“ für alte Versionen funktionieren nicht mehr, während neue rar gesät sind… Aber ich schweife ab...

Was ist also ein Honeypot in zwei Worten? Es ist eine Falle, in unserem Fall irgendein beliebter Port auf der externen IP-Adresse. Jede Anfrage an diesen Port von einem externen Client führt dazu, dass die Quelladresse auf die schwarze Liste gesetzt wird. Das war's.

/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 und 8291 der externen Schnittstelle ether4-wan setzt die IP-Adresse des „Gästen“ auf die Liste „Honeypot Hacker“ (Ports für SSH, RDP und Winbox sind im Voraus deaktiviert oder auf andere geändert). Die zweite Regel macht das Gleiche für den beliebten UDP-Port 5060.

Die dritte Regel verwirft in der Vorrouting-Phase die Pakete von „Gästen“, deren Quelladresse auf die Liste „Honeypot Hacker“ gesetzt wurde.

Nach zweiwöchiger Nutzung meines Heim-Mikrotiks umfasst die Liste „Honeypot Hacker“ etwa 1500 IP-Adressen von Personen, die meine Netzwerkressourcen „auskundschaften“ möchten (zu Hause nutze ich meine eigene Telefonie, E-Mail, Nextcloud, RDP). Die Brute-Force-Angriffe haben aufgehört, es herrscht jetzt Wohlstand.

Bei der Arbeit ist es jedoch nicht so einfach, dort wird der RDP-Server weiterhin durch Passwortversuche angegriffen.

Offensichtlich wurde die Portnummer von einem Scanner lange vor dem Einschalten des Honeypots bestimmt, und während der Quarantäne ist es nicht einfach, über 100 Benutzer umzuprogrammieren, von denen 20 % über 65 Jahre alt sind. Wenn der Port nicht geändert werden kann, gibt es ein kleines funktionierendes Rezept. Ähnliches habe ich im Internet gesehen, aber hier gibt es zusätzliche Anpassungen und Feinabstimmungen:

Regeln zur 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 entfernte Client nur 12 neue „Anfragen“ an RDP stellen. zu einem Server. Ein Anmeldeversuch entspricht 1 bis 4 „Anfragen“. Bei der 12. „Anfrage“ erfolgt eine Sperre für 15 Minuten. In meinem Fall haben die Angreifer mit dem Hacken des Servers nicht aufgehört, sondern sich an die Timer angepasst und tun dies jetzt sehr langsam; diese Geschwindigkeit reduziert die Effektivität des Angriffs auf null. Die Mitarbeiter des Unternehmens haben durch die getroffenen Maßnahmen kaum Unannehmlichkeiten in der Arbeit.

Noch ein kleiner Trick
Diese Regel wird planmäßig um 1 Uhr nachts aktiviert und um 5 Uhr ausgeschaltet, wenn die Menschen sicher schlafen und die automatisierten Scanner 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-Adresse des Angreifers für eine Woche auf die schwarze Liste gesetzt. Schön!

Außerdem füge ich einen Link zu einem Wiki-Artikel hinzu, der eine funktionierende Konfiguration zum Schutz von MikroTik gegen Netzcanner beschreibt. wiki.mikrotik.com/wiki/Drop_port_scanners

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

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

Quelle: habr.com

Ein einfacher Weg, um Ihren Mikrotik vor Angriffen zu schützen