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.

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.

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.

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.

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.

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.

Pour migrer de SHA1 vers un algorithme plus robuste :

1. Tester l’application pilote avec SHA256 ou SHA512.
2. Sélectionner le nouvel algorithme sous Authentication > Multi-factor authentication.
3. Supprimer les anciens tokens SHA1 sous Issued tokens.
4. Demander aux utilisateurs de se connecter avec leur seul mot de passe et d’enregistrer à nouveau le code QR ou la clé Base32.
5. Effectuer des tests 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.

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

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.