Configurer la protection Web de Sophos Firewall avec des politiques Web

La protection Web de Sophos Firewall contrôle les sites Web, les catégories et les contenus Web auxquels les utilisateurs peuvent accéder. En pratique, la protection Web n’est pas simplement un paramètre à cocher. Une politique Web doit être planifiée de manière professionnelle, activée dans une règle de pare-feu appropriée, puis testée avec un trafic réel.

De nombreuses erreurs surviennent parce qu’une politique Web existe mais n’est appliquée à aucune règle de pare-feu active. D’autres problèmes sont liés à HTTPS, à l’inspection TLS, à QUIC, à la reconnaissance des utilisateurs, à l’ordre des règles ou à des exceptions trop larges. Le processus logique est donc : planifier la politique, construire la règle, l’activer, la tester et la surveiller en fonctionnement.

Quel article sur la protection Web est adapté ?

La protection Web chevauche les règles de pare-feu, l’inspection TLS, QUIC, le reporting et les exceptions. Selon la tâche, un article plus spécifique peut être plus approprié :

Ainsi, l’analyse reste claire : il faut d’abord s’assurer que la règle de pare-feu correspond. Ensuite, on vérifie la politique Web, la catégorie, le contexte utilisateur, QUIC, l’inspection TLS et la journalisation.

Ce que contrôle la protection Web

La protection Web se compose de plusieurs éléments. Tous les éléments ne doivent pas être utilisés dans chaque environnement, mais les relations doivent être claires.

La protection Web ne remplace pas une base de règles de pare-feu propre. La règle de pare-feu décide d’abord quel trafic est autorisé de quelle zone à quelle zone cible. La politique Web complète cette règle par un contrôle Web. Les bases de l’ordre des règles, de la source, de la destination, des services et des profils de sécurité sont expliquées dans Comprendre et construire proprement les règles de Sophos Firewall.

Prérequis

Avant le déploiement, ces points doivent être clarifiés :

• La protection Web est sous licence ou incluse dans le bundle utilisé.
• Les réseaux clients concernés ont leurs propres règles de pare-feu.
• La journalisation est activée dans les règles pertinentes.
• Le DNS et l’heure du pare-feu fonctionnent correctement.
• La reconnaissance des utilisateurs est clarifiée si des politiques s’appliquent par utilisateur ou groupe.
• L’inspection TLS est planifiée si le contenu HTTPS doit être examiné plus en détail.
• QUIC/HTTP/3 est consciemment autorisé ou bloqué.
• Il existe un groupe pilote et un plan de secours pour les sites critiques pour l’entreprise.

Il est particulièrement important de séparer les groupes cibles. Une politique Web pour les clients normaux, les serveurs, les invités, les utilisateurs VPN et les systèmes de gestion ne devrait pas être la même. Les serveurs ont souvent besoin de moins de contrôle de navigation, mais de listes de cibles et de mises à jour plus strictes. Les invités ont souvent besoin de catégories et de limitations de bande passante, mais pas d’accès aux ressources internes.

Planifier la politique Web

Une bonne politique Web ne commence pas dans l’interface, mais par quelques décisions professionnelles.

Définir les groupes cibles

Tout d’abord, il est déterminé pour qui la politique s’applique :

• Clients standard dans le LAN
• Ordinateurs portables gérés via VPN
• Wi-Fi invité
• Salles de formation ou environnements scolaires
• Serveurs avec accès HTTP/HTTPS sortant
• Postes de travail administratifs privilégiés

Si la même règle de pare-feu contient plusieurs groupes très différents, la protection Web devient difficile à comprendre. Il est préférable d’avoir des règles et des politiques séparées, par exemple LAN_USERS_WEB, GUEST_WEB ou SERVER_UPDATES_WEB.

Définir les catégories et les groupes d’URL

Les catégories Web Sophos sont bonnes pour un contrôle large : Malware, Phishing, Contenu adulte, Anonymiseurs, Streaming, Réseaux sociaux ou Jeux. Les groupes d’URL sont meilleurs lorsque des domaines individuels doivent être autorisés ou bloqués de manière ciblée.

Utilisation typique :

Les groupes d’URL ne doivent pas devenir une liste de collecte non triée. Si de nombreux domaines sont inscrits, la liste a besoin d’un propriétaire, d’un objectif et d’une date de révision. Pour des listes très grandes ou dynamiques, les Sophos Firewall Threat Feeds ou d’autres éléments d’architecture sont souvent plus appropriés.

Définir prudemment les règles d’autorisation

Les règles d’autorisation dans les politiques Web doivent être strictes. Une règle d’autorisation en haut peut rendre inefficaces les règles de blocage ultérieures, car les règles de politique Web de Sophos sont évaluées de haut en bas. Cela est particulièrement pertinent si un groupe d’URL, une règle de type de fichier ou une exception de catégorie se trouve au-dessus d’autres règles.

En pratique, il est recommandé de :

1. Exceptions commerciales spécifiques autorisées en haut.
2. Catégories de blocage critiques ensuite.
3. Règles d’avertissement ou de quota pour les zones grises.
4. Trafic Web généralement autorisé seulement à la fin.

Créer une politique Web

La politique Web est créée dans le menu suivant :

Web > Policies

Processus de base :

1. Sélectionner Add policy.
2. Donner un nom explicite, par exemple LAN_USERS_STANDARD_WEB.
3. Ajouter des règles.
4. Choisir consciemment les utilisateurs, groupes ou Anybody.
5. Sélectionner les activités, catégories, groupes d’URL, types de fichiers ou filtres de contenu.
6. Définir l’action pour HTTP et HTTPS : Allow, Warn, Block ou Quota.
7. Définir un horaire si la règle doit s’appliquer uniquement à certains moments.
8. Activer la règle.
9. Vérifier la position de la règle au sein de la politique.
10. Activer la journalisation et le reporting.
11. Enregistrer la politique.

Une politique Web seule n’a pas d’effet. La politique doit ensuite être utilisée dans une règle de pare-feu. C’est l’une des erreurs de configuration les plus courantes.

Activer la politique Web dans la règle de pare-feu

La règle de pare-feu se trouve sous :

Rules and policies > Firewall rules

Pour le trafic Internet client normal, une règle de LAN ou d’une zone client vers WAN est généralement responsable. Dans la section Web filtering, la politique Web appropriée est sélectionnée.

Points de vérification dans la règle de pare-feu :

• La zone source et les réseaux source correspondent au réseau client.
• La zone de destination est généralement WAN.
• Les services incluent HTTP/HTTPS ou les services Web souhaités.
• Log firewall traffic est activé.
• Dans la section Web filtering, la bonne politique Web est définie.
• Le scan des malwares est activé de manière appropriée.
• Block QUIC protocol est consciemment défini.
• L’inspection TLS est planifiée séparément et non confondue avec la politique Web.

Si une règle plus générale au-dessus de la règle Web souhaitée correspond, le trafic n’atteint pas la politique Web. Dans de tels cas, Tester les règles de Sophos Firewall avec Log Viewer et Packet Capture peut aider.

Classer HTTPS, l’inspection TLS et QUIC

Une grande partie du trafic Web est HTTPS. Sans inspection TLS, le pare-feu voit moins de contenu. Les catégories, SNI, certificats, IP de destination, informations de domaine et métadonnées aident, mais ne remplacent pas une inspection complète du contenu.

DPI ou Web Proxy ?

Avec la protection Web, il faut décider tôt si la règle de pare-feu concernée utilise le DPI Engine ou le Web Proxy. Cette décision influence quelles fonctions s’appliquent et quels journaux sont pertinents par la suite.

Dans de nombreuses installations, le mode DPI est le meilleur point de départ. Cependant, si des quotas de temps sont nécessaires, une règle purement DPI ne suffit pas. Dans ce cas, le mode Web Proxy doit être planifié et testé consciemment. Cette décision doit être prise avant le déploiement, car un changement ultérieur peut entraîner d’autres problèmes, journaux et expériences utilisateur.

Inspection TLS

Si les téléchargements, le scan des malwares, certaines catégories Web ou les contrôles de contenu doivent être vérifiés de manière fiable, l’inspection TLS doit être planifiée. Cela nécessite un certificat CA de confiance sur les clients, des règles TLS appropriées, des exceptions et un pilote propre.

Le déploiement est décrit dans Déployer progressivement l’inspection TLS sur Sophos Firewall. Pour distribuer et valider le certificat CA, consultez Installer le certificat CA de Sophos Firewall pour le scan HTTPS.

QUIC et HTTP/3

Les navigateurs modernes utilisent souvent QUIC ou HTTP/3 via UDP 443. Cela peut perturber les attentes de filtrage Web, d’inspection TLS et de scan si l’on souhaite examiner le trafic HTTPS classique via TCP.

Dans de nombreux environnements d’entreprise, il est judicieux de bloquer QUIC dans les règles Internet client, afin que les navigateurs reviennent à HTTPS via TCP. Les détails sont expliqués dans Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall.

SafeSearch, YouTube et restrictions de locataire

Sophos Firewall peut définir des contrôles de recherche et de cloud supplémentaires dans les politiques Web.

Options typiques :

• Enforce SafeSearch pour Google, Yahoo et Bing.
• Enforce YouTube restrictions pour les contenus YouTube restreints.
• Restrict login domains for Google Apps pour les domaines Google autorisés.
• Apply Microsoft Entra ID tenant restrictions pour le contrôle des locataires cloud Microsoft.

Ces fonctions sont utiles, mais pas magiques. Avec HTTPS, leur efficacité dépend partiellement du scan HTTPS ou de l’inspection TLS. De plus, elles ne remplacent pas la gouvernance des identités et des applications cloud dans Microsoft 365 ou Google Workspace. Pour les environnements de production, il est conseillé de tester leur efficacité avec de vrais utilisateurs de test et les navigateurs concernés.

Quota et pages d’avertissement

Les politiques Web peuvent non seulement bloquer ou autoriser. Avec des actions d’avertissement ou de quota, on peut informer consciemment les utilisateurs ou permettre un accès limité dans le temps.

Exemples pertinents :

• Les utilisateurs peuvent confirmer consciemment un avertissement pour certaines zones grises.
• Le streaming ou le shopping est autorisé uniquement de manière limitée dans le temps.
• Les environnements scolaires ou de laboratoire autorisent certaines catégories uniquement pendant des périodes définies.

Important : le quota de politique n’est pas pris en charge en mode DPI. Si des quotas de temps sont nécessaires, le mode Web Proxy doit être utilisé. Cela doit être décidé tôt, car DPI et Web Proxy ont des caractéristiques et des limites différentes.

Tester la protection Web

Après l’enregistrement, il ne suffit pas de vérifier si la politique existe. Ce qui est crucial, c’est de savoir si elle s’applique au trafic réel.

1. Utiliser le Policy Tester

Sous Web > Policies, le Policy tester est disponible. Il permet de vérifier quelle décision de politique est attendue pour un utilisateur, une URL et un contexte.

Le Policy Tester est un bon pré-test, mais ne remplace pas un flux de paquets réel. Une règle de pare-feu, un NAT, une inspection TLS, un QUIC ou un routage peuvent toujours empêcher que la politique attendue s’applique au trafic réel.

2. Test réel avec un client pilote

Avec un client pilote, vérifier :

• Site commercial autorisé
• Catégorie bloquée
• Catégorie avertissante
• Autorisation de groupe d’URL
• Blocage de groupe d’URL
• Page HTTPS avec et sans inspection TLS
• Téléchargement d’un type de fichier de test inoffensif
• Comportement avec QUIC activé ou bloqué

3. Vérifier le Log Viewer

Dans le Log Viewer, il devrait être visible :

• Quelle règle de pare-feu a été atteinte
• Quel utilisateur a été reconnu, si pertinent
• Quelle catégorie Web ou groupe d’URL a été impliqué
• Si HTTPS, l’inspection TLS ou le scan des malwares ont été impliqués
• Si l’action a été autorisée, avertie ou bloquée

Pour un dépannage plus approfondi, les fichiers journaux sont également pertinents. La correspondance est expliquée dans Dépannage de Sophos Firewall : Services et journaux.

Alertes instantanées et reporting

Si certaines catégories ne doivent pas seulement être bloquées, mais signalées activement, les alertes instantanées peuvent être utiles. Cela est particulièrement utile dans les écoles, les environnements strictement réglementés ou les zones avec une politique claire d’utilisation d’Internet.

Les trois voies d’évaluation répondent à différentes questions :

Avant les alertes instantanées, il doit être clair qui reçoit l’alerte, quelles catégories déclenchent réellement une réaction, comment les faux positifs sont traités et quand la sélection des catégories est vérifiée. Une liste d’alertes large sans propriétaire génère rapidement du bruit par e-mail, mais pas une meilleure sécurité.

Pour l’activation technique et le triage, consultez Utiliser les catégories Web et les alertes instantanées de Sophos Firewall. Pour des évaluations à plus long terme, Central Firewall Reporting ou Envoyer Syslog à SIEM devraient être examinés.

Gérer les changements et les exceptions en fonctionnement

La protection Web évolue constamment en fonctionnement. De nouveaux services SaaS apparaissent, des domaines individuels sont mal catégorisés, des départements ont besoin d’un accès temporaire et le comportement des navigateurs change. Sans processus clair, des exceptions larges apparaissent rapidement, que personne ne peut plus expliquer par la suite.

Pour chaque changement, il faut au moins noter :

Un petit processus de changement a fait ses preuves :

1. Enregistrer la demande avec l’utilisateur, l’URL, le moment, la raison commerciale et une capture d’écran ou un message d’erreur.
2. Dans le Log Viewer, vérifier quelle règle de pare-feu, politique Web, catégorie et action ont été appliquées.
3. Décider si la catégorie est fondamentalement incorrecte, si seul un domaine individuel doit être autorisé ou si la demande est rejetée.
4. Si une exception est nécessaire, travailler aussi étroitement que possible : groupe d’URL individuel au lieu de catégorie entière, groupe d’utilisateurs individuel au lieu de tout le LAN.
5. Tester le changement dans une règle de test ou un groupe pilote.
6. Après l’enregistrement, effectuer un test réel et documenter le Log Viewer, la catégorie, l’ID de règle et le contexte utilisateur.
7. Fixer une date de révision, surtout pour les exceptions commerciales temporaires.

Les exceptions temporaires doivent être clairement nommées, par exemple TMP_ALLOW_vendor-portal_until_2026-07-31. Les exceptions commerciales permanentes ont également besoin d’un propriétaire. Si personne n’est responsable d’une exception, elle ne devrait pas rester dans la politique de manière permanente.

Si de nombreux domaines individuels apparaissent pour le même service, le problème n’est souvent pas la politique Web, mais l’architecture du service. Il faut alors vérifier si une règle de pare-feu distincte, une politique Web distincte, un groupe d’URL soigneusement entretenu ou un autre point de contrôle est plus approprié. Pour les listes IOC ou de blocage dynamiques, les exceptions de politique Web sont généralement le mauvais endroit ; les Sophos Firewall Threat Feeds sont souvent plus adaptés.

Rollback et autorisation d’urgence

Un changement de politique Web peut affecter immédiatement le travail productif. Il est donc important de définir comment restaurer l’état précédent avant d’effectuer des modifications importantes.

Options de rollback pratiques :

• Dupliquer ou documenter la politique Web concernée avant la modification
• Tester le changement d’abord dans une règle pilote ou un petit groupe d’utilisateurs
• Ne pas supprimer immédiatement l’ancienne règle de pare-feu ou l’ancienne politique Web
• Définir une fenêtre de temps, des utilisateurs de test et un critère de retour
• Après l’enregistrement, vérifier le Log Viewer, l’ID de règle et la décision de catégorie

Pour les blocages aigus, il ne faut pas insérer réflexivement une règle d’autorisation large en haut. Il est préférable d’avoir une exception étroite et limitée dans le temps avec un groupe d’URL clair, un groupe d’utilisateurs et une date de révision. Si la pression est forte, une exception temporaire peut stabiliser le fonctionnement, mais elle doit être réévaluée par la suite.

Erreurs typiques

La politique Web ne s’applique pas

La plupart du temps, la politique n’est pas activée dans la bonne règle de pare-feu, la règle n’est pas atteinte, une règle plus haut autorise le trafic ou le contexte utilisateur ne correspond pas. Vérifiez d’abord le Log Viewer et l’ID de règle.

HTTPS n’est pas bloqué comme prévu

Sans inspection TLS, le pare-feu voit moins de détails. Selon la cible, une décision de domaine ou de catégorie peut fonctionner, tandis que l’inspection du contenu, les types de fichiers ou certaines fonctions de recherche restent limitées.

QUIC contourne l’attente

Si les navigateurs utilisent UDP 443, le trafic peut être traité différemment du HTTPS classique via TCP. Dans les règles client, il faut décider consciemment si QUIC est bloqué.

La règle d’autorisation est trop haute

Une règle d’autorisation large au début de la politique Web peut neutraliser les règles de blocage ultérieures. L’ordre des règles au sein de la politique Web est aussi important que l’ordre des règles dans la liste des règles de pare-feu.

Trop d’exceptions

Les exceptions résolvent rapidement un problème individuel, mais peuvent réduire l’efficacité de la protection. Chaque exception a besoin d’un objectif, d’un propriétaire et d’une date de révision. Si de nombreuses exceptions apparaissent, la structure de la politique est souvent incorrecte ou une application commerciale nécessite une règle distincte.

Le reporting n’affiche rien

Dans ce cas, il faut vérifier la journalisation, le reporting, la règle de pare-feu, le choix de la politique ou la redirection des journaux. Une politique sans journalisation est difficile à évaluer en fonctionnement.

Liste de vérification opérationnelle

• Statut de licence de la protection Web vérifié.
• Trafic client, serveur, invité et VPN évalué séparément.
• Politique Web créée avec un nom explicite.
• Catégories critiques et groupes d’URL planifiés consciemment.
• Ordre des règles au sein de la politique Web vérifié.
• Politique Web activée dans la règle de pare-feu appropriée.
• Log firewall traffic et journalisation Web actifs.
• Inspection TLS et certificat CA vérifiés pour le groupe pilote.
• Stratégie QUIC définie.
• Policy Tester et tests réels effectués.
• Log Viewer et reporting contrôlés.
• Processus de changement pour les exceptions de politique Web défini.
• Exceptions temporaires avec date d’expiration.
• Exceptions documentées avec propriétaire et date de révision.

FAQ