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 du renforcement de la sécurité, consultez 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, l’application des correctifs, l’authentification forte ou le renforcement des serveurs. Cependant, par rapport à une simple redirection 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 plus ciblée.

WAF n’est cependant pas automatiquement la bonne réponse pour chaque publication. L’essentiel 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.

PHP2Shell — état au 24 octobre 2026 : Pour CVE-2026-109618 et CVE-2026-109619, Sophos n’annonce aucune protection spécifique du WAF de Sophos Firewall dans son avis du 22 octobre, version 4. Les environnements d’exécution PHP concernés sur le backend doivent être mis à jour ; une publication derrière le WAF ne remplace pas cette mise à jour. Les signatures IPS fournies depuis le 22 octobre servent à détecter les tentatives d’exploitation. Il faut contrôler séparément si une stratégie IPS adaptée inspecte le chemin de données réel et quelle action elle applique ; le guide IPS explique ces vérifications. L’absence d’alerte ne prouve pas que les correctifs nécessaires sont installés.

Décision avant publication

Avant de créer une règle WAF, il convient de déterminer si WAF, DNAT, VPN ou ZTNA convient à l’application. Cette décision est plus importante que le formulaire de configuration du pare-feu lui-même, car elle détermine la surface d’attaque, l’exploitation et le dépannage.

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.
Proxy inverse ou ZTNA convient aux plateformes web complexes, à l’intégration des identités 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 simplement être rendu accessible rapidement via une redirection de port, le guide 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. Les applications comme Nextcloud ne doivent donc pas être publiées à l’aveugle via WAF ; leur publication doit être planifiée avec 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 peut être mise en place, mais si elle pourra ensuite être exploitée, testée et retirée en toute sécurité. 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 restriction des sources et MFA en option 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é. La règle de pare-feu, la règle NAT, le serveur cible, la route de retour et la journalisation doivent être vérifiés ensemble.
Application web avec WebDAV ou protocole spécial : ne pas utiliser automatiquement WAF. Tester les fonctions prises en charge, le comportement des clients et les autres méthodes de publication.
Application uniquement destinée aux utilisateurs internes : examiner VPN, ZTNA ou un WAF fortement restreint. La nécessité d’un accès public doit être évaluée de manière critique.

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

Planification et prérequis

Une publication WAF stable nécessite un DNS, un certificat, un backend accessible, une journalisation et un plan de retour en arrière. Ces points doivent être définis avant la configuration.

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 ou non HTTP vers HTTPS
Réseaux sources, pays ou groupes d’utilisateurs autorisés
Profil de protection approprié et politique IPS en option
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 également 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 hôte 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 des connexions persistantes, Keep alive et Timeout doivent être vérifiés délibérément plutôt que repris sans examen.

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 accès et peut réduire les performances. Cette option ne doit donc 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 pare-feu. Cela suffit pour de nombreux environnements, mais peut devenir pertinent plus vite que prévu avec de nombreux portails clients, tenants, systèmes de test ou noms d’hôte distincts. Dans ce cas, il ne faut pas créer aveuglément d’autres règles individuelles, mais examiner la stratégie de nommage, les chemins, les serveurs web virtuels et les autres méthodes 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 prennent actuellement pas en charge 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 leur utilisation, les chemins, méthodes d’authentification et profils de protection réellement nécessaires doivent être vérifiés par rapport à l’architecture Microsoft actuelle ; pour une application moderne, laisser Preconfigured template sur None en cas de doute.

Créer l’objet backend à l’aide d’un exemple explicite

Le nom public et le nom du backend remplissent des fonctions différentes. Dans l’exemple suivant, les utilisateurs ouvrent portal.example.com ; le pare-feu accède au serveur via backend.example.com. Ces deux noms sont des exemples et doivent être remplacés par vos propres noms DNS. Du point de vue du pare-feu, le nom du backend doit se résoudre vers le serveur réel, et non vers sa propre adresse WAF publique : sinon, aucun chemin utilisable vers le backend n’est établi.

Sous Hosts and services > FQDN host > Add, créer un objet nommé WAF_Backend_Portal avec FQDN défini sur backend.example.com, puis l’enregistrer. Il est également possible d’utiliser un objet hôte IP pour un serveur backend fixe. Selon la documentation du produit, les hôtes FQDN offrent une compatibilité plus large avec les serveurs ; la résolution DNS et le serveur cible doivent néanmoins être vérifiés.
Sous Web server > Web servers > Add, créer un objet serveur web WAF_Portal_Server et sélectionner l’objet backend sous Host.
Définir Type et Port en fonction du service réellement à l’écoute sur le backend : dans l’exemple HTTPS, HTTPS et 443 ; pour un backend HTTP, HTTP et, par exemple, 80. Le port d’écoute externe n’est défini que dans la règle WAF et ne doit pas nécessairement être identique au port du backend. Pour un backend HTTP, sécuriser délibérément le segment non chiffré ; un frontend HTTPS ne chiffre pas à lui seul ce segment.
N’activer Keep alive que si le serveur web prend en charge la réutilisation des connexions. Évaluer d’abord Timeout avec la valeur par défaut de 300 secondes. Il s’agit du délai d’attente des données à destination ou en provenance du backend, et non d’une durée totale maximale uniforme pour chaque requête : tant que les données arrivent à temps, une réponse peut durer plus longtemps. En cas de 502, vérifier donc les journaux du backend et les interruptions du flux de données plutôt que d’augmenter immédiatement la valeur.
En fonctionnement normal, ne pas activer Disable backend connection pooling comme optimisation des performances. Enregistrer l’objet, contrôler son affectation à la règle WAF ou au chemin Protect de SFOS 23, puis vérifier un accès représentatif au backend.

Planifier la publication WAF avant la configuration

Une règle WAF ne doit pas être planifiée uniquement dans le formulaire de configuration. Il doit être clair au préalable si le Sophos Firewall doit seulement publier l’application 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 en production :

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 facilité d’administration ultérieure influencent la conception.
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, tandis que des profils trop stricts peuvent perturber le fonctionnement des applications.
Comment la journalisation et les tests seront-ils réalisés ? Log Viewer, reverseproxy.log et les 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

La règle WAF proprement dite se compose de l’adresse publique, des noms d’hôte, du certificat, du serveur cible, des sources autorisées et du profil de protection. Ces champs doivent être considérés ensemble, et non comme des options isolées.

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 serveur web créé au préalable avec l’hôte, le protocole, le port et les paramètres de connexion.
Allowed client networks: réseaux sources autorisés à accéder à l’application.
Blocked client networks / countries: sources ou pays bloqués.
Protection policy: protection WAF contre les attaques web typiques.
Authentication: authentification préalable facultative via le pare-feu.

Sophos crée les 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 de pare-feu normale avec NAT derrière. Elle crée une publication via un proxy inverse. Hosted address, Listening port, Domains, le 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, de DNS ou de backend.

Créer une règle WAF

Le chemin du menu est :

Rules and policies > Firewall

Procédure :

Les nouvelles règles sont activées par défaut. Pour une publication préparée mais pas encore autorisée, vérifiez donc explicitement l’état de la règle et laissez-la désactivée jusqu’à la mise en service prévue. Rule position propose Top ou Bottom ; Rule group affecte la règle à un groupe existant ou créé via Create new. Automatic utilise le premier groupe correspondant au type de règle et aux zones sources et de destination. Le regroupement facilite l’administration, mais ne remplace pas la vérification des accès.

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.

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

SFOS 23 : publier des chemins sous Traffic routing

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.
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.
Pour chaque chemin protégé, affectez la politique d’authentification prévue dans le champ Authentication et définissez Allowed client networks de manière réfléchie, 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.
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.
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.
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.

Le chemin par défaut peut être modifié, cloné ou supprimé. Un clone ne reprend pas l’autorisation fonctionnelle : vérifiez à nouveau l’action, le backend, l’authentification et les sources pour la nouvelle affectation. Ne supprimez pas / par inadvertance s’il constitue la route de repli volontairement bloquante.

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 cours via ces règles peuvent alors être interrompues. Les modifications des règles WAF en production doivent donc être effectuées pendant une fenêtre de maintenance ou, à défaut, en tenant explicitement compte de cette interruption possible.

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 approprié. Pour les portails d’administration, les portails partenaires ou les outils internes, il faut d’abord examiner 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’affectation doit être testée par adresse IP, port et protocole avant la mise en production.

Le port par défaut du User Portal est 4443 ; les composants d’écoute des portails et leurs limites sont présentés dans la vue d’ensemble des portails.

SFOS 23 : définir précisément les réponses Block et Redirect

Une action de routage peut regrouper plusieurs entrées sous Paths si elles nécessitent toutes le même traitement. Sous Traffic routing > Add new path, sélectionnez les chemins et l’action, renseignez les champs propres à l’action et enregistrez l’entrée de chemin. Utilisez des entrées distinctes si les backends, les règles d’accès ou les destinations de redirection diffèrent.

Pour Block, Response code détermine la réponse. Par exemple, /admin/ peut utiliser Forbidden (403), tandis que / reste sur Block comme route de repli. La sélection documentée comprend 400 à 417 ainsi que 422, 423, 424 et 426. Choisissez le code selon le sens voulu : 403 indique un accès refusé, 404 un contenu introuvable. Choisir le code 401 ne configure pas de politique d’authentification ; le code de statut seul ne protège pas l’accès par une connexion authentifiée. Lors du test d’acceptation, vérifiez le statut configuré et l’absence de requête correspondante vers le backend.

Pour Redirect, la configuration comprend, outre Paths et Action, les champs Response code, Protocol, Host, Path et Port. Exemple : /old-portal/ avec Temporary Redirection (307), Protocol défini sur HTTPS, un hôte FQDN pour portal.example.com, Path défini sur /portal/ et Port sur 443. Remplacez les noms et les chemins par ceux de votre application cible. 307 désigne une redirection temporaire qui conserve la méthode de la requête ; cela convient à un pilote contrôlé si la destination traite la même méthode. Testez néanmoins séparément le navigateur et le client API, en particulier pour les requêtes POST. La destination /portal/ doit elle-même être accessible et protégée, par exemple par un chemin Protect adapté ; une redirection seule n’y crée aucune configuration de backend ou d’accès.

La sélection propose 300, 301, 302, 303, 304, 305, 307 et 308. Tous les codes proposés ne correspondent pas à une redirection habituelle vers une nouvelle page : 304 décrit la validation du cache. 305 est obsolète pour des raisons de sécurité et n’est pas recommandé pour les applications publiques. N’utilisez 301 ou 308 que si le changement doit être permanent, et tenez compte du comportement des clients et des caches lors du retour en arrière. Les ports par défaut de la destination sont 80 pour HTTP et 443 pour HTTPS. Redirect n’effectue aucune inspection WAF et n’envoie pas la requête à un backend de cette route ; vérifiez donc côté client le statut et la destination de redirection, puis la protection de l’application cible.

Adapter de manière ciblée l’en-tête Host, le HTML et la compression

Les Advanced settings d’une règle WAF permettent de résoudre des problèmes précis de proxy inverse. Ce ne sont pas des options à activer systématiquement :

Pass host header transmet au backend l’en-tête Host demandé par le client. Lorsque plusieurs sites web sont hébergés sur un serveur, cela peut permettre de sélectionner le bon hôte virtuel. Configurez le vHost du backend en fonction du nom publié et vérifiez dans le journal d’accès qu’aucun autre site web ne répond.
Rewrite HTML adapte les liens dans les pages renvoyées. Par exemple, si un lien absolu pointe vers http://backend.example.com/ alors que l’application est publiée sous le nom public, une réécriture peut être nécessaire. Elle n’est généralement pas requise si les noms d’hôte publics sont déjà corrects ou si tous les liens sont relatifs. Le traitement concerne les Content-Types text/* et *xml* ; les téléchargements binaires doivent être servis avec le bon Content-Type, faute de quoi ils risquent d’être endommagés. Testez ensuite séparément les liens publics, les téléchargements et les fonctions de l’application.
Rewrite cookies réécrit les cookies dans les pages renvoyées. En cas de problèmes de session, examinez les cookies réellement définis ainsi que la connexion et la déconnexion, au lieu de confondre la réécriture des cookies avec Cookie signing : la réécriture et la protection contre la manipulation remplissent des fonctions différentes.
Disable compression support est une aide ciblée en cas de pages mal affichées ou d’erreurs de Content-Encoding. Le pare-feu demande alors au backend des données non compressées et les transmet sans compression, quel que soit l’encodage demandé. Documentez l’état précédent, répétez le même appel de page et désactivez l’option si elle ne résout pas le problème.

Certains ports sont réservés aux services système, même lorsque le service concerné n’est pas utilisé. Un listener libre ne suffit pas à rendre un tel port disponible pour WAF ; la vue d’ensemble Ports réservés de Sophos Firewall facilite la planification. Traffic shaping attribue à la publication de la bande passante et une priorité dépendant des horaires. Il s’agit d’une décision d’exploitation, pas d’une protection applicative supplémentaire ; lorsque la politique est activée, testez également les téléversements et les téléchargements sous une charge représentative.

Mise en service et validation

L’enregistrement de la règle ne suffit pas à terminer la publication. Seuls des tests externes, des journaux pertinents et un retour en arrière clairement défini rendent la modification prête pour la production.

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. L’essentiel est que DNS, certificat, Hosted address, backend, profil de protection et journalisation fonctionnent ensemble. En particulier lorsqu’il existe déjà des redirections de port, le changement doit être traité comme une petite mise en production.

Avant la mise en service, vérifiez les points suivants :

Documentez la configuration actuelle du pare-feu ou, au minimum, les paramètres de règle et de certificat concernés.
Identifiez les règles DNAT ou de pare-feu existantes 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 le changement si le nom d’hôte public passe d’une ancienne publication à WAF.
Prévoyez un accès de test externe ; ne testez pas uniquement depuis le LAN interne.
Définissez les cas de test : page d’accueil, connexion, téléversement, téléchargement, chemin API, WebSocket, déconnexion et message d’erreur.
Définissez les emplacements des journaux 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 une connexion impossible, un backend inaccessible, un certificat incorrect, un taux d’erreur élevé ou des 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 le basculement 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, la correspondance avec la règle WAF, le profil de protection ou l’application.

Client externe : vérifier la résolution DNS, le certificat, le statut HTTP, la connexion et les chemins importants. L’application devrait s’ouvrir via le nom d’hôte public sans avertissement de certificat.
Sophos Firewall : vérifier Log Viewer, la règle WAF, reverseproxy.log et les signatures bloquées. La bonne règle WAF devrait traiter l’accès et les journaux devraient montrer les requêtes autorisées ou bloquées avec le motif du blocage.
Serveur web backend : vérifier le journal d’accès, le journal d’erreurs, la session applicative et X-Forwarded-For. La requête devrait atteindre le bon vHost ou chemin, et la logique de traitement de l’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 assure l’authentification.
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 traitement du blocage soient visibles.

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

Sécuriser la protection et les accès

Pour les applications web publiques, WAF n’est qu’une couche de protection. Les certificats, les restrictions sur les sources, les Threat Feeds, les profils de protection et la journalisation du backend doivent être planifiés ensemble.

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, puis 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 wildcard 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. *. n’est autorisé qu’au début, par exemple *.example.com ; plusieurs domaines wildcard peuvent figurer dans une même règle.
Les traits de soulignement dans le label le plus à gauche du domaine ne constituent pas un nom DNS conforme et doivent ê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étermine pour HTTPS, à partir de SNI et du nom d’hôte, quelle règle WAF correspond.

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 une conception rigoureuse de la publication. Si plusieurs applications utilisent des noms d’hôte similaires, une documentation claire des règles et des certificats est nécessaire ; sinon, il devient difficile de savoir par la suite quelle règle WAF correspond 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.

Le nom de l’objet certificat ne peut contenir que des caractères alphanumériques du jeu de caractères US-ASCII ; il ne doit pas être confondu avec le nom DNS dans le certificat. Après la sélection, contrôlez les Domains renseignés automatiquement et modifiez, ajoutez ou supprimez des entrées si nécessaire. HTTPS rend le listener accessible via HTTPS, mais pas également via HTTP. Redirect HTTP redirige séparément les accès du port 80 vers le port 443 ; ces listeners et les éventuels conflits de port doivent donc aussi être planifiés.

Un nom de sous-domaine non correspondant ne provoque pas nécessairement l’affichage d’une page de blocage graphique. La documentation montre par exemple un statut 403 pour un accès via un autre sous-domaine. Vérifiez donc le statut HTTP et reverseproxy.log, et pas seulement l’apparence de la page dans le navigateur.

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 exploité. C’est important pour :

Les journaux d’application et l’analyse de sécurité
Les limites de débit ou la protection des connexions au niveau de l’application
L’analyse des erreurs en lien avec l’utilisateur ou l’IP source
La corrélation SIEM ou la supervision
L’analyse forensique 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 que Log Viewer, reverseproxy.log et le 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. Vous pouvez limiter l’accès dès la règle WAF.

Restrictions utiles :

Autoriser uniquement les adresses IP sources connues ou les réseaux partenaires.
Bloquer les pays non nécessaires.
Bloquer les adresses IP dont le pays d’origine est inconnu uniquement après avoir évalué le risque de bloquer votre propre accès.
Pour les portails, utiliser également WAF-MFA ou une authentification préalable.
Bloquer les sources malveillantes connues via Threat Feeds.

Pour le blocage des pays et des IP malveillantes, 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 considérer uniquement la règle WAF elle-même. Depuis SFOS 22, les Threat Feeds deviennent également plus pertinents pour le trafic entrant et redirigé, comme les publications WAF et DNAT. Le pare-feu peut comparer les correspondances de ce trafic avec les MDR Threat Feeds, NDR Essentials et Third-Party Threat Feeds.

Pour les administrateurs, cela signifie que WAF est la couche de publication, tandis que les Threat Feeds et la réponse active aux menaces peuvent bloquer ou rendre visibles d’autres sources malveillantes connues. Cela ne remplace cependant ni la gestion des correctifs, ni une authentification rigoureuse, ni 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 exploitation ?
Existe-t-il un processus pour les faux positifs, la mise en liste d’autorisation et les autorisations d’urgence ?
Est-il clair qui réagit aux correspondances et si elles sont seulement journalisées ou activement bloquées ?

Cet examen doit avoir lieu avant la mise en service, en particulier pour les portails clients, les interfaces d’administration ou les accès partenaires. Si un flux bloque par la suite du trafic de production, l’équipe d’exploitation doit savoir où consulter la correspondance et comment trancher de manière rigoureuse : véritable attaque, fausse alerte 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 applicatives
Analyse 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 attaques HTTP DoS lentes. Ces paramètres ne s’appliquent pas seulement à une seule règle. Les modifications doivent donc être planifiées de manière délibérée et coordonnées 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 par proxy inverse 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 la connexion, la déconnexion et les changements 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, limitez les exceptions à l’adresse IP ou au réseau le plus restreint nécessaire. 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, testez les anciens clients et toutes les applications publiées au moyen d’un véritable test externe.

Comme paramètres TLS globaux, SFOS propose notamment TLS v1.2 (wide compatibility), TLS v1.2 (strict) et TLS v1.3. Ne modifiez Custom protocol configuration et Custom cipher configuration qu’avec des valeurs OpenSSL documentées et testées ; les suites cryptographiques 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, toutes les publications WAF et reverseproxy.log doivent être vérifiés ; si le service ne démarre pas, annulez les dernières valeurs personnalisées au lieu d’essayer d’autres variantes en production.

Pour les politiques de protection, 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. Le mode Monitor peut être utile en phase pilote, mais pour la protection en production, 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 globalement une catégorie entière ou un niveau supérieur ne remplace pas cette analyse rigoureuse.

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 donc 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 de définir une exception ciblée avec un chemin, une source et une 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.

Créer une politique de protection et comprendre son efficacité

Sous Web server > Protection policies > Add, attribuez un nom explicite, par exemple WAF_Portal_Protection, configurez les fonctions de protection nécessaires et sélectionnez Save. Sélectionnez ensuite cette politique dans le champ Protection de la règle WAF ; sous SFOS 23, elle ne s’applique qu’aux chemins avec Protect. Une politique par défaut existante, par exemple pour Exchange Autodiscover, ne doit être utilisée que pour le cas d’utilisation correspondant.

Pour une phase pilote de votre application, choisissez d’abord clairement entre Monitor et Reject. Monitor ne bloque pas et n’affiche pas les messages WAF concernés dans Log Viewer ; il faut consulter reverseproxy.log. La meilleure visibilité offerte par Reject ne doit pas être confondue avec une compatibilité applicative déjà testée. Pass Outlook anywhere permet aux clients Outlook externes de contourner la protection des serveurs web pour accéder à Exchange. Cette option n’est pas une solution générale de compatibilité pour les portails modernes et doit rester désactivée en l’absence d’un cas d’utilisation hérité dûment justifié.

Bien comprendre la protection des cookies, des URL et des formulaires

Cookie signing complète un cookie défini par le serveur par un second cookie contenant un hachage calculé à partir du nom, de la valeur et d’un secret connu uniquement du pare-feu. Si le client ne fournit pas la paire correspondante, le cookie est rejeté. Cette fonction protège contre les manipulations, mais ne remplace ni des sessions applicatives sécurisées ni une configuration correcte des cookies sur le backend. Après l’activation, testez la connexion, le panier ou les autres parcours qui dépendent des cookies.

Avec Static URL hardening, le pare-feu signe les liens statiques et détermine, à partir de la réponse du serveur, quels liens suivants sont autorisés. Entry URLs définit les URL d’entrée accessibles sans signature de renforcement ; pour un site web simple, / peut être le point d’entrée. Cette liste n’est pas une liste générale de routage. Respectez la casse et n’ajoutez pas de wildcards. Les applications avec des URL générées par JavaScript ou des liens profonds légitimes nécessitent une vérification distincte. Form hardening signe la structure initiale du formulaire et rejette les formulaires modifiés. La limite existante de 8,000 octets et un Content-Type HTML/XML correct restent essentiels.

L’exemple simple documenté de protection contre les attaques utilise Reject, Static URL hardening avec le point d’entrée /, Form hardening, Antivirus, Block clients with bad reputation et Common threat filter. Cookie signing, Pass Outlook anywhere et Skip remote lookups for clients with bad reputation y sont désactivés. Il s’agit d’un profil de test pour ce parcours précis, pas d’une recommandation universelle ni d’une preuve que les paramètres par défaut conviennent à toutes les applications. Pour un portail moderne, évaluez chacune de ces options à partir du trafic réel de l’application. L’option Basic with passthrough qui y est mentionnée n’est pas non plus une recommandation de MFA ; le mode client, la transmission des identifiants et les modèles sont expliqués dans l’article sur l’authentification WAF et le MFA.

Configurer l’antivirus et la réputation de manière réfléchie

Pour Antivirus, Mode détermine si un ou deux moteurs d’analyse sont utilisés ; en analyse simple, sélectionnez le moteur. Direction définit l’analyse des téléversements, des téléchargements ou des deux sens. Block unscannable content bloque, par exemple, les fichiers chiffrés ou endommagés qui ne peuvent pas être analysés. Cette option renforce l’application de la protection, mais peut affecter des documents chiffrés légitimes ; définissez donc au préalable les processus métier autorisés et la procédure de recours au support.

Limit scan size limite le volume à analyser ; 0 ou un champ vide signifie qu’aucune limite de taille n’est imposée à l’analyse. Exemple : avec une limite d’analyse de 50 Mo et des fichiers de 45, 5 et 10 Mo dans un même téléversement, le dernier fichier n’est pas analysé. Un téléversement réussi ne prouve donc pas que chaque fichier qu’il contient a été vérifié. Cette limite d’analyse doit être distinguée de Request size limit, qui concerne l’ensemble du corps HTTP : augmenter la limite du corps ne rend pas automatiquement davantage de contenu analysable. Choisissez les limites en fonction des téléversements réellement nécessaires, des ressources et des exigences de sécurité, puis testez les téléversements de plusieurs fichiers et les contenus non analysables dans un environnement de test autorisé.

Block clients with bad reputation utilise des informations RBL et GeoIP : Sophos SXL pour les RBL et MaxMind pour GeoIP. Des blocages sont également documentés pour les classifications A1 (proxys anonymes ou services VPN) et A2 (FAI par satellite). Cela peut affecter des accès partenaires légitimes. Skip remote lookups for clients with bad reputation peut améliorer les performances, mais modifie l’évaluation effectuée au moyen des requêtes distantes ; ne l’activez pas sans en mesurer les conséquences et ne l’assimilez pas à une liste d’autorisation des sources.

Évaluer Common threat filter par catégorie et par niveau de filtrage

Les catégories répondent à des besoins différents et doivent être choisies délibérément pour l’application :

Application attacks: détecte notamment les accès non autorisés à des chemins et les tentatives typiques d’exécution de commandes, y compris après une éventuelle intrusion.
SQL injection attacks: vérifie les arguments des requêtes pour détecter des commandes SQL intégrées et des caractères d’échappement.
XSS attacks: vérifie les entrées pour détecter des balises de script et du code intégrés.
Protocol enforcement: vérifie la conformité au protocole, les en-têtes courants tels que Host et User-Agent, les limites des arguments et l’utilisation autorisée de HTTP. Un client légitime au comportement inhabituel peut donc aussi être signalé.
Scanner detection: détecte les schémas typiques des bots, des robots d’indexation et des scans ; les accès souhaités des moteurs de recherche ou des outils de supervision doivent néanmoins être testés.
Data leakage: empêche que des informations sensibles parviennent au client, par exemple via les messages d’erreur du serveur. Si Application attacks ou SQL injection attacks est actif, cette catégorie doit également être examinée, car les domaines de détection se recoupent.

Filter strength est réglé par défaut sur Level 1, qui génère le moins de faux positifs. Level 2 ajoute, par exemple, des expressions régulières pour les injections SQL/XSS et d’autres mots-clés d’injection de code ; Level 3 ajoute des règles, des listes de mots-clés et des limites sur les caractères spéciaux ; Level 4 restreint encore davantage les caractères spéciaux et nécessite des tests de faux positifs particulièrement approfondis avant la mise en service. Les limites de journalisation décrites précédemment restent applicables : Level 1 n’est pas journalisé, tandis que Level 2 et les niveaux supérieurs apparaissent dans /log/reverseproxy.log. Ne considérez pas un niveau supérieur comme validé sur le plan de la sécurité simplement parce qu’une page d’accueil s’ouvre.

Vérifier HSTS et la protection MIME avant leur activation

Avec HTTP Strict Transport Security et Redirect HTTP activé, le pare-feu ajoute cet en-tête :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 correspond à un an. Cela ne concerne pas uniquement le point d’entrée testé : includeSubDomains inclut les sous-domaines, et les navigateurs peuvent mémoriser cette directive. Avant l’activation, HTTPS, les certificats et tous les sous-domaines concernés doivent fonctionner durablement ; décocher ensuite la case ne constitue pas un retour en arrière immédiat pour les directives déjà enregistrées par les navigateurs. La présence de preload dans l’en-tête ne prouve pas à elle seule l’inclusion dans une liste de préchargement des navigateurs. MIME-type sniffing protection ajoute X-Content-Type-Options: nosniff ; corrigez donc les types MIME incorrects sur le backend plutôt que de supprimer systématiquement l’en-tête. Vérifiez les deux en-têtes depuis le client externe.

Créer des exceptions aussi ciblées que nécessaire

Sous Add new exception, définissez Paths, Sources, Operation et les vérifications précises à ignorer. Les chemins des exceptions sont sensibles à la casse et acceptent les wildcards, par exemple /products/*/images/*. Cela les distingue des Entry URLs de la politique Static URL Hardening, qui n’acceptent pas de wildcards. Pour Operation, l’opérateur booléen est déterminant : la combinaison d’un chemin et d’une source est plus restrictive que celle d’un chemin ou d’une source. Vérifiez l’intersection souhaitée avant l’enregistrement, afin qu’une source partenaire ne soit pas accidentellement exemptée de protection pour tous les chemins.

Pour Sources d’une exception, les adresses IP, les plages, les listes et les réseaux sont documentés. Cela ne doit pas être extrapolé aux autres champs : pour Path-specific routing sous SFOS 22 ainsi que pour les champs Allowed client networks et Blocked client networks de Passthrough sous SFOS 23, seuls les types d’hôtes IP et Network sont documentés, pas les IP ranges ni les IP lists. Pour une restriction d’accès prévisible, utilisez dans ces champs des objets IP individuels ou des objets réseau.

Les options d’une exception permettent notamment d’ignorer Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation et certaines catégories de Common threat filter. Deux options nécessitent une vigilance supplémentaire :

Never change HTML during static URL hardening or form hardening empêche la réécriture de la page HTML, par exemple si l’application dépend de liens inchangés. Cela ne signifie pas automatiquement que les liens non signés seront acceptés ; une exception ciblée de renforcement peut être nécessaire à cet effet.
Accept unhardened form data accepte les données de formulaire sans signature de renforcement. Une exception pour Form hardening ne suffit pas à elle seule. Cette autorisation supplémentaire supprime une autre vérification et ne convient qu’à un parcours précisément délimité et justifié.

Conservez au préalable la requête légitime en échec, l’heure et la Rule ID confirmée. Répétez ensuite la même requête et effectuez un contre-test avec une source ou un chemin non couvert par l’exception. L’exception n’est correctement délimitée que si le parcours nécessaire fonctionne et si le reste de la protection est maintenu ; en cas de doute, excluez une seule Rule ID confirmée sous Skip filter rules plutôt qu’un domaine entier de protection.

Revalider les politiques de protection migrées

Depuis SFOS 18, Web Server Protection utilise l’OWASP ModSecurity Core Rule Set 3.0. Lors de la migration d’anciennes politiques de protection, des catégories existantes ont été fusionnées, des Rule IDs ont été réattribuées et des Filtering Strengths ont été introduites. Si l’une des catégories fusionnées était auparavant 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.

Pour l’ancienne migration vers SFOS 18, les correspondances suivantes sont importantes : Protocol violations, Protocol anomalies, Request limits et HTTP policy ont été regroupés dans Protocol enforcement ; Generic attacks et Tight security dans Application attacks ; Bad robots dans Scanner detection ; Outbound dans Data leakage. Rigid filtering migre vers Level 1 et doit être réévalué délibérément. La catégorie Trojans a été supprimée ; l’antivirus assure la protection correspondante. Les règles déjà exclues auxquelles une nouvelle Rule ID a été attribuée restent exclues, tandis que les IDs sans correspondance, supprimées ou fusionnées dans une nouvelle règle sont retirées de la liste des exclusions. Il ne faut donc pas copier l’ancienne liste d’exceptions sans vérification, mais la comparer à la politique actuelle et aux journaux actuels.

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 comporte 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 applicatif.

Sans mécanisme supplémentaire d’affinité, les requêtes sont réparties entre les différents serveurs web sélectionnés. Sticky session cookie associe le navigateur à un serveur backend ; si celui-ci tombe en panne, le cookie est mis à jour et la session bascule vers un autre serveur. Cela ne garantit pas le transfert de l’état applicatif : un panier d’achat peut, par exemple, nécessiter un stockage de session partagé.

Hot-standby mode envoie d’abord toutes les requêtes au premier serveur sélectionné et utilise les autres comme serveurs de secours. Lorsque le serveur principal redevient disponible, les sessions y reviennent en principe ; si Sticky session cookie est activé, la session existante reste sur le serveur de secours. Vérifiez donc séparément, lors des tests d’acceptation, le serveur principal, l’ordre des serveurs de secours, la panne, le rétablissement et une opération de connexion ou de panier d’achat réellement dépendante de l’état de session.

Le champ Authentication figure également pour Passthrough dans le tableau de SFOS 23, alors que la présentation des fonctions associe l’authentification à Protect. Cette divergence documentaire ne doit pas être résolue par supposition. Si WAF-MFA est nécessaire, faites reposer la partie protégée sur Protect et sur une politique explicite ; les distinctions et les tests sont décrits dans Authentification WAF avec MFA.

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 accessibles via des liaisons intersites, MPLS ou IPsec basé sur le routage, une route SD-WAN adaptée peut être nécessaire afin que le pare-feu atteigne le Protected Server de manière fiable et que le chemin de retour soit correct. Avec IPsec basé sur le routage, il faut aussi noter que WAF via IPsec basé sur le routage 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 basé sur le routage accessible. Sous Routing > Gateways, créez un objet passerelle pour le chemin distant avec l’adresse IP du pair, l’interface XFRM dotée d’une adresse IP 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 :

Sous Routing > Gateways > IPv4 gateway > Add, créez et enregistrez la passerelle. Dans l’exemple, elle s’appelle gw6 et utilise Gateway IP 10.12.13.2 et Interface xfrm1-10.12.13.1. Sous Monitoring condition, utilisez un hôte qui répond de manière fiable derrière la passerelle ; l’exemple documenté utilise 10.12.13.2. Remplacez ces adresses privées et cette interface par l’adressage réel du tunnel et un hôte de surveillance approprié.
Sous Routing > SD-WAN routes, sélectionnez IPv4, puis Add, avec par exemple le nom SD-WAN_WAF_Portal. Dans Destination networks, supprimez Any et sélectionnez l’interface WAN publique ou la Hosted address par laquelle le client atteint la règle WAF ; dans l’exemple, #Port1. Pour cette route WAF documentée, il ne s’agit pas simplement de l’adresse IP privée du backend.
Dans Services, supprimez Any et sélectionnez le port d’écoute externe de la règle WAF, dans l’exemple TCP 8080. S’il diffère du port backend interne, le port externe doit explicitement être utilisé ici. Ce port non standard doit également être pris en compte dans la requête de test externe.
Sous Link selection settings, sélectionnez Primary and Backup gateways et définissez comme Primary gateway la passerelle XFRM gw6 créée précédemment. Enregistrez la route. Si plusieurs publications utilisent la même passerelle, la même route SD-WAN peut contenir plusieurs adresses WAN publiques et ports d’écoute. Des routes séparées sont nécessaires pour des passerelles différentes.

La procédure SD-WAN renvoie à un guide de VPN basé sur le routage avec des sélecteurs de trafic ; la référence des règles WAF exclut toutefois explicitement les sélecteurs de trafic fondés sur des sous-réseaux. Pour ce cas d’utilisation WAF, prévoyez donc une connexion Any-to-Any et n’interprétez pas le titre du guide référencé comme une autorisation d’utiliser des configurations de sélecteurs de sous-réseaux.

La validation sépare ensuite les couches : le test externe doit correspondre à la règle WAF attendue ; dans le Log Viewer, corrélez la règle WAF, les erreurs du proxy inverse et l’heure ; l’interface XFRM, le moniteur de la passerelle et la route SD-WAN 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

En exploitation, l’essentiel est de pouvoir continuer à comprendre le fonctionnement de la publication : quelle règle correspond au trafic, quels journaux sont pertinents, quelles exceptions existent et comment procéder en cas d’incident.

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 la correspondance SNI n’est pas correcte.
Mauvaise Hosted address choisie : le pare-feu sélectionne une autre règle ou ne reconnaît aucun trafic WAF correspondant.
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 configurées correctement.
Version Exchange postérieure à 2013 planifiée avec un modèle WAF : le modèle ne correspond pas à la limite de prise en charge de WAF.
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.
Délai d’expiration du backend mal réglé : les longues réponses se terminent par des erreurs, même si l’application est globalement accessible.
Backend accessible via VPN ou SD-WAN sans route adaptée : la règle WAF correspond, mais le Protected Server n’est pas atteint de manière fiable.
IPsec basé sur le routage avec Traffic Selectors vers le backend : WAF via ce chemin n’est pas pris en charge.
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 prise en charge.
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, vérifiez systématiquement les points suivants :

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

Pour la première analyse, le Log Viewer est utile. Pour un dépannage plus approfondi, consultez les journaux de Web Server Protection sur le pare-feu. Un aperçu des fichiers journaux et des services est disponible dans Dépannage de Sophos Firewall : services et journaux.

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 précise affectée ou corrigée, ni solution de contournement prise en charge.

Pour délimiter la cause, comparez de manière contrôlée la même requête via WAF et directement sur le backend. L’URL exacte et l’heure du test sont importantes :

Vérifiez si le chemin contient réellement %2F. Une barre oblique normale / ou l’absence du chemin par défaut correspond à un autre problème.
Comparez l’heure dans Log Viewer, /log/reverseproxy.log et le journal d’accès du serveur web.
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 d’exclure l’absence de la ressource elle-même.

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 proxy inverse adapté ou un accès privé, au regard de 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 motif permettant d’identifier le problème 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 externes de mise en service 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 limitées dans le temps.
La modification a été testée de l’extérieur.
La date d’expiration ou la date de révision est documentée.

Situer les objets WAF dans l’API XML

Pour les automatisations, la publication, le backend et la politique de protection forment un ensemble, mais restent des objets distincts. FirewallRule avec PolicyType HTTPBased contient HTTPBasedPolicy ; RealServers décrit le serveur web backend et ProtocolSecurity la politique de protection. La règle WAF référence ces objets, elle ne remplace pas leur configuration. L’accès, la vérification TLS, les secrets, les opérations d’écriture explicites et l’évaluation du statut XML sont expliqués dans Limiter l’accès à l’API XML de manière sûre.

Les correspondances suivantes expliquent les références SFOS 22/23, mais ne constituent pas des modèles de requêtes exécutables. Avant toute écriture, comparer l’API help du build installé avec l’objet existant, préparer une sauvegarde et une procédure de retour arrière, puis vérifier d’abord une requête de lecture sans risque. Si la syntaxe, l’unité ou la correspondance des actions n’est pas clarifiée, ne pas écrire, mais demander une clarification au support. Cela vaut tout particulièrement après un changement de version.

Ne pas confondre publication et chemins d’accès

Name identifie la FirewallRule ; la référence autorise au maximum 60 caractères, sans virgules, en UTF-8. Position est obligatoire et indique Bottom, Top, After ou Before ; pour les deux dernières variantes, la règle de référence nommée doit également être fournie. Pour Status, le tableau indique la valeur par défaut ON et les valeurs d’écriture Disable et Enable : omettre ce champ n’est pas une manière sûre de préparer une publication désactivée. Selon le tableau, LogTraffic est défini par défaut sur Disable ; vérifier explicitement la journalisation. IPFamily propose aussi IPv6 dans le contrat commun de FirewallRule, mais HTTPBasedPolicy est explicitement limité à IPv4. Les règles réseau et utilisateur sont traitées dans Règles de pare-feu, et ne doivent pas être reprises comme charge utile WAF.

Dans la partie WAF, HostedAddress, ListenPort, HTTPS, HTTPSCertificate et Domains/Domain correspondent au point d’écoute public. Le tableau présente HostedAddress, ListenPort, HTTPS et Domains comme des champs obligatoires. ListenPort est un entier compris entre 1 et 65535 ; les valeurs documentées sont 80 lorsque HTTPS est désactivé et 443 lorsque HTTPS est activé. Il ne s’agit pas du port du backend. RedirectHTTP est la redirection HTTP distincte. Vérifier ensemble le nom public, le certificat et le point d’écoute après chaque modification.

Les associations de chemins se trouvent sous HTTPBasedPolicy/AccessPaths/AccessPath. À cet emplacement, backend référence les objets serveur web ; allowed_networks, denied_networks, blocked_countries et block_unknown_country décrivent l’accès des clients. stickysession_status et hot_standby concernent l’affinité de session et la sélection du backend. Une politique d’authentification référencée est expliquée dans l’article sur l’authentification WAF ; la présence d’un champ ne prouve pas à elle seule l’application de la MFA pour chaque action.

Différence entre versions : Le tableau SFOS 22 décrit path comme une chaîne unique et backend comme un tableau obligatoire. Dans SFOS 23, path est un tableau comportant plusieurs valeurs, tandis que backend est indiqué comme facultatif. Selon le tableau, les valeurs de chemin sont limitées à 63 caractères et ne doivent pas contenir de virgules. Facultatif ne signifie pas ici qu’il soit pertinent de publier un chemin Protect ou Passthrough sans backend affecté : l’interface actuelle exige la sélection d’un backend pour ces actions, tandis que Block et Redirect ne publient aucun backend.

SFOS 23 ajoute action en minuscules, avec les valeurs autorisées 0, 1, 2, 3, ainsi que response_code, redirect_protocol, redirect_host, redirect_port et redirect_path. La référence n’associe pas ces quatre nombres aux actions de l’interface. Ne pas établir de correspondance à partir de leur ordre ou d’une supposition ; une correspondance confirmée pour le build installé est indispensable avant toute modification automatisée. Action avec une majuscule, avec les valeurs Accept, Drop, Reject, figure dans l’exemple sous UserPolicy ou NetworkPolicy, et non dans le bloc WAF. Il ne remplace ni l’action WAF externe de l’interface ni AccessPath/action. Le tableau indique littéralement http et https pour redirect_protocol, 1 à 65535 pour redirect_port et au maximum 8192 caractères pour redirect_path. response_code y est uniquement décrit comme un entier ; le choix dans l’interface présenté plus haut reste déterminant pour la configuration concrète.

L’exemple ne constitue pas non plus une preuve du schéma : il mélange path et Path, contient des références vides et des valeurs de remplacement, et ne présente pas intégralement HTTPSCertificate ni LogTraffic dans le bloc WAF. SFOS 22 présente encore websocket_passthrough ; SFOS 23 utilise le modèle d’actions. Confirmer donc la graphie, l’imbrication, les champs nécessaires et la journalisation dans le contrat propre au build, plutôt que de compléter mécaniquement l’exemple. ProtocolSecurity dans le bloc WAF référence la politique de protection. Les options avancées PassHostHeader, RewriteHTML, RewriteCookies et CompressionSupport relèvent des adaptations du reverse proxy expliquées plus haut ; ne pas harmoniser des valeurs contradictoires entre l’exemple et le tableau en créant ses propres énumérations.

L’exemple présente également SourceNetworks/Network et ExceptionNetworks/Network, tandis que son commentaire mentionne comme alternatives Authentication, AllowFrom, BlockFrom ou AccessPaths. Ne pas en déduire une équivalence d’alias, une combinaison autorisée ou une règle de priorité. Pour les objets existants utilisant cette représentation de l’accès, clarifier la structure et ses effets dans le build installé ; si ces points restent incertains, ne pas effectuer d’écriture automatisée.

Un bloc distinct Exceptions/Exception est prévu pour les exceptions. Dans ce bloc, path, source et op relient les conditions ; le tableau indique littéralement and, or, AND, OR pour op. skipcookie, skipurl, skipform, skipav et skipbadclients omettent les vérifications correspondantes. En revanche, skiphtmlrewrite empêche la modification des contenus correspondants, et skipform_missingtoken autorise les données de formulaire sans signature de durcissement, en complément de l’exception de formulaire. La ligne correspondante du tableau inverse la description et la valeur par défaut ; ne pas en déduire une valeur par défaut fiable. Les conséquences de sécurité des deux options décrites plus haut restent déterminantes. skip_threats_filter_categories utilise des tokens différents de ceux de la politique de protection, par exemple application_attacks et data_leakages. Ne pas confondre ces tokens d’exception avec les noms affichés dans la politique. Le texte descriptif obsolète concernant les anciennes catégories n’autorise pas non plus l’utilisation des anciens tokens. Après une modification, vérifier séparément le chemin autorisé, le chemin bloqué, la route de repli et une requête non couverte par une exception.

Le tableau décrit path pour les routes Site-Path ; l’exemple d’exception montre en revanche plusieurs éléments path au sein d’une Exception, sans contrat propre clairement défini dans le tableau. Ne pas transposer aux exceptions la cardinalité ni les limites des chemins de routage. Avant toute modification automatisée des exceptions, confirmer la structure, le nombre d’éléments et les valeurs autorisées dans le build installé ; ne procéder à aucune écriture si le contrat n’est pas clarifié.

Vérifier de manière sûre le contrat du backend et le délai d’attente

Pour RealServers, Name, Host, Port et TimeOut sont documentés comme des champs obligatoires. Name autorise au maximum 60 caractères UTF-8 sans virgule. Host est une référence à un objet hôte IP ou FQDN, et non un nom WAF public librement interchangeable. Port va de 1 à 65535, avec une valeur par défaut API de 80 ; Type indique littéralement Plaintext (HTTP) ou Encrypted (HTTPS). Pour un backend HTTPS, vérifier donc explicitement le point d’écoute et le port réels, plutôt que de reprendre la valeur de port par défaut de l’API.

L’API décrit TimeOut avec une valeur par défaut de 300, une plage de 1 à 65535 et la précision qu’il ne s’applique que lorsque Keep alive est activé. L’interface graphique explique en revanche Timeout comme le délai d’attente des données vers le backend ou en provenance de celui-ci, et indique un HTTP-502 à son expiration. Il s’agit d’une description différente, et non d’une preuve d’un comportement identique lorsque le keep-alive est désactivé. Pour les configurations via l’interface, utiliser le test de pause dans le transfert de données décrit plus haut ; avant une automatisation, clarifier la dépendance et la valeur enregistrée dans le build installé. Ne pas en déduire qu’il faut augmenter globalement le délai d’attente.

Pour KeepAlive, l’exemple présente Enable/Disable, mais le tableau ne présente que 0 et Enable, ainsi que la valeur par défaut ON. Ne pas corriger silencieusement cet écart en supposant une valeur Disable. DisableReuse indique Disable et Enable et correspond à Disable backend connection pooling. Sauvegarder l’état initial, relire l’objet modifié, puis seulement vérifier un transfert de données représentatif ainsi que les journaux du backend. Une réponse API seule ne prouve ni l’accessibilité du backend ni l’adéquation des paramètres de connexion.

Politique de protection et options dépendantes

Selon le tableau, ProtocolSecurity exige Name, Mode et RequestSizeLimit. Pour Name, la limite est de 60 caractères UTF-8 sans virgule ; Mode indique Monitor et Reject. Les options CookieSigning, StaticUrlHardening et FormHardening correspondent aux protections des cookies, des URL et des formulaires décrites plus haut. Selon le tableau, PassOutlookAnywhere est défini par défaut sur OFF : l’API décrit très brièvement l’accès Exchange, tandis que l’interface graphique mentionne explicitement le contournement de Web Server Protection. Sans cas d’usage hérité justifié, laisser donc cette option désactivée et ne pas la traiter comme une simple option de compatibilité. Lorsque StaticUrlHardening est activé, la référence décrit EntryURLType avec Manual, SitemapFile, SitemapURL ; pour le cas manuel, l’exemple présente EntryURLList/EntryURL, avec plusieurs URL d’entrée de 255 caractères maximum chacune. Ne pas en déduire que l’interface graphique propose toutes les variantes API de manière identique.

Le tableau de l’API indique une valeur par défaut de OFF pour CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation et ThreatsFilter, et de 1 pour ParanoiaLevel. Une Policy nouvelle ou référencée ne prouve donc pas à elle seule que des contrôles de protection sont activés. Lors de la création, définir explicitement les options souhaitées et relire leurs valeurs. Lors d’une modification sans contrat de mise à jour confirmé, ne supposer ni la conservation des champs omis ni leur réinitialisation aux valeurs par défaut.

Lorsque AntiVirus est activé, AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent et LimitScanSize deviennent pertinents. L’entier Megabytes dépend en outre de l’activation de LimitScanSize. Cela reste distinct de la limite du corps de la requête. SkipRemoteLookups dépend de BlockClientsWithBadReputation ; ne pas déduire l’effet de la vérification de réputation de la seule description succincte de l’API.

ThreatsFilter active le filtre des menaces courantes. Cela comprend ThreatFilters/Filter, ParanoiaLevel de 1 à 4 et SkipFilterRules/FilterRules comme liste d’identifiants de règles entiers. Les tokens de filtre autorisés sont littéralement Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. Le dernier token diffère du nom Data leakage dans l’interface graphique. N’exclure de manière ciblée que les faux positifs avérés, puis vérifier à nouveau les autres protections ; le niveau, la catégorie et l’exception sont des décisions distinctes.

RequestSizeLimit reste un conflit entre sources : Le tableau API indique un champ obligatoire, une valeur par défaut de 10, la description « Megabytes » et une plage d’entiers de 1 à 1073741824. L’interface graphique actuelle documente en revanche une plage de 1 à 1024 MB, avec une valeur par défaut de 10 MB. RequestSizeLimit est totalement absent de l’exemple API. Ne pas en déduire une conversion octets/MB, une limite étendue utilisable en production ou un caractère facultatif sûr. Pour l’interface graphique, utiliser la plage documentée en MB ; n’utiliser une valeur d’écriture API qu’après confirmation de l’unité, de la plage et du comportement du champ obligatoire dans le build installé. Il en va de même pour l’intitulé de tableau HSTS Enforcement, absent de l’exemple : ne pas inventer de balise XML à partir du nom. XContentTypeOptions décrit la protection MIME ; contrôler depuis l’extérieur l’affectation enregistrée de la politique et les en-têtes réels.

Distinguer les réponses XML selon l’opération

Les nombres suivants sont des statuts d’objet XML, et non des codes de statut HTTP. Message.* désigne ici un nom de symbole non résolu issu de la référence, et non un message d’erreur traduit ni une preuve d’une cause précise. Vérifier ensemble la réponse, l’opération et l’état enregistré de l’objet ; en cas d’erreurs, d’avertissements ou de modification potentiellement partielle, ne jamais réécrire à l’aveugle. Le guide central de sécurité de l’API explique la procédure sûre de vérification et d’escalade.

Pour les réponses de FirewallRule pertinentes pour le WAF, les différences suivantes 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. Pour 202, relire également le nom de l’objet et ses références, et ne pas simplement réutiliser l’ancien nom.
Add firewall rule 541 → Message.VHIPRangeConflict. Edit firewall rule 541 a en revanche Message.FWRuleFailMaxUser ; un même code ne doit pas déclencher le même diagnostic.
Add firewall rule 543 et Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 et Edit firewall rule 543 → Message.CannotUseDefaultPort. La correspondance est inversée entre Add et Edit : vérifier le point d’écoute, le port et la redirection, et ne pas classifier uniquement d’après le nombre.
Pour Add firewall rule et Edit firewall rule : 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Comparer avec la configuration existante des points d’écoute et des domaines ; ne pas modifier les ouvertures de ports sur la base d’une supposition.
Pour les deux opérations : 547 → Message.warn_update_business_policy ; 548 et 549 utilisent tous deux Message.MaxIPv4ForAppServerAllowed. Cette double association au même symbole ne prouve pas l’existence de limites différentes qu’il faudrait inventer. Vérifier l’avertissement et l’état WAF effectivement enregistré.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer ; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Ne pas confondre les domaines publics génériques avec un hôte backend approprié. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName : vérifier le nom et le type de politique, et ne pas écraser un autre objet.
Pour Add, Edit et Delete firewall rule : 596 → Message.CMLOCALOperationrestriction. Pour Delete, figurent également 200 → Message.FWDelSuccess et 500 → Message.FWRuleDeleteFail. Clarifier la responsabilité d’administration et les références avant une nouvelle tentative. La page Delete décrit Name comme facultatif et utilise un texte descriptif inapproprié concernant Before/After ; ce n’est pas un modèle de suppression sûr. Confirmer la cible exacte et le contrat Remove propre au build ; sinon, ne pas supprimer.

Le backend et la politique de protection ont également leurs propres séries de réponses : Add Web Server 200/500/502 correspondent à Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist ; Update Web Server 200/500 à Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 correspondent à Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist ; Edit Protection Policy 200/500 à Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. Les graphies RecodExist sont conservées littéralement, et non corrigées en d’autres noms de symboles. En cas de collision de noms, lire d’abord l’objet existant ; une suppression suivie d’une recréation n’est pas une stratégie sûre de nouvelle tentative par défaut.

Pour l’objet global WAFSlowHTTP, RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit et RequestHeaderTimeoutExtensionRate correspondent à l’option et aux trois limites expliquées plus haut. Les quatre sont documentés comme des champs obligatoires ; l’option indique Disable et Enable, les autres valeurs sont des entiers sans plage indiquée. NetworkExceptions/Host est une liste facultative de références d’hôtes. Les valeurs d’exemple 10, 30, 5000 ne sont pas des valeurs par défaut avérées. SlowHTTP Protection indique 200 avec Operation Successful. et 500 avec Operation Fail.. Les modifications restent globales : vérifier les valeurs enregistrées et les exceptions strictement délimitées, puis valider toutes les publications concernées avec des clients légitimes lents.

Questions fréquentes

WAF remplace-t-il l'application des correctifs au serveur web ?

Non. WAF peut détecter ou bloquer des attaques, mais ne peut pas compenser durablement une application non sécurisée. Le système d’exploitation, le serveur web, les frameworks, les plugins et le code de l’application doivent toujours être maintenus.

A-t-on besoin de DNAT en plus ?

Pour la même publication web, normalement non. La règle WAF prend en charge la publication via la Hosted address et transmet les requêtes au serveur web protégé. DNAT reste pertinent pour d’autres protocoles ou des applications web non prises en charge.

Pourquoi le serveur web ne voit-il pas l'IP réelle du client ?

Le pare-feu fonctionne comme un proxy inverse. Le serveur web voit donc souvent le pare-feu comme adresse source. L’IP client d’origine est dans l’en-tête X-Forwarded-For, à condition que l’application ou le serveur web évalue cet en-tête.

Peut-on publier plusieurs sites web via la même IP publique ?

Oui, pour HTTPS, le pare-feu utilise SNI et le nom d’hôte pour choisir la règle WAF appropriée ou le serveur web virtuel approprié. DNS, certificat et Domains dans la règle WAF doivent être correctement alignés.

Devrait-on utiliser WAF pour Nextcloud ?

Pas sans examen attentif. WebDAV est documenté comme un cas non pris en charge par WAF. Étant donné que Nextcloud utilise intensivement WebDAV, une publication via WAF n’est pas adaptée dans de nombreux environnements.

Les Threat Feeds protègent-ils également les règles WAF ?

Sous SFOS 22, les Threat Feeds peuvent également être pertinents pour le trafic entrant et redirigé comme les publications WAF et DNAT. Pour qu’une véritable protection en résulte, les flux, la journalisation, les alertes, la responsabilité et le processus de gestion des faux positifs doivent être correctement gérés.