RouterOS-Update & Patch-Guide MikroTik

Zusammenfassung Das Aktualisieren von MikroTik RouterOS über eine ISP-Flotte hinweg ist ein kontrollierter Prozess, keine Ein-Klick-Aktion. Wählen Sie einen Release-Kanal, der zu Ihren SLAs passt, sichern Sie jedes Gerät, validieren Sie an einem Piloten und rollen Sie dann in topologiebewussten Wellen mit klarem Rollback-Pfad aus. 2026 ist das wichtiger denn je: eine öffentlich ausnutzbare RouterOS-Schwachstelle (CVE-2026-7668) und ein frisches Stable-Release (7.23.1) bedeuten, dass ungepatchte Edge-Router ein aktives Risiko sind.

Was Ist RouterOS-Patching für eine ISP-Flotte?

RouterOS-Patching ist der disziplinierte Prozess, eine Population von MikroTik-Geräten von einer RouterOS-Version auf eine neuere zu heben, um Sicherheitslücken, Stabilitätsfehler und Verhaltensregressionen zu beheben — ohne die darauf laufenden Dienste zu beschädigen. Auf einem einzelnen Heimrouter ist das eine Zwei-Minuten-Aufgabe. Über Hunderte oder Tausende von CPEs und Edge-Routern hinweg wird es zu einem operativen Programm: Sie brauchen eine Release-Kanal-Richtlinie, einen Backup-Standard, einen Staging-Schritt, ein gestaffeltes Rollout und einen Rollback-Plan. Das Ziel ist leicht formuliert und im großen Maßstab schwer zu erreichen — jedes Gerät endet gepatcht, und keines geht dabei offline.

Es verdient einen echten Workflow, weil ein Upgrade genau das berührt, was Sie bei einem Fehlschlag nicht leicht wieder erreichen: einen Router am Kundenrand, oft hinter CGNAT. Ein schlechter Push, der den Verwaltungszugang verliert, wird zum Außeneinsatz. Deshalb optimiert der folgende Workflow zuerst auf Sicherheit und Erreichbarkeit und erst danach auf Geschwindigkeit.

Warum Jetzt Patchen: Das Sicherheitsbild 2026

Die Patch-Kadenz bleibt eine stille Hintergrundaufgabe, bis eine Schwachstelle die Sache erzwingt, und 2026 liefert konkrete Gründe, sie zu verschärfen. CVE-2026-7668 ist ein Out-of-Bounds-Read im SCEP-Endpunkt von RouterOS mit Bewertung CVSS 7.3 (Hoch); sie lässt sich aus der Ferne auslösen, und ein öffentlicher Exploit existiert. Separate Advisories dieses Zyklus betreffen ein Problem unzureichender Zugriffskontrolle bei der VXLAN-Quell-IP-Validierung (behoben in RouterOS 7.20 und neuer) sowie eine Speicherkorruptionslücke im SMB-Dienst, die ein nicht authentifizierter Angreifer mit präparierten Paketen auslösen kann.

MikroTiks Leitlinie ist konsistent: Halten Sie RouterOS aktuell und hinter einer Firewall, die nicht vertrauenswürdige Netzwerke blockiert. Der aktuelle Stable-Zweig, RouterOS 7.23.1 (veröffentlicht am 2. Juni 2026), behebt zudem ein BGP-Speicherleck und ein Stabilitätsproblem beim DHCPv4-Snooping. Das ist der gewöhnliche Grund, warum Flotten einen wiederholbaren Patch-Prozess statt Ad-hoc-Upgrades brauchen.

Schritt 1 — Den Richtigen Release-Kanal Wählen

RouterOS bietet mehr als einen Zweig, und die Wahl ist eine Richtlinienentscheidung, keine Präferenz. Stable-Releases erscheinen alle paar Monate mit getesteten Funktionen und Fixes; Long-Term-Releases erhalten nur kritische und Sicherheits-Fixes und ändern sich zwischen Versionen weit weniger. Für Edge- und CPE-Flotten von ISPs, die Vorhersehbarkeit schätzen, ist der Long-Term-Zweig oft die richtige Standardwahl, wobei Stable für Hardware oder Funktionen reserviert bleibt, die es erfordern. Was auch immer Sie wählen: Führen Sie niemals Testing- oder Development-Builds in der Produktion aus. Dokumentieren Sie den Zweig pro Geräteklasse, damit die Entscheidung im Team wiederholbar ist.

Schritt 2 — Zuerst Sichern und Exportieren

Aktualisieren Sie nie ohne Wiederherstellungspunkt. Erstellen Sie sowohl ein Binär-Backup (/system backup save) als auch einen menschenlesbaren Konfigurationsexport (/export file=), denn der Export übersteht Versionswechsel und erlaubt einen Wiederaufbau, selbst wenn ein Binär-Backup sich nicht auf einen anderen Build zurückspielen lässt. Ziehen Sie beide vom Gerät in Ihr Verwaltungssystem. Bestätigen Sie vor dem Start, dass genug freier Speicher für die neuen Pakete vorhanden ist, und bevorzugen Sie eine kabelgebundene oder Konsolenverbindung — ein Upgrade über WLAN oder eine wacklige Verbindung ist der Weg, wie Router mitten im Schreiben gebrickt werden. Für Geräte, bei denen der Wiederherstellungszugang die eigentliche Sorge ist, ist unser Netinstall-Wiederherstellungsleitfaden die Rückfalloption, wenn ein Upgrade schiefgeht.

Schritt 3 — An einem Pilotgerät Testen

Aktualisieren Sie zuerst einen repräsentativen Router und beobachten Sie ihn. Wählen Sie ein Gerät, das eine Produktionsklasse widerspiegelt — gleiches Modell, gleiche Rolle, ähnliche Konfiguration — und spielen Sie die Zielversion während eines Wartungsfensters ein. Prüfen Sie nach dem Reboot die Version, bestätigen Sie, dass die Pakete aktiviert sind, und sichten Sie das Changelog auf Verhaltensänderungen, die Ihre Konfiguration betreffen (Firewall-Semantik, Standarddienste, Schnittstellenbenennung). Erst wenn der Pilot sauber ist, autorisieren Sie das breitere Rollout. Dieser eine Schritt verhindert den teuersten Fehlermodus: eine Regression erst dann zu entdecken, wenn sie bereits an tausend Kunden ausgeliefert wurde.

Schritt 4 — In Topologiebewussten Wellen Ausrollen

Beim Massen-Rollout geht es um Reihenfolge und Tempo, nicht darum, überall gleichzeitig einen Knopf zu drücken. Gruppieren Sie Geräte nach Topologie, damit verkettete Router der Reihe nach aktualisiert werden — Sie wollen nicht, dass ein vorgelagerter Router neu startet, bevor ein nachgelagertes Gerät seine Pakete geladen hat. Definieren Sie Wellen mit eigenen Wartungsfenstern und verfolgen Sie jedes Gerät in einer Abgleichsliste, damit jede Einheit mit einem Problem erneut eingereiht und nicht vergessen wird. Um Internet-Bandbreite zu sparen, lassen Sie Geräte auf einen zentralen Router als lokalen Paket-Mirror zeigen; das steuert auch, welche Version die Flotte beziehen darf.

Ein gestaffeltes Rollout funktioniert nur, wenn Sie jedes Gerät tatsächlich erreichen können, um seine Rückkehr zu bestätigen. Das ist der operative Haken bei CPE hinter CGNAT — und genau dort zahlt sich zentrale Verwaltung aus.

Schritt 5 — Prüfen, Dann bei Bedarf Zurückrollen

Bestätigen Sie nach jeder Welle das Ergebnis: Prüfen Sie die gemeldete Version, bestätigen Sie, dass die Routerboard-Firmware wo zutreffend ebenfalls aktualisiert wurde (/system routerboard upgrade), und validieren Sie, dass die für Sie wichtigen Dienste Datenverkehr durchleiten. Verhält sich ein Gerät fehlerhaft, stellen Sie das vorherige Binär-Backup wieder her, bauen Sie aus dem RSC-Export neu auf oder installieren Sie als letztes Mittel die vorherige Version mit Netinstall. Ein Patch-Programm ist nicht „fertig”, wenn die neue Version installiert ist — es ist fertig, wenn jedes Gerät als gesund verifiziert und jede Ausnahme bis zum Abschluss verfolgt ist.

Tipps für Patching im Flottenmaßstab

• Standardisieren Sie eine einzige gehärtete Baseline, damit Upgrades vorhersehbar sind. Unsere Best Practices zur Winbox-Sicherheit und der Leitfaden zu Device-Mode-Security-Ops definieren die Baseline, auf die sich die meisten Upgrade-Probleme zurückführen lassen.
• Beschränken Sie den Verwaltungszugang vor und nach Upgrades auf ein VPN oder vertrauenswürdige IPs, damit eine halb gepatchte Flotte nie exponiert ist.
• Halten Sie die Verwaltungsebene auch hinter CGNAT erreichbar, damit Prüfung und Rollback keinen Vor-Ort-Besuch erfordern.
• Sichten Sie MikroTiks Sicherheitsadvisories nach Plan, statt auf einen Vorfall zu warten.

FAQ

Wie oft sollte ich RouterOS aktualisieren? Bewerten Sie jedes Release anhand Ihrer Zweig-Richtlinie und patchen Sie außerplanmäßig, sobald ein Advisory von Ihnen exponierte Dienste betrifft. Es gibt kein festes Intervall — nur eine vom Risiko getriebene Kadenz.

Stable oder Long-Term für eine ISP-Flotte? Long-Term ist die sicherere Standardwahl für Edge und CPE; verwenden Sie Stable dort, wo Sie neuere Hardware-Unterstützung oder Funktionen brauchen, nach Validierung in Staging.

Was, wenn ein Upgrade ein entferntes Gerät brickt? Stellen Sie aus dem Backup oder RSC-Export wieder her; ist das Gerät nicht erreichbar, retten Sie es mit Netinstall. Deshalb sind ein getestetes Backup und ein erreichbarer Verwaltungspfad vor jeder Welle Pflicht.

Patchen Sie Ihre Ganze Flotte Ohne Außeneinsätze

Der schwierigste Teil des Flotten-Patchings ist nicht das Upgrade — es ist, jedes Gerät danach zu erreichen und zu verifizieren, besonders bei CPE hinter CGNAT. MKController zentralisiert die Sichtbarkeit über Ihre gesamte MikroTik-Flotte, und NATCloud gibt Ihnen Erreichbarkeit von innen nach außen ohne Port-Forwarding, sodass gestaffelte Rollouts, Prüfung und Rollback alle aus der Ferne ablaufen.

Starten Sie Ihre kostenlose MKController-Testversion