Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access

Pour la fonction OTP locale, on ouvre Authentication > Multi-factor authentication, on sélectionne d’abord Specific users and groups, on active les services nécessaires et on teste l’ensemble avec un groupe pilote. All users ne doit être utilisé qu’après la réussite des tests.

MFA protège WebAdmin, VPN Portal et l’accès à distance contre l’utilisation d’un mot de passe volé comme seul moyen d’authentification. Cette protection ne remplace toutefois ni des règles d’accès restrictives ni un accès d’urgence testé. Cet article couvre donc l’activation sécurisée, le choix de l’application, la récupération et le dépannage.

La procédure principale configure le Sophos OTP local. RADIUS et Entra ID SSO sont comparés plus loin comme solutions alternatives.

Activer Sophos OTP en toute sécurité

Avant l’activation

Avant toute modification, les points suivants doivent être clarifiés :

• Le pare-feu utilise une heure correcte sous Administration > Time, idéalement via NTP.
• Les utilisateurs et les groupes sont disponibles localement ou par AD, LDAP ou un autre serveur d’authentification.
• Un groupe pilote et un second administrateur testé existent.
• La console et la procédure de récupération du admin par défaut sont connues.
• Une sauvegarde récente et une procédure documentée de réinitialisation des tokens sont disponibles.

Pour un Active Directory classique, Ajouter Active Directory à Sophos Firewall explique la configuration de la source d’utilisateurs.

Sous Administration > Device access, on définit les zones depuis lesquelles WebAdmin, User Portal, VPN Portal et les autres services locaux sont accessibles. Les Local service ACL exception rules limitent encore l’accès aux réseaux de gestion, aux réseaux VPN ou aux adresses sources connues. Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access détaille ce durcissement.

SSH ne fait pas partie des services protégés par Sophos OTP. Il doit être limité par Device Access et utiliser si possible une clé publique ; la procédure est décrite dans Se connecter à Sophos Firewall par SSH.

⚠️ MFA réduit le risque lié aux mots de passe compromis, mais ne diminue pas la surface d’attaque d’un service accessible publiquement. WebAdmin, SSH et les portails ne doivent jamais être exposés plus largement que nécessaire.

Avant les tests négatifs, on vérifie également Administration > Admin and user settings > Login security > Block login. Plusieurs échecs volontaires peuvent bloquer l’adresse IP source pour WebAdmin, CLI, VPN Portal et User Portal, et ainsi exclure aussi un administrateur de secours utilisant le même réseau. Une seconde source ou l’accès à la console doit donc être disponible.

Configurer MFA pour un groupe pilote

1. Se connecter à WebAdmin et ouvrir Authentication > Multi-factor authentication.
2. Sous One-time password (OTP), sélectionner d’abord Specific users and groups.
3. Ouvrir Add users and groups, sélectionner le groupe pilote et appliquer la sélection.
4. Activer Generate OTP token with next sign-in si une application d’authentification est utilisée.
5. Sous Require MFA for, sélectionner uniquement les interfaces de connexion réellement nécessaires.
6. Sous OTP hash algorithm, choisir un algorithme pris en charge par l’application prévue.
7. Ne modifier les paramètres facultatifs OTP timestep settings que si l’application accepte le même pas de temps ; la valeur par défaut est de 30 secondes.
8. Enregistrer avec Apply.

Après Apply, un utilisateur pilote termine immédiatement la procédure : selon le service sélectionné, il se connecte d’abord à User Portal ou VPN Portal avec son seul mot de passe, enregistre le code QR ou la clé Base32 dans l’application d’authentification, puis ouvre une nouvelle session avec <password><passcode>. Un code volontairement incorrect doit être refusé et la tentative doit apparaître dans Log viewer. All users ne peut être envisagé qu’après ce test positif et négatif.

Les options utilisateur signifient :

• No OTP: MFA est désactivée.
• All users: MFA s’applique à tous les utilisateurs ; à utiliser seulement après le pilote.
• Specific users and groups: MFA s’applique uniquement aux comptes ou groupes sélectionnés.

Pour les utilisateurs authentifiés par un serveur externe, le retrait d’un groupe MFA ne prend pas effet immédiatement lors de la première connexion suivante. Sophos exige encore une connexion avec MFA ; l’OTP ne disparaît que lors des connexions ultérieures. Une modification de groupe est donc vérifiée avec une nouvelle session et au moins deux connexions contrôlées.

Lorsque Generate OTP token with next sign-in est activé, les utilisateurs enregistrent une application logicielle lors de leur prochaine connexion. User Portal est alors automatiquement sélectionné comme service MFA. Lorsque cette option est désactivée, les tokens matériels ou gérés manuellement sont attribués sous Issued tokens.

Choisir les services de manière réfléchie

Sous SFOS 22, les services suivants sont disponibles sous Require MFA for :

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

MFA pour User Portal s’applique également à Captive Portal et aux Client Authentication Agents. Les utilisateurs d’accès à distance doivent d’abord enregistrer leur token via VPN Portal ou User Portal.

Pour WAF, la sélection du service ne suffit pas. À partir de SFOS 22, Webserver Protection, une Authentication Policy basée sur un formulaire et son affectation à la règle WAF sont nécessaires. La procédure complète est décrite dans Sécuriser Sophos Firewall WAF avec MFA.

Choisir le modèle MFA adapté

Sophos OTP local

Sophos OTP gère les tokens directement sur le pare-feu et ne nécessite aucune infrastructure RADIUS ou de fournisseur d’identité supplémentaire. Il convient particulièrement aux utilisateurs locaux normaux, aux petits environnements et au durcissement rapide de WebAdmin ou de l’accès à distance.

La contrepartie d’un déploiement simple est un token distinct des processus Microsoft 365 existants. Les utilisateurs et le support doivent connaître l’enregistrement de l’application, la saisie du mot de passe plus OTP et la procédure de changement d’appareil.

RADIUS ou Entra ID SSO

Une plateforme MFA existante peut mieux s’intégrer à la gestion centralisée des identités via RADIUS ou SSO. Elle requiert toutefois des tests propres à chaque service :

• VPN Portal ne prend pas en charge RADIUS avec MFA par challenge.
• Sophos Connect ne prend pas en charge les challenges OTP. Le client envoie ensemble le mot de passe et l’OTP au format passwordotp, mais prend en charge MFA par appel et notification push.
• User Portal et WebAdmin prennent également en charge MFA par challenge.
• Avec Entra ID SSO, MFA s’effectue chez le fournisseur d’identité ; la MFA Sophos OTP locale ne peut pas être ajoutée à la même connexion SSO.
• Entra SSO avec Sophos Connect exige au minimum la version 2.4 du client sous Windows. WebAdmin SSO n’est pas disponible sur l’appareil auxiliaire HA.

Pour l’accès à distance, consulter le guide dédié Configurer Microsoft Entra ID SSO pour Sophos Connect et VPN Portal. Si Entra doit plutôt contrôler la connexion WebAdmin et les rôles d’administrateur, Entra ID SSO pour WebAdmin de Sophos Firewall décrit le Role mapping, le moindre privilège, la connexion pilote et l’accès local de secours.

Sophos Connect ou SSL VPN : quelle solution choisir ? aide à choisir le modèle d’accès à distance ; avant le déploiement, il faut également vérifier la version du client Sophos Connect.

Quel que soit le modèle, on commence par un groupe pilote. Les autres utilisateurs ne sont ajoutés qu’après validation de WebAdmin, des portails, des véritables clients VPN, des groupes, des délais d’attente, des journaux et de la solution de secours.

Configurer les tokens et l’application d’authentification

Enregistrer et gérer les tokens

Lorsque Generate OTP token with next sign-in est activé, l’utilisateur se connecte à VPN Portal ou User Portal et scanne le code QR. Les administrateurs peuvent également enregistrer le token dans WebAdmin si MFA y est imposé. Le code QR n’apparaît que pour les utilisateurs et groupes auxquels MFA est appliqué.

Sous Authentication > Multi-factor authentication > Issued tokens, les tokens émis peuvent être contrôlés, désactivés temporairement, supprimés ou ajoutés manuellement. On peut également y générer des codes à usage unique supplémentaires et vérifier ou synchroniser le décalage horaire d’un token.

En cas de perte du smartphone ou de changement d’application, l’ancien token est supprimé après vérification de l’identité de l’utilisateur. Celui-ci se connecte ensuite une fois au portail avec son seul mot de passe et enregistre le nouveau code QR affiché. Un ancien token ne doit pas continuer à exister en parallèle sans contrôle.

Provisionner manuellement un token matériel ou logiciel

Si le pare-feu ne doit pas générer de code QR, Generate OTP token with next sign-in reste désactivé. Les tokens déjà enregistrés continuent de fonctionner ; pour les nouveaux utilisateurs, le seed est saisi manuellement sous Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). Le libellé du bouton est plus restrictif que sa fonction, car la même boîte de dialogue permet également de provisionner manuellement un token logiciel.

Sélectionner d’abord OTP hash algorithm et le timestep requis par le token concerné ou l’application d’authentification utilisée. Les règles suivantes s’appliquent à Secret :

• Pour un token matériel, saisir la clé individuelle fournie par le fabricant.
• Pour un token logiciel, utiliser un seed hexadécimal unique et suffisamment aléatoire. Si l’application exige Base32, convertir localement ce seed avec un outil hors ligne contrôlé.
• Un seed de production ne doit jamais être saisi sur un site public de conversion ni placé dans un ticket, un e-mail non chiffré ou une commande shell conservée dans l’historique. Toute personne connaissant le seed peut générer des codes OTP valides.

Si le token concerné diffère du Default token timestep global, activer Use custom timestep uniquement pour ce token et saisir l’intervalle qu’il prend réellement en charge. Sans cette option, la valeur globale s’applique ; vérifier la compatibilité de l’application et du matériel avant d’enregistrer.

Sélectionner ensuite l’utilisateur prévu avec précision et enregistrer avec Save. Le token matériel ou le seed Base32 est remis une seule fois par un canal protégé. Tester ensuite un code correct et un code volontairement incorrect, puis synchroniser si nécessaire le décalage horaire sous Issued tokens. Si le seed a pu être divulgué, ne pas continuer à utiliser le token : le supprimer et en attribuer un avec un nouveau seed.

Distribuer des codes à usage unique supplémentaires de manière contrôlée

Si l’accès à l’application ou au token matériel est temporairement indisponible, modifier l’utilisateur concerné sous Authentication > Multi-factor authentication > Issued tokens. Sous Additional codes, le bouton plus génère des codes supplémentaires ; Save les associe au token. Le pare-feu supprime automatiquement chaque code de la liste après son utilisation.

Vérifier l’identité de l’utilisateur avant de distribuer les codes. Les remettre une seule fois par un canal protégé exclusivement à cet utilisateur et ne pas les placer ensemble dans un ticket ou un e-mail non protégé. Les codes supplémentaires ne remplacent pas le renouvellement d’un token définitivement perdu ou potentiellement copié : supprimer l’ancien token et en enregistrer un nouveau avec un nouveau seed.

L’application et l’algorithme de hachage doivent être compatibles

SFOS 22 prend en charge SHA1, SHA256 et SHA512. Sophos recommande SHA256 ou SHA512, mais l’application doit prendre en charge l’algorithme sélectionné :

• Sophos Intercept X for Mobile et Google Authenticator prennent en charge SHA256 et SHA512.
• Microsoft Authenticator ne prend pas en charge ces deux algorithmes dans ce flux Sophos. Le scan du code QR peut réussir, mais la connexion échoue ensuite.
• Duo Mobile et Okta Verify figurent parmi les applications citées par Sophos ; leur compatibilité avec le code QR et l’algorithme doit correspondre au système d’exploitation et à la configuration utilisés.
• Les autres applications TOTP ne sont approuvées qu’après un véritable test pilote.

Sophos Intercept X for Mobile prend en charge un timestep personnalisé pour les tokens. La plupart des autres applications d’authentification ne prennent en charge que la valeur par défaut de 30 secondes ; la valeur globale n’est donc pas modifiée uniquement pour une application.

Sous iOS, le code QR Sophos ne peut pas être scanné avec Google Authenticator, Duo Mobile ou Microsoft Authenticator. Le compte doit être créé manuellement à l’aide de la clé Base32 affichée. Okta Verify exige un enregistrement Base32 manuel sous iOS et Android. Cela ne résout toutefois pas l’absence de prise en charge de SHA256/SHA512 par Microsoft Authenticator.

L’ancienne application Sophos Authenticator est arrivée en fin de vie le 31 juillet 2022 et ne doit plus être prévue pour les nouveaux déploiements.

Après une mise à niveau depuis une version antérieure à SFOS 22, il faut s’attendre à trouver des tokens SHA1, car les versions précédentes de SFOS généraient les tokens MFA avec SHA1. La sélection d’un algorithme global plus robuste ne convertit pas ces tokens existants.

Pour migrer de SHA1 vers un algorithme plus robuste :

1. Tester l’application pilote avec SHA256 ou SHA512.
2. Activer Generate OTP token with next sign-in.
3. Sélectionner le nouvel algorithme sous Authentication > Multi-factor authentication.
4. Enregistrer avec Apply.
5. Supprimer les anciens tokens SHA1 sous Issued tokens.
6. Demander aux utilisateurs de se connecter avec leur seul mot de passe et d’enregistrer à nouveau le code QR ou la clé Base32.
7. Effectuer des tests de connexion contrôlés avec un code correct et un code incorrect.

Des tokens utilisant des algorithmes différents peuvent coexister pendant la migration. Les tokens qui ne sont pas supprimés continuent toutefois d’utiliser leur ancien algorithme.

Limiter le timestep et les fenêtres de tolérance

Sous OTP timestep settings, on configure non seulement l’intervalle des nouveaux codes, mais aussi deux fenêtres de vérification. Les trois valeurs ont des effets différents :

• Default token timestep définit l’intervalle auquel l’application ou le token matériel génère un nouveau code. La valeur par défaut est de 30 secondes. Une modification s’applique uniquement aux nouveaux tokens et ne change pas les tokens existants.
• Maximum verification code offset détermine pendant combien de pas de temps un code non utilisé reste valide. Avec la valeur par défaut 2 et un pas de 30 secondes, les codes non utilisés des 60 secondes précédentes sont également acceptés.
• Maximum initial verification code offset s’applique au premier code après le scan du code QR. Avec la valeur par défaut 10 et un pas de 30 secondes, la fenêtre est de 300 secondes si le code n’a pas encore été utilisé.

Ces fenêtres ne remplacent pas une heure correcte. Vérifier d’abord le NTP du pare-feu et l’heure du terminal, puis conserver chaque décalage aussi faible que possible avec les applications et tokens matériels utilisés. Une fenêtre plus large accepte plus longtemps un code intercepté encore inutilisé. Après une modification, tester un nouveau token pilote ; ne pas supposer qu’un token existant utilise le timestep modifié.

Saisir correctement le mot de passe et l’OTP

Pour les connexions Sophos OTP natives, le format officiel est <password><passcode>, sans espace ni séparateur.

Exemple :

Mot de passe : MonMotDePasseSecurise
Code OTP :     123456
Saisie :       MonMotDePasseSecurise123456

Sophos Connect peut afficher un troisième champ distinct au moyen de otp: true. Le client ajoute le code au mot de passe en interne. Cette présentation ne modifie pas le format envoyé au serveur d’authentification.

Sécuriser et restaurer l’administrateur par défaut

Activer MFA pour l’admin par défaut

L’utilisateur local admin par défaut n’est pas activé via la liste normale des utilisateurs. On ouvre Administration > Device access, on active MFA for default admin, puis on y configure le token matériel ou logiciel.

Au préalable, le second administrateur, l’accès de gestion et l’accès à la console doivent fonctionner. Les codes à usage unique supplémentaires sont conservés de manière sûre, par exemple dans un gestionnaire de mots de passe. Le compte admin par défaut reste un compte d’urgence et ne sert pas à l’administration quotidienne.

Les autres administrateurs ne peuvent ni activer, ni désactiver, ni modifier, ni supprimer le token du compte admin par défaut. L’OTP hash algorithm global sélectionné s’applique également à ce token.

Récupération via la Device Console

Les options de menu 6 et 7 apparaissent uniquement si MFA for default admin a déjà été configuré sous Administration > Device access. Si elles sont absentes, ne pas conclure automatiquement à une erreur de console ; vérifier d’abord ce paramètre et que le compte est bien l’utilisateur default admin. Ces options ne s’appliquent pas aux autres comptes administrateur.

Si le token est seulement temporairement indisponible, la Device Console permet une connexion unique sans MFA :

1. Saisir 2 pour System Configuration.
2. Saisir 6 pour Skip multi-factor authentication for next Admin user login.
3. Se connecter à WebAdmin et contrôler le token.

En cas de perte de l’appareil ou de token définitivement inutilisable, on réinitialise MFA :

1. Saisir 2 pour System Configuration.
2. Saisir 7 pour Reset multi-factor authentication for Admin user.
3. Confirmer avec y.
4. Se connecter une fois à WebAdmin avec le seul mot de passe administrateur.
5. Suivre les instructions pour enregistrer à nouveau MFA, puis retester une connexion avec MFA.

Ces deux options modifient uniquement l’état de MFA. Si le mot de passe du compte administrateur par défaut est également inconnu, l’article séparé sur la récupération du mot de passe explique la procédure série documentée pour les appliances physiques et les limites en cas de perte simultanée du mot de passe et de MFA.

Tester, contrôler les journaux et déployer

Tester chaque service séparément

Une connexion réussie à WebAdmin ne prouve pas que les portails et les clients VPN fonctionnent de la même manière. Avant un déploiement général, on teste :

• WebAdmin: Connexion de l’administrateur pilote avec un OTP correct, puis volontairement incorrect.
• Default admin: Vérification du chemin Device Access distinct et de la procédure de récupération documentée.
• User Portal et VPN Portal: Enregistrement par QR ou Base32 et connexion avec <password><passcode>.
• SSL VPN et IPsec Remote Access: Test de véritables clients et du groupe d’utilisateurs exactement utilisé en production.
• Sophos Connect: Le cas échéant, test du troisième champ OTP, des profils client actuels et du comportement appel/push.
• RADIUS ou Entra SSO: Vérification des délais d’attente, des journaux IdP et du comportement de challenge réellement pris en charge.
• Device Access: Test depuis un réseau source autorisé et un réseau non autorisé.

Le nombre d’échecs volontaires reste limité après vérification de Block login. Le résultat attendu ne se résume pas à une connexion réussie : un code incorrect doit être rejeté, la tentative doit être journalisée et le service doit être accessible uniquement depuis les réseaux prévus.

Lire correctement les journaux d’authentification

Dans Log viewer, on examine les connexions réussies et échouées avec le service, l’utilisateur, la source, l’heure et la raison documentée. Selon l’événement, SFOS peut ne fournir qu’un message générique tel que des identifiants incorrects. Sans preuve supplémentaire, on ne doit pas en déduire que le mot de passe, l’OTP ou un code expiré est à lui seul responsable.

Avec une MFA externe, les journaux RADIUS, NPS ou IdP font partie de la même vérification. Dépannage Sophos Firewall : services et journaux aide à identifier les fichiers journaux locaux et les services. Pour une conservation plus longue et la corrélation, consulter Envoyer le Syslog Sophos Firewall vers un SIEM.

Avant le déploiement général

• Groupe pilote testé avec succès pour tous les services nécessaires.
• Second administrateur, codes à usage unique et récupération par Device Console documentés.
• Utilisateurs informés de l’enregistrement de l’application et de la saisie mot de passe plus OTP.
• Réinitialisation des tokens définie pour les smartphones perdus ou remplacés.
• Device Access, blocages de connexion et conservation centralisée des journaux contrôlés.
• Responsabilités, délais d’attente et solution de secours définis pour la MFA externe.

Dépannage

Token, code QR et saisie

Le code OTP n’est pas accepté

On compare d’abord l’heure du pare-feu et du smartphone, l’application utilisée, l’algorithme de hachage et le pas de temps. Sous Issued tokens, on peut vérifier et synchroniser le décalage horaire. Après une migration d’algorithme, l’ancien token doit avoir été supprimé et enregistré à nouveau.

Un changement de serveur NTP doit être planifié séparément, car le pare-feu reconnecte alors les tunnels IPsec existants.

Le code QR n’apparaît pas ou ne peut pas être scanné

L’utilisateur doit appartenir au groupe MFA sélectionné et se connecter à VPN Portal ou User Portal. Les administrateurs peuvent également s’enregistrer dans WebAdmin lorsque MFA y est actif. Le portail et la source doivent aussi être autorisés sous Administration > Device access.

Sous iOS ou avec Okta Verify, on utilise la clé Base32 plutôt que le scan du code QR lorsque les restrictions mentionnées s’appliquent.

La connexion signale un mot de passe incorrect

Pour une connexion Sophos OTP native, le mot de passe doit être immédiatement suivi du code. Sans champ OTP distinct, le mot de passe seul est incomplet.

Accès, groupes et accès à distance

Le portail n’est pas accessible

On contrôle d’abord la zone, la source et le service requis sous Administration > Device access. Une Local Service ACL Exception Rule restrictive est plus sûre qu’une autorisation WAN générale.

MFA ne s’applique pas à l’accès à distance

Les configurations MFA et Remote Access doivent utiliser le même groupe d’utilisateurs réellement importé. On réimporte ou redistribue ensuite le profil client et on teste la connexion avec le véritable client. Le token doit être enregistré via VPN Portal ou User Portal avant la première connexion VPN.

MFA ne s’applique qu’à certains utilisateurs

Il ne faut pas comparer uniquement les noms de groupes visibles, mais vérifier les groupes réellement associés par AD, LDAP, RADIUS ou Entra ID. Après le retrait d’un utilisateur AD d’un groupe MFA, une dernière connexion avec MFA peut encore être nécessaire ; seules les connexions suivantes n’exigent plus d’OTP.

Verrouillage et MFA externe

L’administrateur est verrouillé

Pour le compte admin par défaut, on utilise les options 6 ou 7 de la Device Console décrites plus haut. Pour un autre administrateur, on utilise le second administrateur préparé depuis une source autorisée, puis on contrôle les groupes, le token et l’état du blocage de connexion.

RADIUS ou Entra MFA ne fonctionne pas de manière fiable

On contrôle les délais d’attente RADIUS, les journaux IdP, les groupes et le comportement de challenge du service concerné. Un test réussi du serveur d’authentification ne prouve pas qu’une connexion de production via VPN Portal, Sophos Connect ou WebAdmin fonctionne. Chacun de ces chemins doit être testé séparément.