MikroTik Device-Mode: Guia de Seguretat i Operacions
Resum
Device-mode és la “porta de funcions” de RouterOS per a subsistemes arriscats. Aquesta guia explica com funciona, per què existeix, les novetats de les versions i com mantenir l’automatització i MKController estables.
MikroTik Device-Mode: Guia de Seguretat i Operacions
Què és device-mode (i què no és)
Històricament, MikroTik RouterOS assumia que si t’autenticaves, eres de confiança. Aquesta forma de pensar ha quedat obsoleta.
Device-mode és un estat persistent de seguretat que determina què pot fer el sistema operatiu, independentment de qui hi accedeixi. Està “per sota” dels permisos d’usuari. Així, ni tan sols una sessió d’administrador pot activar eines d’alt risc si la política de device-mode no ho permet.
Device-mode és diferent de Safe Mode. Safe Mode t’ajuda a evitar bloquejos mentre fas canvis. Device-mode és una política durable que persisteix després de reinicis i actualitzacions.
Per què MikroTik va introduir device-mode
Resumint: els atacants van aprendre a convertir routers perifèrics en armes a escala d’internet.
Un dels motius principals va ser l’era del botnet Mēris. Routers compromesos es van usar com a repetidors i generadors de tràfic, abusant de funcions legítimes per a enginyers de xarxa però devastadores en massa quan són segrestades.
Els elements més abusats incloïen:
- Proxy SOCKS, usat per tunel·lar tràfic d’atac.
- Bandwidth-test, abusat per amplificar tràfic.
- Scheduler + fetch, per persistència i lliurament de càrregues.
Device-mode aplica el principi del mínim privilegi a nivell de plataforma. Fa que el “control remot” sigui menys rendible. Un atacant pot robar credencials, però no pot activar les opcions més perilloses sense un pas físic.
La confirmació física
Una regla clau és la verificació d’accés físic.
Si tries canviar una funció restringida de no a sí, RouterOS accepta la sol·licitud però la deixa pendent. Cal confirmar-la localment, normalment amb un botó o reinici fred (cicle d’energia) dins el temps establert.
Això vol dir que la frontera de seguretat no és només la teva contrasenya, sinó la teva contrasenya més la prova que algú pot tocar el dispositiu.
Consell: Tracta els canvis de device-mode com a “control de canvis.” Si el dispositiu és remot, planifica com faràs el reinici necessari (PDU intel·ligent, PoE gestionat, mans in situ).
On s’ubica device-mode a la pila de seguretat
Un model mental pràctic:
- Grups d’usuaris: “Què pot clicar o escriure aquest usuari.”
- Tallafocs: “Quin tràfic pot arribar als serveis.”
- Device-mode: “Què pot executar el sistema operatiu en general.”
Per tant, device-mode no substitueix el tallafocs. És la darrera línia de defensa quan hi ha un problema.
Modes, marques i què es bloqueja a l’operació real
Device-mode es configura a /system/device-mode. Internament és un conjunt de flags booleans que regulen subsistemes.
Exemples de flags que afecten operacions reals:
fetch: bloqueja/tool/fetchi tota automatització que hi depengui.scheduler: bloqueja/system/scheduleri scripts programats.socks: bloqueja l’activació del proxy SOCKS.bandwidth-testitraffic-gen: bloquegen les eines de test i generació de tràfic.container: bloqueja contenidors RouterOS tret que s’activi explícitament.partitionsirouterboard: bloquegen canvis baixos de magatzematge i boot.install-any-version/allowed-versions: limita vies de downgrade que reintrodueixen vulnerabilitats antigues.
Segons la versió de RouterOS, MikroTik també va definir modes preestablerts (per exemple: home, basic, advanced i rose segons hardware). El nom és menys important que la configuració resultant. Un nou dispositiu pot arribar amb un perfil restrictiu que impedeixi la configuració per defecte fins que ho planifiquis.
Evolució Tècnica per Versions i Anàlisi del Canvi
La implementació de device-mode ha seguit un trajecte no lineal, passant d’un control específic per contenidors a un marc d’aplicació global.
Fase 1: Seguretat de Contenidors (RouterOS v7.4beta - v7.12)
Device-mode va aparèixer amb el suport a contenidors (entorns compatibles amb Docker) a RouterOS v7.4beta. MikroTik va identificar que permetre executar binaris de tercers era un risc sense precedents. Així, el paquet de contenidors fou la primera funció que requerí activació via /system/device-mode/update container=yes seguida d’una pulsació de botó. Durant aquest període, device-mode era vist principalment com un “interruptor de seguretat per contenidors”.
Fase 2: La Base de Seguretat (v7.13 i v6.49.8)
MikroTik va portar elements de device-mode al branch v6 en la versió 6.49.8 i va introduir la propietat allowed-versions a la 7.13. Aquesta propietat restringeix el downgrade a versions amb vulnerabilitats conegudes, bloquejant atacs de rollback com Chimay-Red (CVE-2017-20149).
Fase 3: La Renovació a la Versió 7.17
La versió 7.17 (principis 2025) va ampliar significativament el marc, afegint conceptes de “modes” predefinits per categoritzar dispositius segons hardware i entorn.
| Nom del Mode | Tipus de Hardware | Postura de Seguretat | Restriccions Clau (per defecte) |
|---|---|---|---|
| Advanced | CCR, 1100, Alta gamma | Permissiu | container, traffic-gen, install-any-version |
| Home | hAP, cAP, SOHO | Estricte | scheduler, fetch, socks, bandwidth-test, sniffer |
| Basic | RB estàndard, Switches | Equilibrat | socks, bandwidth-test, proxy, zerotier |
| Rose | RDS, Outdoor Wireless | Ús Especial | Igual que Advanced però amb container=yes¹ |
¹ Durant l’actualització a v7.17, el sistema va renombrar automàticament el mode legacy “enterprise” a “advanced”. Per desplegaments existents, MikroTik va intentar mantenir funcionalitats assignant el mode més proper al perfil hardware. Tot i això, es van produir problemes operacionals perquè funcions com traffic-gen (essencial per /tool flood-ping) i reparticionament es van desactivar fins i tot en mode “advanced”.
Fase 4: Automatització i Ajustaments (v7.19 - v7.22)
Les darreres versions han abordat el “bloqueig d’automatització” causat per la necessitat de confirmació física. La versió 7.19.4 va introduir el mode rose, per a dispositius RDS amb suport a instal·lació de contenidors d’origen.
La 7.22rc3 (febrer 2026) va permetre configurar device-mode en la imatge inicial via Netinstall i FlashFig amb “scripts de mode”. Això facilita que ISP defineixin l’estat de seguretat a la primera instal·lació, eliminant la necessitat de botons físics en milers d’unitats. També va eliminar la propietat authorized-public-key-hash, aclarint especulacions sobre canvis remots via claus SSH.
Estat “Flagged” i comptador d’intents
Device-mode no es limita a flags estàtics.
RouterOS pot marcar un dispositiu com a flagged quan detecta patrons sospitosos, com manipulació de fitxers o scripts amb conducta persistent. En aquest estat, pot aplicar un mode segur més estricte, desactivant eines restringides.
També hi ha un comptador d’intents per canvis fallits de device-mode. Si s’intenten canviar sense confirmació física, el comptador pot bloquejar més actualitzacions fins a reinici físic.
Operativament: si veus números d’intents imprevistos, investiga abans d’augmentar permisos.
Problemes de provisió: el bloqueig d’automatització
Els ISP i grans parcs volen provisió zero-touch. Device-mode ho pot complicar.
Un bloqueig comú és:
- El router arrenqua en mode restrictiu.
- El primer script necessita
/tool/fetchper descarregar configuracions o certificates. fetchestà bloquejat pel device-mode.- La provisió falla i mai s’arriba a reparar remotament.
Alguns equips acaben obrint cada unitat, activant funcions manualment i tornant a empaquetar. No és viable a gran escala.
Els fluxos nous permeten ajustar device-mode durant la instal·lació d’imatge (p. ex. via scripts de mode a Netinstall/FlashFig). Si gestiones volum, planifica la imatge d’or.
Avís: Un
/system/reset-configurationestàndard pot no reiniciar device-mode en molts models. Si assumes que “reset = estat de fàbrica”, això pot ser un problema.
Com habilitar amb seguretat una funció necessària (exemple CLI)
Si realment necessites una funció restringida, segueix aquest procés:
- Consulta l’estat actual
/system/device-mode/print- Sol·licita el canvi amb un timeout
/system/device-mode/update fetch=yes activation-timeout=10m- Fes la confirmació física
- Prem el botó Mode/Reset una vegada (depèn del model), o
- Reinicia el dispositiu (cold reboot).
- Verifica
/system/device-mode/printSi perds el timeout, RouterOS descarta el canvi pendent i manté la política anterior.
Activació basada en risc: matriu ràpida
| Capacitat | Ús legítim típic | Risc principal | Enfocament més segur |
|---|---|---|---|
fetch | descarregar configs, renovar certs | lliurament remot de càrregues | només a endpoints HTTPS coneguts; restringir sortida |
scheduler | còpies de seguretat, tasques manteniment | persistència | mantenir scripts mínims; monitorar tasques no esperades |
socks | túnel intern | relé de botnet | vincular a VLAN gestió; restringir via tallafocs |
traffic-gen / bandwidth-test | proves d’enllaç | DoS/amplificació | habilitar només en finestres de manteniment |
container | executar serveis al router | persistència a llarg termini | preferir servidors dedicats; reforçar magatzematge i tallafocs |
Impacte en l’adopció de MKController (Device-Mode desactivat)
MKController depèn d’un accés de gestió previsible. Device-mode pot ser un “fre invisible” durant la posada en marxa.
Si device-mode bloqueja una acció requerida (p. ex. habilitar un servei, executar un script o permetre una eina d’instal·lació), el procés d’adopció pot aturar-se. El símptoma és que “el dispositiu és accessible però les tasques fallen.”
Per això la guia de resolució de problemes destaca Device-Mode disabled com a punt específic a revisar: si device-mode impedeix funcions essencials, cal un pas de confirmació física planificada abans d’adoptar i gestionar completament el dispositiu a MKController. Vegeu l’apartat 4 aquí: https://mkcontroller.com/docs/management/troubleshooting/troubleshooting/#4-device-mode-disabled
Consell pràctic: en desplegaments grans, incorpora una política device-mode al checklist d’estadi. Decideix quines flags permetràs abans d’enviar dispositius. Documenta com es farà la confirmació física. Estalviarà molts cicles de suport després.
On ajuda MKController: Un cop el dispositiu està adoptat, MKController redueix logins repetits i comprovacions manuals centralitzant inventari, governança d’accés i visibilitat operativa. Així, només toques device-mode quan hi hagi una necessitat real i justificada.
Checklist post-actualització per estandarditzar
Fes-ho després d’actualitzacions RouterOS o recepció de nou hardware:
- Confirma el mode actual i si encaixa amb la teva política.
- Valida les eines que utilitzes (p. ex. si
fetchischedulerfuncionen). - Revisa la política de allowed versions si operes en entorns regulats.
- Inspecciona el comptador d’intents i l’estat
flaggedper anomalies. - Documenta quins llocs requereixen confirmació física i com es farà.
Per documentació oficial sobre device-mode, la de MikroTik és un bon punt de partida: https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode
Sobre MKController
Esperem que aquests coneixements t’hagin ajudat a navegar millor el teu univers MikroTik i Internet! 🚀
Ja sigui ajustant configs fins a l’últim detall o posant ordre al caos de xarxa, MKController fa la teva vida més fàcil.
Amb gestió en núvol centralitzada, actualitzacions de seguretat automàtiques i un dashboard fàcil d’usar, tenim el que necessites per millorar la teva operació.
👉 Comença la prova gratuïta de 3 dies ara a mkcontroller.com — i descobreix com és el control de xarxa sense esforç.