Sécuriser le WAF de Sophos Firewall avec MFA

Avec Sophos Firewall WAF MFA, vous pouvez sécuriser davantage les applications Web publiées via le Web Application Firewall avec une authentification multi-facteurs. Cela est particulièrement utile pour les portails internes, les interfaces d’administration, les espaces clients ou les accès partenaires qui doivent être accessibles via HTTPS mais ne doivent pas être protégés uniquement par l’application elle-même.

Le WAF-MFA ne remplace pas une application sécurisée, une gestion des correctifs ou un concept de droits d’accès bien défini. Il s’agit d’une couche de protection en amont sur le pare-feu. Le pare-feu vérifie d’abord la connexion et le second facteur avant de rediriger l’accès vers le serveur Web protégé.

Pour la publication de base d’un serveur Web via WAF, suivez d’abord les instructions de Sophos Firewall WAF : Publier un serveur Web en toute sécurité. Cet article se concentre sur l’authentification en amont et le MFA.

Quand le WAF-MFA est-il pertinent ?

Le WAF-MFA est particulièrement puissant lorsque qu’une application Web doit être accessible depuis Internet mais n’est pas destinée à tous les visiteurs.

Cas d’utilisation typiques :

• portails internes avec accès externe
• interfaces d’administration d’applications spécialisées
• portails partenaires ou clients avec un cercle d’utilisateurs restreint
• applications Web héritées sans MFA robuste propre
• applications nécessitant une protection d’accès supplémentaire avant le backend

Pour les sites Web publics, les boutiques ou les pages d’information, le WAF-MFA n’est généralement pas adapté, car chaque visiteur verrait d’abord une connexion au pare-feu. Pour les applications privées complexes, ZTNA, SSE ou un proxy inverse dédié peuvent être plus appropriés que le WAF-MFA. Si WebDAV est nécessaire, il faut être particulièrement prudent : le WAF de Sophos ne prend pas en charge WebDAV de manière fiable, ce qui peut être pertinent pour des applications comme Nextcloud.

Quand le WAF-MFA ne suffit pas

Le WAF-MFA est une couche d’accès en amont. Cette couche ne répond pas à toutes les questions d’architecture. Surtout pour les portails critiques, il faut décider consciemment si l’application doit être accessible publiquement.

Si un portail reste accessible dans le monde entier, le MFA ne doit pas être la seule mesure. Les réseaux sources fixes, la limitation par pays, les Threat Feeds, les profils de protection et les correctifs backend propres réduisent également le risque.

Prérequis

Avant la configuration, ces points doivent être clarifiés :

• L’application Web est déjà planifiée ou publiée via une règle WAF.
• Les utilisateurs ou groupes sont présents sur le pare-feu, par exemple localement, via AD, LDAP ou RADIUS.
• Les utilisateurs peuvent configurer leur token OTP.
• L’heure système du pare-feu est correcte et NTP fonctionne.
• HTTPS avec un certificat approprié est utilisé pour la règle WAF.
• Il est clair si le serveur Web backend nécessite sa propre authentification ou si le pare-feu doit prendre en charge la connexion entièrement.
• Un utilisateur de test et un accès de secours administratif sont disponibles.

⚠️ Le MFA pour WAF doit d’abord être testé avec un groupe pilote. Une mauvaise combinaison de groupe MFA, de politique d’authentification WAF et d’authentification backend peut exclure des utilisateurs légitimes ou rendre une application apparemment “cassée”.

Planification du pilote, du fallback et des responsabilités

Le WAF-MFA agit avant l’application elle-même. Par conséquent, le déploiement ne doit pas être traité comme une règle de pare-feu normale, mais comme une modification du processus de connexion de l’application. Les utilisateurs voient d’abord la connexion du Sophos Firewall et ensuite, selon le backend, l’application elle-même.

Avant l’activation, ces points doivent être établis :

• Quel groupe d’utilisateurs teste en premier ?
• Qui peut désactiver l’accès si la connexion échoue ?
• Existe-t-il un deuxième accès administrateur qui ne dépend pas de la même règle WAF, du même portail ou du même utilisateur de test ?
• Quelles parties de l’application doivent être testées après une connexion réussie ?
• Qui vérifie reverseproxy.log, Log Viewer et les logs backend en cas d’erreurs ?
• Comment les utilisateurs sont-ils informés sur le token, l’expiration de session et une éventuelle deuxième connexion backend ?

Une erreur de planification fréquente est la confusion entre l’authentification du pare-feu et l’authentification backend. Le WAF peut vérifier les utilisateurs avant le backend. Cela ne signifie pas automatiquement que l’application elle-même n’a plus besoin de sa propre connexion, vérification des rôles ou gestion des sessions. Surtout pour les portails administratifs et les données clients, les autorisations backend doivent être consciemment maintenues.

Si le service publié est destiné à peu de personnes, il faut restreindre les sources en plus du MFA. Pour la publication de base et la limitation des sources, consultez Sophos Firewall WAF : Publier un serveur Web en toute sécurité. Si des droits d’utilisateur ou un MFA d’accès à distance sont généralement planifiés, consultez Activer le MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access.

Un rollback doit être préparé avant l’activation. En pratique, cela signifie : documenter l’ancienne méthode d’accès fonctionnelle, nommer la règle WAF et la politique d’authentification, désigner la personne responsable et choisir un moment où le retour d’utilisateur et la vérification des logs sont possibles. Si l’application est critique pour l’entreprise, le WAF-MFA doit d’abord être activé pour un domaine de test, un groupe pilote ou une fenêtre de maintenance.

Éléments de la configuration

Pour le WAF-MFA, plusieurs paramètres doivent être compatibles :

La différence la plus importante : le MFA n’est pas activé uniquement globalement. La règle WAF concernée doit également utiliser une politique d’authentification appropriée.

Activer le MFA pour le WAF

Le chemin de menu est :

Authentication > Multi-factor authentication

Procédure :

1. Sous One-time password (OTP), sélectionnez soit All users soit Specific users and groups.
2. Pour Specific users and groups, ajoutez les utilisateurs ou groupes concernés.
3. Activez Generate OTP token with next sign-in si les utilisateurs doivent configurer leur token lors de la prochaine connexion.
4. Sous Require MFA for, activez l’option Web application firewall.
5. Enregistrez la configuration.

Si les utilisateurs doivent configurer leur token eux-mêmes, ils doivent avoir accès à un portail où le code QR est affiché. Dans de nombreux environnements, cela concerne le User Portal ou le VPN Portal. La planification générale du MFA est décrite dans Activer le MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access.

Préparer le déploiement des tokens et la communication avec les utilisateurs

Le WAF-MFA échoue souvent en exploitation non pas à cause de la règle WAF elle-même, mais à cause du déploiement des tokens. Les utilisateurs doivent savoir où le code QR apparaît, quelle application utiliser, combien de temps une session est valide et si une deuxième connexion à l’application suit après la connexion au pare-feu.

Avant d’activer la règle WAF en production, il faut déterminer :

Si Generate OTP token with next sign-in est utilisé, la première connexion doit être testée de manière contrôlée. Il est important de vérifier si les utilisateurs voient le code QR dans le portail attendu et s’ils peuvent ensuite accéder à l’application WAF avec le mot de passe plus l’OTP. Les portails eux-mêmes sont décrits dans Sophos Firewall Portals : WebAdmin, User Portal et VPN Portal.

Pour le helpdesk et l’exploitation, il doit être documenté au minimum :

• nom d’hôte publié de l’application WAF
• groupe d’utilisateurs concerné
• politique d’authentification utilisée
• algorithme OTP utilisé
• application d’authentification autorisée
• procédure de réinitialisation du token
• message attendu en cas de mot de passe ou OTP incorrect
• emplacements des logs pour la première vérification : Log Viewer et reverseproxy.log

Surtout pour les partenaires externes ou les portails rarement utilisés, la première connexion ne doit pas se faire en cas d’urgence en production. Un court pilote avec des utilisateurs normaux révèle souvent des problèmes que les administrateurs ne voient pas dans leur propre test : application d’authentification différente, accès au portail manquant, deuxième connexion backend non claire ou délais d’expiration de session trop courts pour l’application.

Créer une politique d’authentification WAF

Le chemin de menu est :

Web server > Authentication policies

Pour le WAF-MFA, le mode client doit être réglé sur Form. Avec l’authentification basée sur formulaire, le pare-feu peut gérer la connexion via un formulaire et des sessions.

Procédure :

1. Ouvrez Add.
2. Donnez un nom explicite, par exemple WAF_MFA_Portal_Users.
3. Pour Mode, sélectionnez l’option Form.
4. Sélectionnez un Authentication template approprié.
5. Sélectionnez les utilisateurs ou groupes qui auront accès à cette publication WAF.
6. Choisissez consciemment le Authentication forwarding mode.
7. Réglez le Session timeout et le Session lifetime en fonction de l’application.
8. Enregistrez.

Choisir correctement le transfert d’authentification

Le Authentication forwarding mode détermine ce qui se passe entre le pare-feu et le backend.

Si l’application n’a pas besoin de sa propre authentification ou si la connexion au pare-feu en amont suffit, None est souvent plus propre. Si le backend lui-même attend une authentification HTTP Basic, le mode de transfert doit correspondre à l’application.

⚠️ L’authentification de base ne doit être utilisée qu’avec HTTPS. De plus, il doit être clair si le backend doit réellement traiter les données de connexion transmises par le pare-feu.

Utiliser la politique d’authentification dans la règle WAF

La règle WAF est modifiée sous Rules and policies > Firewall rules. L’action est Protect with web server protection.

Dans la règle WAF concernée, ces points doivent être compatibles :

• Adresse Hosted address et port d’écoute corrects.
• Domaine correct et certificat HTTPS approprié.
• Serveur Web protégé correct.
• Politique d’authentification souhaitée sélectionnée.
• Le groupe d’utilisateurs dans la politique d’authentification correspond au groupe MFA.
• Les restrictions d’accès via Allowed client networks, pays ou Threat Feeds sont consciemment définies.

Pour les portails publics ou fortement exposés, le MFA ne doit pas être la seule mesure de protection. La limitation par pays et par source est décrite dans Sophos Firewall : Bloquer les pays et les IP malveillantes. Pour les listes de blocage dynamiques, consultez Sophos Firewall Threat Feeds.

Planifier les sessions et les délais d’expiration

Avec l’authentification WAF basée sur formulaire, le pare-feu fonctionne avec des sessions. Dans la politique d’authentification, vous définissez :

• Session timeout : après quelle inactivité les utilisateurs doivent se reconnecter
• Session lifetime : combien de temps une connexion reste valide au maximum

De plus, sous Web server > General settings, il y a le nombre maximal de sessions simultanées pour l’authentification par proxy inverse basée sur formulaire. La valeur par défaut est 25,000, la plage prise en charge est de 100 à 100,000.

Des sessions courtes augmentent la sécurité, mais peuvent déranger les utilisateurs. Des sessions très longues sont plus pratiques, mais augmentent le risque qu’un accès navigateur volé ou partagé reste utilisable plus longtemps. Pour les portails administratifs, il est préférable de commencer de manière conservatrice et d’observer le comportement en exploitation.

Algorithme OTP et application d’authentification

SFOS 22 prend en charge, en plus de SHA1, SHA256 et SHA512 pour les tokens OTP. Cela est judicieux du point de vue de la sécurité, mais ne fonctionne que si l’application d’authentification utilisée prend en charge l’algorithme choisi.

Points importants :

• SHA256 ou SHA512 sont plus sûrs que SHA1.
• Toutes les applications d’authentification ne prennent pas en charge ces algorithmes dans ce contexte.
• Microsoft Authenticator peut scanner le code QR avec SHA256 ou SHA512, mais la connexion peut échouer ensuite.
• Si l’algorithme est modifié, les anciens tokens doivent être supprimés et rescannés.

Pour les déploiements en production, il est conseillé de tester l’application souhaitée et l’algorithme avec un petit groupe pilote. Ce n’est qu’ensuite que les utilisateurs existants devraient être largement migrés.

Plan de test après la configuration

Après la configuration, il ne suffit pas de vérifier si la page de connexion apparaît. Il est important de tester le chemin d’accès complet.

1. Utilisez un navigateur externe ou un réseau de test externe.
2. Ouvrez l’URL WAF avec un utilisateur du groupe autorisé.
3. Testez la connexion avec le mot de passe correct et l’OTP.
4. Testez la connexion avec un OTP incorrect.
5. Testez un utilisateur en dehors du groupe autorisé.
6. Vérifiez l’expiration de la session après inactivité.
7. Vérifiez la fonction backend de l’application.
8. Vérifiez le Log Viewer et reverseproxy.log pour les anomalies.

Pour les fichiers journaux, consultez Dépannage Sophos Firewall : Services et logs. Les événements WAF sont généralement liés au Reverse Proxy et apparaissent également dans le Log Viewer.

Pour l’acceptation, chaque cas de test doit être associé à un résultat visible :

Si seul le navigateur semble réussir, mais qu’aucun log approprié n’est visible, l’acceptation est incomplète. Il faut alors vérifier si la bonne règle WAF correspond, si la politique d’authentification est vraiment active et si les logs arrivent à l’endroit attendu.

Mise en service et exploitation après l’activation

Après un test réussi, le WAF-MFA ne doit pas simplement être activé à grande échelle puis oublié. Les premières heures après la mise en service sont importantes, car les utilisateurs réels apportent d’autres navigateurs, d’autres applications d’authentification, des mots de passe enregistrés, des favoris anciens et d’autres états de session que le test administrateur.

Pour la mise en service, un petit plan d’exploitation est conseillé :

Pour les applications critiques pour l’entreprise, la mise en service ne doit pas être programmée à un moment où personne ne peut vérifier correctement les problèmes de connexion. Il est préférable d’avoir une fenêtre contrôlée avec des utilisateurs de test de différents groupes, suivie d’une courte révision des logs et seulement ensuite l’extension à d’autres utilisateurs.

Après quelques jours, la configuration doit être vérifiée à nouveau :

• Y a-t-il des utilisateurs qui contournent le MFA parce qu’ils accèdent via une autre règle WAF ou une autre URL ?
• L’accès est-il toujours autorisé uniquement pour les groupes prévus ?
• La durée de session et le timeout d’inactivité correspondent-ils à l’application ?
• Les connexions refusées et les problèmes de token sont-ils réellement vus en exploitation ?
• Y a-t-il des cas de support qui indiquent une communication utilisateur peu claire ou une mauvaise application d’authentification ?
• Les anciennes règles de test, les domaines de test ou les exceptions temporaires ont-ils été supprimés ?

Ce suivi est particulièrement important si plusieurs noms d’hôte, chemins ou règles WAF pointent vers la même application. Sinon, il peut arriver qu’un chemin soit correctement protégé par MFA, mais qu’un deuxième chemin reste accessible sans authentification en amont.

Erreurs typiques

Dépannage

Le MFA n’est pas demandé

Vérifiez d’abord si Web application firewall sous Require MFA for est activé. Ensuite, vérifiez si la règle WAF utilise vraiment une politique d’authentification et si cette politique contient les utilisateurs ou groupes attendus.

La connexion fonctionne, mais l’application ne s’ouvre pas

Le problème se situe souvent après la connexion au pare-feu. Vérifiez l’accessibilité du backend, le certificat, l’en-tête d’hôte, le chemin, la politique de protection et le transfert d’authentification. Si le backend attend sa propre authentification, le mode de transfert doit y correspondre.

L’utilisateur ne peut pas se connecter après un changement d’algorithme

Si vous êtes passé de SHA1 à SHA256 ou SHA512, les tokens existants doivent être supprimés et rescannés. De plus, l’application d’authentification doit prendre en charge le nouvel algorithme.

Le mot de passe et l’OTP sont transmis au backend

Pour le WAF-MFA, vérifiez si la version du pare-feu est à jour. Les notes de version SFOS-22.0 documentent un bug WAF corrigé où le code OTP n’était pas retiré du mot de passe avant que les données ne soient transmises au backend.

Trop de sessions ou sessions anciennes

Vérifiez le timeout de session, la durée de session et les paramètres globaux de session WAF. En environnements de production, il doit être clair si des sessions longues sont souhaitées ou si les utilisateurs doivent se réauthentifier rapidement après inactivité.

Liste de contrôle

• La règle WAF est documentée et testée en externe.
• Le certificat HTTPS correspond au nom d’hôte publié.
• Le MFA s’applique au bon groupe d’utilisateurs.
• Require MFA for > Web application firewall est activé.
• La politique d’authentification WAF utilise Form.
• Le transfert d’authentification correspond à l’application backend.
• Le déploiement de tokens, l’accès au portail et la procédure du helpdesk sont préparés.
• Le timeout de session et la durée de session sont définis consciemment.
• L’application OTP et l’algorithme de hachage ont été testés.
• L’accès administrateur de secours est disponible.
• Le rollback et la personne responsable sont documentés.
• La source d’authentification et la connexion backend ont été vérifiées séparément.
• Le Log Viewer et reverseproxy.log ont été vérifiés après le test.
• La fenêtre de support de mise en service et la procédure de réinitialisation de token sont définies.
• Les noms d’hôte alternatifs, chemins et règles WAF ont été vérifiés pour éviter le contournement du MFA.
• Les exceptions temporaires du pilote ont été supprimées après le déploiement.

Questions fréquentes