Guida aggiornamento e patch RouterOS

Riepilogo Aggiornare MikroTik RouterOS su una flotta ISP è un processo controllato, non un’azione con un solo clic. Scegli un canale di rilascio adatto ai tuoi SLA, esegui il backup di ogni dispositivo, convalida su un pilota, poi distribuisci a ondate consapevoli della topologia con un chiaro percorso di rollback. Nel 2026 questo conta più che mai: una falla RouterOS sfruttabile pubblicamente (CVE-2026-7668) e una nuova release stable (7.23.1) significano che i router edge non aggiornati sono un rischio attivo.

Che cos’è il patching di RouterOS per una flotta ISP?

Il patching di RouterOS è il processo disciplinato di portare una popolazione di dispositivi MikroTik da una versione di RouterOS a una più recente per correggere falle di sicurezza, bug di stabilità e regressioni di comportamento — senza compromettere i servizi che vi girano sopra. Su un singolo router domestico è un’attività di due minuti. Su centinaia o migliaia di CPE e router edge, diventa un programma operativo: servono una policy sui canali di rilascio, uno standard di backup, una fase di staging, un rollout graduale e un piano di rollback. L’obiettivo è facile da enunciare e difficile da realizzare su larga scala — ogni dispositivo finisce aggiornato e nessuno va offline nel frattempo.

Merita un vero workflow perché un upgrade tocca l’unica cosa che non puoi raggiungere facilmente di nuovo se fallisce: un router al confine del cliente, spesso dietro CGNAT. Un push sbagliato che perde l’accesso di gestione si trasforma in un intervento sul posto. Per questo il workflow seguente ottimizza prima la sicurezza e la raggiungibilità, e solo dopo la velocità.

Perché applicare patch ora: il quadro di sicurezza 2026

La cadenza delle patch resta un’attività silenziosa di sottofondo finché una vulnerabilità non costringe ad affrontarla, e il 2026 offre ragioni concrete per renderla più stringente. CVE-2026-7668 è un out-of-bounds read nell’endpoint SCEP di RouterOS con punteggio CVSS 7.3 (Alto); può essere innescato da remoto ed esiste un exploit pubblico. Advisory separati di questo ciclo riguardano un problema di controllo degli accessi improprio nella validazione dell’IP sorgente VXLAN (corretto in RouterOS 7.20 e successivi) e una falla di corruzione della memoria nel servizio SMB che un aggressore non autenticato può attivare con pacchetti predisposti.

L’indicazione di MikroTik è coerente: mantieni RouterOS aggiornato e dietro un firewall che blocca le reti non attendibili. L’attuale ramo stable, RouterOS 7.23.1 (rilasciato il 2 giugno 2026), corregge anche una perdita di memoria BGP e un problema di stabilità del DHCPv4-snooping. Questo è il motivo ordinario per cui le flotte hanno bisogno di un processo di patching ripetibile invece di upgrade ad hoc.

Passo 1 — Scegliere il canale di rilascio giusto

RouterOS offre più di un ramo, e la scelta è una decisione di policy, non una preferenza. Le release stable escono ogni pochi mesi con funzionalità e correzioni testate; le release long-term ricevono solo correzioni critiche e di sicurezza, cambiando molto meno tra le versioni. Per le flotte edge e CPE degli ISP che apprezzano la prevedibilità, il ramo long-term è spesso la scelta predefinita giusta, con stable riservato all’hardware o alle funzionalità che lo richiedono. Qualunque cosa tu scelga, non eseguire mai build testing o development in produzione. Documenta il ramo per classe di dispositivo, così la decisione è ripetibile in tutto il team.

Passo 2 — Prima eseguire backup ed esportazione

Non aggiornare mai senza un punto di ripristino. Crea sia un backup binario (/system backup save) sia un’esportazione di configurazione leggibile (/export file=), perché l’esportazione sopravvive ai cambi di versione e ti permette di ricostruire anche se un backup binario non si ripristina su un build diverso. Trasferisci entrambi dal dispositivo al tuo sistema di gestione. Conferma che ci sia spazio libero sufficiente per i nuovi pacchetti prima di iniziare, e preferisci una connessione cablata o console — aggiornare via Wi-Fi o su un collegamento instabile è il modo in cui i router vengono bloccati a metà scrittura. Per i dispositivi in cui l’accesso di recupero è la vera preoccupazione, la nostra guida al recupero con Netinstall è il ripiego quando un upgrade va storto.

Passo 3 — Testare su un dispositivo pilota

Aggiorna prima un router rappresentativo e osservalo. Scegli un dispositivo che rispecchi una classe di produzione — stesso modello, stesso ruolo, configurazione simile — e applica la versione di destinazione durante una finestra di manutenzione. Dopo il riavvio, verifica la versione, conferma che i pacchetti siano abilitati ed esamina il changelog per cambiamenti di comportamento che riguardano la tua configurazione (semantica del firewall, servizi predefiniti, denominazione delle interfacce). Solo quando il pilota è pulito autorizzi il rollout più ampio. Questo singolo passo previene la modalità di guasto più costosa: scoprire una regressione dopo che è già stata distribuita a mille clienti.

Passo 4 — Distribuire a ondate consapevoli della topologia

Il rollout di massa riguarda l’ordine e il ritmo, non premere un pulsante ovunque tutto in una volta. Raggruppa i dispositivi per topologia così che i router concatenati si aggiornino in sequenza — non vuoi che un router a monte si riavvii prima che un dispositivo a valle abbia recuperato i suoi pacchetti. Definisci le ondate con le proprie finestre di manutenzione e tieni traccia di ogni dispositivo in un elenco di riconciliazione, così ogni unità con un problema viene rimessa in coda, non dimenticata. Per ridurre la banda internet, fai puntare i dispositivi a un router centrale che funge da mirror di pacchetti locale; questo controlla anche quale versione la flotta può recuperare.

Un rollout graduale funziona solo se puoi effettivamente raggiungere ogni dispositivo per confermarne il ritorno. È questo il problema operativo con i CPE dietro CGNAT — ed è qui che la gestione centralizzata dà il suo valore.

Passo 5 — Verificare, poi fare rollback se necessario

Dopo ogni ondata, conferma il risultato: controlla la versione riportata, conferma che anche il firmware del routerboard sia stato aggiornato dove applicabile (/system routerboard upgrade) e verifica che i servizi a cui tieni stiano facendo passare traffico. Se un dispositivo si comporta in modo anomalo, ripristina il backup binario precedente, oppure ricostruisci dall’esportazione RSC, oppure reinstalla la versione precedente con Netinstall come ultima risorsa. Un programma di patching non è «finito» quando la nuova versione è installata — è finito quando ogni dispositivo è verificato sano e ogni eccezione è seguita fino alla chiusura.

Consigli per il patching su scala di flotta

• Standardizza un’unica baseline rafforzata così che gli upgrade siano prevedibili. Le nostre best practice di sicurezza Winbox e la guida alle operazioni di sicurezza in device-mode definiscono la baseline a cui risale la maggior parte dei problemi di upgrade.
• Limita l’accesso di gestione a una VPN o a IP attendibili prima e dopo gli upgrade, così una flotta patchata a metà non è mai esposta.
• Mantieni il piano di gestione raggiungibile anche dietro CGNAT, così che verifica e rollback non richiedano una visita sul posto.
• Esamina gli advisory di sicurezza di MikroTik secondo un programma anziché aspettare un incidente.

FAQ

Con quale frequenza dovrei aggiornare RouterOS? Valuta ogni release rispetto alla tua policy di ramo e applica patch fuori programma ogni volta che un advisory riguarda servizi che esponi. Non esiste un intervallo fisso — solo una cadenza guidata dal rischio.

Stable o long-term per una flotta ISP? Long-term è la scelta predefinita più sicura per edge e CPE; usa stable dove ti serve supporto per hardware o funzionalità più recenti, dopo aver convalidato in staging.

E se un upgrade blocca un dispositivo remoto? Ripristina dal backup o dall’esportazione RSC; se il dispositivo è irraggiungibile, recuperalo con Netinstall. Ecco perché un backup testato e un percorso di gestione raggiungibile sono obbligatori prima di ogni ondata.

Applica patch all’intera flotta senza interventi sul posto

La parte più difficile del patching di flotta non è l’upgrade — è raggiungere e verificare ogni dispositivo dopo, specialmente i CPE dietro CGNAT. MKController centralizza la visibilità sull’intera tua flotta MikroTik, e NATCloud ti offre raggiungibilità dall’interno verso l’esterno senza port forwarding, così che rollout graduali, verifica e rollback avvengano tutti da remoto.

Inizia la tua prova gratuita di MKController