MikroTik RouterOS update- en patchgids

Samenvatting MikroTik RouterOS updaten over een ISP-vloot is een gecontroleerd proces, geen handeling van één klik. Kies een releasekanaal dat past bij je SLA’s, maak van elk apparaat een back-up, valideer op een pilot en rol vervolgens uit in topologiebewuste golven met een duidelijk terugrolpad. In 2026 telt dit meer dan ooit: een publiek te misbruiken RouterOS-kwetsbaarheid (CVE-2026-7668) en een verse stable-release (7.23.1) betekenen dat niet-gepatchte edge-routers een actief risico zijn.

Wat Is RouterOS-Patching voor een ISP-Vloot?

RouterOS-patching is het gedisciplineerde proces om een populatie MikroTik-apparaten van de ene RouterOS-versie naar een nieuwere te tillen om beveiligingslekken, stabiliteitsbugs en gedragsregressies te verhelpen — zonder de erop draaiende diensten te breken. Op één thuisrouter is dit een taak van twee minuten. Over honderden of duizenden CPE’s en edge-routers wordt het een operationeel programma: je hebt een releasekanaalbeleid nodig, een back-upstandaard, een staging-stap, een gefaseerde uitrol en een terugrolplan. Het doel is eenvoudig te formuleren en moeilijk op grote schaal te bereiken — elk apparaat raakt gepatcht en geen enkel apparaat valt onderweg uit.

Het verdient een echte workflow omdat een upgrade precies datgene raakt wat je bij een mislukking niet makkelijk weer kunt bereiken: een router aan de klantrand, vaak achter CGNAT. Een slechte uitrol die de beheertoegang verliest, wordt een ritje naar locatie. Daarom optimaliseert de onderstaande workflow eerst voor veiligheid en bereikbaarheid, en pas daarna voor snelheid.

Waarom Nu Patchen: Het Beveiligingsbeeld van 2026

De patchcadans blijft een stille achtergrondtaak tot een kwetsbaarheid de kwestie afdwingt, en 2026 levert concrete redenen om die aan te scherpen. CVE-2026-7668 is een out-of-bounds read in het SCEP-eindpunt van RouterOS met een score van CVSS 7.3 (Hoog); hij is op afstand te triggeren en er bestaat een publieke exploit. Aparte adviezen van deze cyclus betreffen een probleem met onvoldoende toegangscontrole bij VXLAN-bron-IP-validatie (verholpen in RouterOS 7.20 en later) en een geheugencorruptielek in de SMB-dienst dat een niet-geauthenticeerde aanvaller met geprepareerde pakketten kan triggeren.

De richtlijn van MikroTik is consistent: houd RouterOS actueel en achter een firewall die niet-vertrouwde netwerken blokkeert. De huidige stable-tak, RouterOS 7.23.1 (uitgebracht op 2 juni 2026), verhelpt ook een BGP-geheugenlek en een stabiliteitsprobleem met DHCPv4-snooping. Dit is de gewone reden waarom vloten een herhaalbaar patchproces nodig hebben in plaats van ad-hoc-upgrades.

Stap 1 — Kies het Juiste Releasekanaal

RouterOS biedt meer dan één tak, en de keuze is een beleidsbeslissing, geen voorkeur. Stable-releases verschijnen elke paar maanden met geteste functies en fixes; long-term-releases ontvangen alleen kritieke en beveiligingsfixes en veranderen veel minder tussen versies. Voor edge- en CPE-vloten van ISP’s die voorspelbaarheid waarderen, is de long-term-tak vaak de juiste standaardkeuze, met stable gereserveerd voor hardware of functies die het vereisen. Wat je ook kiest: draai nooit testing- of development-builds in productie. Documenteer de tak per apparaatklasse zodat de beslissing herhaalbaar is binnen het team.

Stap 2 — Maak Eerst een Back-up en Exporteer

Upgrade nooit zonder herstelpunt. Maak zowel een binaire back-up (/system backup save) als een leesbare configuratie-export (/export file=), want de export overleeft versiewisselingen en laat je herbouwen, zelfs als een binaire back-up niet wil terugzetten op een andere build. Trek beide van het apparaat naar je beheersysteem. Bevestig dat er genoeg vrije opslag is voor de nieuwe pakketten voordat je begint, en geef de voorkeur aan een bekabelde of console-verbinding — upgraden via wifi of een onstabiele verbinding is hoe routers midden in het schrijven onbruikbaar raken. Voor apparaten waarbij herstaltoegang de echte zorg is, is onze Netinstall-herstelgids de terugvaloptie wanneer een upgrade misgaat.

Stap 3 — Test op een Pilotapparaat

Upgrade eerst één representatieve router en houd hem in de gaten. Kies een apparaat dat een productieklasse weerspiegelt — zelfde model, zelfde rol, vergelijkbare configuratie — en zet de doelversie erop tijdens een onderhoudsvenster. Verifieer na de herstart de versie, bevestig dat de pakketten zijn ingeschakeld en bekijk de changelog op gedragsveranderingen die je configuratie raken (firewallsemantiek, standaarddiensten, interfacebenaming). Pas wanneer de pilot schoon is, autoriseer je de bredere uitrol. Deze ene stap voorkomt de duurste faalmodus: een regressie ontdekken nadat die al naar duizend klanten is uitgerold.

Stap 4 — Rol Uit in Topologiebewuste Golven

Massa-uitrol draait om volgorde en tempo, niet om overal tegelijk op een knop drukken. Groepeer apparaten op topologie zodat geketende routers in volgorde worden geüpdatet — je wilt niet dat een upstream-router herstart voordat een downstream-apparaat zijn pakketten heeft opgehaald. Definieer golven met eigen onderhoudsvensters en volg elk apparaat in een afstemmingslijst zodat elke eenheid met een probleem opnieuw in de wachtrij komt en niet wordt vergeten. Om internetbandbreedte te besparen, laat je apparaten wijzen naar een centrale router die als lokale pakketspiegel fungeert; dit bepaalt ook welke versie de vloot mag ophalen.

Een gefaseerde uitrol werkt alleen als je elk apparaat daadwerkelijk kunt bereiken om te bevestigen dat het is teruggekomen. Dat is de operationele adder onder het gras bij CPE achter CGNAT — en daar verdient gecentraliseerd beheer zich terug.

Stap 5 — Verifieer, Rol Daarna Terug Indien Nodig

Bevestig na elke golf het resultaat: controleer de gerapporteerde versie, bevestig dat de routerboard-firmware waar van toepassing ook is geüpgraded (/system routerboard upgrade), en valideer dat de diensten die jou aangaan verkeer doorlaten. Als een apparaat zich misdraagt, herstel dan de vorige binaire back-up, bouw opnieuw op vanuit de RSC-export, of herinstalleer de vorige versie met Netinstall als laatste redmiddel. Een patchprogramma is niet „klaar” wanneer de nieuwe versie is geïnstalleerd — het is klaar wanneer elk apparaat als gezond is geverifieerd en elke uitzondering tot afsluiting is gevolgd.

Tips voor Patching op Vlootschaal

• Standaardiseer één geharde baseline zodat upgrades voorspelbaar zijn. Onze best practices voor Winbox-beveiliging en de gids voor device-mode-beveiligingsoperaties definiëren de baseline waarop de meeste upgradeproblemen terug te voeren zijn.
• Beperk beheertoegang tot een VPN of vertrouwde IP’s vóór en na upgrades, zodat een half-gepatchte vloot nooit blootgesteld is.
• Houd het beheervlak bereikbaar, zelfs achter CGNAT, zodat verificatie en terugrollen geen bezoek ter plaatse vereisen.
• Bekijk de beveiligingsadviezen van MikroTik volgens een schema in plaats van te wachten op een incident.

FAQ

Hoe vaak moet ik RouterOS updaten? Beoordeel elke release aan de hand van je takbeleid en patch buiten de planning telkens wanneer een advies diensten raakt die je blootstelt. Er is geen vast interval — alleen een cadans gedreven door risico.

Stable of long-term voor een ISP-vloot? Long-term is de veiligere standaardkeuze voor edge en CPE; gebruik stable waar je nieuwere hardware-ondersteuning of functies nodig hebt, na validatie in staging.

Wat als een upgrade een extern apparaat onbruikbaar maakt? Herstel vanuit een back-up of RSC-export; als het apparaat onbereikbaar is, herstel het dan met Netinstall. Daarom zijn een geteste back-up en een bereikbaar beheerpad verplicht vóór elke golf.

Patch Je Hele Vloot Zonder de Ritjes naar Locatie

Het lastigste deel van vlootpatching is niet de upgrade — het is elk apparaat daarna bereiken en verifiëren, vooral CPE achter CGNAT. MKController centraliseert het zicht over je MikroTik-vloot, en NATCloud geeft je van-binnen-naar-buiten-bereikbaarheid zonder port forwarding, zodat gefaseerde uitrol, verificatie en terugrollen allemaal op afstand gebeuren.

Start je gratis MKController-proefperiode