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

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

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

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

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

Décision avant publication

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

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

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

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

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

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

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

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

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

Planification et prérequis

Prérequis

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

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

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

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

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

Les règles WAF sont également orientées vers des publications IPv4. Si une application doit impérativement être publiée en IPv6, le design doit être vérifié séparément. Les modèles Exchange ne sont pas non plus un laissez-passer pour les environnements Exchange modernes : Sophos documente que les règles WAF ne supportent actuellement pas les versions Exchange postérieures à 2013.

Planifier la publication WAF avant la configuration

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

Ces questions sont importantes avant une publication productive :

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

Pour les certificats, il convient de clarifier tôt si un certificat existant sera importé, si le pare-feu doit créer et renouveler un certificat Let’s Encrypt ou si un certificat généré à l’extérieur est nécessaire. Pour les certificats génériques, il existe une instruction séparée : Créer un certificat Let’s Encrypt Wildcard.

Configurer la règle WAF

Structure de base d’une règle WAF

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

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

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

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

Créer une règle WAF

Le chemin du menu est :

Rules and policies > Firewall rules

Procédure :

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

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

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

Les conflits de port doivent être clarifiés avant l’enregistrement. Selon la Hosted address, WAF peut utiliser le même port que SSL VPN, mais pas le même port que User Portal. Si WebAdmin, VPN Portal, User Portal ou une ancienne publication DNAT écoute déjà sur une IP publique, l’attribution doit être univoque. Sinon, l’erreur ressemblera plus tard à un problème WAF alors qu’une autre fonction répond.

Go-live et validation

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

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

Avant la mise en service, vérifiez :

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

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

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

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

Test d’acceptation après la mise en service

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

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

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

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

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

Sécuriser la protection et les accès

Certificats et noms d’hôte

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

Points importants :

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

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

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

Planifier l’IP du client et les journaux du backend

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

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

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

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

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

Restreindre l’accès client

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

Restrictions utiles :

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

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

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

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

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

En pratique, il convient de vérifier :

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

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

Profils de protection et exceptions

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

Domaines de protection typiques :

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

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

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

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

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

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

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

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

Exemples :

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

Il convient de noter que le pare-feu n’évalue pas simplement les chemins selon l’ordre des lignes de table. Sophos priorise les chemins plus longs et donc plus spécifiques. Les chemins spécifiques doivent donc être planifiés et testés proprement. Si WebSocket est nécessaire, WebSocket passthrough peut être activé. Le trafic WebSocket est alors transmis sans la même vérification WAF, car le protocole ne peut pas être vérifié de la même manière que le trafic HTTP normal.

Le chemin par défaut / doit rester défini consciemment. S’il est supprimé, les chemins non correspondants ne sont pas transmis à un serveur par défaut, mais rejetés avec 404 Not Found. Cela peut être voulu, mais en cas d’erreur cela ressemble vite à un problème backend.

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

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 particulièrement consciemment. Pour des backends via liaisons de site, MPLS ou route-based IPsec, une SD-WAN Route adaptée peut être nécessaire afin que le pare-feu atteigne le Protected Server de manière fiable et que le retour soit correct. Avec route-based IPsec, il faut aussi noter que WAF via route-based IPsec avec Traffic Selectors pour sous-réseaux n’est pas supporté par Sophos ; les connexions Any-to-Any sont l’issue documentée.

Exploitation et dépannage

Erreurs typiques

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

Dépannage

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

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

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

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

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

Questions fréquentes