Sophos Firewall WAF : Publier un serveur web en toute sécurité

Avec Web Server Protection ou Web Application Firewall (WAF), vous publiez des applications web internes ou basées sur le cloud via le Sophos Firewall. Le pare-feu fonctionne comme un proxy inverse : les clients se connectent à l’adresse publique du pare-feu, qui vérifie le trafic HTTP ou HTTPS et transmet la requête au serveur web protégé.

Pour le contexte global de hardening, consulter le hub Sophos Firewall Hardening : bonnes pratiques pour une configuration sécurisée.

Une règle WAF ne remplace pas automatiquement le développement sécurisé des applications, les correctifs, l’authentification forte ou le renforcement des serveurs. Cependant, par rapport à un simple transfert de port, elle réduit considérablement la surface d’attaque, car le trafic HTTP(S) peut être vérifié, restreint et journalisé de manière ciblée.

WAF n’est cependant pas automatiquement la bonne réponse pour chaque publication. Ce qui est crucial, c’est de savoir si l’application fonctionne réellement correctement via HTTP ou HTTPS, si le pare-feu doit évaluer les noms d’hôte et les chemins, et si la couche de proxy inverse supplémentaire convient à l’application.

Décision avant publication

Quand WAF est-il préférable à DNAT ?

Pour les services TCP ou UDP simples, on utilise toujours NAT et les règles de pare-feu. Pour les applications web, WAF est souvent le meilleur choix.

• DNAT convient aux services non HTTP, aux redirections de port simples et aux protocoles spéciaux. Le pare-feu traduit et autorise alors principalement le trafic.
• WAF / Web Server Protection convient aux applications HTTP et HTTPS lorsque le nom d’hôte, le certificat, les chemins, les profils de protection, l’authentification ou les règles de pays sont pertinents.
• Reverse Proxy ou ZTNA convient aux plateformes web complexes, à l’intégration d’identité et aux applications privées, lorsque l’accès doit être fortement contrôlé ou ne doit pas être public.

Si un serveur web interne doit être rapidement accessible via un transfert de port, l’instruction Publier un serveur via DNAT sur Sophos Firewall peut aider. Pour les applications web publiques, il est conseillé d’examiner d’abord WAF.

⚠️ WebDAV n’est pas pris en charge par Sophos WAF. Par conséquent, les applications comme Nextcloud ne doivent pas être publiées à l’aveugle via WAF, mais plutôt planifiées via des règles de pare-feu et NAT appropriées ou une autre architecture de publication.

Décision : WAF, DNAT ou accès privé

La question la plus importante n’est pas de savoir à quelle vitesse une publication est construite, mais si elle peut être exploitée, testée et retirée en toute sécurité par la suite. Cette classification aide avant la mise en œuvre technique :

• Site web public ou application HTTPS simple : WAF est généralement le bon point de départ. DNS, certificat, nom d’hôte, profil de protection, journalisation et accessibilité du backend doivent être testés.
• Portail client, portail partenaire ou interface d’administration : WAF avec limitation de source et MFA optionnel peut être utile. Il faut d’abord vérifier si WAF-MFA, des règles de pays ou des réseaux sources fixes sont possibles.
• Service TCP ou UDP pur : DNAT est généralement plus adapté. Règle firewall, règle NAT, serveur cible, route de retour et journalisation doivent être vérifiés ensemble.
• Application web avec WebDAV ou protocole spécial : ne pas utiliser automatiquement WAF. Tester les fonctions supportées, le comportement client et les alternatives de publication.
• Application uniquement pour les utilisateurs internes : vérifier VPN, ZTNA ou WAF fortement restreint. L’accessibilité publique doit être remise en question de manière critique.

Pour les applications privées, une règle WAF accessible dans le monde entier représente souvent trop de surface d’attaque. Si seules quelques personnes doivent accéder, des réseaux sources fixes, VPN, ZTNA ou une autre architecture d’accès privé sont souvent plus propres qu’une publication web publique.

Planification et prérequis

Prérequis

Avant la première règle WAF, il convient de clarifier ces points :

• Nom DNS public, par exemple portal.example.com
• Adresse IP publique ou alias sur l’interface WAN
• Certificat pour le nom d’hôte publié
• Adresse IP interne ou FQDN du serveur web
• Port cible interne du serveur web
• Décision de rediriger HTTP vers HTTPS
• Réseaux sources, pays ou groupes d’utilisateurs autorisés
• Profil de protection approprié et politique IPS optionnelle
• Journalisation activée pour une analyse ultérieure
• Accès de test externe en dehors de votre propre LAN

Le nom DNS public doit pointer vers l’adresse utilisée dans la règle WAF comme Hosted address. Pour HTTPS, le certificat doit correspondre au nom d’hôte publié.

Le pare-feu a aussi besoin d’un objet serveur web sous Web server > Web servers. On y décrit le serveur cible interne ou externe avec l’hôte, le protocole et le port. L’hôte est un objet IP ou FQDN. Pour les backends, HTTP ou HTTPS sont possibles ; les ports standard sont 80 et 443. Si le serveur web backend fournit de longues réponses ou nécessite keep-alive, Keep alive et Timeout doivent être vérifiés consciemment au lieu d’être repris par hasard.

Le Timeout du backend peut aller de 1 à 65,535 secondes ; la valeur par défaut est de 300 secondes. À son expiration, WAF envoie 502 au client. Disable backend connection pooling impose une nouvelle connexion au backend pour chaque requête et peut réduire les performances. Cette option ne doit servir qu’à un dépannage ciblé, puis l’état antérieur documenté doit être rétabli.

Il faut aussi tenir compte très tôt des limites de Web Server Protection. Sophos indique notamment une limite de 60 règles WAF par firewall. Cela suffit pour de nombreux environnements, mais peut devenir pertinent plus vite que prévu avec de nombreux portails clients, mandants, systèmes de test ou noms d’hôtes séparés. Dans ce cas, il ne faut pas construire aveuglément d’autres règles individuelles, mais vérifier le concept de noms, les chemins, les serveurs web virtuels et les alternatives de publication.

SFOS 22 ne prend pas en charge les règles WAF sur IPv6. Une application ne doit donc pas être planifiée comme publication IPv6 avec cette fonction ; l’aperçu Prise en charge et limites d’IPv6 sur Sophos Firewall avec SFOS 22 distingue WAF des fonctions IPv6 prises en charge pour les règles et la protection. Les modèles Exchange ne sont pas non plus un laissez-passer pour les environnements Exchange modernes : Sophos documente que les règles WAF ne supportent actuellement pas les versions Exchange postérieures à 2013.

Les modèles préconfigurés proviennent d’un ancien environnement applicatif Microsoft : Exchange Autodiscover, Outlook Anywhere et Exchange General s’arrêtent à cette limite d’Exchange 2013 ; les autres guides Sophos mentionnent Microsoft Lync, Remote Desktop Gateway ou RD Web 2008/R2 ainsi que SharePoint 2010/2013. Ils ne constituent donc pas une référence actuelle pour Microsoft 365, les versions modernes d’Exchange, Teams ou les déploiements RDS actuels. Avant d’utiliser un modèle, comparer les chemins, méthodes d’authentification et politiques de protection réellement nécessaires avec l’architecture Microsoft actuelle ; pour une application moderne, laisser Preconfigured template sur None en cas de doute.

Planifier la publication WAF avant la configuration

Une règle WAF ne doit pas être planifiée uniquement dans le masque. Il doit être clair au préalable si le Sophos Firewall doit seulement publier ou s’il doit également prendre en charge l’authentification, les profils de protection, les règles de pays et la journalisation.

Ces questions sont importantes avant une publication productive :

• Est-ce vraiment une application HTTP ou HTTPS ? Pour d’autres protocoles, DNAT est généralement plus approprié.
• L’application doit-elle être accessible publiquement ? Les portails d’administration privés conviennent souvent mieux au VPN, ZTNA ou aux réseaux sources restreints.
• Quel nom d’hôte et quel certificat sont utilisés ? DNS, SNI, certificat et domaines WAF doivent correspondre.
• Combien de publications sont prévues ? La limite de règles WAF et la maintenabilité ultérieure influencent le design.
• Le pare-feu doit-il authentifier les utilisateurs ? Pour les portails, WAF-MFA peut être pertinent.
• Quels profils de protection sont actifs ? Des exceptions trop larges affaiblissent le WAF, des profils trop stricts peuvent casser les applications.
• Comment sera-t-il journalisé et testé ? Log Viewer, reverseproxy.log et journaux du backend doivent être connus avant la mise en service.

Pour les certificats, il convient de déterminer rapidement si un certificat existant doit être importé avec sa clé privée et sa chaîne de CA, si le pare-feu doit lui-même créer et renouveler un certificat Let’s Encrypt ou si un certificat généré en externe est nécessaire. Une procédure distincte est disponible pour les certificats wildcard : Créer un certificat wildcard Let’s Encrypt.

Configurer la règle WAF

Structure de base d’une règle WAF

Une publication WAF se compose de plusieurs éléments :

• Hosted address : adresse IP publique ou alias sur laquelle les clients atteignent l’application.
• Listening port : port public, généralement 80 ou 443.
• Domains : noms d’hôte qui doivent correspondre à la règle WAF.
• HTTPS certificate : certificat pour le nom d’hôte publié.
• Web server : objet web server créé au préalable avec hôte, protocole, port et paramètres de connexion.
• Allowed client networks : réseaux sources autorisés à accéder.
• Blocked client networks / countries : sources ou pays bloqués.
• Protection policy : protection WAF contre les attaques web typiques.
• Authentication : authentification préalable optionnelle via le pare-feu.

Sophos crée des règles WAF dans la section des règles de pare-feu. L’action s’appelle Protect with web server protection.

Important : une règle WAF n’est pas une règle firewall normale avec NAT derrière. Elle crée une publication reverse proxy. Hosted address, Listening port, Domains, certificat, Protected server et Allowed client networks doivent donc correspondre. Si l’un de ces champs ne convient pas, l’erreur ressemble souvent à un problème de certificat, DNS ou backend.

Créer une règle WAF

Le chemin du menu est :

Rules and policies > Firewall

Procédure :

La procédure numérotée ci-dessous avec Protected servers s’applique uniquement à SFOS 22 et reste inchangée pour cette version. Les règles WAF prennent uniquement en charge IPv4. L’action Protect with web server protection au niveau de la règle ne doit pas être confondue avec l’action par chemin Action > Protect sous Traffic routing dans SFOS 23 ; pour SFOS 23, suivez les instructions distinctes placées directement après cette procédure.

1. Sélectionnez IPv4.
2. Ouvrez Add firewall rule.
3. Sélectionnez New firewall rule.
4. Donnez un nom de règle explicite.
5. Définissez consciemment Rule position, surtout si des règles WAF plus générales ou d’anciennes publications existent déjà.
6. Pour Action, choisissez l’option Protect with web server protection.
7. Si aucun modèle spécial n’est nécessaire, laissez Preconfigured template sur None.
8. Sous Hosted server details, définissez l’adresse publique, le port d’écoute, HTTPS, le certificat et les domaines.
9. Sous Protected servers, sélectionnez l’objet web server adapté ou créez-le d’abord sous Web server > Web servers.
10. Définissez consciemment Allowed client networks. Pour les sites web publics, Any IPv4 peut être nécessaire ; pour les portails, une restriction est généralement préférable.
11. Si nécessaire, définissez Blocked client networks ou Blocked countries.
12. Vérifiez consciemment Protection, Intrusion prevention et Traffic shaping dans les politiques avancées.
13. Enregistrez la règle et testez-la de l’extérieur.

SFOS 23 : publier des chemins sous Traffic routing

1. Sous Rules and policies > Firewall, créez ou modifiez une règle IPv4. Pour l’Action au niveau de la règle, continuez à sélectionner Protect with web server protection et configurez l’adresse publique, le port, le certificat HTTPS et les domaines appropriés. Une nouvelle règle contient par défaut / avec Block : sans configuration de routage supplémentaire, les requêtes sont rejetées et l’application n’est pas publiée.
2. Sous Traffic routing, utilisez Edit ou Add new path pour modifier ou ajouter le chemin précisément prévu. Pour Action, sélectionnez explicitement Protect et affectez les objets backend nécessaires depuis Web server > Web servers. Un modèle crée bien des chemins avec Protect, mais l’affectation des backends reste nécessaire.
3. Pour chaque chemin protégé, affectez la politique d’authentification prévue dans le champ Authentication et définissez consciemment Allowed client networks, sans laisser ce champ vide. Vérifiez de manière ciblée Blocked client networks, Blocked countries et Block IP addresses of unknown country-origin ; pour les origines géographiques inconnues, tenez également compte du risque de bloquer votre propre accès.
4. Si seuls certains chemins doivent être publiés, conservez délibérément / avec Block comme route de repli. Ne définissez / sur Protect que si toute l’application doit être publiée ; vérifiez explicitement le backend, l’authentification, les restrictions d’accès et les parties de l’application ainsi rendues accessibles. Les chemins plus longs et plus spécifiques sont évalués en premier, et non selon l’ordre du tableau.
5. Distinguez les actions : Block rejette les requêtes pour le chemin sélectionné sans les transmettre au backend. Protect applique la politique de protection de la règle ainsi que les paramètres d’authentification et d’accès configurés. Redirect envoie au client une redirection vers la destination configurée au lieu de publier un backend. Passthrough crée un tunnel vers le backend sans inspection WAF et sans application de la politique de protection. Protection s’applique uniquement aux chemins avec Protect.
6. Après l’enregistrement, testez depuis l’extérieur un chemin prévu comme autorisé, un chemin volontairement bloqué et un chemin sans correspondance spécifique. Si vous utilisez Redirect ou Passthrough, testez également ces actions séparément. Corrélez le résultat côté client, Log Viewer, reverseproxy.log et les journaux du backend pour la même requête et au même moment.

Règles existantes après la mise à niveau : selon la documentation Sophos, les règles WAF existantes sont automatiquement converties en Protect lors de la mise à niveau vers SFOS 23 ; les routes spécifiques aux chemins existantes sont conservées. Cela diffère du comportement par défaut / avec Block des nouvelles règles et de l’ancienne migration des ModSecurity Protection Policies sous SFOS 18. Après la mise à niveau, vérifiez néanmoins pour chaque chemin l’action, le backend, l’authentification, les restrictions d’accès et la route réellement utilisée, puis effectuez un test d’acceptation externe ; la migration automatique ne remplace pas la validation.

Mise en perspective du tutoriel : le tutoriel Sophos sur la protection d’un serveur web contre les attaques utilise toujours la procédure avec Protected servers et mentionne IPv4 or IPv6, alors que la référence des règles WAF limite WAF à IPv4. Ce tutoriel n’est donc pas un guide complet du routage sous SFOS 23. Pour la configuration actuelle, utilisez IPv4 et les actions explicites par chemin décrites ci-dessus.

Lorsque la règle est enregistrée, Sophos redémarre les règles de protection des serveurs web. Les connexions en direct existantes via ces règles peuvent être interrompues. Les modifications des règles WAF en production doivent donc être effectuées pendant une fenêtre de maintenance ou au moins de manière consciente.

Si Allowed client networks reste vide, la règle WAF ne fonctionne pas correctement ; le navigateur peut alors recevoir un 400 Bad Request. Pour une application publique, Any IPv4 est possible, mais pas automatiquement correct. Pour les portails d’administration, portails partenaires ou outils internes, il faut d’abord vérifier les réseaux sources fixes, la limitation par pays, WAF-MFA, VPN ou ZTNA.

Les conflits de port doivent être clarifiés avant l’enregistrement. WebAdmin et User Portal nécessitent chacun un port unique. WAF et VPN Portal utilisent tous deux TCP ; s’ils utilisent le même port, leurs Hosted address ou adresses IP WAN doivent donc être différentes. WAF peut se distinguer de SSL VPN par l’adresse IP WAN, le port ou le protocole, car SSL VPN prend en charge TCP ou UDP. Un FQDN ou un nom SNI différent ne suffit pas à lui seul pour séparer ces listeners. Si un autre service ou une ancienne publication DNAT écoute déjà sur une IP publique, l’attribution doit être testée par adresse IP, port et protocole avant la mise en production.

Go-live et validation

Planifier la mise en service et le retour en arrière

Une publication WAF ne doit pas être considérée comme terminée simplement en enregistrant la règle. Ce qui est crucial, c’est de savoir si DNS, certificat, Hosted address, backend, profil de protection et journalisation fonctionnent ensemble. En particulier pour les transferts de port existants, le changement doit être traité comme une petite publication.

Avant la mise en service, vérifiez :

• Documentez la configuration actuelle du pare-feu ou au moins les paramètres de règle et de certificat concernés.
• Identifiez les règles DNAT ou de pare-feu précédentes qui concernent le même port, la même IP publique ou le même nom d’hôte.
• Désactivez les anciennes règles DNAT ou documentez clairement pourquoi elles ne concurrencent pas la règle WAF.
• Réduisez le TTL DNS avant un changement si le nom d’hôte public passe d’une ancienne publication à la WAF.
• Fournissez un accès de test externe, ne testez pas seulement depuis le LAN interne.
• Définissez des cas de test : page d’accueil, connexion, téléchargement, API, WebSocket, déconnexion et message d’erreur.
• Définissez les points de journalisation attendus : Log Viewer, reverseproxy.log, journal d’accès du backend et journal d’erreurs du backend.
• Définissez un critère de retour en arrière, par exemple connexion impossible, backend inaccessible, certificat incorrect, taux d’erreur élevé ou parties critiques de l’application défectueuses.

Lors du changement, une seule publication doit être active à la fois. Si une ancienne règle DNAT et une nouvelle règle WAF utilisent la même IP publique et le même port, le comportement est difficile à comprendre. Avant de passer en production, il doit être clair quelle règle traite réellement le trafic.

Un retour en arrière simple consiste souvent à désactiver la nouvelle règle WAF et à réactiver la publication précédente. Si DNS a également été modifié, le TTL DNS doit être pris en compte. En cas de problèmes de certificat ou de nom d’hôte, un retour en arrière via DNS seul est souvent trop lent ; dans ces cas, l’ancienne règle sur la même Hosted address doit pouvoir être réactivée ou un accès alternatif doit être disponible.

Après la mise en service, les premiers accès doivent être activement surveillés. Ce qui est important, ce ne sont pas seulement les codes de statut HTTP réussis, mais aussi les blocages WAF, les erreurs du backend, les redirections inattendues, les problèmes de session et les informations manquantes sur l’IP du client dans les journaux du backend.

Test d’acceptation après la mise en service

Un test WAF n’est complet que lorsque la même requête est traçable sous trois angles : client, pare-feu et backend. Cela permet de détecter plus rapidement si un problème réside dans DNS, le certificat, le matching WAF, le profil de protection ou l’application.

• Client externe : vérifier résolution DNS, certificat, statut HTTP, login et chemins importants. L’application devrait s’ouvrir via le nom d’hôte public sans avertissement de certificat.
• Sophos Firewall : vérifier Log Viewer, règle WAF, reverseproxy.log et signatures bloquées. La bonne règle WAF devrait traiter l’accès et les logs devraient montrer les requêtes autorisées ou bloquées avec raison.
• Serveur web backend : vérifier access log, error log, session applicative et X-Forwarded-For. La requête devrait atteindre le bon vHost ou chemin, et la logique d’IP client doit être comprise.

Pour les applications en production, vous devez tester au moins ces cas :

• Accès via le bon nom d’hôte et via un domaine non correspondant.
• Connexion avec un utilisateur valide et invalide, si l’application ou WAF authentifie.
• Téléversement, téléchargement, fonction API ou WebSocket, si l’application utilise ces fonctions.
• Accès depuis une source autorisée et, si possible, depuis une source délibérément non autorisée.
• Comportement d’une requête de test WAF connue et inoffensive, pour que la journalisation et le chemin de blocage soient visibles.

Si l’application semble fonctionner après la mise en service mais qu’aucun journal approprié n’est visible, le test n’est pas encore terminé. Il se peut alors qu’une autre publication corresponde, que la journalisation manque ou que l’accès ne passe pas par le chemin attendu.

Sécuriser la protection et les accès

Certificats et noms d’hôte

Pour HTTPS, la règle WAF doit utiliser un certificat correspondant au nom d’hôte public. Le certificat est importé ou créé sous Certificates > Certificates et ensuite sélectionné dans la règle WAF.

Points importants :

• Le nom DNS doit correspondre au certificat.
• Le certificat HTTPS sélectionné peut remplir automatiquement la liste des domaines dans la règle WAF ou écraser des entrées de domaine existantes.
• Avec plusieurs noms d’hôte sur la même IP, le pare-feu utilise SNI.
• Les certificats génériques sont possibles, mais doivent être documentés proprement.
• Les domaines wildcard ne sont utilisés qu’après les règles de domaine plus spécifiques.
• Les underscores dans le label gauche du domaine ne sont pas un nom DNS propre et devraient être évités pour les domaines WAF.
• Le backend peut utiliser un autre nom interne si l’en-tête Host et l’application peuvent le gérer.
• En cas de problèmes avec les liens absolus, Rewrite HTML peut devenir pertinent.

Si plusieurs serveurs web virtuels fonctionnent sur la même IP et le même port, le pare-feu décide pour HTTPS en fonction de SNI et du nom d’hôte, quelle règle WAF est appropriée.

Les Domains dans la règle WAF doivent donc correspondre exactement au DNS et au certificat. Les wildcards peuvent aider, mais ne doivent pas remplacer un concept de publication propre. Si plusieurs applications utilisent des noms d’hôtes similaires, une documentation claire des règles et certificats est nécessaire, sinon il devient difficile de savoir plus tard quelle règle WAF matche réellement. Un test avec un sous-domaine volontairement non correspondant est utile : il permet de voir si la règle spécifique, une règle wildcard ou aucun serveur web virtuel correspondant répond.

Planifier l’IP du client et les journaux du backend

Dans les publications WAF, le serveur web interne ne voit souvent pas l’IP réelle du client comme adresse source directe. Le Sophos Firewall fonctionne comme un proxy inverse et établit lui-même la connexion au backend. Pour l’application et les journaux du serveur web, l’adresse du pare-feu peut donc être visible en premier.

Si l’application ou le backend a besoin de l’IP client d’origine, il convient de vérifier tôt si X-Forwarded-For ou un en-tête comparable est évalué. C’est important pour :

• Journaux d’application et évaluation de la sécurité
• Limites de taux ou protection de connexion au niveau de l’application
• Analyse des erreurs avec référence à l’utilisateur ou à l’IP source
• Corrélation SIEM ou surveillance
• Analyse judiciaire après un incident

La limite de confiance est importante : un backend ne doit traiter ces en-têtes comme fiables que si la requête provient réellement du Sophos Firewall ou d’un proxy inverse défini. Les clients publics ne doivent pas pouvoir définir directement X-Forwarded-For comme preuve de sécurité. En pratique, le serveur web ne doit donc faire confiance qu’à l’IP du pare-feu et ignorer ou remplacer les en-têtes provenant d’autres sources.

Pour le dépannage, cela signifie : Log Viewer, reverseproxy.log et journal du backend doivent couvrir le même moment de test. Si seule l’IP du pare-feu est visible dans le backend, ce n’est pas automatiquement une erreur WAF, mais souvent un comportement normal de proxy inverse.

Restreindre l’accès client

Toutes les applications web ne doivent pas être accessibles dans le monde entier. Déjà dans la règle WAF, vous pouvez limiter l’accès.

Restrictions utiles :

• Autoriser uniquement les adresses IP sources connues ou les réseaux partenaires.
• Bloquer les pays non nécessaires.
• Bloquer les adresses IP d’origine inconnue uniquement si le risque de verrouillage est évalué.
• Pour les portails, utilisez également WAF-MFA ou authentification préalable.
• Bloquer les sources malveillantes connues via Threat Feeds.

Pour le blocage des pays et des mauvaises IP, consultez Sophos Firewall : Bloquer les pays et les IP malveillantes. Pour les listes de menaces dynamiques, Sophos Firewall Threat Feeds est pertinent.

Planifier les Threat Feeds et la réponse active aux menaces

Pour les applications web accessibles publiquement, il ne faut pas seulement considérer la règle WAF elle-même. Depuis SFOS 22, les Threat Feeds deviennent également pertinents pour le trafic entrant et redirigé comme les publications WAF et DNAT. Le pare-feu peut comparer ces correspondances avec les MDR Threat Feeds, NDR Essentials et Third-Party Threat Feeds.

Pour les administrateurs, cela signifie : WAF est la couche de publication, les Threat Feeds et la réponse active aux menaces peuvent bloquer ou rendre visibles des sources malveillantes connues supplémentaires. Cela ne remplace cependant pas la gestion des correctifs, une authentification propre et le renforcement des applications.

En pratique, il convient de vérifier :

• La réponse active aux menaces est-elle configurée de manière appropriée dans l’environnement ?
• Les Threat Feeds pertinents sont-ils utilisés et régulièrement vérifiés ?
• Les événements WAF, les journaux de réponse active aux menaces et les journaux du backend sont-ils visibles en fonctionnement ?
• Existe-t-il un processus pour les faux positifs, la liste blanche et les autorisations d’urgence ?
• Est-il clair qui réagit aux correspondances et si elles sont seulement journalisées ou activement bloquées ?

Surtout pour les portails clients, les interfaces d’administration ou les accès partenaires, cet examen doit avoir lieu avant la mise en service. Si un Threat Feed bloque plus tard le trafic productif, l’exploitation doit savoir où voir la correspondance et comment décider proprement : véritable attaque, fausse alarme ou application mal publiée.

Profils de protection et exceptions

Une règle WAF ne doit pas seulement publier, mais aussi protéger. Pour cela, on utilise des politiques de protection, des politiques IPS optionnelles et des exceptions.

Domaines de protection typiques :

• Manipulation de cookies
• Renforcement des URL
• Renforcement des formulaires
• Cross-Site Scripting
• Attaques d’application
• Vérification antivirus
• Clients à mauvaise réputation

Sous Web server > General settings se trouvent d’autres paramètres globaux pour Web Server Protection, notamment le contrôle des versions TLS et la protection contre les schémas HTTP DoS lents. Ces paramètres ne s’appliquent pas seulement à une seule règle. Les changements doivent donc être planifiés consciemment et coordonnés avec les publications WAF existantes.

SFOS 23 : adapter le profil de workers de manière ciblée

Sous Web server > General settings > Worker customization, le pare-feu calcule les valeurs par défaut en fonction des ressources CPU et RAM disponibles ; elles conviennent à la plupart des installations. Des valeurs plus élevées peuvent affecter négativement les performances WAF et les ressources système. N’activez donc Use custom worker profile qu’après avoir confirmé le besoin et évalué les effets. Au préalable, documentez les valeurs actuelles et l’état calculé ou personnalisé du profil, créez une sauvegarde de la configuration et prévoyez une fenêtre de maintenance ainsi qu’un retour en arrière vers exactement cet état antérieur. Cette adaptation ne modifie pas Maximum sessions.

• Start servers : nombre de processus workers lancés au démarrage du serveur web.
• Server limit : nombre maximal de processus workers pouvant s’exécuter simultanément.
• Minimum spare threads : nombre minimal de threads inactifs maintenus disponibles pour de nouvelles requêtes.
• Maximum spare threads : nombre maximal de threads inactifs avant la suppression des threads excédentaires.
• Threads per child : nombre maximal de threads workers par processus worker.
• Asynchronous request worker factor : contrôle la mise à l’échelle des processus workers pour les connexions et les requêtes asynchrones.

Pour l’authentification reverse proxy basée sur formulaire, le champ global Maximum sessions limite les sessions utilisateur simultanées de toutes les règles WAF qui utilisent cette méthode d’authentification. La valeur par défaut est 25,000 et la plage autorisée va de 100 à 100,000. Lorsque la limite est atteinte, le pare-feu ferme les sessions anciennes ou expirées pour en accepter de nouvelles. Il ne s’agit donc pas d’une capacité par règle : dimensionnez-la selon les connexions simultanées des applications concernées, puis vérifiez connexion, déconnexion et changement de session après toute modification.

Pour Slow HTTP protection, Soft limit est le délai initial accordé pour recevoir l’en-tête de la requête. Hard limit fixe la limite supérieure absolue. Extension rate détermine combien d’octets supplémentaires reçus prolongent le soft limit d’une seconde. Ces trois valeurs doivent être testées ensemble et avec de véritables clients lents ; une seule valeur trop permissive peut affaiblir inutilement la protection.

Pour Slow HTTP protection, limiter les exceptions à une adresse IP ou à un réseau aussi restreint que possible. Sophos prend en charge ici les objets hôte IP et réseau, mais pas les plages d’adresses IP ni les listes d’hôtes. La Minimum TLS version est également globale ; avant de la renforcer, tester les anciens clients et toutes les applications publiées au moyen d’une connexion externe réelle.

Comme paramètres TLS globaux, SFOS propose notamment TLS v1.2 (wide compatibility), TLS v1.2 (strict) et TLS v1.3. Ne modifier Custom protocol configuration et Custom cipher configuration qu’avec des valeurs OpenSSL documentées et testées ; les cipher suites de TLS 1.3 sont gérées séparément. Des valeurs incorrectes peuvent empêcher le démarrage du service Apache géré par SFOS et donc de Web Server Protection. Le plan de changement doit inclure les valeurs précédentes, une sauvegarde de la configuration, une fenêtre de maintenance et un accès d’administration alternatif. Ensuite, tester toutes les publications WAF et vérifier reverseproxy.log ; si le service ne démarre pas, restaurer les dernières valeurs personnalisées au lieu d’essayer d’autres variantes en production.

Pour les Protection Policies, le mode est important. Reject bloque et génère des événements visibles dans Log Viewer pour les règles WAF. Monitor journalise seulement, mais ces messages WAF n’apparaissent pas forcément dans Log Viewer ; il faut alors vérifier reverseproxy.log. Monitor peut être utile en phase pilote, mais en protection productive il doit être clair si les attaques sont seulement observées ou réellement rejetées.

Le Common threat filter utilise quatre Filtering Strengths. Level 1 est le plus permissif et n’est pas journalisé ; à partir de Level 2, les correspondances apparaissent dans /log/reverseproxy.log, tandis que le risque de faux positifs augmente aussi. Une règle individuelle ne doit être exclue sous Skip filter rules qu’au moyen de la Rule ID confirmée dans le journal. Désactiver largement une catégorie entière ou un niveau supérieur ne remplace pas cette analyse.

Static URL hardening est sensible à la casse, n’accepte pas de wildcards et n’aide pas pour les URL générées dynamiquement par JavaScript. Form hardening compare la structure du formulaire et prend en charge les formulaires jusqu’à 8,000 octets. Si un contenu binaire est servi à tort comme HTML ou XML, ces deux fonctions peuvent l’endommager ; il faut d’abord corriger le Content-Type du backend plutôt que de désactiver largement la protection.

Pour l’analyse antivirus, la limite de taille s’applique au volume total téléversé dans une requête et non à chaque fichier. Le Request size limit supplémentaire pour le corps HTTP va de 1 à 1,024 Mo et vaut 10 Mo par défaut. HTTP Strict Transport Security n’ajoute l’en-tête HSTS que si la règle WAF utilise Redirect HTTP ; MIME-type sniffing protection définit X-Content-Type-Options: nosniff. Il faut donc tester les téléversements, téléchargements et en-têtes avec l’application réelle.

L’IPS dans une règle WAF doit être évalué séparément. Sophos n’utilise IPS pour WAF que lorsque la communication entre le pare-feu et le serveur web passe par HTTP. Si le backend est connecté en HTTPS, il ne faut donc pas attendre automatiquement le même effet d’une politique IPS sélectionnée.

Les exceptions doivent être définies de manière étroite. Si une application ne fonctionne pas en raison d’un chemin unique ou d’une source spécifique, il ne faut pas désactiver tout le profil de protection. Il est préférable d’avoir une exception ciblée avec chemin, source et justification claire.

⚠️ Chaque exception réduit l’efficacité de la protection. Le chemin, la source, la raison, la date et la date de révision doivent être documentés pour que les solutions temporaires ne deviennent pas permanentes.

Revalider les Protection Policies migrées

Depuis SFOS 18, Web Server Protection utilise l’OWASP ModSecurity Core Rule Set 3.0. Lors de la migration d’anciennes Protection Policies, des catégories existantes ont été fusionnées, des Rule IDs ont été réattribués et des Filtering Strengths ont été introduites. Si l’une des catégories fusionnées était active, la nouvelle catégorie commune peut donc être activée même si une autre partie était auparavant désactivée.

Après une telle mise à niveau, comparer uniquement le nom de la politique ne suffit pas. Les catégories actives, les exceptions et les Filtering Strengths doivent être contrôlées par rapport à la documentation précédente. Il faut ensuite effectuer des tests positifs et négatifs contrôlés avec le trafic réel de l’application, puis vérifier Log Viewer et reverseproxy.log. La politique migrée n’est validée que si les requêtes légitimes continuent de fonctionner et si les attaques de test attendues sont détectées.

Routage spécifique au chemin, WebSocket et équilibrage de charge

WAF peut rediriger les requêtes en fonction du chemin vers différents serveurs backend. Cela est utile si une application a plusieurs composants ou si un seul nom d’hôte doit être réparti sur plusieurs services internes.

Exemples :

• /api/ va à un serveur API.
• /shop/ va à un système de boutique.
• / va au serveur web par défaut.

Le pare-feu n’évalue pas les chemins selon l’ordre du tableau : il donne la priorité aux chemins plus longs, et donc plus spécifiques, avant la route de repli. Cette correspondance doit être testée de manière ciblée. Uniquement pour SFOS 22 : la case WebSocket passthrough peut être activée pour le chemin du site web qui en a besoin ; le trafic WebSocket est alors transmis sans protection WAF, car les données WebSocket ne peuvent pas être inspectées comme du trafic HTTP normal. Pour SFOS 23 : sous Traffic routing, configurez uniquement le chemin WebSocket nécessaire avec Action > Passthrough et le backend prévu. Ce tunnel fonctionne sans inspection WAF et sans politique de protection ; les autres chemins de l’application restent sur Protect. Ne basculez jamais l’ensemble du portail sur Passthrough comme solution de contournement. Testez séparément le passage de la connexion au protocole WebSocket, le transfert des données et la reconnexion. Cela ne permet pas de conclure à l’application du MFA avec Passthrough ; si une authentification est nécessaire, clarifiez la responsabilité avec la personne responsable de l’authentification.

Uniquement pour SFOS 22 : avec la procédure utilisant Protected servers, le chemin par défaut / transmet les requêtes sans correspondance plus spécifique au serveur par défaut affecté. Si cette route par défaut est supprimée, le pare-feu rejette ces requêtes avec 404 Not Found. Pour SFOS 23 : les requêtes sans correspondance plus spécifique utilisent l’action de / ; pour les nouvelles règles, il s’agit de Block par défaut. Conservez délibérément cette route de repli si seuls certains chemins doivent être publiés. Protect pour / n’est pertinent que si la publication de toute l’application est voulue et nécessite de vérifier les accès supplémentaires ainsi ouverts. Aucun statut 404 fixe n’est garanti pour SFOS 23 : la réponse de Block est configurée via Response code.

Avec plusieurs serveurs backend, des sessions persistantes ou un mode veille à chaud sont possibles. Cela aide dans les cas simples de haute disponibilité ou de répartition de charge, mais ne remplace pas un concept complet d’équilibrage de charge d’application.

Atteindre des backends WAF distants via SD-WAN

Si le serveur web protégé ne se trouve pas dans le réseau local du pare-feu, le routage et SD-WAN doivent être vérifiés avec une attention particulière. Pour des backends via des liaisons de site, MPLS ou route-based IPsec, une SD-WAN Route adaptée peut être nécessaire afin que le pare-feu atteigne le Protected Server de manière fiable et que le retour soit correct. Avec route-based IPsec, il faut aussi noter que WAF via route-based IPsec avec des Traffic Selectors pour sous-réseaux n’est pas pris en charge par Sophos ; les connexions Any-to-Any sont l’alternative documentée.

La conception documentée par Sophos commence par une règle WAF fonctionnelle et un tunnel route-based accessible. Sous Routing > Gateways, créer un objet gateway pour le chemin distant avec l’adresse IP du pair, l’interface XFRM adressée et un hôte de surveillance fiable derrière le pair. Ce n’est qu’ensuite que la route ciblée pour le trafic proxy WAF est créée sous Routing > SD-WAN routes :

1. Destination networks correspond à l’interface WAN publique ou à la Hosted address par laquelle le client atteint la règle WAF.
2. Services contient le Listening Port externe de la règle WAF. S’il diffère du port backend interne, le port externe doit explicitement être utilisé ici.
3. Sous Primary gateway, sélectionner le gateway XFRM créé précédemment.
4. Si plusieurs publications utilisent le même gateway, la même SD-WAN Route peut contenir plusieurs adresses WAN publiques et Listening Ports. Des routes séparées sont nécessaires pour des gateways différents.

La validation sépare ensuite les couches : le test externe doit correspondre à la règle WAF attendue ; dans le Log Viewer, corréler la règle WAF, les erreurs du reverse proxy et l’heure ; l’interface XFRM, le moniteur du gateway et la SD-WAN Route doivent être actifs sur le pare-feu ; enfin, le serveur backend doit recevoir la requête et répondre par le chemin prévu. Un tunnel vert ne prouve à lui seul ni la correspondance SD-WAN ni l’accessibilité du backend.

Exploitation et dépannage

Erreurs typiques

• Le nom DNS public pointe vers la mauvaise IP : la règle WAF n’est jamais atteinte.
• Le certificat ne correspond pas au nom d’hôte : les navigateurs affichent des erreurs de certificat ou le matching SNI ne correspond pas.
• Mauvaise Hosted address choisie : le pare-feu matche une autre règle ou aucun trafic WAF.
• Allowed client networks vide : la règle ne fonctionne pas comme prévu.
• Limite de règles WAF non prise en compte : d’autres publications ne peuvent plus être représentées proprement.
• Version Exchange postérieure à 2013 planifiée avec un template WAF : le modèle ne correspond pas à la limite WAF supportée.
• Conflit de port avec User Portal, VPN Portal ou un autre service : l’application n’est pas accessible ou un service du pare-feu répond.
• Le backend n’est pas accessible en interne : les clients externes reçoivent des erreurs bien que DNS et certificat soient corrects.
• Timeout backend mal réglé : les longues réponses se terminent par des erreurs, même si l’application est fondamentalement accessible.
• Backend via VPN ou SD-WAN sans route adaptée : la règle WAF matche, mais le Protected Server n’est pas atteint de manière fiable.
• Route-based IPsec avec Traffic Selectors vers le backend : WAF via ce chemin n’est pas supporté.
• Exception WAF trop large : l’efficacité de la protection diminue inutilement.
• Application WebDAV publiée via WAF : l’application ne fonctionne pas de manière fiable ou n’est pas supportée.
• Le chemin URL contient %2F : WAF répond avec 404 Not Found, bien que la ressource soit accessible directement sur le backend. %2F est la forme encodée dans une URL d’une barre oblique / et doit être distinguée d’une erreur 404 normale du backend.
• Modification de règle sans fenêtre de maintenance : les connexions existantes peuvent être interrompues lors du redémarrage des règles WAF.
• Ancienne règle DNAT et nouvelle règle WAF en concurrence : il est difficile de savoir quelle publication traite le trafic.

Dépannage

Si une publication WAF ne fonctionne pas, il convient de vérifier systématiquement :

1. Le nom DNS public pointe-t-il vers la bonne IP publique ?
2. La bonne Hosted address est-elle sélectionnée dans la règle WAF ?
3. Le port d’écoute est-il libre et non occupé par WebAdmin, User Portal, VPN Portal ou une autre publication ?
4. Le certificat correspond-il au nom d’hôte appelé ?
5. Le serveur web interne est-il accessible depuis le pare-feu ?
6. Les Allowed client networks, Blocked client networks et Blocked countries sont-ils correctement définis ?
7. Le Protected Server se trouve-t-il derrière une route, SD-WAN Route ou connexion VPN qui convient réellement du point de vue du pare-feu ?
8. Existe-t-il une règle WAF plus générale qui correspond avant ?
9. L’accès est-il affiché dans le Log Viewer comme autorisé, bloqué ou rejeté ?
10. Y a-t-il des indices dans /log/reverseproxy.log ?
11. La Protection Policy est-elle en mode Monitor ou Reject ?
12. Le timeout de l’objet web server convient-il à l’application ?

Pour la première analyse, le Log Viewer est utile. Pour un dépannage plus approfondi, les journaux de protection des serveurs web sur le pare-feu sont utiles. Un aperçu des fichiers journaux et des services est disponible dans Associer correctement les service logs Sophos Firewall.

WAF répond avec une erreur 404 lorsque le chemin contient %2F

Un problème particulier concerne les URL contenant une barre oblique encodée. Un appel comme https://portal.example.com/api/files/project%2Freport.pdf peut renvoyer 404 Not Found via Sophos WAF, alors que la ressource existe lorsqu’elle est appelée directement sur le backend. Sophos suit ce comportement sous la référence NC-159041 et ne mentionne actuellement ni version SFOS affectée ou corrigée, ni workaround supporté.

Pour délimiter la cause, il faut comparer la même requête via WAF et directement sur le backend. L’URL exacte et l’heure du test sont importantes :

1. Vérifier si le chemin contient réellement %2F. Une barre oblique normale / ou l’absence du chemin par défaut correspond à un autre problème.
2. Comparer l’heure dans Log Viewer, /log/reverseproxy.log et le log d’accès du serveur web.
3. Si aucune entrée correspondante n’apparaît sur le backend, la requête a probablement été rejetée avant le serveur web. Un test direct sur le backend permet également de confirmer que la ressource existe.

Une exception WAF large ne résout pas précisément ce problème et réduirait inutilement la protection. Il ne faut pas non plus modifier la configuration Apache gérée par SFOS : le traitement restrictif des barres obliques encodées contribue à empêcher le contournement des contrôles de chemin ou d’accès.

La solution la plus propre consiste à faire générer par l’application ou son éditeur des URL sans barres obliques encodées. Si ce n’est pas possible, il faut évaluer consciemment une autre méthode de publication, comme DNAT, un reverse proxy adapté ou un accès privé, par rapport à la perte de protection WAF. Pour les applications qui ne peuvent pas être modifiées, Sophos Support doit examiner le build SFOS concerné et le cas d’utilisation. Les formes project%2Freport.pdf et project/report.pdf ne constituent qu’un schéma de diagnostic et ne sont pas automatiquement équivalentes sur le plan fonctionnel.

Liste de contrôle pour les règles WAF en production

• Le nom de la règle décrit l’application, le nom d’hôte et l’environnement.
• La personne responsable ou le propriétaire du système est documenté.
• DNS, certificat et Hosted address sont vérifiés.
• L’accessibilité du backend a été testée depuis le pare-feu.
• La publication précédente et le retour en arrière sont documentés.
• Les anciennes règles DNAT ou de pare-feu ne concurrencent pas la règle WAF.
• Les tests de mise en service externe sont définis.
• L’accès est limité aux sources ou pays nécessaires.
• Les Threat Feeds et la réponse active aux menaces ont été évalués pour les applications publiques.
• La journalisation est active.
• Le profil de protection n’est pas inutilement désactivé.
• Les exceptions sont étroites, justifiées et temporaires.
• La modification a été testée de l’extérieur.
• La date d’expiration ou la date de révision est documentée.

Questions fréquentes