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

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.

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

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

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 :

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.

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

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 :

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.

Structure de base d’une règle WAF

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

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.

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. Pour Action, choisissez l’option Protect with web server protection.
6. Si aucun modèle spécial n’est nécessaire, laissez Preconfigured template sur None.
7. Sous Hosted server details, définissez l’adresse publique, le port d’écoute, HTTPS, le certificat et les domaines.
8. Sous Protected servers, sélectionnez ou créez un nouveau serveur web interne.
9. 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.
10. Si nécessaire, définissez Blocked client networks ou Blocked countries.
11. Vérifiez le profil de protection, IPS et les options avancées.
12. 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.

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.

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.

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

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

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. Les chemins spécifiques doivent ê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.

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.

Erreurs typiques

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. Existe-t-il une règle WAF plus générale qui correspond avant ?
8. L’accès est-il affiché dans le Log Viewer comme autorisé, bloqué ou rejeté ?
9. Y a-t-il des indices dans /log/reverseproxy.log ?

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 Sophos Firewall Troubleshooting : Services et journaux.

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