Comptes et groupes utilisateurs sur MikroTik#

Création de comptes à droits restreints (lecture seule, API, monitoring) sur RouterOS 6 et 7. La syntaxe des menus /user n'a pas changé entre les deux versions.

1. Principe#

RouterOS sépare deux notions :

• le groupe (/user group) porte les policies — ce que le compte a le droit de faire ;
• l'utilisateur (/user) porte l'identité, le mot de passe, et une restriction par adresse source.

Ne jamais modifier les groupes intégrés (read, write, full) : créer un groupe dédié par usage. Un groupe modifié est invisible dans un export diffé, et c'est la porte ouverte aux élévations de privilèges silencieuses.

2. Les policies disponibles#

Le piège de la policy winbox#

winbox est nécessaire pour l'API sur plusieurs builds RouterOS 7, malgré son nom. Sans elle, le login API échoue avec une erreur peu explicite. Elle n'accorde aucun droit de modification : c'est un droit de session, pas d'écriture.

Ce que sensitive protège#

Sans sensitive, le compte ne peut lire ni les mots de passe PPP, ni les clés d'authentification OSPF, ni les communautés SNMP — même en ayant read. Pour un compte de monitoring, l'omettre est un vrai gain : un collecteur compromis ne livre pas les secrets de l'infrastructure.

3. Compte de monitoring en lecture seule#

Usage type : collecteur de supervision (OSPFView, LibreNMS, Observium, script maison) qui interroge l'API sans jamais écrire.

/user group add name=readonly-api policy=read,api,test,winbox \
    comment="Lecture seule via API - monitoring"

/user add name=monitoring group=readonly-api password="<mot de passe fort>" \
    address=192.168.3.0/24,10.99.0.0/16 \
    comment="Collecteur de supervision"

Volontairement absentes : write, policy, sensitive, ftp, reboot, password. Le compte lit la configuration et exécute des tests réseau, rien de plus.

Sur RouterOS 7, ajouter rest-api si le collecteur utilise l'API REST plutôt que l'API binaire :

/user group set [find name=readonly-api] policy=read,api,rest-api,test,winbox

4. La restriction par adresse — la seconde barrière#

Le paramètre address= du compte refuse la connexion depuis toute autre source, même avec les bons identifiants.

/user set [find name=monitoring] address=192.168.3.0/24,10.99.0.0/16

Règles de bon sens :

• lister toutes les sources possibles : un collecteur peut joindre le routeur par le LAN, par un tunnel, ou par une IP publique selon le chemin emprunté ;
• ne jamais laisser un compte sans restriction d'adresse s'il est joignable depuis internet ;
• quand la source passe par du NAT, l'adresse vue par le routeur n'est pas celle de la machine — vérifier avec :

/ip firewall connection print where dst-port=8728

La colonne SRC-ADDRESS donne l'adresse réellement à autoriser.

Piège vécu : réadresser des tunnels sans élargir au préalable les restrictions address= verrouille tous les accès distants d'un coup. Toujours ajouter la nouvelle plage en gardant l'ancienne, vérifier l'accès, et seulement ensuite retirer l'ancienne.

5. Autres profils utiles#

Compte de sauvegarde de configuration#

Lecture seule + accès aux fichiers, pour un script qui récupère les exports :

/user group add name=backup-ro policy=read,ftp,ssh,test \
    comment="Recuperation des exports de config"
/user add name=backup group=backup-ro password="<...>" address=192.168.3.0/24

Attention : read permet de générer un export contenant la configuration complète. Sans sensitive, les secrets y sont masqués, mais la topologie et les règles de filtrage sont lisibles. Restreindre l'adresse en conséquence.

Compte d'administration déléguée sans gestion des utilisateurs#

Peut tout configurer sauf créer des comptes ou lire les secrets :

/user group add name=admin-delegue policy=read,write,winbox,ssh,test,reboot \
    comment="Admin sans gestion des comptes ni secrets"
/user add name=technicien group=admin-delegue password="<...>" \
    address=192.168.3.0/24

L'absence de policy empêche l'auto-élévation : le compte ne peut pas se donner plus de droits ni créer un compte plus permissif.

Compte de consultation ponctuelle (console uniquement)#

/user group add name=console-ro policy=read,ssh,winbox,test
/user add name=lecture group=console-ro password="<...>" address=192.168.3.0/24

6. Vérification#

/user print detail
/user group print detail
/user active print

/user active print liste les sessions en cours avec leur adresse source et le mode d'accès — utile pour repérer une connexion inattendue.

Test des droits#

Depuis la machine autorisée :

ssh monitoring@<routeur>

Puis sur le routeur :

/ip route print

→ doit fonctionner.

/ip route add dst-address=1.2.3.4/32 gateway=1.1.1.1

→ doit être refusé (erreur de permission).

/ppp secret print detail

→ les mots de passe doivent être masqués si sensitive est absente.

Si l'ajout de route réussit, la policy write a fui quelque part — vérifier le groupe et l'absence d'appartenance à un second groupe.

7. Sécurité de l'accès API#

API en clair vs API-SSL#

Sur un LAN de confiance, l'API simple est acceptable. Dès que le trafic traverse internet ou un réseau partagé, utiliser api-ssl ou faire passer l'API dans un tunnel.

/ip service set api address=192.168.3.0/24,10.99.0.0/16
/ip service set api-ssl address=192.168.3.0/24,10.99.0.0/16 \
    certificate=<nom-du-certificat> disabled=no

Restreindre les services eux-mêmes#

La restriction address= du service (/ip service) s'ajoute à celle du compte. Les deux doivent autoriser la source pour que la connexion aboutisse.

/ip service print detail

Désactiver les services inutilisés plutôt que de les laisser ouverts :

/ip service set telnet disabled=yes
/ip service set ftp disabled=yes
/ip service set www disabled=yes

Ne jamais fermer son dernier chemin d'accès. Avant de restreindre SSH sur un routeur joignable depuis internet, s'assurer de conserver au moins une source de secours indépendante de l'infrastructure locale (une IP mobile, celle d'un tiers de confiance). Un routeur distant verrouillé nécessite un déplacement.

8. Bonnes pratiques#

1. Un compte par usage, jamais de compte partagé entre un humain et un automate — les traces deviennent illisibles et la révocation impossible.
2. Ne jamais utiliser admin pour un collecteur ou un script.
3. Toujours restreindre par adresse, y compris sur le LAN.
4. Omettre sensitive dès que le compte n'a pas besoin de lire les secrets.
5. Omettre policy sauf pour les comptes d'administration réels — c'est la policy qui permet l'auto-élévation.
6. Élargir avant de restreindre : quand les adresses sources changent (réadressage, nouveau tunnel), ajouter la nouvelle plage, vérifier l'accès, puis retirer l'ancienne.
7. Vérifier après création avec un test d'écriture qui doit échouer — la configuration seule ne prouve rien.
8. Exporter avant et après toute modification de comptes : /export compact file=users-<date>.

9. Suppression et révocation#

/user disable [find name=<compte>]      # revocation immediate, reversible
/user remove [find name=<compte>]       # definitive
/user group remove [find name=<groupe>] # apres avoir retire tous ses membres

Préférer disable à remove pour une révocation temporaire : la configuration reste documentée et le retour arrière est immédiat.

Pour couper une session active :

/user active print
/user active remove <numero>