Meine ersten Schritte mit MikroTik RouterOS (Teil 3)

Leser dieses Blogs wissen, dass ich ein bekennender Freund von OpenWRT bin. Doch ein Blick über den Tellerrand schadet ja nicht – und so habe ich mich die letzten Wochen auf Empfehlung zweier Freunde hin näher mit RouterOS von MikroTik befasst und eine Basiskonfiguration aufgesetzt, die ich in der folgenden Serie näher vorstellen möchte.

Teil 3 befasst sich mit der Deaktivierung nicht benötigter Dienste und dem Absichern des Systems.

Die Lektüre von Teil 1 und Teil 2 wird empfohlen, da die folgende Anleitung darauf aufbaut. Auch hier gilt das bereits Gesagte: RouterOS ist für mich noch Neuland, für konstruktives Feedback zu Ungenauigkeiten oder Fehlern im Artikel bin ich dankbar. ;-)

Die hier genannten Befehle sind mit RouterOS bis einschließlich Version 6.40.x getestet. Ab Version 6.41 ändert sich insbesondere die Konfiguration der Bridges, sodass die Kommandos ggf. angepasst werden müssen. Einen Überblick über die Neuerungen gebe ich in einem separaten Blogposting.

Dienste abschalten

RouterOS wird standardmäßig mit einer ganzen Reihe von aktivierten Diensten ausgeliefert, die für den späteren Betrieb nicht zwingend nötig sind. Nachdem wir im vorherigen Teil bereits SSL-Zertifikate erstellt haben, gibt es beispielsweise keinen vernünftigen Grund mehr, noch unverschlüsselte Zugriffe auf die Weboberfläche zu erlauben. Auch der FTP- oder API-Dienst werden oftmals nicht benötigt und sollten daher deaktiviert werden.

Zunächst deaktiviere ich alle Dienste außer WinBox – Letzteres bleibt aktiviert, um sich nicht selbst auszusperren, auch wenn zu diesem Zeitpunkt die Verbindung vermutlich ohnehin noch nicht über IP (Layer 3), sondern über MAC (Layer 2) zustande kommt:

/ip service disable [find name!=winbox]

Anschließend wird das in Teil 2 erstellte SSL-Zertifikat sowohl für die API als auch den Webserver hinterlegt:

/ip service set certificate="gateway1.local" www-ssl
/ip service set certificate="gateway1.local" api-ssl

Anschließend werden SSH und Webserver wieder aktiviert:

/ip service enable ssh
/ip service enable www-ssl

RouterOS hat standardmäßig auch einen so genannten Neighbour Discovery-Dienst (NDP) aktiv, mit dem weitere Geräte in der Umgebung gefunden werden. Diesen lasse ich zwar grundsätzlich aktiviert, schalte ihn allerdings für die Schnittstelle aus, die zum Internet geht:

/ip neighbor discovery set ether1 discover=no

Für Access Points und Switches muss obiger Befehl indes nicht ausgeführt werden, denn diese sind nur mit dem lokalen Netzwerk verbunden. Wer möchte, kann RouterOS auch anweisen, NDP auf neu erstellten, dynamischen Schnittstellen von Haus aus zu deaktivieren, was ich jedoch auf meinen Systemen nicht mache:

/ip neighbor discovery settings set default=no

Ebenfalls mit an Bord ist ein Bandbreitenmonitor, der als Dienst läuft, in vielen Umgebungen aber nicht benötigt wird. Er lässt sich einfach deaktivieren:

/tool bandwidth-server set enabled=no

Eingangs schon angesprochen wurde der Zugriff auf einige Dienste per Layer 2. Dafür stellt RouterOS sowohl einen Ping als auch einen Telnet-Zugriff sowie die grafische Oberfläche WinBox bereit. Ping und WinBox lasse ich auf meinen Systemen aktiviert, Telnet hingegen schalte ich aus, da diese Verbindung unverschlüsselt wäre.

Vor der Deaktivierung konfiguriere ich die Schnittstelle trotzdem auf das lokale Interface, damit im Fall einer nachträglichen Aktivierung des Dienstes nur lokale Systeme Zugriff erhalten:

/tool mac-server set [find] interface=INTERFACE

INTERFACE muss durch die jeweils genutzte Schnittstelle ersetzt werden. Für Switches ist dies ether1, für Router ether2 (da das erste Interface zum Internet geht) und für Access Points bridge1. Schlussendlich deaktiviere ich den Zugriff komplett:

/tool mac-server disable [find]

Absichern von Diensten

Im nächsten Schritt werden die verbleibenden Dienste abgesichert. Zwar lässt sich dies auch per Firewall regeln, es schadet aber trotzdem nicht, alles von vornherein abzuriegeln, zumal aktuell ja noch gar keine Firewall in Betrieb ist.

Grundsätzlich möchte ich keinen Konfigurationsdienst von außen nutzen, weswegen ich Zugriffe darauf ausschließlich von IP-Adressen im Bereich 192.168.x.y erlaube:

/ip service set address=192.168.0.0/16 [find]

Analog zu Telnet wird im nächsten Schritt der Zugriff auf WinBox per Layer 2 nur über eine bestimmte Schnittstelle erlaubt:

/tool mac-server mac-winbox add interface=INTERFACE
/tool mac-server mac-winbox disable [find default=yes]

INTERFACE muss wieder durch die jeweils genutzte Schnittstelle ersetzt werden. Für Switches ist dies ether1, für Router ether2 (da das erste Interface zum Internet geht) und für Access Points bridge1.

Zudem wird generell die Nutzung von Syncookies und Reverse Path Filtering für TCP-Pakete aktiviert:

/ip settings set tcp-syncookies=yes rp-filter=strict

RoMON

Seit kurzem bietet RouterOS einen Dienst namens RoMON an. Damit wird ein Gerät als Ausgangspunkt für die Konfigurationsverbindung zu anderen Systemen genutzt. So lassen sich beispielsweise über den Router von außen auch andere MikroTik-Komponenten wie Switches und Access Points konfigurieren, ohne eine Portweiterleitung einzurichten.

Standardmäßig ist dieser Dienst deaktiviert. Zunächst setze ich ein Secret, das allen Geräten bekannt sein muss:

/tool romon set secrets=supergeheimespasswort

Anstelle von supergeheimespasswort sollte unbedingt ein eigenes Kennwort gesetzt werden, idealerweise mit einer Kombination aus Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen.

Anschließend wird die Schnittstelle gesetzt, auf der RoMON arbeiten soll:

/tool romon port set [find] forbid=yes
/tool romon port add interface=INTERFACE disabled=no

INTERFACE muss erneut durch die jeweils genutzte Schnittstelle ersetzt werden. Für Switches ist dies ether1, für Router ether2 (da das erste Interface zum Internet geht) und für Access Points – anders als vorher, denn RoMON ist kabelgebunden – ebenfalls ether1.

Abschließend wird RoMON aktiviert:

/tool romon set enabled=yes

Ob der Schritt erfolgreich war, das verrät

 /tool romon print

in den Feldern enabled und secrets.

Firewall Service Ports

Danach nehmen wir uns noch die Einrichtung der Firewall Service Ports vor. RouterOS unterstützt verschiedene so genannte NAT-Helper, von denen standardmäßig mehrere aktiviert sind. Ich benötige in der Regel aber nur FTP, die anderen Dienste funktionieren bei mir problemlos auch ohne Helper.

Im Fall von SIP klappt es sogar gerade dann nicht, wenn der Helper aktiviert ist, aber SIP hinter NAT ist ja ohnehin ein Quell immerwährender Freude… ;-)

Zunächst deaktiviere ich sämtliche Helper mittels

/ip firewall service-port disable [find]

um dann in einem zweiten Schritt den FTP-Helper einzuschalten:

/ip firewall service-port enable ftp

Die Helper sind übrigens nur auf dem Router notwendig – am Switch und am Access Point lasse ich sie grundsätzlich deaktiviert, die letzte Zeile sollte daher auf diesen Geräten entfallen.

SSH-Zugriff

Da wir gerade in den Tiefen der Konfiguration sind, bietet sich auch ein erneuter Blick auf den SSH-Server an. Im vorherigen Teil haben wir diesen bereits so konfiguriert, dass er ausschließlich starke Kryptographie unterstützt – allerdings ist nach wie vor eine Anmeldung per Passwort möglich. Deutlich sicherer ist es, die Anmeldung ausschließlich per SSH-Schlüssel zu erlauben – Grundsätzliches dazu findet ihr in einem separaten Artikel.

RouterOS erlaubt diese Konfiguration pro Benutzer: Jeder Benutzer, der einen Schlüssel hinterlegt hat, darf sich fortan nur noch damit anmelden. Dieses Verhalten lässt sich über die Einstellung

/ip ssh set always-allow-password-login=yes

anpassen, wovon ich jedoch abrate.

Um nun einen Schlüssel mit einem Benutzernamen zu verbinden, wird der Public Key zunächst hochgeladen, beispielsweise per WinBox oder SSH. Anschließend genügt ein Befehl wie

/user ssh-keys import user=maxmuster public-key-file=maxmuster.pub

um den Schlüssel für den Benutzer zu hinterlegen. Für mehrere Schlüssel, beispielsweise vom Bürocomputer, dem Home-Office und dem Tablet, kann der Befehl einfach mehrfach mit verschiedenen Dateinamen aufgerufen werden.

Touchscreen absichern

Sicherheitsrelevant kann auch der eingebaute Touchschreen sein, sofern das Gerät über einen solchen verfügt, denn hierüber lassen sich verschiedene Konfigurationen zunächst ohne Authentifizierung vornehmen. Auf meinen Systemen setze ich daher zum einen eine PIN (für den Fall dass ich später die Konfiguration per Touchscreen zulasse) und deaktiviere im zweiten Schritt alle Konfigurationsmöglichkeiten. Das Display dient dann nur noch der Information, weswegen ich gleichzeitig die Anzeigedauer, das Farbschema und den Startbildschirm festlege:

/lcd pin set pin-number=1234 hide-pin-number=yes
/lcd set backlight-timeout=5m color-scheme=light default-screen=stats read-only-mode=yes

Statt 1234 sollte natürlich ein etwas sichererer Code gewählt werden. Je nach Einbaurichtung des Geräts kann der Bildschirm auch auf den Kopf gestellt werden:

/lcd set flip-screen=yes

Damit ist die Basiskonfiguration des Systems abgeschlossen. Zum jetzigen Zeitpunkt gibt es aber noch keinerlei Firewall, aber auch noch keine IP-Verbindung, da weder Adressen, noch Nameserver oder Routing-Tabellen eingerichtet sind.

Der Thematik widmen wir uns dann (endlich!) im vierten Teil der Serie.