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

• Configurer fondamentalement la protection Web et les politiques Web: Cet article.
• Comprendre Single ou Dual Engine, les erreurs d’analyse, les limites de taille et un véritable test antimalware : Configurer et tester l’analyse antimalware de Sophos Firewall.
• Évaluer les catégories Web, les groupes d’URL et les alertes instantanées: Utiliser les catégories Web et les alertes instantanées de Sophos Firewall.
• Déchiffrer et examiner le trafic HTTPS: Introduire correctement l’inspection TLS de Sophos Firewall.
• Distribuer le certificat CA pour les clients gérés: Distribuer le certificat CA de Sophos Firewall pour l’inspection TLS.
• Classer QUIC et HTTP/3 en cas de problèmes de filtrage Web: Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall.
• Découvrir quelle règle de pare-feu et quelle politique s’appliquent réellement: Tester les règles de Sophos Firewall avec Log Viewer, Policy tester et Packet Capture.
• Analyser les événements Web et de sécurité sur une plus longue période: Central Firewall Reporting ou Envoyer Syslog à SIEM.

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.

• Politique Web: Règles pour les accès Web autorisés, avertis, bloqués ou basés sur des quotas.
• Catégories Web: Catégories Sophos et catégories personnalisées pour les sites Web.
• Groupes d’URL: Listes de domaines personnalisées pour des règles d’autorisation ou de blocage ciblées.
• Types de fichiers: Contrôle de certains types de téléchargements ou de fichiers.
• Filtres de contenu: Termes ou modèles pour le contrôle du contenu.
• Exceptions: Exceptions ciblées au comportement Web, TLS ou de scan.
• Search engine enforcement: SafeSearch et restrictions YouTube.
• Advanced settings: restrictions des domaines de connexion Google Apps et Microsoft Entra ID Tenant Restrictions.
• Journalisation et reporting: Traçabilité dans Log Viewer, Reporting, Central ou SIEM.

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.

Si les politiques Web doivent réagir aux utilisateurs ou aux groupes, la reconnaissance des utilisateurs doit fonctionner. AD SSO, Captive Portal, STAS, SATC ou d’autres méthodes ne devraient pas être découverts seulement pendant le déploiement de la politique Web. Dans le Log Viewer, il doit être visible si une requête a été évaluée comme utilisateur connu, comme groupe ou comme Anybody ou utilisateur inconnu.

Les critères utilisateur de la règle de pare-feu correspondante priment sur Users dans la politique Web. Celle-ci peut restreindre ce périmètre, mais ne peut pas inclure un utilisateur exclu par la règle de pare-feu.

Parcours minimal vers une politique Web opérationnelle

Créer la politique sous Web > Policies avec au moins une décision Allow/Block ciblée. Modifier ensuite une règle réelle sous Rules and policies > Firewall rules avec Action: Accept, les Source Zone et Source Network, Destination Zone et Destination Network, ainsi que les Services requis. Activer Log firewall traffic et affecter la politique sous Web filtering. Vérifier le NAT existant par rapport au chemin Internet actuel, sans en créer un nouveau uniquement pour cette politique.

Avant la modification, relever la Rule ID et les résultats obtenus avec une URL volontairement autorisée et une autre volontairement bloquée. Répéter exactement les mêmes requêtes depuis un client ayant le véritable contexte source et utilisateur. Valider uniquement lorsque Log Viewer indique la Rule ID attendue, la nouvelle politique et de vrais résultats Allow et Block.

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

La catégorie highly objectionable criminal activity est toujours bloquée. Ni les règles de politique ni les exclusions ne peuvent l’autoriser, et SFOS masque le domaine dans les journaux et rapports.

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 :

• Bloquer les catégories de risques connues: Catégorie Web.
• Autoriser certains domaines SaaS: Groupe d’URL.
• Traiter un domaine mal catégorisé: Groupe d’URL ou catégorie personnalisée.
• Limiter le streaming dans le temps: Politique Web avec horaire ou quota.
• Page d’avertissement au lieu de blocage dur: Politique Web avec action d’avertissement.

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.

Créer et utiliser des URL Groups en toute sécurité explique comment les domaines valides, la logique OR, l’utilisation dans une Web Policy et les exclusions TLS s’articulent.

Pour les correspondances purement par domaine, les groupes d’URL sont généralement préférables aux catégories Web personnalisées. Sophos indique que les groupes d’URL sont plus performants et peuvent générer moins de faux positifs. Les catégories personnalisées sont utiles lorsqu’un domaine doit aussi apparaître dans une logique de politique propre en plus de sa catégorie Sophos standard.

Les mots-clés dans les catégories personnalisées doivent être utilisés avec beaucoup de prudence. Les mots-clés sont vérifiés sur l’URL complète, y compris le chemin et la requête. Une autorisation basée sur un mot-clé peut donc s’appliquer involontairement si ce mot apparaît dans un paramètre de requête sur un autre domaine. Pour les décisions d’autorisation, des domaines concrets ou des groupes d’URL sont généralement plus propres ; les règles par mot-clé conviennent plutôt à des cas de blocage étroits.

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 :

Une autorisation répondant à un besoin métier et placée au-dessus de règles de blocage critiques ne s’applique qu’à son périmètre strictement défini. Si une catégorie à risque doit rester bloquée sans exception, sa règle de blocage doit précéder toutes les règles Allow correspondantes. Vérifier l’ordre avec une destination métier autorisée et une destination bloquée dans le périmètre de l’exception ; l’autorisation d’un domaine ne doit pas autoriser involontairement tous les types de fichiers ou tous les contenus de cette destination.

• Règles d’avertissement ou de quota pour les zones grises.
• 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. Vérifier search engine enforcement, par exemple SafeSearch ou YouTube restrictions.
5. Définir policy quota status si des actions Quota sont utilisées.
6. Vérifier Advanced settings, notamment logging, reporting, les gros téléchargements, Google Apps et Microsoft Entra ID Tenant Restrictions.
7. Enregistrer la politique.

Une règle au sein de la politique Web est créée avec Add rule. Le pare-feu crée d’abord une règle par défaut désactivée qui bloque HTTP pour Anybody. Les champs sont ensuite ajustés de manière ciblée :

1. Ouvrir Users et définir délibérément Anybody, des utilisateurs précis ou des groupes.
2. Ouvrir Activities et sélectionner All web traffic, User activities, Categories, URL Groups ou File types.
3. Pour le contenu, ouvrir l’onglet séparé Content filters, choisir le filtre et activer and with content. Conserver Use action pour HTTPS.
4. Définir Action pour HTTP : Allow, Warn, Block ou Quota.
5. Vérifier l’action HTTPS : Use action, Allow HTTPS, Warn HTTPS, Block HTTPS ou Quota HTTPS.
6. Définir Constraints si la règle ne doit s’appliquer qu’à un horaire.
7. Vérifier la position de la règle au sein de la politique.
8. Activer l’état de la règle.
9. Enregistrer la politique.

Dans Users > Add new item, désélectionner Anybody si seuls certains utilisateurs ou groupes sont concernés. Dans Activities > Add new item, désélectionner All web traffic avant de sélectionner des Activities individuelles. Valider chaque sélection avec Apply selected items. Sinon, la règle reste inutilement large malgré l’ajout d’objets individuels. Les actions HTTP s’appellent Allow HTTP, Warn HTTP, Block HTTP et Quota HTTP ; Use action applique la même décision à HTTPS. Pour les Content filters, ce couplage est fixe et ne peut pas être remplacé par une action HTTPS différente.

Importer proprement des listes de filtres de contenu

Les Content filters sont gérés sous Web > Content filters, puis sélectionnés dans Activities au sein de la règle de politique Web. Pour les listes de termes plus longues, Sophos accepte un simple fichier .txt. Le fichier peut contenir au maximum 2,000 lignes et chaque entrée peut comporter jusqu’à 80 caractères, espaces et signes de ponctuation compris.

Le fichier contient exactement un terme par ligne, chaque ligne étant évaluée comme exact match. Il ne doit contenir ni titre, ni commentaire, ni métadonnée, ni colonne supplémentaire et doit être enregistré en UTF-8 pour les caractères non ASCII.

Procédure sûre :

1. Nettoyer les termes dans un éditeur de texte et placer exactement une entrée par ligne.
2. Enregistrer le fichier au format .txt avec l’encodage UTF-8.
3. Importer la liste sous Web > Content filters et lui attribuer un nom explicite.
4. Dans Activities, ouvrir l’onglet Content filters, sélectionner le filtre, activer and with content et laisser HTTPS sur Use action.
5. Avec un client pilote, tester un terme autorisé et un terme volontairement correspondant, puis vérifier l’action dans Log Viewer.

Si l’importation est refusée ou si certains termes ne s’appliquent pas, vérifier d’abord le nombre de lignes, la longueur des caractères, l’encodage et les caractères invisibles supplémentaires. Une règle Allow trop large placée au-dessus de la règle Content filter ne doit pas contourner la liste.

Pour l’importation, sélectionner précisément Add content filter, saisir le nom, sélectionner un fichier tel que blocked.txt avec Choose file, puis cliquer sur Apply. Dans la règle de politique Web, vérifier ensuite explicitement Block HTTP et Use action pour HTTPS, valider le filtre avec Apply selected items, activer Status et enregistrer la politique. L’importation seule n’active aucun blocage. Pour le pilote, une politique dédiée et affectée est préférable à une modification non maîtrisée de la Default Policy partagée.

Créer des types de fichiers Web personnalisés

Sophos Firewall identifie les File types d’après l’extension du fichier ou l’en-tête MIME. Les types intégrés ne sont pas modifiables. Un type personnalisé se crée sous Web > File types > Add à partir d’un modèle approprié, puis est complété avec les extensions nécessaires sans point initial ou avec des en-têtes MIME. Le même objet peut ensuite être utilisé dans les politiques de protection Web et de messagerie.

Dans la boîte de dialogue Add, renseignez un nom. Template est facultatif et reprend les extensions et en-têtes MIME courants d’une catégorie ; vous pouvez compléter ces valeurs pour le type personnalisé. Cliquez ensuite sur Save. Une extension ne doit pas commencer par un point : pdf est correct, contrairement à .pdf. Les types intégrés servent de modèles et ne sont pas modifiables ; toute adaptation nécessite un type personnalisé.

SFOS propose les catégories intégrées All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files et Web files. La vue détaillée sous Web > File types constitue la référence opérationnelle pour les extensions et en-têtes MIME actuellement configurés. Par exemple, Compressed files comprend notamment 7z, gz, rar, tar.gz et zip, tandis que Document files comprend notamment docx, xlsx, pptx, odt, rtf et pdf. Avant d’autoriser une catégorie, ouvrez donc le type intégré concerné dans votre version de SFOS et comparez son contenu au cas d’usage réel plutôt que de vous fier uniquement à son nom.

Le nouveau type de fichier ne produit aucun effet à lui seul. Il doit être sélectionné sous Activities > File types dans la règle de politique Web concernée. Il faut ensuite vérifier l’action, l’état et l’ordre de la règle, ainsi que l’affectation de la politique Web à la règle de pare-feu qui traite réellement le trafic.

La validation se fait avec un téléchargement représentatif et un fichier volontairement similaire qui ne doit pas correspondre. La politique Web et l’action sont contrôlées dans Log Viewer. Une correspondance fondée sur l’extension ou l’en-tête MIME est une classification de politique, pas une preuve de malware ni d’une analyse Zero-Day effectuée. Pour HTTPS, la visibilité nécessaire dépend également du chemin TLS Inspection. Si le type ne correspond pas, comparez d’abord l’état et l’ordre de la règle, le File Type réellement sélectionné, la réponse Content-Type du serveur, l’extension visible et l’état de TLS Inspection. Un type MIME erroné ou générique envoyé par le serveur peut produire un résultat différent de celui que suggère le nom du fichier.

Référence des types de fichiers intégrés

La référence suivante associe les extensions et les en-têtes MIME documentés aux catégories intégrées. Elle décrit une classification, et non un fichier autorisé ou sûr. Avant toute modification, vérifier ces valeurs par rapport à celles de votre propre installation. All executable files couvre également les exécutables Mac/Linux grâce à des en-têtes MIME supplémentaires ; Executable files est orienté Windows. Dynamic files génère des contenus Web dynamiques, tandis que Encoded files comprend notamment des contenus chiffrés ou encodés en binaire. Les catégories peuvent se chevaucher : mdf figure par exemple dans les bases de données et les images disque, tar dans les documents et tar.gz dans les fichiers compressés. En particulier, application/octet-stream dans Backup files est une valeur MIME générique, et non une preuve fiable qu’il s’agit d’un fichier de sauvegarde.

All executable files

• Extensions: exe, cmd, bat, com.
• En-têtes MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Extensions: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, ram, mp3, wmv.
• En-têtes MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv, audio/ac3, audio/x-ape, audio/flac, audio/mpeg, audio/mp4, audio/ogg.

Backup files

• Extensions: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• En-têtes MIME: application/octet-stream.

Compressed files

• Extensions: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• En-têtes MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Extensions: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• En-têtes MIME: application/pics-rules, application/vnd.ms-officetheme.

Database files

• Extensions: accdb, db, mdsn, mdb, mdf, pdb, sql, sqlite.
• En-têtes MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensions: rb, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj, asc, cbl, cp, cpp, csproj, dev, fs, fsproj, fsx, ftl, gem, hpp, ise, ism, java, ocx, pas, pod, r.
• En-têtes MIME: text/pascal, application/x-bsh, application/x-sh, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl, application/x-shar.

Disk image files

• Extensions: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• En-têtes MIME: application/x-cdlink.

Document files

• Extensions: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, bld, blg, bvp, cdd, cdf, contact, csv, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vdb, odt, opml, pages, rtf, sig, tex, wpd, wps, pdf.
• En-têtes MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/vnd.ms-project, application/x-project, application/cdf, application/x-cdf, application/x-netcdf, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/x-vcard, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf, application/vnd.oasis.opendocument.graphics, application/vnd.oasis.opendocument.presentation, application/vnd.oasis.opendocument.formula, application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.spreadsheet, application/vnd.ms-excel.addin.macroEnabled.12, application/vnd.ms-excel.sheet.binary.macroEnabled.12, application/vnd.ms-excel.sheet.macroEnabled.12, application/vnd.ms-excel.template.macroEnabled.12, application/vnd.ms-powerpoint.addin.macroEnabled.12, application/vnd.ms-powerpoint.slideshow.macroEnabled.12, application/vnd.ms-powerpoint.template.macroEnabled.12, application/vnd.ms-word.document.macroEnabled.12, application/vnd.ms-word.template.macroEnabled.12, application/vnd.openxmlformats-officedocument.presentationml.template, application/vnd.openxmlformats-officedocument.spreadsheetml.template, application/vnd.openxmlformats-officedocument.wordprocessingml.template.

Dynamic files

• Extensions: jsp, asp, php, cgi, shtml.
• En-têtes MIME: text/x-script.perl, text/asp.

Encoded files

• Extensions: bin, enc, hex, hqx, mim, mime, uue.
• En-têtes MIME: application/mac-binary, application/macbinary, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Extensions: exe, cmd, bat, com.
• En-têtes MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec.

Image files

• Extensions: bmp, gif, jpeg, jpg, pcx, png.
• En-têtes MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/jp2, image/vnd.adobe.photoshop, image/tiff.

Page layout files

• Extensions: idml, indd, inx, isd, mdi, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• En-têtes MIME: application/x-mspublisher, application/vnd.ms-xpsdocument.

Plugin files

• Extensions: 8bi, arx, plugin, vst, xll.
• En-têtes MIME: application/x-visio.

System files

• Extensions: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, key, lnk, msp, prf, profile, scf, scr, sys.
• En-têtes MIME: application/vnd.ms-cab-compressed, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp.

Video files

• Extensions: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• En-têtes MIME: application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, Video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash, video/x-flv, video/x-ms-asf, video/3gpp, video/mp4, video/mj2.

Web files

• Extensions: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• En-têtes MIME: application/atom+xml.

Regrouper proprement les User Activities

Sous Web > User activities > Add, une User activity regroupe Web Categories, File types et URL Groups dans une activité réutilisable. Ces éléments sont évalués avec OR ; une seule correspondance suffit. Le nom ne désigne donc pas un utilisateur connecté, mais un ensemble de critères Web.

La User Activity est ensuite sélectionnée sous Activities dans la règle de politique Web. Cette méthode convient lorsque la même combinaison est utilisée dans plusieurs politiques. Pour la validation, tester au moins une correspondance par type d’objet inclus ainsi qu’un cas similaire qui ne doit pas correspondre.

Dans la boîte de dialogue, définir un nom explicite tel que RISK_WEB_CONTENT, sélectionner les catégories, types de fichiers ou URL Groups nécessaires avec Add new item, puis enregistrer avec Save. Show: All permet, si nécessaire, de limiter les types d’objets affichés. Par exemple, une activité peut regrouper la catégorie Spyware/Malware et une liste personnalisée de domaines de test bloqués : un seul de ces critères suffit à déclencher l’action de blocage de la règle de politique. Pour les tests, utiliser des destinations inoffensives que vous contrôlez vous-même, sans ouvrir de véritable site de malware.

Vérifier l’ordre des règles et les politiques migrées

Les règles de politique Web sont évaluées de haut en bas. Par exemple, si une règle Allow pour le type de fichier .mdb se trouve au-dessus d’une règle de blocage de catégorie, les téléchargements .mdb depuis cette catégorie restent autorisés. En mode DPI, la connexion initiale à la catégorie peut être autorisée jusqu’à l’identification du type de fichier ; si le fichier ne correspond ensuite pas, le pare-feu interrompt la connexion sans afficher de page de blocage. Si la catégorie doit toujours être bloquée, sa règle doit précéder la règle Allow du type de fichier.

Les anciennes politiques migrées sont en outre soumises à une limite stricte de 128 règles par politique. Si la source en contient davantage, SFOS n’utilise que les premières 128. Il faut donc regrouper consciemment les règles adjacentes de User Activities, Categories, URL Groups, File types et Dynamic Categories en Activities combinées avant ou après la migration. Le nombre, l’ordre et de vrais tests Allow et Block font partie de la validation de la migration.

Les plages récurrentes sont créées sous forme de planification distincte. La procédure et la différence avec une règle de pare-feu limitée dans le temps sont décrites dans Configurer des planifications pour les règles et stratégies Sophos Firewall.

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.

Ne regrouper que des règles adjacentes ayant la même affectation d’utilisateurs, les mêmes actions HTTP/HTTPS et les mêmes conditions temporelles. Les différences concernant Content filters, Constraints ou l’ordre des règles ne doivent pas être perdues. Avant le regroupement, sauvegarder ou documenter l’ancienne politique et consigner, pour chaque Activity, des cas représentatifs avec et sans correspondance. Après le regroupement, vérifier à nouveau ces décisions ; une réduction du nombre de règles ne prouve pas à elle seule une protection équivalente.

Configurer Advanced settings de manière ciblée

Enable logging and reporting inclut la politique dans les journaux et les rapports ; Log firewall traffic reste également nécessaire dans la règle de pare-feu correspondante. Prevent downloading of large files bloque les téléchargements dépassant la taille renseignée. Choisir le seuil en fonction des téléchargements réellement nécessaires à l’activité et le vérifier avec des fichiers inoffensifs dont la taille est inférieure et supérieure à cette valeur ; ce blocage des téléchargements n’est pas une limite de taille pour l’analyse antimalware.

Add X-Forwarded-For header to outgoing HTTP requests transmet à la destination l’adresse IP de la requête HTTP d’origine. Cette option n’est pas nécessaire au filtrage Web. Ne l’activer que pour un besoin justifié, car le serveur de destination reçoit alors des informations supplémentaires sur le client ; évaluer au préalable la transmission d’adresses internes et les exigences de protection des données. Pour le pilote, documenter les valeurs précédentes et, en cas d’effets indésirables, annuler uniquement ces modifications.

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.
• Scan HTTP and decrypted HTTPS est activé lorsque le scan des malwares Web ou du contenu doit s’appliquer.
• Use Zero-day protection n’est utile que si les fichiers sont scannés via HTTP ou HTTPS déchiffré.
• Block QUIC protocol est consciemment défini.
• Sur le chemin transparent de la règle de pare-feu, Use web proxy instead of DPI engine est activé pour SafeSearch, YouTube Restrictions et les restrictions de connexion Google Apps ; dans les autres cas et avec Direct Proxy, le mode est choisi selon les fonctions requises.
• L’inspection TLS est planifiée séparément et non confondue avec la politique Web.

Sophos Firewall active Block QUIC protocol par défaut lorsqu’une politique Web est sélectionnée dans la règle ou lorsque Scan HTTP and decrypted HTTPS est activé. C’est souvent judicieux, car QUIC ne peut pas être scanné comme le trafic HTTPS classique. Il ne faut toutefois pas simplement accepter cette option sans test : les navigateurs, les services Google, les outils de collaboration et certaines applications SaaS peuvent changer de comportement lorsque QUIC est bloqué.

Si Application Control est aussi utilisé dans la même règle de pare-feu, il existe un chevauchement important : certaines Micro Apps, par exemple les chargements ou téléchargements dans Dropbox ou Gmail, sont reconnues via des détails d’URL. Dans les environnements DPI, cette détection nécessite une règle SSL/TLS Inspection adaptée avec déchiffrement. Application Control peut alors évaluer ces Micro Apps même si la politique Web elle-même n’est pas le point de décision principal.

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.

• Mode DPI: Standard moderne pour de nombreuses règles Internet client. L’inspection TLS fonctionne via les règles d’inspection SSL/TLS, le quota n’est pas pris en charge.
• Mode Web Proxy: Environnements avec comportement de proxy explicite ou quota de politique. Vérifier le comportement du proxy, la compatibilité navigateur/client et les journaux du proxy.

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.

Dans une règle de pare-feu transparente, le Transparent Web Proxy traite uniquement les ports 80 et 443 ; sur les autres ports, le DPI Engine peut inspecter le trafic HTTP et SSL/TLS si la règle de pare-feu et les règles SSL/TLS Inspection correspondent. Direct Proxy constitue un chemin explicite distinct, choisi par le client, et ne requiert pas nécessairement Use web proxy instead of DPI engine. Il faut donc toujours consigner si le test emprunte le chemin transparent ou la configuration proxy explicite du client.

Le choix fonctionnel complet, la migration pilote et les contrôles propres à chaque mode sont réunis dans Comparer correctement DPI Engine et Web Proxy.

Configurer Direct Web Proxy avec un fichier PAC explique comment combiner le listener, le fichier PAC, Device Access et une règle proxy opérationnelle.

Les clients IPv6-only qui accèdent à des destinations web IPv4-only utilisent un chemin distinct à deux règles. NAT64 avec Direct Web Proxy sépare la Web Policy dans la règle IPv6 d’Application Control et IPS dans l’egress IPv4.

Si Sophos Firewall doit transmettre ses Web Requests à un parent proxy, configurer un upstream proxy dans WAN ou LAN/DMZ guide à travers le chemin de règles et de NAT adapté à chaque topologie.

Lorsque plusieurs utilisateurs RDS partagent la même IP de serveur, Per-Connection AD SSO pour les hôtes multi-utilisateurs peut distinguer les connexions proxy HTTP et HTTPS individuelles. La méthode ne s’applique pas au trafic sans proxy et doit donc être délibérément différenciée de SATC.

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 place SafeSearch et YouTube sous Search engine enforcement, et les restrictions de connexion Google Apps et Entra sous Advanced settings.

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.

La référence de l’API XML de SFOS 22/23 décrit EnforceSafeSearch comme applicable uniquement lorsque les catégories Adult Content, Nudity et Porn sont refusées dans la Web Policy. Vérifiez ces décisions dans la politique effectivement affectée au trafic ; activer l’option et remplir les prérequis de proxy et de HTTPS scanning ne suffit pas à établir cette condition documentée. Cette exigence de l’API ne définit pas à elle seule la validation dans l’interface de chaque build. Si l’aide de la build installée diffère, clarifiez cette différence avant de vous fier à SafeSearch.

Sur le chemin transparent de la règle de pare-feu, SafeSearch, YouTube Restrictions et les restrictions Google Apps exigent Use web proxy instead of DPI engine ; un Direct Proxy explicite peut fournir ces fonctions proxy sans cette option de règle de pare-feu. Pour Bing et Yahoo sur HTTPS, SafeSearch exige en plus HTTPS scanning, tandis que les restrictions de connexion Google Apps ne s’appliquent qu’aux domaines hébergés par Google. Les Microsoft Entra ID Tenant Restrictions sont distinctes, nécessitent des valeurs de tenant correctes et doivent être testées avec de vraies connexions au cloud Microsoft plutôt qu’avec une simple URL d’exemple. Ces contrôles ne remplacent pas la gouvernance des identités et des applications cloud dans Microsoft 365 ou Google Workspace.

Sous Apply Microsoft Entra ID tenant restrictions, Restrict-Access-To-Tenants contient les locataires autorisés sous forme de liste de noms de domaine ou d’identifiants de domaine séparés par des virgules, avec un maximum de 256 caractères au total. Restrict-Access-Context contient l’identifiant de domaine du locataire qui définit la restriction, avec un maximum de 50 caractères. Reprendre ces valeurs depuis votre propre administration des locataires, et non depuis un exemple de configuration tiers. Sauvegarder d’abord les valeurs existantes ; tester ensuite, dans le pilote, une connexion à un locataire autorisé et une connexion à un locataire non autorisé et, en cas d’erreur, restaurer uniquement les valeurs modifiées à leur état précédent.

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.

L’allowed time quota est défini au niveau de la politique Web et s’applique à toutes les règles de cette politique qui utilisent une action Quota. Si deux catégories nécessitent des quotas de temps différents, des politiques Web séparées sont plus propres qu’une seule politique avec des attentes de quota mélangées. Les quotas sont réinitialisés localement à minuit et ne peuvent pas être définis sur zéro.

Policy Quota ne s’applique ni aux Content filters ni aux Dynamic Categories. Une modification ne prend pas effet si la politique est invalide, s’il ne reste plus de temps ou si une session Quota est déjà active. Vérifier d’abord la politique et la session.

Ce quota de Web Policy s’applique aux catégories web et n’est pas la Surfing Quota basée sur l’utilisateur. La création, l’attribution et le contrôle de la consommation de Surfing Quota et Network Traffic Quota suivent une procédure distincte.

Lors de l’accès à une destination soumise à une action Quota, la page de quota s’affiche d’abord. L’utilisateur choisit une durée dans la limite du quota disponible et sélectionne Proceed, ou renonce à l’accès avec Return to previous page. À la fin de la période choisie, la page s’affiche à nouveau ; lorsque le quota est épuisé, aucune durée restante n’est proposée. Un Policy Override peut permettre à la place un accès temporaire ; dans ce cas, le quota ne s’applique pas. L’autorisation d’override ne doit donc pas être activée pour tous les utilisateurs comme une alternative utilisable sans restriction.

Une règle SSL/TLS Inspection correspondante avec Action > Deny continue de bloquer l’accès ; augmenter le quota ou le réinitialiser ne résout pas ce conflit. Vérifier d’abord si le blocage TLS est intentionnel au regard des exigences métier. Ne prévoir une Web Exception permettant d’ignorer le déchiffrement HTTPS que pour un cas explicitement approuvé et strictement délimité. Cette exception supprime aussi les contrôles qui en dépendent et peut autoriser des certificats serveur invalides ; ne pas l’utiliser comme solution corrective par défaut. Vérifier séparément l’accès pilote autorisé, le maintien du blocage hors du périmètre de l’exception et le retour arrière par désactivation de l’exception pilote. Le périmètre réel de la Web Exception doit être défini par ses critères pris en charge, par exemple l’IP source du pilote associée au motif de nom d’hôte confirmé — et non par le groupe de l’utilisateur soumis au quota.

Contrôler la Policy Quota en exploitation

Sous Web > Policy quota status, SFOS affiche pour chaque utilisateur le temps restant dans les Web Policies concernées sur une période de 24 heures. L’utilisateur sélectionné peut y être réinitialisé avec Reset. Il s’agit d’un changement d’état volontaire et non d’un bouton de diagnostic : l’utilisateur, la politique, le temps restant, la raison et l’heure sont d’abord documentés.

Cette réinitialisation concerne la Policy Quota temporelle d’une catégorie web. Elle n’est pas identique à Reset user accounting pour les Surfing Quota ou Network Traffic Quota. Un reset ne corrige ni un mauvais ordre des règles ni une identification utilisateur absente.

Personnaliser les pages d’avertissement et de blocage

Sous Web > User notifications, il est possible de configurer des images personnalisées ainsi que des messages de blocage, d’override, de quota et d’avertissement. Les variables {category}, {user} et {url} insèrent la catégorie web, le nom d’utilisateur et l’URL bloquée. La preview contrôle la présentation et le texte, mais ne prouve pas que la bonne Web Policy et la bonne règle de pare-feu correspondent à la requête de production.

Le message doit expliquer brièvement pourquoi l’accès a été bloqué ou a fait l’objet d’un avertissement, et où signaler un besoin professionnel légitime. Les noms d’utilisateur et les URL peuvent contenir des informations sensibles ; la page ne doit donc comporter aucun secret interne, mot de passe ou coordonnée inutile.

Pour les images, activer Use custom images et sélectionner les images souhaitées. Pour les textes, activer selon le cas Use custom block message, Use custom override message, Use custom quota message ou Use custom warn message, puis saisir le texte. Ouvrir le lien de prévisualisation associé, puis vérifier le type de message correspondant avec une véritable requête pilote. Ne pas utiliser de données clients réelles dans les images de test.

Limiter les Policy Overrides en toute sécurité

Un utilisateur déjà autorisé par l’administrateur crée sa session dans le User Portal comme suit :

1. Ouvrir My policy overrides > Add et attribuer un nom de session explicite.
2. Conserver le code d’accès proposé ou en générer un nouveau avec Generate access code. Un code personnalisé créé manuellement n’est autorisé que si ce droit a été expressément accordé.
3. Sélectionner les sites Web et les catégories Web autorisés nécessaires ; les destinations exclues des overrides par l’administrateur ne peuvent pas être autorisées.
4. Sous Restricted to time periods, sélectionner une planification existante dans la liste. Il s’agit de sélectionner une planification, et non de saisir librement une plage horaire quelconque.
5. Enregistrer avec Apply. Saisir ensuite le code d’accès dans le champ prévu sur la page de blocage lors d’une requête bloquée correspondante.

Avec Status, l’utilisateur active ou désactive cette session d’override. Cette fonction est distincte de la gestion administrative via View overrides : l’administrateur peut indépendamment activer, désactiver ou supprimer la session créée par l’utilisateur. Sans autorisation, ce parcours utilisateur n’est pas disponible ; la restriction au groupe principal AD et aux utilisateurs individuels reste applicable.

Les Policy Overrides sont un autre outil que les quotas. Avec Enable policy override, les utilisateurs autorisés peuvent créer dans le User Portal un accès temporaire à des sites Web normalement bloqués. Authorized users and groups limite les personnes autorisées et Blocked websites and categories définit les destinations qui ne peuvent jamais être contournées. Allow manual access code entry n’est activé que si les codes créés par les utilisateurs correspondent au processus d’approbation.

Sous Web > General settings > Policy overrides, documenter d’abord l’état précédent et les utilisateurs autorisés. Dans le User Portal, l’utilisateur autorisé définit les sites ou catégories, une plage de temps limitée et un code d’accès pour l’override. Lors de l’accès à une destination bloquée correspondante, la page de blocage contient un champ supplémentaire pour ce code. Si Allow manual access code entry est activé, les utilisateurs désignés peuvent créer leurs propres codes ; sinon, ils doivent utiliser des codes générés. Ce choix ne doit pas être confondu avec la saisie d’un code déjà valide sur la page de blocage.

View overrides permet d’afficher, d’activer, de désactiver et de supprimer les overrides existants. Pour la validation, utiliser un utilisateur de test autorisé et accéder à une destination correspondante pendant la plage de temps avec un code valide ; sans code, hors de cette plage ou pour une destination qui ne peut jamais être exemptée, le blocage normal doit rester effectif. Corréler utilisateur, Rule ID, politique Web, action et heure dans Log Viewer. En HTTPS, la page de blocage doit pouvoir s’afficher ; une simple interruption de connexion ne fournit aucun champ de saisie.

Pour le retour arrière, désactiver l’override pilote via View overrides et vérifier le blocage initial avec une nouvelle requête. Ensuite seulement, supprimer un override devenu inutile et restaurer uniquement les valeurs globales modifiées pendant le pilote à leur état précédent documenté. Ne pas supprimer globalement les overrides existants des autres utilisateurs.

Pour les utilisateurs AD, My policy overrides ne s’applique qu’au groupe principal et aux utilisateurs individuels, pas aux autres appartenances à des groupes. Une règle d’inspection SSL/TLS correspondante avec Action > Deny reste prioritaire. Si un override approuvé doit fonctionner dans ce cas, une Web Exception au périmètre étroit est planifiée pour ignorer le déchiffrement HTTPS et testée séparément par un cas négatif ; la règle TLS n’est pas assouplie globalement. L’autorisation d’override ne restreint pas la Web Exception ; définir son propre périmètre associant IP source et nom d’hôte ou catégorie, puis le vérifier par des tests négatifs comme décrit ci-dessous.

Web Exceptions et exceptions TLS

Les Web Exceptions sont puissantes et donc dangereuses lorsqu’elles servent de solution rapide : une exception sous Web > Exceptions peut contourner des contrôles pour le trafic correspondant, indépendamment de la politique Web appliquée. Le contournement de HTTPS decryption supprime les contrôles qui en dépendent et autorise les certificats serveur invalides, tandis que le contournement de Malware and content scanning désactive automatiquement aussi Zero-day protection.

Dans les environnements DPI, une restriction importante s’applique : les Web Exceptions ne prennent effet que lorsqu’une politique Web est définie, que Malware and content scanning est actif ou qu’ATP est actif. Les SSL/TLS Exclusion Rules sont en revanche le bon endroit lorsqu’il s’agit uniquement de ne pas déchiffrer certaines connexions TLS. La différence opérationnelle est importante :

• SSL/TLS Exclusion Rule: exclut de manière ciblée les connexions TLS du déchiffrement, typiquement à cause du Certificate Pinning ou d’une incompatibilité.
• Web Exception: peut ignorer les contrôles de politique Web, le scan des malwares, l’analyse Zero-Day ou la validation des certificats.
• URL Group in Web Policy: contrôle Allow, Warn, Block ou Quota; un URL Group n’est pas un critère de Web Exception.

Pour les Web Exceptions, éviter les domaines racine et les expressions régulières d’URL trop larges : un motif non délimité tel que example.com peut aussi correspondre à du texte dans le chemin ou les paramètres de requête d’un autre domaine. Des motifs de noms d’hôte précis peuvent correspondre dans le contexte TLS ; les chemins propres aux URL ne sont visibles qu’en HTTP ou sur du HTTPS déjà déchiffré. Les critères pris en charge pour les Web Exceptions sont les expressions régulières d’URL, les catégories Web, les adresses IP source et les adresses IP de destination — et non les utilisateurs, les groupes d’utilisateurs ou les URL Groups.

Pour une autorisation répondant à un besoin métier et limitée à un groupe d’utilisateurs, utiliser la règle de pare-feu correspondante et Users dans la Web Policy ; pour une exclusion du déchiffrement limitée à des identités en mode DPI, utiliser la règle d’inspection SSL/TLS appropriée avec Don’t decrypt et des critères explicites d’utilisateur ou de groupe. Ces critères d’identité ne deviennent pas des critères d’une Web Exception appliquée séparément et ne limitent pas à eux seuls son contournement.

Pour un pilote de Web Exception, combiner les Source IP addresses des clients concernés avec un motif de nom d’hôte confirmé ou une catégorie Web justifiée. Tester à la fois une source non approuvée et une destination située hors du périmètre réel de correspondance ; une adresse IP n’est pas une identité utilisateur. Ne pas déduire de la logique générale AND que les exceptions par IP source et par IP de destination peuvent être combinées pour une exclusion TLS : les consignes conservées concernant l’exclusion TLS indiquent qu’elles ne peuvent pas être combinées, et leur portée exacte reste incertaine. Si les deux restrictions IP sont nécessaires, s’arrêter sans activer ni élargir l’exception et obtenir une clarification propre à la version utilisée. La procédure et les limites de correspondance sont décrites dans Créer et tester des Web Exceptions en toute sécurité.

Les exceptions combinent leurs différents critères avec AND. Au sein d’un même type de critère, par exemple plusieurs URL Patterns, OR s’applique. C’est pratique, mais sujet aux erreurs : une exception avec URL Pattern et Source IP ne s’applique que si les deux correspondent. Une exception avec de nombreux URL Patterns peut en revanche agir beaucoup plus largement que prévu.

Il faut être particulièrement prudent avec Policy checks. Si une Web Exception ignore les Policy checks, cela peut affaiblir indirectement d’autres décisions de règles. En combinaison avec Synchronized Security Heartbeat, une telle exception peut faire que des requêtes Web ne soient pas bloquées comme prévu, même si les contrôles Heartbeat sont définis dans la règle de pare-feu.

Automatiser Web Protection de manière ciblée via l’API XML

L’API XML est utile lorsque les mêmes objets Web vérifiés doivent être maintenus sur plusieurs pare-feu. Elle ne remplace ni l’affectation de la Web Policy à la règle de pare-feu réellement appropriée ni la vérification du trafic. Avant toute écriture, sauvegarder l’état actuel des objets, leurs références et l’ancienne Policy. L’accès, la construction des requêtes, la version de l’API, le statut XML et l’Audit Trail sont expliqués dans Configurer l’accès à l’API XML de manière sécurisée et analyser les réponses. Les relations entre objets ci-dessous ne constituent pas une requête complète exécutable. En cas de contradictions entre sources explicitement signalées, consulter d’abord API help du build installé et ne rien écrire sans clarification univoque.

Les objets d’abord, la Policy et l’affectation ensuite

Un cas d’automatisation simple consiste à créer un URL Group dédié aux destinations professionnelles, un File Type dédié aux téléchargements et une User Activity regroupant ces critères. Lire ou créer d’abord ces objets avec leurs noms réels, puis faire référencer ces objets par les règles de la Policy et, enfin, affecter de manière contrôlée la Web Policy à la règle de pare-feu existante réellement appropriée. Un nouvel objet, à lui seul, n’autorise ni ne bloque encore aucun trafic.

• URL Group : WebFilterURLGroup contient Name et des entrées URL répétées sous URLlist. La graphie URLlist n’est pas identique à celle de URLList pour une Web Category externe. IsDefault identifie un URL Group intégré ; selon la référence, ce champ est en lecture seule et ses modifications sont ignorées lors d’un Update. Il ne transforme pas un objet personnalisé en objet par défaut modifiable. Pour les valeurs de domaine appropriées et la maintenance dans l’UI, la procédure URL Group reste déterminante.
• File Type : FileType regroupe FileExtensionList avec des valeurs FileExtension répétées et MIMEHeaderList avec des valeurs MIMEHeader répétées. Le commentaire de l’exemple XML décrit Template en indiquant que les extensions et les en-têtes MIME du modèle sont repris et que les entrées indiquées séparément sont ajoutées en complément. Après l’écriture, vérifier donc la liste complète effective, et pas seulement les valeurs ajoutées. L’exemple montre Blank, mais le tableau des paramètres n’explique pas Template ; ne pas en déduire une liste universelle de modèles autorisés. Les extensions restent sans point initial, par exemple pdf.
• User Activity : UserActivity utilise Name pour le nom existant et NewName pour un renommage souhaité. Sous CategoryList figurent des objets Category avec Type et ID. Dans l’exemple, les désignations de type web category, file type et url group sont distinctes de l’ID, qui est le nom de l’objet. Ne pas utiliser un terme de type comme identifiant d’objet et ne pas inventer d’identifiant numérique. L’exemple nomme la balise de description Desc, tandis que le tableau indique Description ; confirmer la balise valide pour le build concerné. La combinaison OR des critères de l’Activity reste distincte de l’action HTTP/HTTPS ultérieure.

En cas d’erreur File Type, ces réponses XML sont particulièrement pertinentes : Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type ou Edit File Type 503 / Message.FileTypeSameDetailRecordExists et 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. Il s’agit de symboles de référence inchangés, et non de textes de message résolus ni de codes HTTP. Pour 202, lire l’ancien et le nouveau nom ainsi que les références de Policy ; pour 503, comparer les valeurs détaillées déjà présentes et, pour 505, vérifier les extensions/en-têtes MIME. Ne pas simplement créer un deuxième objet sous un autre nom.

Catégories personnalisées : séparer contenu, classification et bande passante

WebFilterCategory distingue deux modes de saisie avec ConfigureCategory : Local utilise DomainList/Domain et KeywordList/Keyword ; External utilise URLList/URL pour la liste de catégories externe. L’URL d’une liste externe n’est pas automatiquement une valeur de domaine professionnel à autoriser. L’origine, la mise à jour et le contenu de la liste externe doivent pouvoir être retracés. Ne pas mélanger les deux modes dans une même requête sans vérification.

Classification classe la catégorie, mais ne décide pas de l’action Allow ou Block. La description cite parfois des désignations différentes de celles du tableau des enums ; celui-ci indique Productive, Unproductive, Acceptable et Objectionable. ConfigureCategory n’est pas non plus entièrement cohérent : l’exemple montre Local/External, tandis que le tableau ajoute 0. Ne transmettre ni des noms de classification traduits ni 0 comme valeur de remplacement non vérifiée. QoSPolicy référence une politique de bande passante, pas une action de Web Policy ; le choix et l’effet sont vérifiés dans la procédure Traffic Shaping. Seule une règle de Web Policy appropriée transforme la catégorie en décision d’accès.

Le tableau des catégories exige une vérification précise des détails après l’opération :

• Add Category 201 / Message.WFCCategoryDetailCannotAdded et Update Category 201 / Message.WFCCategoryDetailCannotUpdated : ne pas considérer toutes les réponses XML 2xx comme signifiant que les valeurs de domaine/mot-clé/liste ont été intégralement enregistrées. Relire séparément l’en-tête de l’objet et chaque ensemble de détails nécessaire. Add Category 202 renvoie, comme 200, à Message.WFCAddSuccess ; le nom de symbole commun n’explique pas la différence entre les codes.
• Add Category 522 / Message.WFCMaxFiveURL et 523 / Message.WFCMaxFiveKeyword, mais Update Category 503 / Message.WFCMaxFiveURL et 504 / Message.WFCMaxFiveKeyword : analyser conjointement l’opération et le code. Les noms de symboles, à eux seuls, ne prouvent pas l’existence d’une limite actuelle universelle de cinq entrées ; clarifier le nombre réellement autorisé en consultant l’aide du build installé.
• Delete WebFilter Category 201 / Message.WFCRelationExists et 203 / Message.WFCSomeCategoryCannotDeleted : vérifier les références et les catégories restantes avant de supprimer ou de réessayer. Ne pas conclure à une réussite globale de la suppression pour une sélection de plusieurs catégories.

Tous les symboles Message.* restent ici volontairement non résolus. Avant un Retry, sauvegarder l’état réellement enregistré et la réponse ; en particulier, ne pas répéter aveuglément une modification de catégorie partiellement appliquée.

Content Condition Lists : Key n’est pas Name

Un objet ContentConditionList contient le Name visible, l’identité distincte Key et ContentList avec des valeurs ContentString répétées. La référence exige Name et Key ; pour Delete Content Condition List, Key est explicitement le sélecteur. Lors de la lecture et de la documentation, conserver donc les deux valeurs et ne jamais utiliser le nom affiché comme clé de suppression sans vérification.

Le tableau de l’API décrit ContentString comme des valeurs regex brutes et indique que les doublons ne sont pas ignorés. L’import UI décrit ci-dessus est, en revanche, une liste de texte avec un Exact Match par ligne. Il n’est donc pas établi qu’un import UI et une liste regex de l’API aient un format d’entrée identique. Avant tout changement, clarifier la sémantique en consultant l’aide du build et tester des correspondances et des absences de correspondance inoffensives ; ne pas transmettre une liste de texte existante comme payload regex sans vérification.

Les associations contradictoires entre opérations et messages dans la référence sont particulièrement frappantes :

Ces lignes démontrent une contradiction documentaire, et non qu’un Update supprime ou qu’un Delete met à jour. Vérifier l’opération, Key, la réponse et les contenus réellement présents. Sans clarification univoque pour le build, n’en déduire aucune opération destructive et ne déclencher aucun Retry automatique à partir d’un nom de symbole.

WebFilterPolicy : préserver l’ordre et les sélecteurs

WebFilterPolicy conserve les règles sous RuleList/Rule. Chaque règle référence, sous CategoryList/Category, un nom d’objet ID et un sélecteur type. L’exemple de Policy utilise WebCategory, URLGroup, UserActivity, DynamicCategory et FileType ; ces tokens diffèrent des désignations de type de l’exemple User Activity, et la balise type y est écrite en minuscules. Reprendre la graphie, le type d’objet et le nom existant depuis l’objet lu ou l’aide du build, plutôt que de sérialiser des labels UI ou des identifiants inventés.

HTTPAction et HTTPSAction sont des décisions distinctes ; FollowHTTPAction décrit leur couplage. L’exemple de l’API indique Deny, Allow, Warn, Log et Quota. Ces valeurs d’exemple ne confirment pas qu’elles sont toutes sélectionnables sur chaque build, et Deny ne doit pas être simplement remplacé par le terme UI Block. PolicyRuleEnabled contrôle l’activation de la règle, Schedule le calendrier référencé et UserList/User le périmètre des utilisateurs. CCLRuleEnabled et CCLList/CCL associent les filtres de contenu à la règle ; l’exemple y référence un nom de CCL, tandis que la suppression de la CCL nécessite sa Key. Le comportement HTTPS d’un Content Filter doit toujours correspondre au couplage UI expliqué ci-dessus. Lors d’un Update, préserver l’ordre, le périmètre des utilisateurs, le calendrier, les filtres de contenu et la Default Action, puis comparer l’ensemble de la Policy enregistrée. L’absence d’un champ ne permet de présumer avec certitude ni son maintien ni sa suppression.

Pour les entrées suivantes, la référence ne fournit aucun modèle exécutable exempt de contradictions :

• DefaultAction : le tableau indique un maximum d’un caractère, tout en autorisant Allow et Deny. Ne pas tronquer à un caractère et ne pas inventer de codage numérique de remplacement. EnableReporting montre Enable/Disable dans l’exemple, tandis que le tableau autorise uniquement Enable ; la désactivation n’est donc pas confirmée sans vérification du build.
• DownloadFileSizeRestriction : le commentaire XML indique de 1 à 1536 MB, le tableau des paramètres de 0 à 1536. La signification de 0 reste donc indéterminée ; ne pas le traiter comme une absence de limite ni comme une limite active valide. Définir conjointement DownloadFileSizeRestrictionEnabled et la limite en suivant l’aide du build, puis vérifier avec des fichiers inoffensifs de part et d’autre de la limite confirmée. Le tableau de l’API indique QuotaLimit de 1 à 1440 ; confirmer cette plage pour le build utilisé. DPI ne prend toujours pas en charge la Policy Quota.
• Tenant Controls : Office365Enabled, Office365TenantsList et Office365DirectoryId relèvent de la restriction des tenants Microsoft. Pour la liste, le tableau de l’API indique 4096 caractères, tandis que l’aide UI pour Restrict-Access-To-Tenants indique 256 ; ne pas assimiler ces limites et ne pas déduire de l’indication de l’API qu’une valeur plus longue peut être utilisée en production. La valeur d’exemple pour Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, contient des caractères non hexadécimaux et n’est pas une valeur d’exemple GUID valide. Ne pas la corriger silencieusement, mais utiliser le véritable Directory ID issu de l’administration de son propre tenant et tester les connexions aux tenants autorisés comme non autorisés. Confirmer la correspondance des champs UI, les longueurs et la sémantique dans le build installé.

Add Policy 522 / Message.WebPoliciesLimit concerne la limite des Policies ; ne pas en déduire une limite pour les règles ou les catégories. Update Policy 503 / Message.WFPQuotaLimitInvalid exige la vérification de la valeur de Quota saisie. La référence mentionne en outre Update Policy from API comme désignation d’opération distincte ; ses lignes de réponse ne contiennent pas cette entrée 503. Cela ne prouve pas que cette voie accepte n’importe quel Quota. Vérifier le statut, la Policy enregistrée et l’effet réel avant une nouvelle écriture.

Ne pas confondre options de protection globales et notifications

WebFilterSettings est la section des paramètres globaux du filtre Web, et non une WebFilterPolicy individuelle. Elle contient notamment PharmingProtection, Scanning, BlockUnscannableContent et PUAWhitelist avec des noms PUA répétés. Une entrée PUA est une exception délibérément approuvée, pas une étape nécessaire à une nouvelle Web Policy. Le choix du scanner et son effet restent traités dans la procédure Malware Scanning liée ; adapter un message n’est pas une raison pour modifier au passage les options de protection globales ou la liste PUA.

WebFilterProtectionSettings est un autre contrat distinct d’analyse/protection, avec des champs tels que ScanMode et FileSizeThreshold. Des champs de protection aux noms similaires n’en font pas un synonyme de WebFilterSettings ou de WebFilterNotificationSettings ; ne pas échanger les charges utiles entre ces objets. Pour un simple texte d’information, ne pas inclure d’options d’analyse, de taille ou de certificat. Pour cet objet de protection également, le contrat valide doit provenir de l’aide du build, et non de valeurs d’exemple reprises sans vérification.

Ici aussi, l’exemple contredit le tableau : BlockUnscannableContent montre Enable/Disable, tandis que le tableau autorise Allow et Block (Best Protection). Ne pas uniformiser ces enums ni les deviner à partir du nom du champ. Avant toute modification, sauvegarder le comportement existant et clarifier le contrat exact du build.

WebFilterNotificationSettings concerne, en revanche, les notifications destinées aux utilisateurs. OverrideDefaultDeniedMessage est associé à DefaultDeniedMessage, et OverrideDefaultWarnedMessage à DefaultWarnedMessage ; les textes personnalisés ne sont délibérément sélectionnés qu’avec l’Override correspondant. Des champs Override/Quota supplémentaires figurent dans le tableau, mais sont en partie absents de l’exemple : OverrideDefaultOverrideMessage/DefaultOverrideMessage et OverrideDefaultQuotaMessage/DefaultQuotaMessage. Les commutateurs Override/Quota indiquent 0/1 comme valeurs autorisées, mais aussi Enable comme valeur par défaut. Il s’agit d’une autre contradiction entre sources, et non d’une raison de coder tous les flags de la même manière. Pour un simple changement de texte, ne modifier que les champs de texte/Override prévus, selon le contrat confirmé du build, et vérifier la page correspondante lors du pilote.

DeniedMessageImage sélectionne Default ou Custom. L’exemple associe TopImageFile et BottomImageFile à un nom de fichier de la requête multipart ; le tableau décrit jpg/jpeg. Pour les User Notifications, le tableau nomme toutefois le paramètre supérieur Top Image, tandis que l’exemple utilise TopImageFile. Ces informations ne suffisent pas à construire avec certitude les noms des parties, Content-Disposition, le point de terminaison d’upload ou l’association des fichiers. Clarifier d’abord le transfert de fichiers en consultant l’aide du build ou une collection officielle confirmée à cet effet. Ne pas effectuer de modification automatisée d’image sans contrat d’upload confirmé. Les champs de message/image similaires dans WebFilterSettings ne rendent pas les deux objets interchangeables.

DefaultWebFilterNotificationSettings est encore distinct : il propose des textes de message par défaut nommés, par exemple WebsiteBlocked. Un cas d’usage pertinent et limité consiste à fournir une information approuvée avec le bon contact de support. Pour cela, sauvegarder exactement le texte d’origine concerné, ne modifier que la clé de message confirmée, vérifier l’aperçu correspondant et la page pilote réelle, puis restaurer exactement ce texte si nécessaire. Le texte d’un message n’est ni une autorisation d’accès ni une preuve de détection de malware/Zero-Day.

Relire et valider chaque modification automatisée

Après chaque opération d’écriture, relire l’objet précisément ciblé via l’API ou dans WebAdmin : comparer les noms/Keys, les listes effectives, les références, l’ordre de la Policy, l’activation et l’affectation réelle au pare-feu. Exécuter ensuite les mêmes requêtes pilotes autorisées et bloquées qu’avant la modification, puis corréler Rule ID, utilisateur, Web Policy et action dans le Log Viewer. Une réussite HTTP, un code XML 2xx ou un symbole Message.* non résolu ne suffit pas à lui seul. En cas de modification partielle ou de réponse ambiguë, sauvegarder d’abord l’état réel et l’Audit Trail, puis corriger de manière ciblée ; aucun Retry Add/Delete aveugle. Seules les modifications propres documentées sont annulées, et non les autres Policies, Overrides ou valeurs de protection globales existantes.

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

Le chemin exact est Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web teste le chemin transparent combiné, tandis que Web policy only isole la décision de la politique Web. Le test Web ne représente que les accès transparents, ne tient pas compte des routes SD-WAN et n’accepte pas de Source Networks avec adresse MAC. Sans protocole, il utilise HTTP ; sans port, il utilise le port standard du protocole choisi.

Avant la modification, exécuter les deux modes pertinents comme valeurs de référence et relever le résultat ainsi que la Rule ID attendue, puis répéter les mêmes tests après la modification. Le Policy Tester reste un contrôle préalable : il faut le compléter par de vrais tests Allow et Block depuis un client pilote, car le NAT, l’inspection TLS, QUIC, le routage ou un chemin Direct Proxy explicite peuvent traiter le flux réel différemment.

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
• Si une Web Exception ou une TLS Exclusion s’est appliquée
• Si un téléchargement a été traité différemment en raison de sa taille, d’une erreur de scan des malwares ou d’une analyse Zero-Day

Pour Syslog ou SIEM, l’URL et l’action ne suffisent pas. Une analyse fiable nécessite aussi Firewall Rule ID, utilisateur, catégorie, politique Web, méthode HTTP, statut, résultat de scan, indication d’exception et relation SSL/TLS. Si ces champs manquent dans le SIEM ou sont mal normalisés, la protection Web paraît vite moins claire dans le reporting qu’elle ne l’est réellement sur le pare-feu.

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 :

• E-mail rapide pour quelques catégories Web sensibles: Alertes instantanées.
• Rapports récurrents, tendances et évaluations par utilisateur ou catégorie: Central Firewall Reporting.
• Conservation à long terme, corrélation avec d’autres systèmes ou processus SOC: Syslog ou SIEM.

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 :

• Qui a besoin de l’accès ? Empêche les exceptions globales pour quelques utilisateurs.
• Quel domaine, catégorie ou type de fichier est concerné ? Sépare proprement le groupe d’URL, la catégorie Web et le type de fichier.
• Est-ce une exception temporaire ou permanente ? Une date de révision évite qu’une autorisation provisoire ne reste active indéfiniment sans suivi.
• Quelle règle de pare-feu et quelle politique Web sont concernées ? Empêche les modifications sur la mauvaise règle.
• Comment sera-t-il testé ? Rend le succès traçable dans le Log Viewer.

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 autorisation répondant à un besoin métier est nécessaire, conserver un périmètre étroit dans la règle de pare-feu correspondante et la Web Policy : un URL Group précis plutôt qu’une catégorie entière, et des Users explicitement définis plutôt que l’ensemble du LAN. Si une Web Exception est nécessaire à la place, utiliser ses propres critères d’URL, de catégorie ou d’IP pris en charge ; un groupe d’utilisateurs ou un URL Group n’est pas un critère de Web Exception.
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

En cas de blocage urgent, ne pas insérer par réflexe une règle Allow large en tête de liste. Privilégier une autorisation répondant à un besoin métier, étroite et limitée dans le temps, dans la règle de pare-feu correspondante et la Web Policy, avec un URL Group précis, des Users explicitement définis et une date de révision. Il ne s’agit pas d’une Web Exception limitée à un groupe d’utilisateurs. Tout contournement d’inspection nécessaire exige ses propres critères de correspondance approuvés et pris en charge, ainsi que des tests positifs et négatifs distincts. Réévaluer ensuite l’autorisation temporaire.

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.

Si la connexion n’est pas déchiffrée, le pare-feu peut tout de même utiliser des informations SNI ou de domaine pour les décisions de politique. Les pages de blocage, les pages d’avertissement, les types de fichiers, les Content Filters, le scan des malwares et l’analyse Zero-Day nécessitent toutefois plus de visibilité. Dans le Log Viewer, il faut donc vérifier non seulement l’action de la politique Web, mais aussi le statut SSL/TLS Inspection.

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.

Les Web Exceptions qui ignorent Policy checks ou Malware and content scanning sont particulièrement risquées. Si seul HTTPS decryption pose problème, une SSL/TLS Exclusion est généralement plus étroite et plus compréhensible.

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, journalisation de la politique Web et Reporting actifs.
• Règles de politique Web activées et dans le bon ordre.
• Inspection TLS et certificat CA vérifiés pour le groupe pilote.
• Stratégie QUIC définie.
• Web Exceptions et TLS Exclusions documentées séparément.
• 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