Sécuriser OPNsense : compte dédié, 2FA et filet de secours

Ton OPNsense voit passer tout ton réseau. Il décide qui parle à qui, il tient tes VLANs, il sépare tes objets connectés de tes machines perso. Tout le cloisonnement qu’on a construit ensemble repose sur lui.

Maintenant, regarde qui garde la porte de son interface d’administration. Un compte qui s’appelle root, créé à l’installation, et un mot de passe. C’est tout.

Le problème n’est pas que root soit fragile en soi. C’est que son nom est connu de la planète entière. Quelqu’un qui cherche à entrer n’a qu’une moitié de l’équation à trouver, et cette moitié-là est la seule chose qui se dresse entre lui et les clés de ton réseau. Le jour où il passe, tes VLANs, tes règles, ton cloisonnement ne valent plus rien : il lui suffit de les modifier.

Un pare-feu, c’est un point unique. Celui qui le contrôle contrôle tout ce qui se trouve derrière. Et quand on a fait le choix d’héberger soi-même son infrastructure, on a aussi fait le choix d’en être le seul gardien. Personne ne viendra verrouiller cette porte à ta place.

C’est ce qu’on va faire, avec la même logique que pour Proxmox :

• créer un compte administrateur dédié, à ton nom, pour ne plus jamais utiliser root au quotidien ;
• désactiver root, dans l’interface comme en SSH ;
• ajouter une seconde serrure avec la double authentification TOTP ;
• et surtout, préparer le filet de secours, pour que ce durcissement ne se retourne pas contre toi le jour où ton téléphone tombe à l’eau.

Parce qu’un pare-feu dont tu t’es toi-même verrouillé dehors n’est pas plus sûr. Il est juste inaccessible.

Environnement de ce tuto : OPNsense 26.7 en VM sur Proxmox VE 9.2, dans un réseau de démonstration. Toutes les manipulations ont été testées avant rédaction.

Créer ton compte administrateur dédié

Première règle, et elle conditionne tout le reste : on ne touche pas à root tant qu’un autre compte administrateur n’a pas fait ses preuves. Désactiver root avant, c’est scier la branche sur laquelle tu es assis.

Pourquoi un compte dédié plutôt que root avec un meilleur mot de passe ? Parce que ton nom d’utilisateur redevient un secret. Un attaquant qui vise root connaît déjà l’identifiant. Face à un compte dont il ignore le nom, il repart de zéro.

Direction System ‣ Access ‣ Users. Pour l’instant, root est seul.

Clique sur le + en bas à droite. Les champs qui comptent :

• Username : un nom qui ne se devine pas. Évite admin, administrator, opnsense ou ton pseudo public.
• Password : une phrase de passe longue, rangée dans ton gestionnaire de mots de passe.

Pour la démo, j’utilise un nom explicite, HMT, pour que tu t’y retrouves dans les captures. Chez toi, choisis un nom qui ne se devine pas.

Descends ensuite plus bas sur la page :

• Login shell : par défaut, OPNsense propose Default (none for all but root), autrement dit aucun shell pour tout autre compte que root. Remplace-le par /bin/csh. La raison est pratique : la documentation officielle précise qu’un compte ne peut se connecter à la console que si son shell n’est pas /sbin/nologin. Or la console fait partie de ton accès de secours. Un admin sans shell, une fois root désactivé, c’est une console où plus personne n’entre.
• Group membership : sélectionne admins. C’est ce groupe qui donne les droits complets sur l’interface.
• OTP seed et Authorized keys : laisse vides pour l’instant, on y revient.

Enregistre. Maintenant, le test qui compte : déconnecte-toi, et reconnecte-toi avec ton nouveau compte. Ouvre quelques pages, vérifie que tu as bien accès à tout, y compris System ‣ Access ‣ Users. En haut à droite, c’est ton nouveau compte qui doit apparaître.

Tant que ce test n’est pas concluant, root reste actif.

Désactiver root

Ton compte dédié fonctionne, tu t’es connecté avec, tu as vérifié tes accès. Maintenant seulement, on neutralise root.

Désactiver plutôt que supprimer : root est un compte système (OPNsense l’indique en toutes lettres dans sa fiche, Defined By : system). On ne le supprime pas, on le met hors service. Il reste là, inutilisable, et c’est exactement ce qu’on veut.

Connecté avec ton nouveau compte, va dans System ‣ Access ‣ Users et édite root. Coche Disabled, puis enregistre.

Dans la liste, root apparaît désormais grisé.

Vérifie tout de suite : déconnecte-toi, et essaie de te reconnecter en root. La connexion doit échouer.

Note le message : Wrong username or password. OPNsense ne dit pas que le compte est désactivé. C’est voulu, et c’est une bonne pratique : un attaquant n’apprend rien sur l’état de tes comptes. Si la connexion passe, quelque chose n’a pas été enregistré, et tu recommences avant d’aller plus loin.

Et en SSH ? Va dans System ‣ Settings ‣ Administration, section Secure Shell. Deux cas :

• Le serveur SSH n’est pas activé : il n’y a pas de porte SSH, rien à faire. Si tu n’utilises pas la ligne de commande à distance, c’est la meilleure situation : un service éteint ne peut pas être attaqué.
• Le serveur SSH est activé : vérifie que Permit root user login est décoché. Sur notre installation de démo, elle l’était déjà, mais on vérifie plutôt que de le supposer. La documentation d’OPNsense elle-même déconseille la connexion root et recommande de te connecter avec un autre utilisateur, puis d’élever tes droits.

Désactiver le compte et fermer la connexion root en SSH, ce sont deux réglages différents. On vérifie les deux, sans parier sur le fait que l’un couvre l’autre.

À ce stade, root ne sert plus à rien pour quelqu’un de l’extérieur. Mais ton compte dédié repose encore sur un seul mot de passe. C’est ce qu’on règle maintenant.

Ajouter la double authentification TOTP

Si ton mot de passe fuite, qu’il soit capturé, deviné ou réutilisé ailleurs, la porte s’ouvre. La 2FA ajoute une seconde serrure : un code à six chiffres qui change toutes les 30 secondes, généré par une application sur ton téléphone. Sans ce code, le mot de passe seul ne suffit plus.

On l’a vu dans l’article sur la double authentification : ce code doit vivre dans une application séparée de ton gestionnaire de mots de passe. Même règle ici. Proton Authenticator, Aegis ou n’importe quelle application TOTP standard fera l’affaire.

Chez OPNsense, la 2FA ne s’active pas avec une simple case sur ton compte. Elle se construit en quatre temps :

• un serveur d’authentification ;
• un secret lié à ton compte ;
• un test ;
• puis la bascule.

L’ordre compte, et la bascule vient en dernier.

1. Créer le serveur TOTP

Va dans System ‣ Access ‣ Servers et clique sur +. Remplis :

Enregistre. Ce serveur vérifie deux choses à la fois : ton mot de passe local et le code TOTP. Il apparaît dans la liste, à côté de Local Database.

2. Générer le secret de ton compte

Retourne dans System ‣ Access ‣ Users et édite ton compte dédié, dans mon cas HMT. Dans le champ OTP seed, clique sur l’icône engrenage : OPNsense génère un secret et affiche le QR code correspondant. Scanne-le avec ton application TOTP, puis enregistre. Un code à six chiffres apparaît dans l’application, renouvelé toutes les 30 secondes.

Ce QR code, c’est ta seconde clé. Quiconque le voit peut générer tes codes. Ne le photographie pas, ne le partage pas, et ne le laisse pas affiché plus longtemps que nécessaire. (Celui de la capture a été régénéré depuis : il ne correspond plus à rien.)

3. Tester avant de basculer

Va dans System ‣ Access ‣ Tester. Choisis ton serveur TOTP, entre ton nom d’utilisateur, puis dans le champ mot de passe, saisis le code à six chiffres suivi de ton mot de passe, collés, sans espace. Par exemple : 123456tonmotdepasse.

C’est le piège classique : il n’y a pas de champ séparé pour le code. Par défaut, le code vient d’abord, le mot de passe ensuite. Cet ordre peut être inversé avec l’option Reverse token order du serveur, mais garde-le tel quel et retiens-le.

Si le testeur affiche une authentification réussie, tout fonctionne. Sinon, tu corriges maintenant, tant que rien n’est encore imposé.

4. Basculer l’authentification

C’est l’étape qui rend la 2FA réelle. Par défaut, OPNsense valide les connexions contre sa base locale, sans code. Tant que tu ne changes pas ce réglage, ta 2FA est configurée mais pas exigée.

Avant de toucher à quoi que ce soit, deux réflexes :

• prends un snapshot de ta VM OPNsense dans Proxmox (on détaille la manip dans le filet de secours, plus bas) ;
• garde un deuxième onglet ouvert, déjà connecté. Si la nouvelle connexion échoue, cette session active te permet de revenir en arrière sans rien casser.

Va dans System ‣ Settings ‣ Administration, section Authentication. Dans Server, sélectionne ton serveur TOTP, et uniquement lui, dans mon cas 2FA : décoche Local Database. La documentation officielle est claire : c’est ce réglage qui empêche un utilisateur local d’entrer sans 2FA.

Enregistre, puis ouvre une fenêtre de navigation privée et connecte-toi : nom d’utilisateur, puis code et mot de passe collés. Tu arrives sur le tableau de bord ? Ton pare-feu exige désormais deux serrures.

Le filet de secours

On a verrouillé la porte à double tour. Reste une question que la plupart des tutos oublient : que se passe-t-il le jour où ton téléphone tombe à l’eau ?

On l’a testé : la console d’OPNsense applique la même règle que l’interface web. Mot de passe seul, refusé. Code et mot de passe, accepté.

C’est cohérent, et c’est une bonne nouvelle pour la sécurité : il n’y a pas de porte dérobée par la console. Mais ça veut dire aussi que sans ton second facteur, tu es dehors partout.

Le filet se prépare donc maintenant, pendant que tu as encore accès. Trois réflexes.

1. Sauvegarder ton second facteur

OPNsense ne te donne aucun code de secours quand tu actives la 2FA. Ta seule clé de récupération, c’est le seed.

Bonne nouvelle : si ton application 2FA est bien configurée, tu es peut-être déjà couvert. La plupart des applications sérieuses proposent une sauvegarde chiffrée, une synchronisation entre appareils ou un export. Proton Authenticator, par exemple, fait les trois. Vérifie maintenant, pas le jour où tu en as besoin, que la sauvegarde est active et qu’elle ne vit pas uniquement sur ton téléphone.

Si ton application ne propose rien de tel, ou pour une double sécurité, garde une copie du seed hors de ton téléphone. Tant que tu es connecté, il reste consultable : System ‣ Access ‣ Users, édite ton compte, bouton show dans le champ OTP seed.

Note-le sur papier et range-le en lieu sûr. Pas dans ton gestionnaire de mots de passe : on ne met pas le second facteur dans le même coffre que le premier.

2. Snapshot avant chaque changement d’authentification

Ton OPNsense tourne en VM : profites-en. Avant de toucher aux comptes ou à la 2FA, prends un snapshot dans Proxmox : sélectionne ta VM, menu Snapshots, puis Take Snapshot. Donne-lui un nom clair.

Si tu te verrouilles, sélectionne le snapshot dans la liste et clique sur Rollback : tu reviens à l’état d’avant.

Deux limites honnêtes. Tout ce que tu as modifié après le snapshot est perdu. Et un snapshot consomme de l’espace disque à mesure que la VM écrit : une fois la manip validée, supprime-le avec Remove. Un snapshot oublié, c’est de l’espace qui fond sans que tu le voies.

3. Télécharger la sauvegarde de configuration

Une fois tout en place, va dans System ‣ Configuration ‣ Backups, section Download. Avant de cliquer sur Download configuration, coche Encrypt this configuration file : le fichier XML téléchargé sera chiffré.

Chiffré ou non, traite ce fichier comme un secret : c’est la configuration de ton pare-feu. Il se range avec le même soin que le seed.

Un pare-feu durci sans filet, c’est un pari. Avec ces trois réflexes, c’est une décision.

Ce qui a changé

Avant, la porte de ton pare-feu tenait sur un identifiant connu de tous et un mot de passe. Maintenant :

• root est désactivé, et sa connexion SSH reste fermée ;
• tu entres avec un compte à toi, dont le nom ne se devine pas ;
• chaque connexion exige ton mot de passe et un code qui change toutes les 30 secondes, sur le web comme en console ;
• et tu as préparé ton filet : second facteur sauvegardé, snapshot, configuration téléchargée.

Ce durcissement protège l’accès à l’administration d’OPNsense. Il ne corrige pas une règle de pare-feu trop permissive, il ne te protège pas si ton poste de travail est compromis, et il ne remplace pas les mises à jour régulières. Il retire la cible la plus évidente. C’est déjà beaucoup.

Retiens surtout ceci : chaque couche de sécurité que tu ajoutes est aussi une couche que tu dois pouvoir traverser. Un pare-feu durci dont tu as perdu les clés ne protège plus ton réseau, il t’en prive. C’est pour ça que le filet n’est pas une option en fin de tuto : c’est la moitié du travail.

Quand on héberge soi-même, personne ne réinitialise ton mot de passe par mail, et personne ne vérifie ton identité au téléphone. C’est le prix de l’indépendance, et c’est aussi sa valeur : les clés de ton réseau sont entre tes mains, et seulement entre tes mains.

Ta tech, tes règles, ta liberté.

Sources

• OPNsense, documentation officielle : Two-factor authentication
• OPNsense, documentation officielle : Settings, section Administration (Secure Shell, Console, Authentication)
• OPNsense, documentation officielle : Local Users & Groups
• Proton : Proton Authenticator support (sauvegarde, synchronisation, export)
• IETF : RFC 6238, TOTP: Time-Based One-Time Password Algorithm
• Tests réalisés sur OPNsense 26.7 et Proxmox VE 9.2 (septembre 2026) : console avec et sans TOTP, connexion root désactivé, snapshot et rollback.