Utiliser les catégories Web et les alertes instantanées de Sophos Firewall

Les catégories Web déterminent les sites auxquels les utilisateurs peuvent accéder. Les alertes instantanées ajoutent des notifications par e-mail pour quelques catégories choisies et surveillées. Pour que l’ensemble fonctionne, la catégorie, la politique Web, la règle de pare-feu, la journalisation et l’envoi des e-mails doivent être cohérents.

Cette fonction est particulièrement utile dans les écoles, les services sensibles ou les environnements où certains accès Web ne doivent pas attendre le rapport mensuel pour être signalés.

Une catégorie seule ne modifie pas le trafic. Une politique Web doit l’associer à une action, puis être affectée à une règle de pare-feu correspondante. L’inspection TLS, la gestion de QUIC et la journalisation déterminent en outre ce que le pare-feu peut identifier et restituer.

Pour la planification générale des politiques Web, commencez par Configurer la protection Web de Sophos Firewall avec des politiques Web. Pour la base des règles, consultez Comprendre et configurer correctement les règles de Sophos Firewall. Cet article se concentre sur la partie opérationnelle Web : catégories, groupes d’URL, alertes instantanées, évaluation et réaction.

Orientation

On commence par choisir la méthode de protection ou de configuration adaptée au cas réel. Cela évite les règles trop larges et les doublons lors du dépannage.

Séparer clairement les termes

Sophos utilise plusieurs objets Web qui sont facilement confondus au quotidien.

• Catégorie Web: Catégorie pour les domaines, URL ou mots-clés. De nombreuses catégories proviennent de Sophos, des catégories personnalisées sont possibles. Autoriser, bloquer, limiter ou signaler les accès Web selon le risque ou le contenu.
• Groupe d’URL: Liste de domaines pouvant être utilisée dans les politiques Web ou les exceptions TLS. Listes d’autorisation ou de blocage explicites, lorsque des domaines spécifiques sont plus importants que les catégories.
• Politique Web: Ensemble de règles pour les utilisateurs, groupes, catégories, groupes d’URL, types de fichiers, filtres de contenu et actions. Contrôler les accès Web et les associer à une règle de pare-feu.
• Alertes instantanées: Notification par e-mail pour les accès aux catégories surveillées. Notification rapide pour les catégories particulièrement sensibles ou à risque.
• Visionneuse de journaux et rapports: Évaluation de la décision réelle. Vérifier si la catégorie, la politique, l’utilisateur et la règle de pare-feu fonctionnent comme prévu.

Une politique Web n’a d’effet que si elle est sélectionnée dans une règle de pare-feu appropriée sous Security features > Web filtering. La politique Web seule n’est donc pas une règle qui traite le trafic de production.

Quand les catégories Web sont-elles utiles ?

Les catégories Web sont particulièrement utiles lorsque les accès Web ne doivent pas être simplement autorisés ou bloqués de manière générale. Scénarios typiques :

• Bloquer les catégories de logiciels malveillants, de phishing et de fraude.
• Restreindre les anonymiseurs, les proxys et les services de contournement.
• Surveiller particulièrement les catégories de commande et de contrôle ou de logiciels espions.
• Bloquer les catégories telles que le contenu pour adultes, les jeux d’argent ou les substances contrôlées selon le contexte.
• Autoriser les applications cloud critiques pour l’entreprise, mais restreindre les services cloud privés ou de partage de fichiers.
• Dans les écoles ou les environnements surveillés, surveiller les catégories particulièrement sensibles avec des alertes instantanées.
• Limiter la bande passante pour certaines catégories Web via le modelage du trafic.

Les catégories ne doivent pas être mises sur blocage ou alerte de manière arbitraire. Sinon, de nombreux résultats apparaissent que personne ne peut examiner de manière significative. Il est préférable d’avoir un ensemble petit et clair avec un propriétaire, un chemin de réaction et une révision.

Prérequis

Avant la configuration, ces points doivent être clarifiés :

• La protection Web ou un bundle Sophos Firewall approprié est sous licence.
• Il existe une règle client ou utilisateur qui doit utiliser le filtrage Web.
• Un appariement utilisateur ou groupe est prévu si les politiques doivent s’appliquer par utilisateur.
• Log firewall traffic est activé dans la règle de pare-feu pertinente.
• Sous System services > Log settings, au moins Content filtering est sélectionné pour Local reporting. Pour Central Reporting ou Syslog, sélectionner le même type de journal dans la colonne de destination correspondante.
• Les notifications par e-mail fonctionnent si les alertes instantanées doivent être utilisées.
• Le modèle utilisé prend en charge les alertes instantanées ; les XGS 87 et XGS 88 ne prennent pas en charge cette fonction.
• Pour une évaluation à long terme, Central Firewall Reporting ou Syslog est prévu.
• Une décision explicite a été prise concernant la gestion de QUIC et l’inspection TLS.

Pour une évaluation centrale, consultez Activer le Central Firewall Reporting. Si les journaux doivent être envoyés à un SIEM propre, Envoyer les journaux Syslog de Sophos Firewall à un SIEM est l’article de suivi approprié.

Planifier le design de la policy

Avant la configuration technique, définir quelles catégories doivent être contrôlées, lesquelles doivent seulement faire l’objet d’une alerte et qui doit y réagir. Une politique ciblée et claire est généralement préférable à un catalogue maximal.

Planifier les catégories et les groupes d’URL

Pour les administrateurs, il est important de savoir quand une catégorie Web personnalisée et quand un groupe d’URL est plus approprié.

Une catégorie Web personnalisée est utile lorsque :

• Les domaines ou mots-clés doivent être utilisés comme catégorie dans plusieurs politiques Web.
• La catégorie doit être visible dans les rapports et les journaux.
• Un concept de modelage du trafic par catégorie est prévu.
• Une catégorie surveillée pour les alertes instantanées doit être créée.

Un groupe d’URL est généralement préférable lorsque :

• Seuls des domaines spécifiques sont collectés.
• Une petite liste d’autorisation ou de blocage est nécessaire.
• La liste doit également être utilisée pour les exceptions TLS.
• Le filtrage par mots-clés doit être évité.

Pour les correspondances de domaines pures, les groupes d’URL sont plus directs et plus faciles à contrôler que les catégories avec mots-clés. Utiliser ces dernières uniquement dans les règles de blocage, pas d’autorisation : les paramètres de requête peuvent sinon forcer un accès indésirable.

Un groupe d’URL contient des domaines valides. Les expressions régulières ne sont pas autorisées ; les entrées sont évaluées avec OR, une seule correspondance suffit donc. L’aide actuelle de SFOS 22 ne précise aucun maximum fixe. Cela ne garantit pas des listes illimitées. Pour les listes grandes ou maintenues dynamiquement, il faut vérifier si une base de catégories importée ou un flux de menaces est plus approprié.

Créer et utiliser des URL Groups en toute sécurité présente le processus complet de création, de Web Policy, de TLS et de test.

Distinguer catégories fixes, dynamiques et absentes

La plupart des catégories intégrées reposent sur une recherche d’URL. ActiveX, Applets, Cookies et HTTPUpload sont au contraire dynamiques : le pare-feu les attribue par inspection du contenu. Une recherche d’URL seule ne confirme donc pas qu’une telle règle de contenu correspondra à une requête réelle. ALLWebTraffic désigne tout le trafic HTTP, pas seulement les sites encore inconnus.

None et Uncategorized sont deux résultats différents. Avec None, la recherche a réussi, mais la base d’URL ne contient aucune catégorie. Avec Uncategorized, la recherche a échoué. Avant de créer une exception, distinguer une classification absente d’un problème de catégorisation ; aucun des deux résultats ne prouve qu’un site est sans danger.

Choisir les catégories selon leur signification

Une catégorie ne constitue pas un verdict de sécurité général sur tous les contenus d’un service. Ces distinctions comptent pour choisir les actions de politique :

• CRL and OCSP concerne la vérification de révocation des certificats ; Software updates, les mises à jour de logiciels courants. Ces accès sont normalement nécessaires. Download freeware & shareware exclut expressément les sites de mise à jour des systèmes d’exploitation, antivirus et autres logiciels critiques. Un blocage des téléchargements ne doit pas empêcher les mises à jour par accident.
• Content delivery couvre généralement des contenus secondaires ou intégrés d’autres sites. Un blocage global peut perturber des sites autorisés ; contrôler l’hôte cible réel et le site principal dans les journaux avant d’accorder une exception.
• Command & control désigne des serveurs de commande de logiciels malveillants connus, Spyware & malware, des sites hébergeant du contenu malveillant, et Phishing & fraud, notamment des sites frauduleux et de phishing. Newly registered websites et Parked Domain sont en revanche des signaux de risque, pas des preuves de logiciel malveillant.
• Business cloud apps, Personal cloud apps et Personal network storage distinguent applications professionnelles, services cloud personnels et stockage réseau privé. Décider selon le risque de fuite de données et le besoin métier, pas seulement selon le mot « cloud ».
• Anonymizers et Translators peuvent contourner le filtrage ; Image search, Portal sites et les moteurs de recherche peuvent exposer des contenus d’autres catégories. Autoriser le site principal ne signifie donc pas autoriser toutes les destinations intégrées.
• Live audio, Live video, Video hosting, Surveillance et Voice & video calls distinguent diffusion en direct, vidéo à la demande, surveillance et communication. Le choix entre limitation de bande passante et blocage dépend du service nécessaire. Les sites de casinos, d’hôtels et de complexes touristiques relèvent de Travel s’ils ne proposent ni jeux d’argent en ligne ni conseils de jeu ou de paris. Le nom de l’hôtel seul ne prouve pas sa classification.

Glossaire compact pour le diagnostic et les environnements sensibles

• HTTPUpload concerne les restrictions d’envoi par HTTP et constitue une catégorie dynamique ; IPAddress concerne les sites consultés par leur adresse IP. Ce sont des cas distincts de règles, pas des synonymes d’absence de classification.
• Pro-suicide & self-harm couvre les sites qui encouragent le suicide ou l’automutilation. Les écoles peuvent surveiller d’éventuels risques pour les élèves avec cette catégorie. Les pages de santé mentale, d’aide et de soutien n’en relèvent pas du seul fait de leur sujet. Une correspondance nécessite une analyse humaine, pas une conclusion automatique d’incident.
• Sex education couvre les images et textes préconisant le bon usage des contraceptifs, les discussions sur la pilule, le stérilet et les autres contraceptifs, ainsi que la manière de parler avec son partenaire des maladies, de la grossesse et du respect des limites personnelles. Les sites commerciaux vendant des accessoires sexuels en sont exclus et relèvent généralement de Sexually explicit. Cette dernière catégorie couvre les produits pour adultes, dont les accessoires sexuels, les CD-ROMs et les vidéos ; les contenus d’abus sexuels sur mineurs et de pédophilie, notamment ceux de la liste IWF ; les services pour adultes, dont la visioconférence, les services d’escorte et les clubs de strip-tease ; les récits érotiques et descriptions d’actes sexuels ; les dessins, animations, groupes et forums sexuellement explicites ; les sites sexuels ou érotiques présentant une nudité totale ou partielle ; les représentations d’actes sexuels, y compris avec des animaux ou des objets ; les textes ou images d’exploitation ou de violence sexuelle ; le bondage, les fétiches et les piercings génitaux ; les sites naturistes présentant de la nudité et les photographies érotiques ou fétichistes présentant de la nudité. Les sites d’information sur la santé sexuelle, le cancer du sein et les infections sexuellement transmissibles sont exclus, sauf ceux présentant des exemples graphiques.
• Intolerance & hate couvre les sites prônant ou suscitant le dénigrement ou l’attaque de populations ou d’institutions selon la religion, la race, la nationalité, le genre, l’âge, le handicap ou l’orientation sexuelle ; les programmes politiques ou sociaux suprémacistes excluant d’autres groupes selon ces critères ; le révisionnisme ou la négation de l’Holocauste et les autres révisionnismes encourageant la haine ; la coercition ou le recrutement pour un gang ou une secte ; le militantisme extrémiste ; et les contenus ouvertement offensants ou irrespectueux des opinions et croyances d’autrui. Dans cette définition, un gang est un groupe dont l’activité principale consiste à commettre des crimes graves, qui possède un nom, un signe ou un symbole d’identification commun et dont les membres commettent, individuellement ou collectivement, des crimes en son nom. Une secte est un groupe recrutant et retenant ses adeptes par tromperie, manipulation et influence abusive, altérant leur personnalité et leur comportement, avec une direction toute-puissante, une idéologie totalisante et une volonté individuelle subordonnée au groupe, qui se place en dehors de la société. Les actualités, documents historiques et reportages de presse relatant ces faits sont exclus, sauf pour les exemples graphiques. Rapporter les faits ne signifie pas automatiquement les approuver.
• Gambling couvre les jeux d’argent et loteries en ligne utilisant de l’argent réel ou virtuel ; les informations et conseils pour miser, participer à des loteries ou à des jeux d’argent, y compris les loteries clandestines ; les casinos virtuels et les activités de jeux d’argent offshore ; les pronostics sportifs et paris collectifs ; ainsi que les sports virtuels et ligues fantasy offrant des récompenses importantes ou exigeant des mises significatives. Games couvre les sites permettant de jouer ou de télécharger des jeux, l’hébergement de jeux ou de concours, les conseils de jeu et codes de triche, ainsi que les revues et magazines consacrés aux jeux en ligne. Distinguer les deux catégories selon l’activité proposée, pas seulement selon le mot « jeu ».
• Radio & audio hosting couvre les contenus audio et musicaux légitimes à la demande, avec Spotify et Pandora comme exemples descriptifs, contrairement aux diffusions en direct d’événements ou de programmes de Live audio. Ces exemples ne garantissent pas la classification actuelle de leurs URL. Online Chat couvre le chat Web et la messagerie instantanée ; Voice & video calls concerne la téléphonie par Internet et les appels vidéo. Choisir selon la forme de communication nécessaire.
• Unauthorized software stores couvre la distribution de logiciels et d’applications de légitimité douteuse pour ordinateurs et appareils mobiles, avec des téléchargements potentiellement malveillants ou contenant des chevaux de Troie. Tout magasin non approuvé n’est pas nécessairement malveillant. Le distinguer des Software updates nécessaires et approuvées pour les produits courants.

Pour les catégories sensibles, utiliser uniquement des cas de test approuvés et sans danger et des jeux d’essai contrôlés ; ne jamais visiter de contenus illégaux ou éprouvants. Faire examiner catégorie, contexte et éventuelle mauvaise classification par une personne avant toute escalade. Les définitions thématiques ordinaires du catalogue et les exemples historiques de services sont omis pour des raisons éditoriales ; ils ne constituent pas une simple navigation et ne sont pas présentés comme une taxonomie intégralement traduite.

Avant des changements étendus, sauvegarder la politique et tester avec des destinations approuvées et sans danger la correspondance voulue, les mises à jour nécessaires et les vérifications de révocation. En cas de panne, restaurer l’action de la catégorie concernée et refaire les tests plutôt que désactiver tout le filtrage Web.

Generative AI comme catégorie Web dans SFOS 23.0

SFOS 23.0 documente Generative AI comme catégorie Web intégrée pour les sites et services permettant de créer ou de transformer du contenu à l’aide de prompts. Les sites dont l’objectif principal n’est pas l’IA générative sont expressément exclus. Une fonction d’IA supplémentaire au sein d’un autre service ne suffit donc pas à présumer son appartenance à cette catégorie. Celle-ci ne garantit pas la détection de tous les usages de l’IA.

Cette classification des URL par Sophos s’utilise dans une Web Policy. Elle est distincte des signatures applicatives et de la catégorie d’applications Generative AI d’Application Control. Une catégorie Web personnalisée portant le même nom ne se synchronise pas automatiquement avec le catalogue d’applications. Une liste de domaines gérée par l’administrateur dans un groupe d’URL ou une catégorie personnalisée reste également un objet distinct, avec son propre responsable et sa date de révision, et non la catégorie intégrée.

Avant un blocage généralisé, vérifier l’effet sur la version déployée dans un pilote limité :

1. Vérifier la catégorie sous Web > Categories et utiliser Diagnostics > URL category lookup pour une URL de test autorisée et sans danger. La recherche indique uniquement la classification, pas la décision réelle de la politique ; une catégorie personnalisée peut déterminer le résultat affiché.
2. Sous Web > Policies, vérifier la catégorie, les actions HTTP/HTTPS et l’ordre des règles. La politique doit être sélectionnée dans la règle de pare-feu correspondante, sous Security features > Web filtering. Contrôler Enable logging and reporting, Log firewall traffic et Content filtering sous System services > Log settings > Local reporting.
3. Compléter Policy tester par une requête réelle et contrôlée depuis un client, puis vérifier dans Log Viewer la catégorie utilisée, la Web Policy, la règle de pare-feu et l’action. Examiner séparément les décisions d’Application Control. En cas d’écart, vérifier d’abord les catégories personnalisées, l’ordre des règles, les exceptions et le chemin TLS/QUIC, sans présumer une détection complète de l’IA.

Contrôler l’IA générative explique le choix entre catégorie Web, Application Filter et liste de domaines complémentaire, ainsi que le déroulement du pilote.

Bloquer, alerter ou simplement signaler ?

Toutes les catégories ne nécessitent pas le même traitement. Un bon design de protection Web sépare les décisions de sécurité strictes des indications et de l’évaluation pure.

• Bloquer : Logiciels malveillants, phishing, services de contournement connus et catégories clairement interdites. Un site légitime peut être bloqué si sa classification est incorrecte.
• Avertir : Zones grises, environnements de formation et catégories autorisées délibérément. Les utilisateurs peuvent s’habituer aux avertissements et continuer par réflexe.
• Alerte instantanée : Quelques catégories nécessitant une véritable réponse. Trop d’alertes entraînent une fatigue liée aux alertes.
• Reporting uniquement : Analyse des tendances, rapports d’utilisation et signaux faibles. Les résultats ne sont visibles que plus tard.

Pour les environnements productifs, une petite sélection claire est souvent meilleure qu’un catalogue maximal. Si personne n’évalue une alerte, la catégorie ne doit pas être configurée comme alerte instantanée. Si une catégorie doit toujours être bloquée, une alerte supplémentaire n’est utile que si elle entraîne un suivi concret.

Une limite système fixe s’applique aux sites que Sophos classe comme activité criminelle particulièrement répréhensible : le pare-feu les bloque indépendamment de la politique Web ou d’une exception et masque le nom de domaine dans les journaux et les rapports. Dans ce cas, un nom de domaine absent n’est donc pas une erreur de journalisation.

Configuration

La configuration comporte quatre éléments : catégorie ou groupe d’URL, politique Web, règle de pare-feu et, facultativement, alertes instantanées. Leur cohérence est nécessaire pour agir sur le trafic de production.

Créer ou ajuster une catégorie Web

Le chemin de menu est :

Web > Categories

Processus de base :

1. Modifier une catégorie existante ou choisir Add.
2. Attribuer un nom.
3. Sélectionner la classification.
4. Facultativement, sélectionner une politique de modelage du trafic.
5. Choisir le type de configuration.
6. Ajouter des domaines ou des mots-clés.
7. Facultativement, activer les alertes instantanées.
8. Enregistrer.

Pour les catégories personnalisées, le nom doit clairement décrire l’objectif. Des noms comme Custom1 ou Blocklist ne sont pas très utiles par la suite. Il est préférable d’utiliser des noms comme Alert_Self_Harm, Block_Proxy_Anonymizer ou Allow_Business_Cloud_Exceptions.

Les domaines sont vérifiés par rapport au nom de domaine dans l’URL et incluent automatiquement les sous-domaines. Les mots-clés, en revanche, sont vérifiés par rapport à l’URL complète, y compris le chemin et la requête. Cela peut être utile, mais génère plus facilement des faux positifs.

Si une base de données d’URL externe est utilisée, le pare-feu vérifie cette liste toutes les 48 heures pour les mises à jour. Cet intervalle ne peut pas être modifié. Pour les listes de blocage publiques, il est néanmoins conseillé de vérifier si Configurer et gérer en toute sécurité les flux de menaces de Sophos Firewall est plus approprié.

Une catégorie personnalisée ne remplace pas la catégorie Sophos par défaut d’une URL. Une URL peut appartenir à plusieurs catégories. Le pare-feu évalue les catégories dans l’ordre de la liste ; les journaux et rapports indiquent celle utilisée pour la décision de la politique. Il faut donc retester une requête réelle après avoir modifié les entrées ou leur ordre.

Avec Local database, le maximum est de 2,000 entrées. Un fichier .txt local contient une entrée par ligne, tandis qu’un fichier .csv contient les entrées séparées par des virgules sur une seule ligne. External URL database accepte un fichier .txt, .csv, .tar, .gz ou .bz2 accessible par HTTP ou FTP, mais ne prend pas en charge l’authentification sur le serveur source. Les entrées non valides sont ignorées.

La taille du cache externe dépend de la mémoire vive du pare-feu. Sophos indique que la plupart des modèles disposant de plus de 4 Go de RAM peuvent mettre en cache jusqu’à 122,880 entrées. Il faut contrôler la limite réellement disponible dans /log/nSXLd.log avant d’utiliser une liste volumineuse en production.

Contrôler les entrées et les imports

Classification sert à filtrer et gérer les catégories. Traffic shaping policy définit les limites d’utilisation et la bande passante montante et descendante ; conserver None si aucune limitation n’est prévue. Configuration type est initialement sur Local. Saisir une entrée dans Search/Add, puis sélectionner Add, ou importer un fichier local avec Browse. Pour une base externe, ajouter à cet endroit l’URL source.

Une entrée de domaine peut inclure un chemin ou une requête, par exemple example.com/research ou example.com/search?q=report ; un préfixe de protocole comme https:// n’a pas sa place dans cette entrée. Ce sont des exemples de syntaxe, pas des destinations de test approuvées. Un mot-clé doit commencer par une lettre, un chiffre ou _. Les caractères invalides, domaines invalides et lignes vides sont rejetés. Si un fichier local dépasse 2,000 entrées, seules les premières 2,000 sont importées. Les archives de bases externes doivent contenir des fichiers texte. La base externe n’a pas de limite fixe d’entrées ; cela ne rend pas son cache, dépendant de la RAM, illimité.

Ne pas créer de liste d’autorisation par mots-clés : ces contrôles sont moins efficaces et examinent aussi les paramètres de requête. Une catégorie autorisée utilisant research pourrait correspondre à blocked.example/?tag=research, alors que le domaine devrait rester bloqué. Utiliser les catégories à mots-clés uniquement dans des règles de blocage, pas pour autoriser l’accès. Un groupe d’URL convient mieux aux autorisations portant seulement sur des domaines. Documenter les entrées et la politique avant l’import ; ensuite, vérifier la liste enregistrée, une correspondance attendue et une non-correspondance. Si les résultats sont incorrects, restaurer les entrées précédentes plutôt qu’assouplir largement les blocages.

Page de blocage propre à la catégorie

Sous Advanced settings > Override default notification page, un message personnalisé peut remplacer le message par défaut lorsque cette catégorie bloque un site. Les variables {category}, {user} et {url} affichent la catégorie, le nom d’utilisateur et l’URL bloquée. N’inclure que les informations nécessaires : utilisateurs et URL peuvent révéler des données sensibles. Noter le message et le réglage précédents, puis vérifier avec une destination sans danger bloquée dans un test contrôlé. Si l’affichage ne convient pas, restaurer le texte précédent ou la page standard ; modifier le message n’autorise pas le site.

Configurer une politique Web

Le chemin de menu est :

Web > Policies

Une politique Web contient des règles pour les utilisateurs, groupes, activités, catégories, groupes d’URL, types de fichiers, filtres de contenu, actions et horaires.

Processus de base :

1. Créer une nouvelle politique Web ou modifier une politique existante.
2. Ajouter une règle.
3. Sélectionner des utilisateurs ou groupes si la politique doit être basée sur l’utilisateur.
4. Sélectionner des catégories ou groupes d’URL.
5. Définir l’action pour HTTP.
6. Vérifier l’action séparée pour HTTPS.
7. Définir un horaire si nécessaire.
8. Sous Advanced settings, activer Enable logging and reporting si la politique doit apparaître dans les journaux et les rapports.
9. Activer le statut de la règle.
10. Vérifier la position de la règle.
11. Enregistrer.

Enable logging and reporting dans la politique Web et Log firewall traffic dans la règle de pare-feu ont des fonctions différentes. Il faut vérifier les deux pour obtenir une évaluation traçable.

L’ordre au sein de la politique Web est crucial. Les règles sont évaluées de haut en bas. Une règle d’autorisation large au-dessus d’une règle de blocage spécifique peut empêcher la règle de blocage de s’appliquer.

Si des utilisateurs sont définis dans la règle de pare-feu et dans la politique Web, il est important de tester consciemment l’effet. Les utilisateurs dans les règles de pare-feu peuvent avoir la priorité sur les utilisateurs dans les politiques Web. En cas de résultats incertains, il est donc conseillé de vérifier non seulement la politique Web, mais aussi la règle de pare-feu.

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

Le chemin de menu est :

Rules and policies > Firewall rules > [Rule] > Security features > Web filtering

Processus de base :

1. Ouvrir la règle client ou serveur pertinente.
2. Vérifier la zone source, le réseau source, la zone de destination et les services.
3. Activer Log firewall traffic.
4. Sous Web filtering, sélectionner la politique Web souhaitée.
5. Activer délibérément Block QUIC protocol ou ne le désactiver que pour une raison justifiée.
6. Vérifier les paramètres de scan des logiciels malveillants et de scan HTTPS.
7. Enregistrer.
8. Tester avec le testeur de politique, le visionneur de journaux et le trafic client réel.

QUIC est souvent un facteur perturbateur pour le filtrage Web. Lorsque les navigateurs communiquent via UDP 443, la logique et la visibilité ne correspondent pas toujours aux attentes du HTTPS classique via TCP. Pour plus de détails, consultez Bloquer correctement le protocole QUIC et HTTP/3 de Sophos Firewall.

Si les contenus HTTPS ou les chemins d’URL complets sont pertinents, la catégorisation Web seule ne suffit pas toujours. Dans ce cas, l’inspection TLS doit être planifiée. Cela ne doit pas être fait à la légère, car les certificats, les exceptions, la confidentialité, la performance et les processus de support sont concernés. Le déploiement est décrit dans Introduire correctement l’inspection TLS de Sophos Firewall.

Exemple : autoriser des catégories uniquement pour un groupe de recherche

Une exception limitée à un groupe est plus sûre qu’une règle d’autorisation générale. Documenter d’abord la politique, la position de la règle de pare-feu et les paramètres du groupe, puis confirmer l’identification des utilisateurs de test. Research, Web categories et Web research group sont des noms d’exemple librement choisis.

1. Créer Research sous Authentication > Groups > Add. Choisir délibérément Surfing quota et Access time, puis Save. Unlimited internet access et Allowed all the time sont des valeurs possibles, pas des prérequis à une exception de catégorie : une utilisation illimitée et un accès permanent nécessitent une approbation distincte.
2. Sous Web > Policies > Add policy, créer Web categories et sélectionner Add rule. La nouvelle règle est en tête, désactivée au départ, et ses réglages initiaux bloqueraient tout le trafic HTTP pour tous les utilisateurs. Modifier la sélection avant de l’activer.
3. Dans Activities, ouvrir All web traffic > Add new item, décocher All web traffic, puis choisir uniquement les catégories approuvées sous Show only > Web category. Confirmer avec Apply selected items.
4. Dans Action, sélectionner Allow HTTP, vérifier délibérément l’action HTTPS distincte, activer Status et enregistrer. Ne pas omettre accidentellement la journalisation ou les autres règles.
5. Sous Rules and policies > Firewall rules, choisir IPv4 ou IPv6, puis Add firewall rule. Limiter Web research group aux réseaux sources, zones, destinations et services nécessaires. Dans le sélecteur d’utilisateurs/groupes, utiliser Add new item, décocher Any, choisir Research et Apply selected items. Affecter la politique sous Security features > Web filtering.
6. Après Save, déplacer la règle avec sa poignée avant la règle générale de travail, sans la placer aveuglément avant d’autres règles de sécurité. Tester avec un membre et un non-membre : seul le groupe approuvé doit accéder à la catégorie autorisée ; les autres catégories et utilisateurs doivent toujours suivre la politique de base prévue. Confirmer l’identifiant de règle, la catégorie et l’action dans Log Viewer.

En cas d’autorisation inattendue, désactiver la nouvelle règle d’exception et restaurer l’ordre ou l’affectation de politique documentés. Refaire les deux tests utilisateur. L’appartenance au groupe ne prouve pas à elle seule que la bonne règle de pare-feu a été appliquée.

L’exemple documenté nomme l’affectation des utilisateurs Identity et le choix de politique Advanced. Les noms des sections peuvent varier selon l’interface. L’essentiel est la sélection restreinte des utilisateurs/groupes et l’affectation de la Web Policy sous Web filtering sur la version installée ; ne pas activer l’exception si cette affectation est incertaine.

Activer les alertes instantanées

Les alertes instantanées sont activées au niveau de la catégorie. Elles sont désactivées par défaut pour toutes les catégories. L’icône de filtre à côté de Instant alerts sous Web > Categories permet d’afficher et de contrôler les catégories surveillées.

Le chemin de menu est :

Web > Categories

Processus de base :

1. Modifier la catégorie.
2. Sélectionner consciemment la catégorie pour la surveillance.
3. Activer les alertes instantanées.
4. Enregistrer.
5. Ouvrir System services > Notifications list.
6. Activer Email notifications en haut de la page.
7. Rechercher Web – Instant alerts.
8. Cocher la case sous Email.
9. Vérifier le serveur de messagerie, l’expéditeur et les destinataires sous Administration > Notification settings.
10. Générer une requête de test et contrôler le prochain lot de notifications, envoyé toutes les cinq minutes.

Le pare-feu envoie des notifications par e-mail pour les catégories surveillées par lots toutes les cinq minutes. Cet intervalle ne peut pas être modifié. Une alerte n’est donc pas une alarme en temps réel à la seconde près, mais une notification par e-mail rapide par rapport aux rapports purement différés.

Les alertes instantanées ne sont pas disponibles sur les XGS 87 et XGS 88. Si la fonction manque sur l’un de ces modèles, la configuration de messagerie ou de notification n’est donc pas nécessairement incorrecte.

Les alertes instantanées ne doivent être activées que pour les catégories où un destinataire défini peut réellement réagir. Une grande liste d’alertes sans responsabilité conduit généralement à une fatigue d’alarme.

Analyse et exploitation

Les alertes ne sont utiles que si elles sont vérifiées, classées et traitées de manière cohérente en exploitation.

Confidentialité et responsabilité interne

Les alertes de catégorie Web peuvent contenir des informations sur l’utilisateur, l’IP source, le moment, la catégorie et, selon la visibilité, également des informations sur la cible. Cela est utile pour la sécurité et l’exploitation, mais peut soulever des questions de droit du travail ou de protection des données selon l’organisation.

Avant l’utilisation en production, il convient donc de clarifier :

• Qui peut voir les alertes Web ?
• Quels résultats sont uniquement vérifiés techniquement et lesquels sont traités comme des incidents de sécurité ?
• Combien de temps les e-mails d’alerte, les rapports ou les événements SIEM sont-ils conservés ?
• L’évaluation est-elle coordonnée avec les RH, la protection des données ou les politiques internes ?
• Comment éviter que des résultats inoffensifs ne soient surinterprétés ?

Techniquement, le paramètre est rapidement activé. Opérationnellement, il doit cependant être traité comme un petit processus de surveillance : destinataire, objectif, chemin de réaction et conservation doivent être cohérents.

Définir le triage des alertes

Les alertes instantanées ne doivent pas toutes être traitées de la même manière. Un seul résultat de catégorie peut être un clic accidentel inoffensif, un service mal classé, un problème de politique ou un véritable incident de sécurité. Il convient donc de définir à l’avance quels résultats doivent être vérifiés immédiatement et lesquels doivent simplement être inclus dans la révision normale.

Un triage simple permet de prioriser les alertes :

• Élevée : Logiciels malveillants, phishing, commande et contrôle, catégories d’exploits ou de logiciels espions. Vérifier rapidement les journaux, l’utilisateur, l’état du terminal et les autres journaux de sécurité.
• Moyenne : Anonymiseurs, proxys, partage de fichiers, stockage cloud privé ou contournements répétés de la politique. Examiner les tendances, clarifier le contexte utilisateur et affiner la politique.
• Faible : Cas isolés dans des zones grises, sans répétition. Les inclure dans le reporting ou la revue hebdomadaire, sans escalade immédiate.
• Faux positif : Site nécessaire à l’activité mal classé. Examiner un groupe d’URL ciblé ou ajuster la catégorie, sans créer de règle d’autorisation générale.

Cette classification ne doit pas seulement exister dans la tête d’un administrateur. Une courte note d’exploitation est utile : catégories surveillées, destinataires, temps de réaction, chemin d’escalade, exceptions autorisées et date de révision. Cela permet de savoir clairement si une alerte doit être simplement documentée, corrigée techniquement ou traitée comme un incident.

Utiliser URL Category Lookup avant le test de policy

Avec une souscription Web Protection active, Diagnostics > URL category lookup indique la catégorie que Sophos attribue à une URL précise. Il faut saisir l’URL de test complète sous Search URL, puis cliquer sur Search. Le résultat affiche le nom et la description de la catégorie. Si l’URL appartient à la fois à une catégorie personnalisée et à une catégorie par défaut, la recherche affiche la catégorie personnalisée.

Le lookup confirme uniquement la catégorisation. Il ne prouve pas quelle règle de pare-feu ou web policy correspond à un client réel, si une exception s’applique, ni comment TLS, QUIC et le chemin de trafic effectif se comportent. Le lookup doit donc être suivi de Policy tester, d’une requête contrôlée depuis un client et de l’analyse dans Log Viewer.

Tester et évaluer

Après chaque modification, il ne suffit pas de sauvegarder, il faut également vérifier l’effet.

Étapes de vérification utiles :

1. Ouvrir Diagnostics > Tools > Pop-out tools > Policy tester. Web > Policies > Policy tester constitue un autre raccourci vers le même outil.
2. Indiquer l’URL, l’utilisateur, l’heure, l’adresse IP source et la zone source, puis tester Firewall, SSL/TLS, and web. Le mode Web policy only ne teste volontairement aucune règle de pare-feu.
3. Sur un client de test, accéder à un site Web approprié.
4. Ouvrir le visionneur de journaux.
5. Vérifier les journaux de filtrage Web, de pare-feu, d’inspection SSL/TLS et de contrôle des applications.
6. Dans la règle de pare-feu, vérifier si le résultat se trouve sur la règle attendue.
7. Pour les alertes instantanées, vérifier la réception des e-mails.
8. Dans Sophos Fusion (anciennement Sophos Central) ou SIEM, vérifier si les événements y sont enregistrés.

Policy tester modélise le trafic Web transparent et ne tient pas compte des routes SD-WAN ; il ne remplace donc pas un flux réel. Si une règle ne correspond pas ou si TLS/QUIC modifie le chemin, la différence n’apparaît souvent que dans Log Viewer ou dans une capture de paquets. Pour de tels cas, consultez Tester une règle de pare-feu avec le visionneur de journaux, le testeur de politique et la capture de paquets.

Pour l’attribution des fichiers journaux, consultez Dépannage de Sophos Firewall : Services et journaux. Les fichiers awarrenhttp.log, webproxy.log et nSXLd.log y sont notamment classés pour les questions de Web et de catégorisation.

Définir la réaction aux alertes instantanées

Une alerte instantanée n’est utile que si l’on sait ensuite ce qui doit se passer. Sinon, cela génère un trafic e-mail supplémentaire, mais pas une meilleure sécurité. Avant l’activation, un processus de réaction simple doit donc être défini.

Pour chaque type de catégorie surveillée, il doit être au moins clair :

• Qui reçoit l’alerte ? Désigner des responsables pour les listes de diffusion.
• Quelle est la rapidité de réaction requise ? Distinguer les résultats critiques du simple suivi.
• Quels journaux sont vérifiés ? Le visionneur de journaux, le Central Reporting, le Syslog ou les journaux de service offrent des niveaux de détail différents.
• Quand un résultat est-il un incident ? Tous les résultats de catégorie ne sont pas automatiquement des incidents de sécurité.
• Qui peut approuver une exception ? Éviter les règles d’autorisation larges et créées dans l’urgence sans évaluation des risques.
• Quand la sélection des catégories est-elle revue ? Prévoir une révision pour réduire la fatigue liée à des ensembles d’alertes trop larges.

Un processus pragmatique ressemble à ceci :

1. Enregistrer l’alerte avec l’utilisateur, l’IP source, la catégorie, l’URL ou le domaine et le moment.
2. Dans le visionneur de journaux, vérifier quelle règle de pare-feu et quelle politique Web ont été appliquées.
3. Si disponible, utiliser le Central Reporting ou le SIEM pour le contexte temporel.
4. Déterminer s’il s’agit d’un cas isolé, d’un modèle répété ou d’un faux positif.
5. En cas de mauvaise catégorisation, travailler uniquement avec un groupe d’URL ciblé ou un ajustement de catégorie.
6. En cas de modèle suspect, évaluer le contexte utilisateur, le statut de l’endpoint et d’autres journaux de sécurité.
7. Documenter la décision : ignorer, observer, bloquer, exception, incident.

Pour une analyse technique détaillée, consultez Dépannage de Sophos Firewall : Services et journaux, Activer le Central Firewall Reporting et Envoyer les journaux Syslog de Sophos Firewall à un SIEM. Si vous n’êtes pas sûr que la bonne règle de pare-feu a été appliquée, consultez Tester une règle de pare-feu avec le visionneur de journaux, le testeur de politique et la capture de paquets.

Recommandation opérationnelle

Pour les environnements productifs, un modèle en trois étapes est judicieux :

1. Bloquer : Bloquer les logiciels malveillants, le phishing, la fraude, la commande et le contrôle, les anonymiseurs et d’autres catégories clairement à risque.
2. Surveiller : Associer quelques catégories sensibles à des alertes instantanées.
3. Évaluer : Vérifier régulièrement les rapports Web, le Central Reporting ou le SIEM.

La limite la plus importante est organisationnelle : une alerte nécessite un destinataire, un délai de réaction et une décision sur ce qu’il advient des résultats. Sinon, les alertes instantanées ne deviennent que du bruit supplémentaire dans les e-mails.

Liste de contrôle

• Licence de protection Web vérifiée.
• Règle de pare-feu pertinente identifiée.
• Politique Web créée ou ajustée.
• Politique Web sélectionnée dans la règle de pare-feu.
• Log firewall traffic activé dans la règle.
• Choix d’activer ou de désactiver Block QUIC protocol effectué explicitement.
• Inspection TLS planifiée ou décision explicite de ne pas l’utiliser.
• Catégories critiques définies.
• Alertes instantanées activées uniquement pour quelques catégories claires.
• System services > Notifications list > Web – Instant alerts activé par e-mail.
• Test effectué avec le testeur de politique.
• Test effectué avec un trafic client réel.
• Visionneur de journaux vérifié.
• Central Reporting ou Syslog vérifié, si une évaluation centrale est attendue.
• Propriétaire et chemin de réaction pour les alertes documentés.

Annuler les modifications en toute sécurité

Avant toute modification, noter l’état de la catégorie, la politique Web et son affectation à la règle de pare-feu. Ce relevé permet un retour ciblé sans désactiver tout le filtrage Web.

1. Pour arrêter uniquement ces alertes, désactiver Instant alerts pour la catégorie sous Web > Categories. Ne pas désactiver globalement Email notifications si d’autres événements utilisent l’e-mail.
2. Si les entrées de catégorie ou l’ordre des règles ont changé, rétablir les entrées et positions notées.
3. Si une autre politique Web a été affectée à la règle de pare-feu, restaurer la précédente sous Rules and policies > Firewall rules > [Rule] > Security features > Web filtering.
4. Refaire les tests initiaux dans Policy tester et sur le client, puis confirmer l’action attendue dans Log Viewer.

Une notification créée avant le retour arrière peut encore arriver dans le prochain lot de cinq minutes. Le critère de réussite est qu’une nouvelle requête contrôlée retrouve l’action de politique notée. Si Instant alerts a été désactivé, cette requête ne doit pas déclencher un nouvel e-mail d’alerte Web.

Dépannage

Si le résultat attendu manque, il faut vérifier pas à pas les logs, le matching des règles et le comportement des policies.

Erreurs typiques

• La politique Web ne s’applique pas : La politique n’est pas sélectionnée dans la règle de pare-feu. Vérifier la règle de pare-feu sous Web filtering.
• La catégorie est autorisée alors qu’elle devrait être bloquée : Une règle d’autorisation large est au-dessus de la règle de blocage. Vérifier l’ordre dans la politique Web et les règles de pare-feu.
• Pas d’alerte instantanée : La catégorie n’est pas surveillée, Email notifications est désactivé globalement ou la case Email de l’événement n’est pas cochée. Vérifier Web > Categories, System services > Notifications list, puis Administration > Notification settings.
• Pas d’information utilisateur dans le journal : L’utilisateur n’est pas reconnu ou la règle ne correspond pas à l’utilisateur. Vérifier l’authentification et, selon la méthode utilisée, STAS, Captive Portal ou la configuration des utilisateurs sans client.
• HTTPS est autorisé de manière inattendue : L’inspection TLS n’est pas adaptée ou l’action HTTPS n’est pas celle attendue. Vérifier la politique Web, les règles d’inspection SSL/TLS et le déchiffrement.
• Le filtrage Web est incomplet : QUIC ou un chemin de trafic incorrect peut en être la cause. Vérifier Block QUIC protocol, les services et le visionneur de journaux.
• Trop d’alertes : La sélection des catégories surveillées est trop large. Réduire la liste des alertes et définir un responsable.
• Domaine manquant dans le journal/rapport : Le domaine peut être masqué en raison d’une catégorie particulièrement critique. Vérifier la catégorie et le comportement de Sophos.

Sophos bloque les sites Web de la catégorie highly objectionable criminal activity de manière systématique et masque le nom de domaine dans les journaux et les rapports. Si une entrée dans ce domaine apparaît anonymisée, cela peut être intentionnel.

Questions fréquentes