Wie so oft, gibt es recht unterschiedliche Möglichkeiten, den Zugriff auf ein RouterOS basiertes System ab zu sichern. Der folgende Artikel zeigt Ihnen, wie Sie - je nach Anforderung - vorgehen können.

Die einfachste Variante ein RouterOS basiertes System ab zu sichern ist sicherlich unter ip services nur die Dienste zu aktivieren, die wirklich benötigt werden und einen IP-Bereich anzugeben, von dem aus der Zugriff auf dieses System erlaubt sein soll. Dieses Vorgehen reicht z. B. aus, wenn ein RouterOS basiertes System als einfaches Internet-Gateway verwendet werden soll und kein Zugriff aus dem Internet auf dieses benötigt wird. Da aber hier nur ein Bereich von erlaubten Absender-IPs hinterlegt werden kann, ist dieses Verfahren bei größeren Installationen i.d.R. nicht anwendbar oder würde zu große Angriffsmöglichkeiten geben.

Per Default sind bis auf Zugriffe per HTTPS und API alle Zugriffsmöglichkeiten von überall aus erlaubt.

  [admin@MikroTik] > ip service print 
  Flags: X - disabled, I - invalid 
   #   NAME                  PORT  ADDRESS            CERTIFICATE                
   0   telnet                23    0.0.0.0/0         
   1   ftp                   21    0.0.0.0/0         
   2   www                   80    0.0.0.0/0         
   3   ssh                   22    0.0.0.0/0         
   4 X www-ssl               443   0.0.0.0/0          none                       
   5 X api                   8728  0.0.0.0/0         
   6   winbox                8291  0.0.0.0/0         

Eine einfache Absicherung wäre nun zunächst dee nicht wirklich benötigten Dienst Telnet zu deaktivieren und alle anderen ausschließlich vom internen Netz heraus verfügbar zu machen:

/ip service set 0 disabled=yes
/ip service set 1,2,3,6 address=192.168.210.0/24

ergibt dann die folgenden Einstellungen:

[admin@MikroTik] > ip service print 
Flags: X - disabled, I - invalid 
 #   NAME                  PORT  ADDRESS            CERTIFICATE                
 0 X telnet                23    0.0.0.0/0         
 1   ftp                   21    192.168.210.0/24  
 2   www                   80    192.168.210.0/24  
 3   ssh                   22    192.168.210.0/24  
 4 X www-ssl               443   0.0.0.0/0          none                       
 5 X api                   8728  0.0.0.0/0         
 6   winbox                8291  192.168.210.0/24  

Somit ist ein Zugriff per Telnet, SSL und API gar nicht mehr und ein Zugriff per FTP, HTTP, SSH und WinBox ausschließlich aus dem Netzwerk 192.168.210.0/24 möglich.

Es gibt viele Gründe, warum der oben gezeigte Weg nicht ausreichend ist. Anbei finden Sie diverse Vorschläge, wie per intelligenten Firewall-Regeln der Zugang zu einem RouterOS basiertem System sehr flexibel gehandelt werden kann. Hierbei verwenden wir unterschiedliche Vorgehensweisen.

Eine Art von Filtern verwendet hierfür dynamische Einträge in der Address-List, so kann eine beliebige Anzahl von falschen Anmeldeversuchen erlaubt werden, bevor die IP-Adresse des Angreifers in eine ebenso dynamische Black-List eingetragen wird und somit jeder weitere Versuch von dieser IP dann geblockt wird.

Eine weitere Art von Filtern überwacht bestimmte Systemausgaben (Applikationsmeldungen) in Abhängigkeit von Häufigkeit und Ziel-Adresse an die diese geschickt wird und trägt bei der Überschreitung von voreingestellten Schwellwerten ebenso die IP-Adresse des Angreifers in eine dynamische Black-List ein und ab diesem Zeitpunkt wird die Absende-IP des Angreifers geblockt.

Diese Art von Filtern eignen sich besonders für TCP-basierte Dienste wie z. B. SSH, Telnet und WinBox. Eigentlich ist der Zugriff erlaubt, kommen aber in gewissen, kurz gewählten Zeitabständen vom selben Absender mehrere Verbindungsversuche, so gehen wir von einer Brute-Force Attake auf das System aus. Jeder neue Verbindungsversuch von der selben Absender-IP zählt hierbei einen Step weiter, bis am Ende die Black-List erreicht wird und diese Absende-IP nun für diesen Dienst dynamisch für einen voreingestellten Zeitraum geblockt wird. Bei dieser Art von Regeln ist die Reihenfolge der Regeln (wie eigentlich immer) sehr wichtig!

Beispiel:
Diese Regeln müssen genau in dieser Reihenfolge auf dem System vorhanden sein, lesen sollten Sie diese allerdings von unten nach oben, in dieser Reihenfolge greifen sie nämlich auch, wenn ein Angreifer mehrfach hintereinander versucht z. B. per SSH mit falschen Login-Daten in das System einzubrechen (Brute-Force).

Bei dem fünften SSH-Verbindungsversuch innerhalb von einem Tag (nach dem vierten) einer Absender-IP die schon in der Liste ssh_blacklist vorhanden ist wird diese nun sofort gedropt:

add action=drop chain=input comment="DROP input SSH brute force" disabled=no \
    dst-port=22 protocol=tcp src-address-list=ssh_blacklist

Bei einem vierten SSH-Verbindungsversuch innerhalb von 5 Minuten (nach dem dritten) einer Absender-IP die schon in der Liste ssh_step_3 vorhanden ist wird diese nun auch in die Liste ssh_blacklist geschrieben:

add action=add-src-to-address-list address-list=ssh_blacklist \
    address-list-timeout=1d chain=input comment=\
    "ADR-LIST SSH step_3 -> ssh_blacklist" connection-state=new disabled=no \
    dst-port=22 protocol=tcp src-address-list=ssh_step_3

Bei einem dritten SSH-Verbindungsversuch innerhalb von 5 Minuten (nach dem zweiten) einer Absender-IP die schon in der Liste ssh_step_2 vorhanden ist wird diese nun auch in die Liste ssh_step_3 geschrieben:

add action=add-src-to-address-list address-list=ssh_step_3 \
    address-list-timeout=5m chain=input comment=\
    "ADR-LIST SSH step_2 -> step_3" connection-state=new disabled=no \
    dst-port=22 protocol=tcp src-address-list=ssh_step_2

Bei einem zweiten SSH-Verbindungsversuch innerhalb von 5 Minuten (nach dem ersten) einer Absender-IP die schon in der Liste ssh_step_1 vorhanden ist wird diese nun auch in die Liste ssh_step_2 geschrieben:

add action=add-src-to-address-list address-list=ssh_step_2 \
    address-list-timeout=5m chain=input comment=\
    "ADR-LIST SSH step_1 -> step_2" connection-state=new disabled=no \
    dst-port=22 protocol=tcp src-address-list=ssh_step_1

Beim ersten SSH-Verbindungsversuch von einer beliebigen IP-Adresse greift diese Regel und fügt die Absender-IP in die Adsress-List ssh_step_1 ein:

add action=add-src-to-address-list address-list=ssh_step_1 \
    address-list-timeout=5m chain=input comment=\
    "ADR-LIST SSH first attempt -> step_1" connection-state=new disabled=no \
    dst-port=22 protocol=tcp 

Diese Regel erlaubt letztendlich SSH zum Router für jede Absende-IP, die nicht weiter oben geblockt wurde:

add action=accept chain=input comment="ALLOW input SSH TO Router itself" \
    connection-state=new disabled=no dst-port=22 protocol=tcp    

Sie können natürlich die Anzahl der möglichen Falsch-Versuche (steps) beliebig varieren bevor die Drop-Regel greifen soll. Gleiches gilt für die Haltezeiten der dynamischen Address-Lists. Durch Ändern der Ports können diese Regeln schnell und einfach für andere Dienste wie z. B. Telnet und WinBox, aber auch für ganz andere Services angepasst werden.

Diese Regeln eignen sich vor allem immer dann, wenn Applikationen einen leicht erkennbaren String zurück geben, wenn Benutzername/Password falsch sind. Dies ist z. B. bei HTTP und FTP der Fall. Auch hier ist der Zugriff eigentlich wieder erlaubt. Wenn aber in einem gewissen Zeitabstand zu oft diese Fehlermeldung an immer das gleiche Ziel geschickt wird, dann wird die Absender-IP ebenfall in eine Blacklist geschrieben und bei weiteren Versuchen gedropt.

Beispiel:

Erlaube den String 530 Login incorrect vom System an eine bestimmte Ziel-Adresse 1 mal pro Minute mit einem Burst von max. 5 mal

add action=accept chain=output comment="LIMIT output FTP 530 Login incorrect" \
    content="530 Login incorrect" disabled=no dst-limit=1/1m,5,dst-address/1m \
    protocol=tcp

Kommt nun nach dem Überschreiten der obigen Zähler ein weiterer Verbindungsversuch vom selben Angreifer wird diese IP-Adresse in die ftp_blacklist geschrieben:

add action=add-dst-to-address-list address-list=ftp_blacklist \
    address-list-timeout=1d chain=output comment=\
    "ADR-LIST FTP 530 Login incorrect -> ftp_blacklist" content=\
    "530 Login incorrect" disabled=no protocol=tcp  

Drop alle eingehende FTP-Verbindungsversuche, wenn die Absender-IP in der ftp_blacklist gespeichert ist:

add action=drop chain=input comment="DROP input FTP brute force" disabled=no \
    dst-port=21 protocol=tcp src-address-list=ftp_blacklist

Erlaube jeden anderen FTP-Verbindungsversuch:

add action=accept chain=input comment="ALLOW input FTP TO Router itself" \
    connection-state=new disabled=no dst-port=21 protocol=tcp

Anmerkung:
Um selbigen Filter für HTTP verwenden zu können wird content=„invalid user name or password“ benötigt.