Guide Sécurité Device-Mode MikroTik

Résumé Le device-mode est la barrière persistante de capacités de RouterOS pour les sous-systèmes à haut risque — fetch, scheduler, proxy SOCKS, bandwidth-test, conteneurs et autres. Il se situe sous les permissions utilisateur, de sorte que même un administrateur complet ne peut pas activer certains outils sans confirmation physique par bouton ou cycle d’alimentation. Ce guide explique comment il fonctionne, pourquoi MikroTik l’a introduit après l’ère du botnet Mēris, comment il a évolué de RouterOS v7.4 à v7.22, et comment planifier le provisioning pour que l’adoption de MKController reste fluide.

Qu’est-ce que le device-mode RouterOS ?

Le device-mode est un état de sécurité persistant de RouterOS qui décide de ce que le système d’exploitation lui-même peut faire, indépendamment de l’utilisateur connecté. Il se situe sous les permissions utilisateur : même une session d’administrateur complet ne peut pas activer certains outils à haut risque à moins que la politique device-mode ne l’autorise, et la frontière de sécurité devient « votre mot de passe plus la preuve physique que quelqu’un peut toucher l’appareil ».

Le device-mode est différent du Safe Mode. Le Safe Mode vous protège des blocages de configuration pendant les changements interactifs (il effectue un rollback si la session se déconnecte). Le device-mode est une politique de capacités de longue durée qui survit aux redémarrages et aux mises à niveau — une fois qu’une fonctionnalité est restreinte, chaque redémarrage maintient la restriction jusqu’à ce qu’une confirmation physique explicite inverse la décision.

Pourquoi MikroTik a introduit le device-mode

Les attaquants ont appris à transformer les routeurs de bordure en armes à l’échelle d’internet. Le botnet Mēris a été le point d’inflexion — des appareils MikroTik compromis ont été utilisés comme relais et générateurs de trafic en abusant de fonctionnalités légitimes pour les ingénieurs réseau mais dévastatrices une fois détournées : proxy SOCKS pour tunneler le trafic d’attaque, bandwidth-test pour l’amplification, scheduler + fetch pour la persistance et la livraison de payload.

Le device-mode applique le principe de moindre privilège au niveau de la plateforme afin qu’un identifiant volé seul ne puisse pas actionner les interrupteurs les plus risqués. La frontière de sécurité devient « votre mot de passe plus la preuve physique que quelqu’un peut toucher l’appareil ».

La poignée de main de confirmation physique

Si vous essayez de faire passer une fonctionnalité restreinte de no à yes, RouterOS accepte la demande mais la garde en attente. Vous devez confirmer localement avec un appui sur bouton ou un cold reboot dans le délai configuré, ou RouterOS rejette le changement. Pour les sites distants, planifiez comment le cycle d’alimentation requis aura lieu — PDU intelligent, injecteur PoE managé, ou mains sur place. Le device-mode ne remplace pas le firewall ni les permissions utilisateur — il se situe en dessous comme dernière ligne de défense.

Modes, flags et ce qui est bloqué

Le device-mode est configuré sous /system/device-mode. En interne, c’est un ensemble de flags booléens qui contrôlent des sous-systèmes spécifiques. Les flags qui apparaissent dans les opérations réelles :

• fetch — bloque /tool/fetch et toute automatisation qui en dépend.
• scheduler — bloque /system/scheduler et les scripts planifiés.
• socks — bloque l’activation du proxy SOCKS.
• bandwidth-test et traffic-gen — bloquent BTest et la génération de trafic.
• container — bloque les conteneurs RouterOS sauf s’ils sont explicitement activés.
• partitions et routerboard — bloquent les changements de stockage bas-niveau et de configuration de boot.
• install-any-version / allowed-versions — restreignent les chemins de downgrade qui réintroduisent d’anciennes vulnérabilités.

Les versions plus récentes de RouterOS ont introduit des modes prédéfinis qui regroupent les flags par niveau de matériel :

Mode	Niveau de matériel	Posture	Restrictions par défaut clés
advanced	CCR, 1100, haut de gamme	Permissif	container, traffic-gen, install-any-version
home	hAP, cAP, SOHO	Strict	scheduler, fetch, socks, bandwidth-test, sniffer
basic	RB standard, switches	Équilibré	socks, bandwidth-test, proxy, zerotier
rose	RDS, wireless extérieur	Usage spécial	Comme advanced mais avec container=yes

Un nouvel appareil peut arriver avec une posture restrictive qui casse votre automatisation standard jusqu’à ce que vous le planifiiez.

Évolution des versions

Le device-mode est passé d’un contrôle spécialisé de conteneur à un framework complet. Il est apparu pour la première fois dans v7.4beta lié au support des conteneurs — la première fonctionnalité exigeant /system/device-mode/update container=yes et un appui sur bouton. v7.13 (et le backport v6.49.8) a introduit allowed-versions pour bloquer les attaques de rollback contre les anciennes CVE. v7.17 (début 2025) a apporté les modes prédéfinis par niveau de matériel avec attribution automatique du mode lors de la mise à niveau. v7.19–v7.22 ont résolu le « deadlock d’automatisation » — v7.22rc3 (février 2026) a ajouté la possibilité de configurer le device-mode via Netinstall et FlashFig en utilisant un « mode script », permettant aux ISPs de définir l’état de sécurité lors du flashage initial au lieu d’appuyer sur des boutons sur des milliers d’unités.

État flagged et douleur de provisioning

RouterOS peut marquer un appareil comme flagged lorsqu’il détecte des motifs suspects (altération de fichiers, comportement de type persistance) et applique un état sûr plus strict. Un compteur de tentatives verrouille également les futures mises à jour de device-mode après des tentatives de changement répétées et échouées sans confirmation physique. Quand les compteurs semblent inattendus, enquêtez d’abord — n’activez pas plus de fonctionnalités pour « faire fonctionner ».

Le motif de deadlock de provisioning : le routeur démarre en mode restrictif, le script de premier boot a besoin de /tool/fetch pour télécharger la config, fetch est bloqué, le bootstrap échoue, l’appareil n’atteint jamais l’état où une correction à distance est possible. Les workflows de provisioning plus récents corrigent cela via les mode scripts Netinstall/FlashFig. Notez que /system/reset-configuration NE réinitialise PAS le device-mode sur de nombreux modèles — les hypothèses « reset égale usine » peuvent vous surprendre.

Comment activer en toute sécurité une fonctionnalité nécessaire

Quand vous avez légitimement besoin d’une capacité restreinte, utilisez une procédure prévisible :

1. Vérifiez l’état actuel :

   /system/device-mode/print

2. Demandez le changement avec un timeout :

   /system/device-mode/update fetch=yes activation-timeout=10m

3. Effectuez la confirmation physique — appuyez sur le bouton Mode/Reset (selon le modèle) ou faites un cold reboot.

4. Vérifiez :

   /system/device-mode/print

Si le timeout expire avant la confirmation, RouterOS rejette le changement en attente et conserve l’ancienne politique.

Matrice d’activation basée sur le risque

Capacité	Besoin légitime typique	Risque principal	Approche plus sûre
fetch	Récupérer configs, renouveler certs	Livraison de payload à distance	Autoriser uniquement les endpoints HTTPS connus ; restreindre l’egress
scheduler	Sauvegardes, tâches de maintenance	Persistance	Garder les scripts minimaux ; surveiller les jobs inattendus
socks	Tunneling interne	Relais de botnet	Lier uniquement au VLAN de gestion ; restreindre par firewall
traffic-gen / bandwidth-test	Tests de lien	DoS / amplification	Activer uniquement pendant les fenêtres de maintenance
container	Exécuter des services sur le routeur	Persistance longue durée	Préférer des serveurs dédiés ; durcir le stockage et le firewall

Impact sur l’adoption de MKController

MKController dépend d’un accès de gestion prévisible ; le device-mode peut être le frein à main invisible pendant l’onboarding. S’il bloque une action requise, le flux d’adoption stagne — le symptôme ressemble souvent à « l’appareil est joignable, mais les tâches échouent ». Le guide de dépannage de MKController met spécifiquement en évidence Device-Mode disabled. Planifiez-le : incluez une politique device-mode dans votre checklist de staging, décidez quels flags sont autorisés avant l’envoi, et documentez comment la confirmation physique aura lieu sur chaque site. Pour le contexte de sécurité associé, consultez nos guides meilleures pratiques de sécurité Winbox et gestion distante WireGuard.

Checklist post-mise à niveau

Après chaque mise à niveau de RouterOS ou à la réception de nouveau matériel : confirmez que le mode actuel correspond à la politique ; validez les outils dont vous dépendez (fetch, scheduler) ; vérifiez allowed-versions dans les environnements régulés ; inspectez attempt-count et l’état flagged à la recherche d’anomalies ; documentez quels sites requièrent une confirmation physique et comment.

Passez à l’étape suivante

Le device-mode est une infrastructure de sécurité essentielle mais ajoute une surcharge opérationnelle à l’échelle, où la confirmation physique sur les sites distants ne peut pas être improvisée. MKController centralise l’inventaire, la gouvernance d’accès et la visibilité afin que vous ne touchiez au device-mode que lorsque c’est justifié, et que l’étape physique soit planifiée plutôt que réactive.

Commencez votre essai gratuit de MKController