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é.

La version est importante : le MFA intégré pour WAF est une fonction de SFOS 22. Sur des versions de firmware plus anciennes, les publications WAF doivent être planifiées avec d’autres architectures, par exemple une authentification externe, un reverse proxy dédié, VPN ou ZTNA.

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.

Utilisation et planification

Quand le WAF-MFA est-il pertinent ?

Le WAF-MFA est particulièrement puissant lorsqu’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. Sophos WAF ne prend pas en charge WebDAV ; les applications comme Nextcloud ne sont donc pas des publications WAF prises en charge. Prévoyez une autre architecture avec des règles de pare-feu adaptées et sa propre protection d’accès ; une publication sans WAF ne conserve pas automatiquement son authentification ni sa protection applicative.

Le WAF protège au niveau de la couche 7, notamment contre la manipulation des cookies, URL et formulaires. Le serveur web, la Protection Policy et la Authentication Policy sont associés via la règle WAF ; un maximum de 60 règles WAF est pris en charge. Le service WAF se gère sous System services > Services. Son redémarrage affecte les applications publiées et n’est pas la première réponse à un échec de connexion isolé.

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.

• L’application est destinée à quelques utilisateurs internes seulement : vérifiez VPN, ZTNA, réseaux sources fixes ou une publication non publique.
• L’application contient des données particulièrement sensibles : vérifiez également les autorisations backend, la journalisation, la piste d’audit et les sessions d’application.
• L’application nécessite WebDAV : choisissez une autre architecture ; un pilote ne transforme pas l’absence de prise en charge WAF en solution prise en charge. Pour d’autres protocoles spéciaux, vérifiez séparément la compatibilité avant le déploiement.
• Les partenaires externes accèdent rarement : documentez clairement le déploiement des tokens, le processus de support et le fallback.
• Le backend a sa propre connexion et ses rôles : considérez le WAF-MFA uniquement comme une couche supplémentaire, pas comme un remplacement des rôles backend.

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.
• Le pare-feu fonctionne avec SFOS 22 ou plus récent.
• 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.

Configuration

Éléments de la configuration

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

• Paramètre MFA : définit quels utilisateurs utilisent le MFA et si le Web application firewall est protégé.
• Politique d’authentification WAF : définit le mode de connexion, les utilisateurs/groupes, le modèle et le comportement de session.
• Règle WAF : lie le serveur Web publié à la politique d’authentification.
• Transfert d’authentification backend : définit si le pare-feu transmet les données de connexion au serveur Web.
• Déploiement de tokens : assure que les utilisateurs peuvent effectivement générer leur code OTP.

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. Définissez consciemment OTP hash algorithm et, si nécessaire, OTP timestep settings. Les valeurs par défaut sont 30 secondes pour Default token timestep, 2 pour Maximum verification code offset et 10 pour Maximum initial verification code offset.
6. Enregistrer la configuration.

Lorsque Generate OTP token with next sign-in est activé, User portal est sélectionné automatiquement. Les utilisateurs se connectent d’abord au VPN portal ou au User portal, puis y scannent le code QR. L’administrateur par défaut peut utiliser la console WebAdmin à la place lorsque le MFA est imposé pour sa connexion WebAdmin. Cette étape d’enrôlement doit fonctionner avant le premier accès WAF. La planification générale du MFA est décrite dans Activer le MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access.

Les deux valeurs d’offset ne constituent pas la solution normale à une horloge incorrecte. Avec un pas de 30 secondes, un Maximum verification code offset de 2 accepte par exemple un code encore inutilisé des 60 secondes précédentes. Une fenêtre plus large tolère davantage de décalage, mais prolonge aussi la validité d’anciens codes. Corrigez d’abord NTP et l’heure du téléphone, puis ne modifiez l’offset que pour une raison documentée.

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 :

• Création de token : où l’utilisateur configure-t-il le token OTP ?
• Accès au portail : le User Portal ou un autre chemin prévu vers le code QR est-il accessible aux utilisateurs concernés ?
• Application d’authentification : quelle application est approuvée et testée avec l’algorithme choisi ?
• Fallback : qui peut réinitialiser un token perdu ou défectueux ?
• Codes d’urgence : sait-on si, et comment, des passcodes uniques supplémentaires peuvent être émis en support ?
• Cas de support : de quelles informations le helpdesk a-t-il besoin en cas de problèmes de connexion ?
• Communication : quelle séquence de connexion les utilisateurs voient-ils à partir de la mise en service ?

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 de nombreux services du pare-feu, le code OTP est traité comme une combinaison du mot de passe et du passcode. La communication aux utilisateurs et le runbook du helpdesk doivent donc préciser quel écran de saisie les utilisateurs voient réellement et si le mot de passe et l’OTP doivent être saisis séparément ou combinés. Avec WAF-MFA et une connexion basée sur Form, ce point est particulièrement important, car une deuxième connexion backend est vite interprétée à tort comme un MFA défectueux.

Sophos Authenticator ne doit plus être planifié comme nouvelle application standard, car l’app est End of Life depuis 2022. En pratique, Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify ou une application validée en interne doivent être testés. Ce qui compte n’est pas seulement le nom de l’app, mais sa capacité à prendre correctement en charge l’algorithme choisi, le timestep et le QR code du pare-feu.

Le système mobile compte également lors du déploiement. Le scan du code QR dans l’application Okta ne fonctionne pas pour ces tokens, ni sous iOS ni sous Android. Sous iOS, cette restriction concerne aussi Google Authenticator, Duo et Microsoft Authenticator. Dans ces cas, l’utilisateur doit saisir manuellement le Base32 secret. Ajoutez cette étape au guide utilisateur : une configuration correcte du pare-feu peut sinon sembler défaillante si le runbook ne prévoit que le scan QR.

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. L’authentification par formulaire crée des cookies de session et permet une déconnexion dédiée ; le pare-feu gère la connexion via le formulaire et les 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.

La documentation de l’API XML de SFOS 23 décrit le paramètre facultatif RedirectToRequestedURL uniquement pour le mode client Form, avec les valeurs Enable et Disable. Avec Enable, l’utilisateur est redirigé vers l’URL initialement demandée après une authentification réussie. La documentation ne précise aucune valeur par défaut pour ce paramètre ; son nom dans l’API n’est pas un libellé de champ de l’interface graphique confirmé. La redirection ne remplace ni l’authentification ni la vérification des autorisations.

Choisir correctement le transfert d’authentification

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

• None : aucune authentification du backend par le pare-feu ; l’authentification en amont reste active. Pour supprimer un en-tête Basic fourni par le client, Remove basic header intervient également.
• Basic : le pare-feu transmet le nom d’utilisateur et le mot de passe au backend via HTTP Basic Authentication.

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.

Avec None, il faut aussi vérifier si Remove basic header doit être activé. Cela évite qu’un en-tête Basic Authentication envoyé par le client soit transmis inutilement au serveur web. C’est particulièrement important lorsque d’anciens clients, des données de navigateur enregistrées ou d’anciennes publications génèrent encore des en-têtes Basic.

⚠️ 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.

Le mode client Basic ne crée pas de cookies de session et ne propose pas de déconnexion dédiée. Sophos exige donc le mode client Form pour le WAF-MFA. Indépendamment de ce choix, le Authentication forwarding mode doit correspondre au backend.

En mode client Basic, Basic prompt est uniquement le texte de la boîte de dialogue du navigateur. En mode de transfert Basic, Username affix ajoute le préfixe ou suffixe configuré lorsqu’un simple nom d’utilisateur est saisi. Vérifiez séparément les identifiants entièrement qualifiés pour éviter de doubler le domaine ou le suffixe au backend. HTTP Basic suit RFC 7617 ; son encodage ne chiffre pas les identifiants.

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. La liste de contrôle suivante et l’association via Protected servers concernent SFOS 22 ; pour SFOS 23, les contrôles explicites par chemin sous Traffic routing décrits ensuite sont également nécessaires.

L’enregistrement d’une règle WAF redémarre toutes les règles de protection des serveurs web. Les connexions actives utilisant ces règles sont interrompues et doivent être rétablies. Coordonnez la modification avec les responsables de toutes les applications concernées dans une fenêtre adaptée, conservez les réglages précédents et vérifiez ensuite l’accessibilité, la connexion avec OTP et l’accès au backend. Cet effet et la procédure de retour arrière n’ont pas été testés ici sur un équipement.

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.

SFOS 23 : associer le MFA à chaque chemin du portail

L’action Protect with web server protection au niveau de la règle ne suffit pas à elle seule. Pour chaque chemin du portail à protéger, sur chaque nom d’hôte publié et dans chaque règle WAF associée, la configuration du chemin doit être correcte ; les étapes MFA et les limites de sessions existantes restent inchangées.

1. Sous Traffic routing, modifiez ou ajoutez chaque chemin protégé du portail et définissez Action > Protect. Affectez les objets backend prévus depuis Web server > Web servers.
2. Dans le champ Authentication, sélectionnez la politique d’authentification prévue. Celle-ci doit utiliser le mode client Form et contenir le groupe d’utilisateurs souhaité ; l’affectation du groupe doit correspondre à la configuration MFA. Vérifiez pour chaque chemin Allowed client networks ainsi que les autres restrictions de source et d’accès, y compris les blocages de réseaux et de pays choisis délibérément.
3. Si seuls certains chemins du portail sont autorisés, conservez / avec Block comme route de repli. Si Protect pour / est voulu pour publier toute l’application, affectez-y la même authentification prévue et des restrictions d’accès appropriées. Vérifiez explicitement que les chemins et noms d’hôte alternatifs disposent d’une protection équivalente ou sont volontairement bloqués.
4. Conservez les tests existants de connexion réussie avec mot de passe et OTP, de fonctionnement du backend, de déconnexion, d’expiration de session et de nouvelle connexion. Un OTP incorrect et un utilisateur extérieur au groupe autorisé doivent être refusés ; les chemins ou noms d’hôte alternatifs ne doivent pas ouvrir un accès non protégé. Corrélez le résultat côté client avec les journaux WAF, d’authentification et du backend.

Limite de la documentation concernant Passthrough : la vue d’ensemble des règles décrit l’authentification comme une fonction de Protect ; parallèlement, le tableau des paramètres de l’action de routage Passthrough propose un champ Authentication. Cette divergence ne démontre ni l’application du MFA ni son contournement avec Passthrough. Faites donc reposer le WAF-MFA requis sur des chemins Protect explicitement configurés, et non sur un comportement non confirmé de Passthrough. Coordonnez séparément les tunnels WebSocket nécessaires avec les responsables du routage WAF et de l’authentification.

Basic with passthrough désigne un mode d’authentification permettant de transmettre les identifiants ; Passthrough sous Traffic routing est, en revanche, une action de routage qui détermine le traitement du trafic. La similitude des noms ne permet de déduire aucune propriété MFA. Pour la publication de base, les responsables doivent vérifier ensemble la configuration des chemins sous SFOS 23 et l’association du MFA : le tutoriel Sophos inchangé sur la protection contre les attaques n’est pas un guide complet du routage sous SFOS 23, et les règles WAF prennent uniquement en charge IPv4.

Personnaliser en toute sécurité une Authentication Template

Un formulaire personnalisé se crée sous Web server > Authentication templates > Add. Le code HTML doit conserver le formulaire avec action="<?login_path?>" et method="POST", ainsi que les champs httpd_username et httpd_password. Pour le MFA, otp_field doit également être présent. La suppression ou le renommage de ces éléments peut empêcher la connexion, même si la page semble correcte.

Pour les images, les styles et les scripts, SFOS fournit notamment les variables <?assets_path?>, <?admin_contact?>, <?company_logo?> et <?company_text?>. Les assets téléversables sont limités à .jpg, .jpeg, .png, .ico, .css et .js. Le template doit d’abord être testé avec un utilisateur pilote ; les identifiants de production, les trackers externes et le JavaScript non vérifié n’ont pas leur place sur la page de connexion.

Après Add, saisissez un nom, sélectionnez le fichier HTML et ses assets, cliquez sur Upload, puis sur Save. Sélectionnez le modèle enregistré dans la politique d’authentification Form. Ce formulaire minimal conserve les noms techniques requis ; il s’agit d’un exemple documentaire, pas d’un modèle testé sur un équipement :

<form action="<?login_path?>" method="POST">
  <label>Username <input name="httpd_username" type="text"></label>
  <label>Password <input name="httpd_password" type="password"></label>
  <?otp_field?><label>OTP <input name="otp_field" type="password"></label><?otp_field?>
  <button type="submit">Login</button>
</form>

Contradictions dans la documentation des modèles : un exemple court de mot de passe utilise type="text", tandis que la définition du champ et l’exemple complet indiquent type="password". Conservez donc le masquage du mot de passe. Une note indique aussi que seul <?login_path?> est remplacé, mais le tableau optionnel décrit également des remplacements pour <?assets_path?> et <?admin_contact?>. Cela ne confirme pas le comportement de chaque version de firmware. Avant le déploiement, vérifiez le formulaire rendu, les chemins des assets, la saisie OTP et la connexion avec un groupe pilote ; ne remplacez pas un modèle fonctionnel sans validation.

<?assets_path?> désigne le chemin des fichiers associés téléversés, par exemple dans <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. Les images et le CSS peuvent ainsi rester hors du formulaire. La description du champ rattache <?admin_contact?> à Administration > Notification settings > Email settings > Send notifications to email address ; vérifiez si cette adresse peut être affichée publiquement. Remplacez <?company_logo?> par le chemin de votre logo et <?company_text?> par le texte visible souhaité, sans présumer un remplacement automatique. Si des variables restent visibles ou si la connexion échoue, revenez au modèle fonctionnel sauvegardé et analysez la cause avec le support au lieu de désactiver le MFA.

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.

Maximum sessions est partagé par toutes les règles WAF avec authentification Form. Une fois la limite atteinte, le pare-feu ferme des sessions anciennes ou expirées pour en accepter de nouvelles. Des demandes répétées de connexion peuvent donc provenir de la capacité globale, pas seulement du timeout d’une politique individuelle.

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.

Si un très grand nombre d’utilisateurs ou plusieurs portails WAF utilisent le même pare-feu, la limite globale de sessions ne doit pas être contrôlée seulement après l’apparition d’erreurs. L’authentification WAF basée sur Form est un paramètre d’exploitation reverse proxy partagé et doit donc être intégrée à la capacité et au monitoring.

Gérer les paramètres globaux du WAF en sécurité

Web server > General settings concerne tous les serveurs web protégés, pas seulement le portail MFA. Avant toute modification, sauvegardez les valeurs, identifiez les applications affectées et la compatibilité des clients, puis prévoyez une fenêtre de maintenance et un retour arrière. Ces indications sont vérifiées documentairement ; leurs effets et leur retour arrière n’ont pas été testés sur un équipement.

Slow HTTP protection limite l’attente d’en-têtes de requête incomplets. Lors d’un DoS Slow HTTP, les fragments arrivant lentement occupent les connexions jusqu’à épuisement de la capacité :

• Soft limit : durée minimale pour recevoir un en-tête de requête.
• Hard limit : durée maximale pour le recevoir.
• Extension rate : quantité de données en octets ; chaque dépassement prolonge le timeout soft d’une seconde.
• Skipped networks/hosts : exceptions ciblées. Utilisez uniquement les types d’hôtes IP IP et Network, pas les IP ranges ou IP lists. Des exceptions larges retirent aussi la protection de clients indésirables.

Après modification, vérifiez les clients légitimes normaux et lents ainsi que les autres applications WAF. N’adoptez pas de timeouts arbitraires comme correction générale des problèmes de connexion.

TLS version settings définit les connexions clientes autorisées. Les profils documentés diffèrent aussi par leurs suites de chiffrement :

• TLS v1 or later : exclut SSLv3 ; profil ancien, non recommandé pour de nouveaux portails.
• TLS v1.1 or later : exclut SSLv3 et TLSv1 ; ce n’est pas non plus un standard moderne de déploiement.
• TLS v1.2 (wide compatibility) : TLSv1.2 uniquement, avec des chiffrements anciens non recommandés.
• TLS v1.2 (strict) : TLSv1.2 uniquement avec les chiffrements recommandés.
• TLS v1.3 : chiffrements TLSv1.3 uniquement.

Vérifiez la prise en charge cliente avant de choisir ; par exemple, IE 8 ou antérieur et Windows XP ne peuvent pas se connecter en TLS 1.2. Ne rétablissez pas la compatibilité ancienne en affaiblissant globalement la sécurité. Testez d’abord un profil strict avec les clients réellement nécessaires et toutes les applications publiées.

Avec Custom TLS, Protocols, Cipher suite et TLS v1.3 cipher suite only utilisent la syntaxe OpenSSL. Les chiffrements TLSv1.3 vont uniquement dans le champ TLSv1.3 séparé, pas dans Cipher suite. Des protocoles ou chiffrements invalides peuvent empêcher Apache de démarrer et perturber le WAF. N’expérimentez pas avec Custom TLS en production sans configuration validée ; en cas d’échec, restaurez les valeurs sauvegardées et vérifiez le service ainsi que l’accès HTTPS de tous les portails affectés.

SFOS 23 – Worker customization : le pare-feu calcule la capacité WAF à partir du CPU et de la RAM. Les valeurs calculées sont optimisées pour le matériel ; la plupart des installations n’ont pas besoin de modification. Des valeurs plus élevées peuvent dégrader les performances WAF et l’utilisation des ressources. Activez Use custom worker profile uniquement après une évaluation soigneuse de la capacité et de l’impact, pas comme correction générique de connexion :

• Start servers : processus worker au démarrage du serveur web.
• Server limit : nombre maximal de processus worker.
• Minimum spare threads : nombre minimal de threads libres maintenus disponibles.
• Maximum spare threads : seuil de threads libres au-delà duquel les excédents sont supprimés.
• Threads per child : nombre maximal de threads par processus worker.
• Asynchronous request worker factor : contrôle la mise à l’échelle des processus pour les connexions et requêtes asynchrones.

Ne copiez pas de valeurs universelles issues d’autres systèmes. Sauvegardez les valeurs initiales, observez une charge représentative et les ressources, puis retestez connexion, OTP, sessions et accès au backend après chaque modification justifiée. En cas de dégradation, restaurez la configuration initiale sauvegardée ; aucun retour arrière réussi n’est affirmé ici.

Automatiser l’authentification WAF via la XML API

L’automatisation repose sur trois objets distincts : FormTemplate fournit le formulaire de connexion, ReverseAuthentication définit l’authentification du client et du backend, et FirewallRule associe la politique à la publication ou à ses chemins. Sauvegarder d’abord le modèle fonctionnel, la politique et toutes les règles qui les utilisent. L’accès, les opérations d’écriture explicites, l’analyse des réponses et les nouvelles tentatives sûres sont expliqués dans Sécuriser l’accès à la Sophos Firewall XML API. Les indications suivantes décrivent les références SFOS-22/23, et non une procédure d’écriture testée sur une appliance. Avant toute modification, consulter l’API help du build installé ; ne rien écrire si des champs ou des associations de téléversement restent incertains.

Distinguer le mode client, le backend et les sessions

Dans l’objet ReverseAuthentication, Name, VirtualWebserverMode et RealWebserverMode sont décrits comme des champs obligatoires. Name autorise au maximum 60 caractères. VirtualWebserverMode sélectionne Basic ou Form pour le client ; la valeur par défaut documentée Basic ne constitue pas une recommandation pour la MFA. Pour la MFA du WAF, Form reste nécessaire. BasicPrompt est le texte d’invite Basic facultatif, limité à 255 caractères. FormTemplate référence le modèle enregistré en mode Form. UserGroupList contient des entrées UserGroup répétables pour des utilisateurs ou groupes existants ; cette sélection doit toujours correspondre au groupe MFA. Le mot Mode dans les notes d’applicabilité ne constitue pas une balise XML supplémentaire attestée.

RealWebserverMode sélectionne indépendamment Basic ou None pour le backend ; ici aussi, le tableau indique Basic comme valeur par défaut. Avec Basic, UsernameAffix fait partie de la connexion au backend. Prefix et Suffix sont des textes facultatifs limités chacun à 255 caractères et prévus uniquement pour la sélection d’affixe correspondante. Avec None, c’est RemoveBasicHeader, avec Enable ou Disable, qui s’applique. La valeur par défaut ON indiquée à cet endroit n’est pas elle-même une valeur d’entrée autorisée ; n’utiliser des valeurs explicites qu’après vérification du build. Les vérifications existantes concernant HTTPS, le backend et les noms d’utilisateur restent nécessaires.

Ne pas reporter les contradictions dans un payload : pour UsernameAffix, l’exemple XML présente None/Prefix/Suffix/PrefixAndSuffix, tandis que le tableau mentionne Basic, Prefix, Suffix, PrefixandSuffix et, simultanément, la valeur par défaut None. Ne deviner ni l’orthographe ni les valeurs de sélection supplémentaires. De même, l’exemple présente SessionTimeout et SessionLifetime comme des commutateurs, leurs champs Limit respectifs comme des entiers et les champs Scope comme Hours/Minutes/Days. Le tableau confirme pour SessionTimeoutLimit la plage de 1 à 9999, mais inverse les types entier et commutateur pour SessionLifetime et SessionLifetimeLimit ; des indications telles que ON et 8 Hours ne correspondent pas de manière cohérente aux types de données. Ces incohérences n’attestent ni de valeurs par défaut fiables ni d’une configuration de session exécutable. Confirmer la limite d’inactivité et la durée de vie maximale souhaitées dans le build installé, relire l’état enregistré et effectuer les tests existants de session, de déconnexion et de nouvelle connexion. L’ajout SFOS-23 RedirectToRequestedURL et son test de redirection distinct restent indépendants de ces points.

Associer le modèle et les fichiers complémentaires

La référence FormTemplate présente FormTemplate comme un objet comportant Name, Description, Template et Assets, avec des entrées Asset répétables. Name et Template sont obligatoires : le nom autorise au maximum 60 caractères, et Template est une chaîne limitée à 255 caractères pour sélectionner et téléverser le modèle HTML. Description est facultatif. Les chaînes Asset facultatives autorisent chacune au maximum 255 caractères et plusieurs valeurs pour les images, feuilles de style ou fichiers JavaScript utilisés.

L’exemple laisse Template et Asset vides. Il ne définit donc ni les noms des parties multipart, ni les chemins de fichiers, ni un encodage Base64, ni du contenu HTML directement transmissible. Ne pas transposer aux FormTemplates une association de téléversement de certificats. Sans contrat de téléversement confirmé, utiliser la séquence existante dans la GUI Upload > Save, puis sélectionner le modèle enregistré via FormTemplate dans la politique Form. Les champs de formulaire requis et les types de fichiers d’assets autorisés indiqués dans la section précédente restent applicables. Vérifier le formulaire rendu, les assets et la connexion OTP avec un utilisateur de test ; le seul enregistrement réussi de l’objet ne prouve pas que le formulaire fonctionne.

Associer l’Authentication Policy à la règle

Pour FirewallRule, cette association concerne la branche WAF HTTPBasedPolicy, et non NetworkPolicy ou UserPolicy. Le tableau des paramètres décrit Authentication comme une chaîne scalaire facultative pour une Authentication Policy. Dans l’exemple de chemin, l’association correspondante apparaît sous la forme AccessPaths > AccessPath > auth_profile. Le commentaire de l’exemple distingue la variante à l’échelle de la règle, avec Authentication et contrôles des sources, de AccessPaths ; il n’atteste ni d’une combinaison quelconque ni d’un héritage automatique. Ne pas mélanger sans vérification les syntaxes à l’échelle de la règle et par chemin, et ne pas supposer qu’une politique présente sur le pare-feu protège déjà tous les chemins.

Dans SFOS 23, le tableau décrit path comme un tableau obligatoire de chaînes à plusieurs valeurs, limitées à 63 caractères, sans virgule et avec prise en charge d’UTF-8 ; SFOS 22 indique ici un scalaire. L’exemple utilise à la fois path et Path. backend est facultatif dans le tableau SFOS-23 ; cela ne garantit pas qu’un portail protégé fonctionne sans backend. Le nouveau champ action propre au chemin indique littéralement 0/1/2/3, sans correspondance fiable avec les actions de la GUI. Ne pas deviner la correspondance des nombres et ne pas assimiler ces valeurs au champ réseau Action. Le routage, le backend et le profil de protection sont expliqués dans WAF : publier un serveur web de manière sécurisée.

Pour modifier l’authentification, lire d’abord les noms d’hôte et les chemins réels de la règle cible, associer la politique Form souhaitée à chaque chemin protégé, puis comparer l’état enregistré à l’état attendu. Tester tous les chemins, noms d’hôte et règles alternatifs, ainsi qu’un OTP incorrect et des utilisateurs extérieurs au groupe. Les contrôles Protect déjà décrits, la limite documentaire concernant Passthrough et la fenêtre de modification des règles WAF restent alors inchangés.

Analyser les réponses des objets avant une nouvelle tentative

Les correspondances suivantes sont des valeurs de statut XML et des symboles Message.* littéraux, non résolus, issus de la référence ; il ne s’agit ni de codes de statut HTTP ni de textes de messages d’exécution attestés. Pour l’association FirewallRule, les différences entre Add et Edit sont particulièrement importantes :

• Add firewall rule: 200 / Message.FWRuleAddSuccess, 500 / Message.FWRuleAddFail, 502 / Message.FWRuleRecordExists.
• Edit firewall rule: 200 / Message.FWRuleEditSuccess, 202 / Message.FirewallRuleUpdateWithRename, 500 / Message.FWRuleEditFail, 502 / Message.FWRuleUpdateRecordExist. Avec 202, relire également le nom réel et toutes les associations.
• Correspondances différentes : Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser ; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort ; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. Le même code ne suffit pas à lui seul pour interpréter la réponse.
• Autres lignes distinctives : Edit 552 / Message.CannotImportDiffPolicytypeWithSameName ; Add 554 / Message.CannotUseFQDNWildCardAsProtectedServer, Edit 554 / Message.CannotUpdateFQDNWildCardAsProtectedServer.
• Delete firewall rule: 200 / Message.FWDelSuccess, 500 / Message.FWRuleDeleteFail, 596 / Message.CMLOCALOperationrestriction. 596 figure également pour Add et Edit ; clarifier l’état réel des autorisations et de l’administration, sans le contourner par des tentatives répétées à l’aveugle ou par une suppression. Supprimer une règle n’est pas un moyen de corriger une association d’authentification manquante.

Les deux objets en amont ont également leurs propres réponses :

• Add Authentication Policy: 200 / Message.ReverseAuthAddSuccess, 500 / Message.ReverseAuthAddFail, 502 / Message.ReverseAuthRecodExist.
• Edit Authentication Policy: 200 / Message.ReverseAuthUpdateSuccess, 500 / Message.ReverseAuthUpdateFail.
• Add FormTemplate: 200 / Message.FormTemplateAddSuccess, 500 / Message.FormTemplateAddFail.
• Edit FormTemplate: 200 / Message.FormTemplateUpdateSuccess, 500 / Message.FormTemplateUpdateFail, 502 / Message.FormTemplateRecodExist. L’orthographe Recod dans ces symboles est conservée littéralement ; ne pas en déduire un statut supplémentaire pour une autre opération.

Consigner ensemble l’opération, le code, la réponse réelle et l’état enregistré du modèle, de la politique et de la règle cible. En cas d’erreur, d’avertissement ou de réponse ambiguë, vérifier d’abord ce qui a réellement été appliqué ; ne pas contourner le problème avec un second nom, un groupe plus large ou un chemin non protégé. Si la syntaxe ou l’association de téléversement reste incertaine, s’arrêter et solliciter le support avec des données expurgées. Ce n’est qu’après confirmation de l’enregistrement que doivent suivre les tests positifs et négatifs existants de MFA, de backend, de session, de déconnexion, de redirection et de chemins alternatifs. Une vérification documentaire ne remplace pas une validation sur son propre pare-feu.

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.
• Les modifications du timestep du token ne s’appliquent qu’aux tokens nouvellement générés et doivent correspondre à l’app utilisée.

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.

Si un utilisateur perd l’app ou si l’algorithme est modifié, répéter la communication utilisateur ne suffit souvent pas. Sous Authentication > Multi-factor authentication > Issued tokens, les tokens peuvent être réinitialisés ou des codes uniques supplémentaires peuvent être générés. Ce processus doit être gouverné en interne, car il a un impact fort sur la sécurité.

Validation et exploitation

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.
9. Vérifier la déconnexion, la reconnexion et l’expiration de session avec le même navigateur.
10. Tester un deuxième hostname ou un chemin alternatif si l’application utilise plusieurs règles WAF.

Pour tester également le retour à l’URL demandée sous SFOS 23, ouvrez une URL réellement protégée dont le chemin est différent de /, sans session WAF valide. Après une connexion réussie avec mot de passe et OTP, lorsque RedirectToRequestedURL est défini sur Enable, vérifiez que l’URL initialement demandée est atteinte exactement et que l’accès au backend respecte les autorisations prévues. Une redirection réussie ne prouve à elle seule ni le MFA ni l’autorisation d’accès ; tous les tests précédents de refus, de backend, de session, de déconnexion, de nouvelle connexion et de chemins alternatifs restent nécessaires.

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 :

• Utilisateur : la connexion au pare-feu apparaît, l’OTP est demandé, puis l’application attendue s’ouvre.
• Sophos Firewall : le Log Viewer et reverseproxy.log montrent une authentification WAF autorisée ou refusée.
• Source d’authentification : AD, LDAP, RADIUS ou la source d’utilisateurs locale montre la connexion réussie ou échouée attendue.
• Backend : l’application atteint le bon état utilisateur ou invité et n’affiche pas de deuxième page d’erreur inattendue.

Si seul le navigateur semble fonctionner, mais qu’aucun log correspondant n’est visible, la validation est incomplète. Il faut alors vérifier si la bonne règle WAF est effectivement appliquée, si la politique d’authentification est 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é :

• Groupe de déploiement : commencer par le groupe pilote, puis ajouter d’autres groupes d’utilisateurs.
• Fenêtre de support : garder le helpdesk ou les administrateurs responsables disponibles pendant les premières connexions.
• Surveillance : observer le Log Viewer, reverseproxy.log et la source d’authentification.
• Réinitialisation de token : définir une procédure claire pour les tokens OTP perdus ou mal configurés.
• Comportement de session : vérifier le timeout et la durée de session après une utilisation réelle.
• Chemin de retour : documenter la règle WAF, la politique d’authentification et les étapes de modification.

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.

Dépannage

Autres erreurs fréquentes

• La politique d’authentification n’utilise pas Form : le comportement MFA ne correspond pas à la configuration WAF attendue.
• Sophos Authenticator est prévu comme nouvelle application standard : l’application est EOL et ne doit plus servir de base à un nouveau déploiement.
• L’accès de secours dépend de la même règle WAF : les administrateurs ne peuvent plus annuler correctement la modification en cas d’erreur.
• Le déploiement des tokens n’a pas été testé : les utilisateurs échouent à la première connexion, bien que la règle WAF soit techniquement correcte.
• Une deuxième URL ou règle WAF reste active sans MFA : les utilisateurs contournent involontairement le MFA en amont.
• Les exceptions temporaires du pilote ne sont pas supprimées : la protection en production est incohérente et difficile à auditer.

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 backend redemande un login après une MFA réussie

Sous SFOS 22.0 GA Respin Build 411, NC-177509 peut survenir : le WAF-MFA basé sur Form réussit, mais le backend demande ensuite une connexion supplémentaire impossible à contourner. Le code OTP n’est pas séparé du mot de passe avant que le pare-feu transmette les identifiants au backend. Ce problème est corrigé à partir de SFOS 22.0 MR1 Build 490.

La correction du code OTP non supprimé porte aussi la référence NC-177201. Les identifiants ne sont pas interchangeables : NC-177509 associe les builds affectées et corrigées, tandis que NC-177201 identifie le texte précis du correctif. Dans un ticket de support, indiquez le symptôme, la build et les deux références.

À vérifier :

• La WAF Authentication Policy utilise Form.
• Authentication forwarding mode est actif et correspond à l’application backend.
• La règle WAF concernée utilise précisément cette Authentication Policy.
• L’erreur apparaît après une MFA réussie, pas déjà lors de la connexion au pare-feu.
• reverseproxy.log, Log Viewer et le journal d’accès du backend couvrent le même moment de test.
• La version SFOS utilisée a été vérifiée.

Sur un système GA concerné, sauvegardez reverseproxy.log, le Log Viewer et le log du backend, puis planifiez une mise à jour vers MR1 Build 490 ou une version ultérieure. Si une mise à jour rapide n’est pas possible, ne modifiez pas le flux d’authentification sans validation ; utilisez les données sauvegardées pour ouvrir un ticket auprès du support Sophos. N’affaiblissez pas le MFA et ne modifiez pas le transfert d’authentification sans analyse : None ne convient que si le backend n’a pas besoin d’identifiants transmis. Pour les portails en production, le plan doit inclure des utilisateurs de test, un rollback et la communication aux utilisateurs.

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. Dans les 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