Comprendre et configurer en toute sécurité les règles Sophos Firewall

Une règle Sophos Firewall détermine quel trafic entre les zones, les réseaux, les utilisateurs et les services est autorisé ou bloqué. L’objectif n’est pas d’activer le plus d’options possible, mais de choisir des critères de correspondance adaptés, le bon ordre, des fonctions de protection appropriées et un test reproductible.

Le chemin du menu est le suivant :

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Avant de sélectionner Add firewall rule, choisissez explicitement IPv4 ou IPv6 sur la page des règles. Les exemples suivants ne constituent pas une autorisation commune aux deux familles de protocoles.

Cet article explique le formulaire de règle de haut en bas et utilise systématiquement l’exemple LAN_to_WAN_Clients. Les sujets spécialisés tels que NAT, TLS Inspection ou IPS sont expliqués dans la mesure nécessaire pour la règle de pare-feu ; les guides détaillés sont liés à l’endroit approprié.

Planifier avant de créer la règle

Identifier le bon point de contrôle

Les règles de pare-feu normales contrôlent le trafic transféré qui traverse le pare-feu. D’autres tâches se configurent ailleurs :

• Services locaux du pare-feu : WebAdmin, User Portal, VPN Portal, SSH, DNS et SNMP sont contrôlés via Administration > Device access, Local Service ACL et la configuration du service concerné. Voir Device Access et Local Service ACL.
• Trafic généré par le système : les connexions initiées par le pare-feu lui-même ne nécessitent pas de règle de pare-feu normale. Les éléments déterminants sont la configuration du service, le routage, WAN Link Manager et, le cas échéant, SD-WAN pour le trafic système.
• Traduction d’adresses et de ports : NAT traduit le trafic, mais ne l’autorise pas. La règle de pare-feu et la règle NAT doivent fonctionner ensemble.
• Routage et chemin de retour : une règle de pare-feu correspondante ne prouve pas que le routage, SD-WAN, VPN ou le chemin de retour sont corrects.
• Logique Web : les catégories Web, les groupes d’URL et les actions sont définis dans la Web Policy. La règle de pare-feu applique cette politique.
• Déchiffrement HTTPS : une SSL/TLS inspection rule déchiffre le trafic. Scan HTTP and decrypted HTTPS analyse uniquement le trafic HTTPS déjà déchiffré.
• Identité de l’utilisateur : AD SSO, STAS, Captive Portal, Entra ID SSO ou RADIUS doivent d’abord associer l’utilisateur au trafic de manière fiable. Les équipements sans connexion peuvent être configurés comme Clientless Users avec une IP fixe et sans ambiguïté ; cette attribution n’est pas une authentification.

Les accès d’administration qui passent à travers le pare-feu vers des serveurs, des commutateurs ou des hyperviseurs relèvent des règles de pare-feu normales. L’accès au pare-feu lui-même relève en revanche de Device Access.

Ordre des règles, IPv4 et IPv6

Sophos Firewall évalue les règles de haut en bas. Dès que tous les critères positifs de correspondance d’une règle sont satisfaits et qu’aucune exclusion ne s’applique, les règles suivantes ne sont plus évaluées. Une règle générale LAN_to_WAN_Any placée au-dessus de LAN_to_WAN_Restricted rend donc la règle spécifique inopérante pour le trafic qu’elle traite.

Les critères positifs de correspondance comprennent notamment Source zone, Source network, la planification, Destination zone, Destination network, Service et l’utilisateur. Tous les critères positifs configurés doivent correspondre à la connexion. Les Exclusions ne sont pas des critères positifs : lorsque tous les critères configurés d’une exclusion correspondent, SFOS ignore cette règle et poursuit l’évaluation des règles suivantes.

Les règles MTA, IPsec ou Hotspot générées automatiquement peuvent apparaître en haut de la liste. Le Server Access Assistant crée également une règle de pare-feu avec DNAT, reflexive SNAT et loopback. Il faut donc vérifier à nouveau l’ordre après un assistant, une migration ou une modification VPN. Pour un hotspot Sophos Firewall, ce contrôle fait explicitement partie de la procédure de configuration ; le guide du DNAT pour les serveurs publiés explique le Server Access Assistant.

⚠️ Avant de créer la règle Drop avec journalisation : Ne pas supposer qu’elle préserve le blocage HTTP/HTTPS existant : la documentation sur Drop, l’authentification, les Web Exceptions et les pages de blocage est contradictoire. Pour tout trafic Web, une clarification écrite de Sophos pour la version SFOS, le build et le chemin de traitement exacts, ou une vérification isolée et expressément autorisée, est nécessaire avant le déploiement en production. Suivre les consignes de vérification, d’annulation des modifications et d’escalade sous Action et journalisation, plus bas.

Si SFOS ne trouve aucune règle correspondante, la règle implicite drop-all avec le Firewall Rule ID #0 s’applique en bas de la liste. Elle n’affiche aucun Usage Count et ne génère aucune entrée normale dans le journal du trafic du pare-feu. Pour rendre ces abandons visibles dans Log Viewer, Central Reporting ou syslog, il faut créer à la fin de la base de règles une règle Drop au périmètre restreint avec Log firewall traffic activé. Pour cela, il faut sélectionner individuellement les zones Source et Destination réellement nécessaires au lieu de la zone Any ; sinon, la règle peut également prendre en compte le trafic interne vers des services locaux. Les détails sont expliqués dans Analyser les paquets abandonnés sur Sophos Firewall.

Pour une règle de journalisation approuvée, sélectionnez dans le jeu de règles IPv4/IPv6 approprié Add firewall rule > New firewall rule, un nom unique, Rule position Bottom, Action Drop et Log firewall traffic. Sélectionnez individuellement Source zones et Destination zones ; définissez Source networks and devices, Destination networks et Services selon le périmètre approuvé, puis cliquez sur Save. Au préalable, consignez l’ordre existant et la configuration de journalisation. De nouvelles connexions de test autorisées et délibérément non autorisées doivent correspondre aux Rule IDs attendus, sans perturber les services locaux. En cas d’écart, désactivez la nouvelle règle et restaurez l’état précédent. La clarification concernant le trafic web dans la section Action et journalisation reste un prérequis ; ces étapes ne constituent pas un test permettant de la considérer comme acquise.

Les règles IPv4 et IPv6 sont gérées séparément. Une règle IPv4 fonctionnelle ne protège pas automatiquement le même service via IPv6. Dans les environnements dual-stack, les deux ensembles de règles doivent être planifiés et testés de manière délibérée.

Séparer clairement la base de règles

Avant de créer une règle, il faut définir sa Source, sa Destination, ses Services, son Owner et son cas de test. Des risques différents ne doivent pas être regroupés dans une règle fourre-tout :

• Accès Internet des clients : réseaux clients vers la zone WAN, avec une Web Policy adaptée, Application Control, IPS et la journalisation.
• Accès Internet des serveurs : uniquement les destinations de mise à jour, de sauvegarde ou de cloud nécessaires, généralement sans correspondance utilisateur.
• Wi-Fi invité : zone Guest vers Internet, sans destinations internes et, si nécessaire, avec une limite de bande passante.
• Administration : réseaux d’administration définis vers les serveurs et l’infrastructure, séparés du trafic client normal.
• Remote Access VPN : zone VPN vers les destinations et services internes réellement nécessaires.
• Site-to-site : réseaux locaux et distants avec le routage, NAT et le chemin de retour appropriés.
• Systèmes publiés : WAN vers une DMZ ou une zone de serveurs avec une source étroitement limitée, DNAT ou WAF, IPS, journalisation et un niveau de correctifs actuel.
• Accès temporaires : règle distincte avec un ticket, un Owner, une date d’expiration et un retrait planifié.

Pour structurer le réseau, voir Configurer les zones et les interfaces de Sophos Firewall.

⚠️ Any peut être utile pour un test rapide, mais constitue rarement une bonne configuration finale. Il faut ensuite limiter la règle aux sources, destinations et Services réellement nécessaires, ou la supprimer.

Exemple pratique : LAN_to_WAN_Clients

Dans cet exemple, les clients d’un LAN défini sont autorisés à accéder à Internet. Les serveurs, les invités, la VoIP et l’administration utilisent des règles distinctes.

• Rule name: LAN_to_WAN_Clients
• Description: Accès Internet pour le réseau client. Web Filtering, App Control et IPS activés. Owner IT, révision 2026-12-01.
• Rule position: Bottom, puis placer la règle sous les règles spécifiques de blocage et d’exception
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: activé
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS et uniquement les services de base effectivement consultés directement sur Internet
• Web policy: Default Workplace Policy
• Block QUIC protocol: activé
• IPS: politique client appropriée
• App control: politique d’application client appropriée
• Shape traffic: uniquement pour un objectif concret de bande passante
• DSCP marking: uniquement si les appareils en aval traitent le marquage

DNS et NTP ne doivent être ajoutés à cette règle LAN-to-WAN que si les clients communiquent directement avec des résolveurs ou des serveurs de temps externes. S’ils utilisent le pare-feu comme service DNS ou de temps, il s’agit d’un trafic local.

Le test d’acceptation doit utiliser un client défini, une destination précise, le Firewall Rule ID attendu, le NAT Rule ID attendu et le Log Viewer. Cela confirme non seulement que l’application fonctionne, mais aussi que les règles prévues traitent la connexion.

Configurer la règle de pare-feu

En-tête

Rule status, Rule name et Description

Rule status est activé par défaut pour une nouvelle règle. Les règles préparées à l’avance peuvent rester désactivées jusqu’à la fenêtre de maintenance. Les règles de test ou de migration désactivées en permanence doivent être révisées régulièrement.

Le nom doit faire apparaître la Source, la Destination et l’objectif, par exemple :

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

La Description documente l’objectif, l’Owner, le ticket, les restrictions et, le cas échéant, la date d’expiration. Des noms comme Rule1, Allow ou Internet sont peu utiles lors de l’exploitation ultérieure. Voir Documenter clairement les règles Sophos Firewall pour la méthode Avanet.

Rule position et Rule group

Lors de la création d’une règle, Rule position propose Top ou Bottom dans SFOS 22. Après l’enregistrement, la règle peut être déplacée dans le tableau ou positionnée précisément avec Move To. Il ne faut utiliser Top que lorsqu’une règle spécifique doit délibérément prendre la priorité sur des règles existantes.

Rule group améliore la lisibilité, mais ne modifie pas la logique de correspondance. None est la valeur par défaut. Avec Automatic, SFOS affecte la règle à un groupe existant en fonction du premier type de règle correspondant ainsi que des zones Source et Destination. Le pare-feu continue d’évaluer chaque règle de haut en bas. Un groupe ne peut pas rester vide. L’aide SFOS 22 demande de détacher une règle avec Detach avant de la déplacer hors du groupe ; on peut aussi déplacer tout le groupe. Supprimer sa dernière règle supprime également le groupe.

Dans le tableau SFOS-22, affichez ou masquez les filtres avec Enable filter / Disable filter, sélectionnez le champ et la valeur sous Add filter, puis réinitialisez-les avec Reset filter. Lorsque le tableau est filtré, vous pouvez sélectionner des règles individuelles, mais pas des groupes de règles. Les règles ou groupes peuvent être activés ou désactivés avec Enable / Disable ; une sélection mêlant des règles actives et inactives empêche cette action. More options propose la modification, le clonage, l’ajout, la suppression, Detach, Reset data transfer count et des actions sur les groupes. Pour une règle qui n’appartient pas encore à un groupe, sélectionnez Add to group > New group, attribuez un nom au groupe et définissez le type de règle ainsi que les zones Source/Destination ; vous pouvez également sélectionner un groupe existant. Les groupes peuvent être modifiés ou supprimés. La colonne # indique la position ; utilisez le Rule handle pour faire glisser une règle ou un groupe, ou saisissez la position cible dans Move To et confirmez avec Enter. Avant chaque déplacement, consignez l’état précédent, puis vérifiez que de nouveaux flux de test correspondent au Rule ID attendu. Un clone ne constitue pas automatiquement une autorisation sûre : vérifiez les critères, l’état et la position avant de l’activer.

L’aide SFOS 23 décrit un autre fonctionnement : pour une recherche filtrée, cliquer dans le champ de recherche, sélectionner un critère proposé et compléter la recherche à l’aide des suggestions supplémentaires. Appuyer sur Enter pour filtrer la table des règles. Pour rechercher une règle par son nom, le saisir directement dans le champ de recherche et appuyer sur Enter ; retirer chaque filtre avec x. Show/Hide columns permet de sélectionner les colonnes visibles, de modifier leur ordre par cliquer-glisser et de figer jusqu’à trois colonnes pour qu’elles soient toujours affichées en premier. Activer ou désactiver via Status, ou en lot avec Turn on / Turn off ; une sélection mêlant règles actives et désactivées empêche cette action en lot. Les règles désactivées sont estompées avec un nom barré. Déplacer une règle au moins une position hors du groupe l’en retire ; la placer entre deux règles d’un autre groupe l’y ajoute. View menu propose Clone rule above/below, Add rule above/below, Move To et Edit group. Survoler Features permet de distinguer le type User/Network et l’action de la règle des actions de policy et des seuils Heartbeat. Dans la table SFOS 23, User signifie Match known users sélectionné et Network, non sélectionné ; les icônes de policy distinguent None, Accept, Drop et Reject, celles de Heartbeat Green, Yellow et No restriction. Cette présentation ne prouve pas un changement du moteur de trafic.

Les icônes sont des indications de configuration, pas des résultats de test : dans SFOS 23, on vérifie sous Features, et dans SFOS 22 sous Feature and service, si l’analyse Web/FTP/mail et la journalisation du trafic sont activées ou désactivées, si le filtrage par proxy est sélectionné et si des politiques sont affectées. Un proxy activé concerne 80/443 ; les autres ports HTTP/TLS restent traités par DPI. Web policy, App control, IPS et Shape traffic peuvent chacun afficher None ; les icônes IPS et de mise en forme du trafic indiquent qu’une politique est affectée, tandis que les icônes Web et App indiquent également son action. Pour Heartbeat, il faut distinguer le statut minimal Green ou Yellow de No restriction et vérifier séparément l’état de Block clients with no heartbeat. No restriction ne prouve pas à lui seul que ce commutateur supplémentaire est désactivé. Les exclusions activées doivent également être prises en compte lors de la vérification de correspondance.

Pour les nouvelles installations, les aides SFOS-22/23 mentionnent une règle LAN-to-WAN ainsi que la règle MTA avec Linked NAT créée automatiquement lorsque le mode MTA est activé ; MTA y est actif par défaut. Cela ne remplace pas la vérification de votre propre installation. La règle implicite #0 ne peut être ni modifiée, ni supprimée, ni déplacée, et reste exclue des filtres. Il faut distinguer ce cas d’un Factory Reset : les deux aides décrivent la suppression de toutes les règles de pare-feu, suivie de la présence de la seule règle Auto added firewall policy for MTA. Il ne faut pas en déduire qu’une autorisation LAN-to-WAN est automatiquement restaurée. Une réinitialisation n’est pas une méthode de nettoyage de règles individuelles ; la sauvegarde, un accès d’administration indépendant et un plan de restauration relèvent de la procédure distincte Réinitialiser Sophos Firewall.

La vue d’ensemble de démarrage Access rules and policies pour SFOS 22/23 décrit également des groupes de règles créés par défaut avec une règle de pare-feu destinée à abandonner le trafic vers WAN, DMZ et les zones internes (LAN, Wi-Fi, VPN et DMZ). Il s’agit de règles de pare-feu visibles et regroupées, et non de la règle implicite #0. Toutefois, cette vue d’ensemble et les paramètres par défaut détaillés d’installation et de réinitialisation mentionnés ci-dessus n’établissent pas un ensemble initial de règles uniforme pour toutes les installations. Vérifiez donc, sur votre version, votre build et votre installation spécifiques de SFOS, sous Rules and policies > Firewall rules, quelles règles et quels groupes sont effectivement présents et activés, quelles zones source/destination et quels autres critères de correspondance ils utilisent, ainsi que leur position. La seule présence d’un groupe ne prouve pas l’isolation : une autorisation correspondante placée plus haut peut déjà autoriser le trafic. Vérifiez la séparation souhaitée des zones à l’aide de nouvelles connexions de test expressément autorisées et des Rule IDs attendus ; pour le trafic web, le conflit de documentation concernant Drop décrit ci-dessus reste applicable. Ne déduisez de la vue d’ensemble de démarrage ni des noms de groupes garantis, ni des conditions de création, ni un effet de blocage général.

Action et journalisation

Action détermine la manière dont le trafic correspondant est traité :

• Accept: autorise la connexion.
• Drop: est documenté comme un abandon sans notification pour le trafic non Web. Le comportement HTTP/HTTPS n’est pas garanti de manière générale en raison du conflit documentaire décrit ci-dessous.
• Reject: rejette la connexion et envoie une réinitialisation TCP pour TCP ; pour UDP et ICMP, l’aide mentionne explicitement l’envoi d’un message ICMP « port inaccessible » à la source.
• Protect with web server protection: crée une règle WAF. Cette option est disponible uniquement pour IPv4 et nécessite Webserver Protection. La configuration est expliquée dans Sophos Firewall WAF.

Lorsque vous sélectionnez Protect with web server protection, Preconfigured template apparaît. None signifie que vous devez définir vous-même les paramètres WAF. Les modèles documentés sont Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2 et Microsoft Sharepoint 2010 and 2013. Ces noms historiques ne préjugent pas de la prise en charge actuelle ni de la sécurité des versions de serveur concernées. Avant toute utilisation, le modèle doit correspondre au service réellement exploité ; la configuration WAF qui suit et sa validation restent nécessaires.

⚠️ Conflit documentaire non résolu pour le trafic Web : L’aide du formulaire de règles SFOS 22/23 décrit pour Drop l’acceptation et l’examen de HTTP/HTTPS, l’authentification des utilisateurs inconnus lorsque Use web authentication for unknown users est activé, l’autorisation des requêtes permises par une Web Exception correspondante et une page de blocage HTML pour les autres requêtes. Le guide de journalisation du trafic abandonné décrit en revanche un abandon silencieux général et lie la page de blocage Web à cette option d’authentification. Ces descriptions contradictoires ne sont pas résolues ici comme un comportement vérifié d’un build SFOS précis. Elles ne permettent de conclure ni à l’abandon silencieux de toutes les connexions Web, ni à une page de blocage dépendant uniquement de l’option d’authentification, ni au blocage systématique de tous les services.

Si un blocage garanti ou une réponse précise est nécessaire, obtenir une clarification écrite de Sophos pour la version SFOS, le build et le chemin de traitement exacts, ou vérifier dans un environnement de test isolé et expressément autorisé. Tester séparément le trafic non Web, HTTP et HTTPS ; pour le trafic Web, couvrir aussi les utilisateurs connus/inconnus, l’authentification activée/désactivée et la présence/absence d’une Web Exception correspondante. Utiliser uniquement des clients, destinations et services de test définis, activer Log firewall traffic et générer de nouvelles connexions. Consigner le build, la position de la règle, le Firewall Rule ID, l’utilisateur, l’Action, les réglages Web/TLS et les résultats des journaux, de Packet Capture et du navigateur. Un délai d’attente dépassé, une page de blocage ou le Policy Tester seul ne prouve pas le blocage souhaité. En cas d’accès inattendu ou de résultat incertain, ne pas déployer en production ; annuler les modifications de test et transmettre les éléments à Sophos Support. Reject fournit la réponse de protocole décrite ci-dessus ; il n’est pas recommandé ici comme remplacement non vérifié du contrôle Web.

Log firewall traffic doit être activé pour les règles importantes. Les journaux sont stockés localement sur le pare-feu par défaut ; vérifier les réglages locaux et les destinations Syslog sous System services > Log settings. L’envoi au service cloud nécessite en plus d’activer Sophos Central services sur la page Sophos Central. L’aide SFOS 22 nomme la destination Sophos Fusion (anciennement Sophos Central), celle de SFOS 23 Sophos Central ; ce nom ne remplace pas le prérequis distinct. Sans événement Destroy, une session peut se terminer sans journal de session final, par exemple en cas de coupure brutale de la liaison.

Central Firewall Reporting ou un serveur Syslog/SIEM conviennent à une conservation plus longue. La journalisation ne sert pas uniquement au dépannage, mais aussi aux révisions : quelles sources correspondent à la règle, quelles destinations sont utilisées et l’accès reste-t-il approprié ?

La même case à cocher est la source de données de NetFlow v5 sur Sophos Firewall : sans Log firewall traffic, NetFlow n’exporte pas les connexions de cette règle.

Source, Destination et Services

La section Source définit l’origine du trafic :

• Source zones: par exemple LAN, VPN, DMZ, Guest ou WAN.
• Source networks and devices: hôtes individuels, réseaux, plages IP, groupes, FQDN hosts ou objets pays.
• During scheduled time: All the time, les heures de travail ou une fenêtre de maintenance.

La zone seule est généralement trop large. L’exemple client combine donc LAN avec net_LAN_Clients. Pour les règles planifiées, l’heure du pare-feu, le fuseau horaire et la planification doivent tous correspondre.

Configurer des planifications pour les règles et stratégies Sophos Firewall montre comment créer et affecter des plages récurrentes ou ponctuelles, puis les tester à leurs limites de commutation.

Sous Destination and services, il faut configurer :

• Destination zones: par exemple WAN, DMZ, LAN ou VPN.
• Destination networks: Any, un hôte, un réseau, un groupe, un objet pays ou un FQDN host.
• Services: définitions de protocoles et de ports telles que HTTP, HTTPS, DNS, NTP ou un service personnalisé.

Le guide Utiliser correctement les hôtes et services de Sophos Firewall explique comment créer des IP hosts, réseaux, plages, listes, services et groupes, puis contrôler leurs dépendances avant toute modification.

Any peut être acceptable pour une règle générale d’accès Internet des clients. Les règles de serveur, d’administration et VPN doivent utiliser des destinations et des Services beaucoup plus restrictifs. Pour les destinations cloud dynamiques, les FQDN hosts et wildcard FQDNs peuvent être utiles.

Règle basée sur l’adresse MAC : clarifier les limites avant de tenter un blocage

Un hôte MAC peut fournir une association supplémentaire à un appareil pour les clients directement visibles, par exemple lorsque leur adresse DHCP change. Une adresse MAC n’est toutefois pas une identité forte : elle peut être modifiée ou imitée. Le guide source présente le MAC-Filtering comme plus sûr et montre Block_MAC pour IPv4 de LAN vers WAN avec Drop, la journalisation, la position Top, le groupe None, la plage horaire All the time, et Any pour la destination et Services. Cette combinaison ne garantit pas ici un blocage complet d’Internet : le conflit HTTP/HTTPS/Web Exceptions documenté plus haut reste non résolu.

Dans le guide, le filtrage Internet basé sur l’adresse MAC est limité aux appareils directement connectés au pare-feu. Si un routeur, un autre pare-feu ou un commutateur de couche 3 se trouve entre les deux, l’adresse MAC d’origine du client n’est pas automatiquement visible. Le guide mentionne à ce sujet MAC binding pour les utilisateurs locaux ; sans clarification de l’association d’identité et du chemin réel des paquets, cela ne garantit pas un filtrage MAC sur un trajet routé et ne remplace pas l’authentification. Avant toute tentative, l’adresse MAC visible à l’entrée du pare-feu doit réellement appartenir au client de test.

Pour un pilote isolé et explicitement approuvé, seul un nouveau flux TCP IPv4 non web vers un serveur de test WAN contrôlé est bloqué :

1. Comparez l’adresse MAC du client de test à celle visible à l’entrée du pare-feu. Sous Hosts and services > MAC host > Add, saisissez le nom MAC_Host, Type MAC address et l’adresse MAC réellement vérifiée, puis cliquez sur Save. 37:97:0E:AB:56:46 est la valeur d’exemple du guide, conservée telle quelle, et ne doit pas être reprise aveuglément.
2. Sous Rules and policies > Firewall rules, sélectionnez IPv4 et Add firewall rule > New firewall rule. Pour Block_MAC, définissez Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time et Destination zones WAN. Limitez la destination au serveur de test contrôlé et Services au service de test TCP non web approuvé, au lieu de reprendre les valeurs Any d’origine. Consignez au préalable l’ordre et l’état de la configuration, puis cliquez sur Save.
3. Générez un nouveau flux de test, par exemple un flux TCP iPerf3 approuvé, et vérifiez Block_MAC avec son Rule ID dans Log Viewer ainsi que l’abandon des paquets du flux de test. Un autre client de contrôle, non bloqué, doit continuer à pouvoir atteindre la destination de test. Un délai d’attente dépassé ne suffit pas à lui seul.
4. Après le pilote, désactivez ou supprimez la règle de test, restaurez l’ordre précédent et confirmez, depuis le client initial, qu’un nouveau flux de test autorisé correspond au Rule ID attendu. Ne supprimez l’hôte MAC de test que si aucune autre configuration n’en a besoin.

En l’absence de correspondance, vérifiez la visibilité de l’adresse MAC, la sélection IPv4, Source, Schedule et l’ordre, sans étendre la règle à tous les appareils. En cas d’accès inattendu ou de perte d’accès du client de contrôle, annulez l’essai et examinez les éléments de preuve en précisant la version et le build exacts. HTTP, HTTPS, Web Exceptions, les autres zones/destinations/services et IPv6 ne sont pas couverts par ce pilote. Un blocage complet d’Internet basé sur l’adresse MAC ne peut être garanti qu’après clarification et vérification distinctes de ces cas.

Utilisateurs, Exclusions et Linked NAT

Match known users

Avec Match known users, les utilisateurs ou les groupes deviennent des critères de correspondance. Selon la configuration, d’autres champs deviennent alors disponibles :

• Use web authentication for unknown users: redirige les utilisateurs Web inconnus vers AD SSO ou Captive Portal. L’authentification et l’accès depuis la zone concernée doivent déjà être configurés. Configurer et tester Captive Portal sur Sophos Firewall montre comment interagissent l’authentification, Device Access, le prérequis DNS et la règle utilisateur.
• Users or groups: limite la règle aux identités sélectionnées.
• Exclude this user activity from data accounting: exclut ce trafic utilisateur de la comptabilisation individuelle de la consommation de données.

Inconnu signifie ici : connecté au terminal, mais pas encore authentifié auprès du pare-feu. Configurez AD SSO avec Kerberos/NTLM ou Captive Portal sous Authentication > Web authentication, et l’accès depuis les zones nécessaires sous Administration > Device access. Par défaut, le trafic correspondant est comptabilisé dans la consommation de données individuelle. Exclude this user activity from data accounting l’exclut de ce décompte, par exemple lorsque ces utilisateurs ne doivent pas être soumis à une limite de données ; il ne s’agit ni d’une autorisation supplémentaire ni d’une authentification.

Une règle utilisateur fonctionne uniquement si l’association de l’utilisateur est fiable. Une règle de repli large placée en dessous ne doit pas autoriser le même trafic sans correspondance utilisateur. Lors du test d’acceptation, l’utilisateur, le groupe et le Rule ID dans le Log Viewer doivent correspondre.

Add exclusion

Add exclusion exclut du trafic de cette règle. SFOS ignore la règle uniquement lorsque tous les critères d’exclusion configurés correspondent, puis évalue la règle suivante.

Les critères disponibles sont Source zones, Source networks and devices, Destination zones, Destination networks et Services.

Une exclusion pertinente peut concerner un serveur de mise à jour exclu d’une règle client générale et traité par une règle distincte placée au-dessus avec d’autres fonctions de protection. Si les Exclusions deviennent nombreuses ou difficiles à comprendre, une règle spécifique distincte est généralement plus claire.

L’exemple documenté par pays autorise HTTPS depuis des pays africains vers 172.16.16.0 et utilise une Exclusion comprenant uniquement Source zone WAN et un objet de pays sélectionné comme Source network. Cette règle n’est ignorée que si les deux critères correspondent ; le trafic peut être autorisé par une règle ultérieure ou aboutir à #0. L’adresse est un exemple conservé tel quel, et non une définition complète de réseau avec préfixe. Pour votre propre test, sélectionnez un objet de destination réellement existant, documentez l’ordre des règles et vérifiez un flux de test exclu ainsi qu’un flux non exclu à l’aide des Rule IDs. Une Exclusion n’est pas un blocage global.

Create linked NAT rule

Dissocier une Linked NAT Rule dans la table NAT la rend modifiable et entraîne son évaluation selon ses propres critères, indépendamment de la règle firewall d’origine. Documenter son périmètre et l’ordre NAT avant l’opération, puis vérifier un nouveau flux de test ; ce n’est pas un simple renommage.

Une Linked NAT Rule est une règle Source NAT qui s’applique uniquement au trafic traité par la règle de pare-feu liée. La règle NAT définit principalement la Source traduite et la Source translation propre à l’interface.

Dans de nombreuses installations, une règle Default SNAT avec MASQ est déjà présente. Cela dépend toutefois de l’état de la configuration et de la migration et doit être vérifié dans la table des règles NAT concernée. Avant d’ajouter une Linked NAT Rule, il faut vérifier si une règle existante traite déjà correctement le trafic. Si une règle NAT indépendante placée plus haut correspond, elle prend la priorité sur la Linked NAT Rule.

Pour DNAT, SFOS détermine d’abord la destination traduite, puis utilise sa zone pour établir la correspondance avec la règle de pare-feu. Une redirection de port vers un serveur de la DMZ nécessite donc généralement Destination zone DMZ dans la règle de pare-feu, même si le client se connecte à l’adresse WAN publique.

Si le NAT Rule ID est inattendu, il faut également vérifier l’ordre sous Rules and policies > NAT rules. Après une modification NAT, une nouvelle connexion doit être créée, car les sessions existantes ne sont pas évaluées à nouveau. NAT n’autorise pas le trafic à lui seul : la règle de pare-feu décide de l’action Accept ou Drop, tandis que NAT traduit les adresses ou les ports. Voir Comprendre NAT sur Sophos Firewall pour les détails.

Pour le trafic client sortant, vous pouvez créer conjointement l’autorisation du pare-feu et le Source NAT :

1. Sous Rules and policies > Firewall rules, sélectionnez la famille de protocoles et ouvrez Add firewall rule > New firewall rule. Définissez le nom et la position ; dans l’exemple, utilisez Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN et Destination networks Any. Network_LAN doit contenir votre propre réseau client vérifié. Le guide indique Services Any ; en production, sélectionnez uniquement les services approuvés.
2. Sélectionnez Create linked NAT rule, définissez le nom et la position de la règle NAT, puis réglez Translated source (SNAT) sur MASQ. Enregistrez d’abord la Linked NAT Rule avec Save, puis la règle de pare-feu avec Save.
3. Vérifiez la règle de pare-feu dans le tableau des règles de pare-feu et la règle SNAT liée dans le tableau NAT à l’aide du Firewall Rule ID et du nom. La règle de pare-feu est évaluée en premier, puis le Source NAT. Avec Linked NAT, seules la source traduite et la traduction de source propre à l’interface de sortie sont modifiables ; les autres critères, y compris les utilisateurs/groupes, proviennent de la règle de pare-feu.

La notation source 10.145.16.10/24 est la valeur d’exemple du guide, conservée telle quelle, et non une valeur à copier sans vérification comme adresse réseau. MASQ utilise l’adresse IP de l’interface de sortie effectivement sélectionnée. Vérifiez au préalable la route appropriée, l’interface et les règles NAT placées plus haut. Un nouveau flux de test doit présenter le Firewall Rule ID, le NAT Rule ID et la source traduite attendus. En cas de traduction incorrecte, vérifiez l’ordre et la sortie ; en cas d’échec, annulez la nouvelle configuration de pare-feu et de Linked NAT et restaurez l’état précédent, y compris l’ordre, sans modifier les autres règles NAT nécessaires.

Sélectionner les fonctions de protection

Toutes les options ne sont pas disponibles avec la Base License. Avant le déploiement, il faut vérifier sous Administration > Licensing :

• Règles de pare-feu normales : Base License
• IPS et Security Heartbeat : Network Protection
• Web Security, Application Control et protection contre les logiciels malveillants Web : Web Protection
• Sandboxing et analyse de fichiers : Zero-Day Protection
• Protection des e-mails : Email Protection
• WAF : Webserver Protection
• NDR Active threat intelligence : Xstream Protection Bundle

Standard Protection et Xstream Protection incluent Web Protection. Le bundle Avanet Epic Protection inclut également Web Protection. Voir Comparer les bundles de licences Sophos Firewall pour la vue d’ensemble complète.

Web Filtering

Web policy applique une Web Policy contenant des catégories, des groupes d’URL, des utilisateurs et des actions. Sans Web Policy, ce champ ne fournit aucun contrôle Web fondé sur les catégories. La politique est créée et testée sous Web Protection.

Apply web category-based traffic shaping utilise les paramètres de bande passante des catégories Web. Cette option est utile uniquement si des limites ou des garanties y sont effectivement configurées.

Block QUIC protocol bloque le trafic UDP sortant sur les ports 80 et 443 pour cette règle. QUIC ne peut pas être analysé comme du trafic HTTP/HTTPS normal et contourne Web Filtering. SFOS active cette option par défaut lorsqu’une Web Policy ou l’analyse des logiciels malveillants est sélectionnée. Voir Bloquer QUIC et HTTP/3 pour les détails.

Scan HTTP and decrypted HTTPS analyse le trafic HTTP et le trafic HTTPS déjà déchiffré à la recherche de logiciels malveillants, mais n’active pas le déchiffrement. En mode DPI, une SSL/TLS inspection rule adaptée doit être configurée sous Rules and policies > SSL/TLS inspection rules ; en mode proxy web, on utilise Decrypt HTTPS during web proxy filtering. Avant le déploiement, vérifiez le chemin de traitement réellement utilisé et assurez-vous que les clients font confiance à l’autorité de certification de déchiffrement.

Use Zero-day protection nécessite Scan HTTP and decrypted HTTPS et envoie les fichiers téléchargés via HTTP/HTTPS pour une analyse supplémentaire visant à détecter les menaces inconnues ou non encore rendues publiques. Cette fonction nécessite Zero-Day Protection et peut entraîner un délai selon le type de fichier et la politique appliquée ; elle n’active pas elle-même le déchiffrement HTTPS.

Scan FTP for malware est nécessaire uniquement si la règle autorise FTP. L’analyse doit être testée séparément pour les systèmes legacy.

Use web proxy instead of DPI engine limite le filtrage proxy aux ports habituels 80 et 443. Le Web Proxy est notamment requis pour SafeSearch, les restrictions YouTube, les restrictions de domaine Google Workspace, Pharming Protection, Web Cache et Parent Proxy. En mode DPI, les SSL/TLS inspection rules s’appliquent à HTTP et TLS sur tous les ports.

Configurer un upstream proxy sur Sophos Firewall décrit la chaîne supplémentaire de règles et de NAT d’un parent proxy. Un proxy dans WAN nécessite un chemin différent de celui d’un proxy dans LAN ou DMZ.

En revanche, un client Direct Web Proxy explicitement configuré utilise le listener même sans cette option. Configurer Direct Web Proxy avec un fichier PAC explique la configuration complète avec le port, Device Access, le fichier PAC, la règle et les tests.

Decrypt HTTPS during web proxy filtering appartient au mode Web Proxy. En mode DPI, le déchiffrement est contrôlé par les SSL/TLS inspection rules. Les Web Exceptions peuvent contourner le déchiffrement, l’analyse des logiciels malveillants, Zero-Day Protection et Policy Checks ; elles doivent donc être étroitement limitées et révisées régulièrement.

Même lorsque Use web proxy instead of DPI engine est activé, le moteur DPI continue de filtrer HTTP et SSL/TLS sur les autres ports ; cette option concerne le proxy pour 80/443, et non l’ensemble du trafic. L’aide décrit le filtrage par proxy web sur un pont sans adresse IP comme un cas entraînant l’abandon du trafic ; il ne doit pas être activé sans vérification. Decrypt HTTPS during web proxy filtering effectue également le déchiffrement en mode Direct-Proxy explicitement configuré sur le client. En mode DPI, les Web Policies, y compris les Web Exceptions, ne s’appliquent que si une Web Policy est définie, si l’analyse des logiciels malveillants/du contenu est active ou si ATP est actif. Ces conditions doivent être distinguées de la détection des micro-applications basée sur les URL expliquée dans la section Application Control, IPS et Traffic Shaping.

Traiter uniquement certaines destinations via le proxy web

Pour limiter SafeSearch, les restrictions YouTube ou les connexions Google Workspace à certains domaines tout en utilisant le déchiffrement DPI pour le reste du trafic, créez une règle dédiée placée plus haut. Vérifiez au préalable la licence Web Protection, les paramètres web globaux appropriés, la confiance des clients dans l’autorité de certification de déchiffrement et la Web Policy souhaitée. Les groupes FQDN déterminent les destinations ; ils ne configurent pas eux-mêmes les domaines de comptes autorisés ni les actions de filtrage.

1. Sous Rules and policies > Firewall rules, sélectionnez IPv4 ou IPv6, ouvrez Add firewall rule > New firewall rule, puis définissez le nom et la position. Sélectionnez Action Accept, la zone source réellement nécessaire et le réseau client approuvé. Le guide source utilise Any à cet endroit ; cette source étendue n’est pas une exigence pour la production.
2. Définissez Destination zones WAN, Destination networks avec les groupes prédéfinis SafeSearch enforcement, YouTube restrictions enforcement et Google app enforcement, ainsi que Services HTTP, HTTPS. Sélectionnez uniquement les groupes nécessaires au cas d’utilisation souhaité.
3. Activez Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine et Decrypt HTTPS during web proxy filtering. La Web Policy elle-même doit correspondre à la restriction souhaitée. Activez Log firewall traffic pour le pilote et enregistrez avec Save.
4. Positionnez la règle au-dessus des règles DPI. À l’aide de nouvelles connexions, vérifiez la restriction SafeSearch/YouTube/de comptes souhaitée, le Rule ID et les journaux web/TLS ; testez également une autre destination qui doit continuer à correspondre à la règle DPI prévue et à la SSL/TLS inspection rule.

Si la restriction ne s’applique pas, vérifiez la position de la règle, l’association FQDN, la Web Policy et QUIC ; en cas d’erreurs de certificat, vérifiez la confiance dans l’autorité de certification et la configuration de déchiffrement. En cas de comportement inattendu, désactivez la nouvelle règle de proxy ou restaurez les valeurs et la position précédentes, puis vérifiez à nouveau le chemin DPI initial. Ne désactivez pas systématiquement la protection TLS ou la vérification des certificats.

Synchronized Security Heartbeat

Les règles Heartbeat nécessitent :

• un pare-feu enregistré dans le même compte Sophos Fusion avec Security Heartbeat activé ;
• un Sophos Endpoint administré avec une licence d’évaluation ou complète ;
• Network Protection sur le pare-feu.

Pour détecter les Heartbeats manquants, il faut sélectionner les zones concernées sous System > Sophos Fusion > Optional configurations > Missing heartbeat zones.

Minimum source HB permitted et Minimum destination HB permitted définissent un état de santé minimal. Destination Heartbeat convient uniquement aux destinations internes, et non à la zone WAN.

Pour les deux seuils, Green autorise seulement Green ; Yellow, Green ou Yellow ; No restriction autorise aussi Red et les appareils sans Heartbeat. Vérifier également les options distinctes de blocage sans Heartbeat. Le guide des Heartbeats manquants distingue perte et absence depuis l’origine ; Synchronized User ID couvre la déconnexion après perte ou veille/reprise et la validation d’une nouvelle connexion.

Les options Block clients with no heartbeat et Block request to destination with no heartbeat concernent les appareils sans Heartbeat. Un appareil qui n’a jamais envoyé de Heartbeat reste autorisé par défaut et n’est bloqué que lorsque les deux options sont activées. Il faut tester ce comportement délibérément avec des appareils qui n’exécutent pas Sophos Endpoint.

Une Web Exception qui ignore les Policy checks peut autoriser des requêtes Web malgré Block clients with no heartbeat. Voir Analyser les alertes Security Heartbeat manquantes pour le processus de vérification pratique.

Application Control, IPS et Traffic Shaping

Identify and control applications (App control) applique une Application Filter Policy. Application Control nécessite Web Protection. Pour les micro-applications basées sur des URL dans le trafic chiffré, telles que les chargements et téléchargements de fichiers dans Dropbox ou Gmail, une SSL/TLS inspection rule de déchiffrement appropriée est nécessaire. Les filtres, les journaux et les faux positifs sont expliqués dans Configurer Application Control.

L’analyse des malwares et du contenu utilise Web > General settings. Sélectionner le filtrage web proxy nécessite d’abord une Web Policy ou Scan HTTP and decrypted HTTPS. Une Application Filter Policy pour les micro-applications basées sur des URL reste appliquée dans le chemin DPI avec déchiffrement lorsque Web policy vaut None et que l’analyse des logiciels malveillants et ATP sont tous deux désactivés. Cela ne supprime pas les conditions propres aux Web Exceptions en DPI. Les guides détaillés couvrent le proxy sur un bridge sans IP et le déchiffrement HTTPS avec Direct Web Proxy.

Apply application-based traffic shaping policy utilise la politique de bande passante attribuée à une application ou une catégorie sous Applications > Traffic shaping default. Les Application Objects servent en revanche aux routes SD-WAN. Une Rules policy sélectionnée via Shape traffic façonne tout le trafic traité par la règle de pare-feu. L’aide actuelle du formulaire de règle ne décrit pas la priorité entre une Application policy et une Rules policy. Pour une conception prévisible, il convient de n’utiliser qu’une méthode par cas d’utilisation et de tester toute combinaison nécessaire sur le build SFOS déployé. Lorsque Match known users est activé, c’est en revanche la Traffic Shaping Policy de l’utilisateur qui s’applique ; si l’utilisateur n’a pas de politique, celle de son groupe s’applique.

Detect and prevent exploits (IPS) applique une IPS Policy. IPS nécessite Network Protection ou une licence d’évaluation valide et doit être activé globalement sous Intrusion prevention > IPS policies. Le trafic client, serveur, serveur Web et VoIP nécessite des politiques distinctes et testées. Voir Configurer et tester IPS pour un déploiement sûr.

Shape traffic attribue une Traffic Shaping Policy à l’ensemble de la règle, par exemple pour la VoIP, les réunions, les sauvegardes ou les invités. Les garanties et les limites doivent correspondre à la bande passante WAN disponible. Voir Configurer Application Traffic Shaping pour plus d’informations.

DSCP marking marque uniquement les paquets IPv4 et IPv6 sortants qui correspondent à cette règle. Il remplace tout marquage DSCP déjà présent sur le trafic entrant. Les paquets de réponse et le trafic généré par le système ne sont pas marqués par la règle de pare-feu. Le marquage seul ne définit aucune priorité ni classification ; tous les commutateurs, routeurs et équipements WAN concernés doivent traiter les valeurs DSCP sélectionnées de manière cohérente.

Un test QoS limité utilise un client défini, une destination de test autorisée et ICMP avec AF31 = 26. Confirmer la règle utilisée, puis vérifier le marquage avec Packet Capture à la sortie WAN et la réponse séparément. CS0 = 0 est la réponse de l’exemple documenté, pas une garantie sur le marquage de tout correspondant. Ne pas créer d’autorisation large avec Any ; retirer ensuite la règle de test. Tester une règle Sophos Firewall explique la capture.

Le choix DSCP doit correspondre à la conception QoS de l’ensemble du trajet : EF désigne Expedited Forwarding pour une faible latence et de faibles pertes avec les services en temps réel ; AF désigne Assured Forwarding avec rejet en cas de surcharge ; CS assure la compatibilité avec IP-Precedence. Il s’agit de concepts de classes, et non d’une qualité de service garantie par le seul marquage. Les valeurs documentées sont :

L’exemple ICMP d’origine utilise 8.8.8.8, Source zone LAN, Destination zone WAN, Any pour la source et la destination, ainsi que AF31. Pour votre propre vérification, remplacez ces éléments par des objets client et de destination précis et approuvés ; ni cette adresse publique ni une autorisation étendue ne sont nécessaires. Avant le test, consignez la valeur DSCP précédente, restaurez-la après le test et vérifiez-la avec de nouveaux paquets. Si la priorisation attendue n’est pas constatée, examinez séparément la correspondance avec la règle, le marquage effectif en sortie et le traitement QoS effectué par les équipements en aval.

NDR Active threat intelligence

Scan with NDR Active threat intelligence compare le trafic à des signatures NDR sélectionnées. L’action est fixée à Log threats : la fonction détecte et journalise les événements, mais ne bloque pas le trafic.

Les conditions requises sont les suivantes :

• Xstream Protection Bundle ;
• activation globale de NDR Active threat intelligence ;
• journalisation IPS activée ;
• sélection de l’option dans chaque règle de pare-feu concernée.

Les XGS Appliances et les déploiements virtuels, logiciels et cloud courants sont pris en charge, à l’exception des XGS 87, 87w, 88 et 88w. XDR ou MDR ainsi que le transfert vers Sophos Fusion sont facultatifs pour une analyse approfondie.

Scan email content

Sous Scan email content, il est possible de sélectionner IMAP, IMAPS, POP3, POP3S, SMTP et SMTPS. La protection nécessite Email Protection. Si les ports standard sont absents sous Services, ils peuvent être ajoutés via Add ports.

Le trafic de messagerie ne doit pas être dissimulé dans une règle générale d’accès Internet des clients. Une règle de messagerie distincte rend la Source, la Destination, les protocoles, la journalisation et les fonctions de protection plus clairs.

Pour un serveur SMTP existant publié par DNAT, Configurer Mail Protection en Legacy mode associe les règles entrante et sortante au NAT, à la politique d’analyse, à TLS et aux logs du proxy Legacy.

Pour la relève du courrier, la case seule ne suffit pas : confiance de la CA, limites globales d’analyse, stratégie POP-IMAP facultative et correspondance réelle de la règle doivent concorder. Analyser et tester POP3 et IMAP sur Sophos Firewall fournit la procédure complète de pilote et de validation.

Préparer les règles de pare-feu via la XML API

Les objets XML FirewallRule et FirewallRuleGroup permettent de modifier les règles et de gérer les groupes de manière traçable. Ils ne remplacent ni la planification des accès ni la validation avec de nouvelles connexions de test. La sécurisation de l’accès, l’envoi de requêtes HTTP POST à APIController, les opérations XML explicites, la vérification TLS, le stockage des secrets et l’analyse des statuts XML plutôt que du succès HTTP sont expliqués dans Sécuriser l’accès à l’API XML. Une requête de lecture sans risque doit d’abord fonctionner depuis l’hôte d’automatisation prévu, avec un compte aux droits strictement limités.

Conserver le type de règle, la structure des éléments parents et l’ordre

Dans la référence SFOS-22/23, Name, Position et PolicyType sont obligatoires pour Add/Edit. Name est une chaîne UTF-8 de 60 caractères au maximum, sans virgule. Sous FirewallRule, PolicyType sélectionne, avec Network, le bloc NetworkPolicy ou, avec User, le bloc UserPolicy. Ne mélangez pas ces branches et ne les envoyez pas toutes les deux sans vérification. HTTPBased et HTTPBasedPolicy relèvent de la configuration WAF, tandis que l’association à l’authentification relève de l’authentification WAF. Les actions sur les chemins WAF ne sont pas une traduction numérique des actions réseau.

IPFamily accepte IPv4 ou IPv6 ; le tableau indique IPv4 comme valeur par défaut. Status accepte Enable ou Disable, mais indique ON comme valeur par défaut. Pour les règles préparées à l’avance, définissez délibérément le statut sur Disable et vérifiez la famille de protocoles enregistrée, au lieu de reprendre les valeurs par défaut de la documentation comme valeurs sûres dans la charge utile. Selon le tableau des paramètres, Position accepte Bottom, Top, After ou Before ; l’exemple écrit ces valeurs en minuscules. Confirmez donc la casse et l’opération complète dans API help du build installé. After/Name et Before/Name désignent la règle existante servant de point d’ancrage ; la référence limite ces balises aux requêtes Set. Section distingue Central_TOP, Local et Central_Bottom : clarifiez qui est responsable de la configuration et par quelle voie elle doit être administrée avant toute tentative d’écriture locale ; ne contournez pas une restriction centrale en utilisant une autre section.

Dans le bloc de politique sélectionné, la source et la destination restent séparées : SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network et Services/Service contiennent des références répétables. Schedule référence une planification existante. Les tableaux limitent les références aux réseaux et aux services à 60 caractères ; ils ne documentent aucune limite globale du nombre de critères. Les mêmes éléments parents peuvent figurer sous Exclusions et désignent alors des exceptions à cette règle, et non des autorisations supplémentaires. Avant toute écriture, lisez les zones, hôtes, services et planifications réellement présents, puis vérifiez la correspondance souhaitée, en tenant compte des règles suivantes.

Dans UserPolicy, MatchIdentity, ShowCaptivePortal et Identity/Member complètent les paramètres liés à l’utilisateur. Pour Member, la documentation prévoit plusieurs références d’utilisateurs ou de groupes, de 256 caractères au maximum. L’association d’identité et l’authentification web doivent fonctionner séparément. DataAccounting n’est décrit que lorsque la correspondance d’identité est activée et exclut le trafic utilisateur de la comptabilisation des données ; il n’assure pas l’authentification. L’exemple et le tableau se contredisent ici : l’exemple indique Include/Exclude, le tableau Enable/Disable. De même, pour WebCategoryBaseQoSPolicy et ApplicationBaseQoSPolicy, l’exemple indique Apply/Revoke, tandis que le tableau décrit une chaîne. Ne traduisez pas automatiquement ces valeurs et ne les considérez pas comme interchangeables. Si la valeur exacte à utiliser pour l’objet et le build reste incertaine, arrêtez la requête d’écriture et demandez une clarification à Sophos.

Action dans la branche Network/User accepte Accept, Drop ou Reject ; le tableau indique Drop comme valeur par défaut. Une action explicite reste nécessaire, et le conflit expliqué plus haut concernant le traitement HTTP/HTTPS avec Drop s’applique également aux modifications via l’API. LogTraffic accepte Enable/Disable, avec Disable comme valeur par défaut documentée ; choisissez délibérément la journalisation pour le test d’acceptation. SkipLocalDestined concerne le trafic vers l’adresse IP de l’appliance et ne remplace pas Device Access. Les références de politiques telles que WebFilter, ApplicationControl, IntrusionPrevention et TrafficShapingPolicy doivent correspondre à la protection planifiée au préalable. L’analyse, le proxy, le déchiffrement, Zero-Day et Heartbeat restent des contrôles distincts, avec les prérequis expliqués plus haut. En particulier, les valeurs par défaut telles que OFF, NULL ou NoRestriction contredisent parfois les valeurs d’entrée indiquées ; ni ces indications ni les éléments vides des exemples ne permettent de déterminer l’effet d’une omission, d’un vidage ou d’une mise à jour sur le build concerné.

Lors du transfert des options de protection existantes, il faut vérifier le domaine de valeurs de chaque champ : ProxyMode mentionne, en plus de Enable/Disable, true/false ; NDRActiveThreatIntelligence mentionne uniquement true/false. Les seuils MinimumSourceHBPermitted et MinimumDestinationHBPermitted acceptent GREEN, YELLOW et No Restriction, tandis que la colonne des valeurs par défaut indique NoRestriction. Ces entrées sont distinctes de celles des commutateurs Heartbeat séparés ; elles ne constituent pas une traduction automatique des libellés de l’interface graphique. Les sélecteurs liés à l’utilisateur WebFilterInternetScheme et ApplicationControlInternetScheme mentionnent Enable/Disable, mais indiquent 0 comme valeur par défaut ; ne les confondez pas avec un nom de politique. Les commentaires XML associent WebCategoryBaseQoSPolicy à un WebFilter sélectionné et ApplicationBaseQoSPolicy à un filtre d’applications sélectionné. Pour la gestion de la bande passante, le tableau mentionne TrafficShappingPolicy/TrafficShapingPolicy, mais l’exemple XML utilise TrafficShapingPolicy : n’en déduisez ni que ces balises sont interchangeables ni qu’elles sont toutes deux acceptées. DSCPMarking est documenté comme une chaîne de caractères ; la sérialisation de la valeur de l’interface graphique doit correspondre au build. Comparez chaque option de protection concernée avant et après la modification ; ne normalisez pas les entrées inconnues et ne perdez aucune option de protection silencieusement.

L’appartenance à un groupe n’est pas une décision de sécurité

FirewallRuleGroup regroupe les règles existantes via SecurityPolicyList/SecurityPolicy. SourceZones/Zone et DestinationZones/Zone sont des éléments parents distincts servant à l’affectation au groupe, et non de nouveaux critères de correspondance pour les règles individuelles. Le champ Policytype du groupe, avec un « t » minuscule, diffère du champ PolicyType d’une règle. Les sélecteurs de groupe documentés sont User/network rule, Network rule, User rule, WAF rule et Any ; ne déduisez pas ces valeurs du type de règle et ne normalisez pas leur graphie.

Le nom du groupe est obligatoire, encodé en UTF-8, sans virgule et limité à 150 caractères ; Description est facultatif et limité à 255 caractères. Pour SecurityPolicy, la référence indique un maximum de 60 caractères par nom de règle, sans virgule, et jusqu’à 200 valeurs. Il s’agit d’une limite d’appartenance documentée, et non d’une capacité garantie par des tests. Pour un groupe Internet Access, lisez d’abord les noms des règles existantes, sélectionnez uniquement les membres approuvés et affectez séparément la source et la destination. L’exemple du fabricant, avec des deux-points et une sélection de tous les types séparée par des virgules, n’est pas une charge utile exécutable.

Avant de mettre à jour un groupe, sauvegardez son appartenance, les positions des règles et leur statut. Ensuite, vérifiez à nouveau ces mêmes règles dans WebAdmin et au moyen d’une requête de lecture autorisée. La description « Add/Remove » de SecurityPolicy ne définit ni une modification incrémentale sûre de la liste ni une sémantique de remplacement. Si le traitement des listes omises ou vides reste incertain, n’effectuez aucune écriture. Selon l’aide de l’interface graphique, un groupe ne peut pas exister sans règle ; le retrait de la dernière règle peut également supprimer le groupe. Le regroupement améliore la lisibilité, mais ne crée ni isolation ni priorité : les critères de correspondance et l’ordre réel de chaque règle restent déterminants.

Distinguer les réponses selon l’opération et relire l’état enregistré

Les correspondances suivantes sont identiques dans les références SFOS 22/23. Les identifiants Message.* restent des symboles documentaires non résolus, et non des messages d’exécution garantis, des traductions ou des causes univoques. Un même code peut désigner des résultats différents selon l’opération. Il s’agit notamment de codes de statut XML, et non de codes de statut HTTP.

Pour la création et la modification de règles Network/User, les distinctions suivantes sont importantes :

• Add firewall rule — 200 — Message.FWRuleAddSuccess ; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename : vérifiez l’ancien et le nouveau nom, les références et le type de règle enregistré, sans supposer simplement que l’opération a entièrement réussi.
• Add firewall rule — 500 — Message.FWRuleAddFail ; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists ; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist : comparez la règle existante et la règle souhaitée à partir de l’état lu, sans écrasement automatique.
• Add firewall rule — 541 — Message.VHIPRangeConflict ; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. N’en déduisez ni une cause d’erreur commune ni une limite numérique du nombre d’utilisateurs.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected ; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected : vérifiez conjointement les zones de destination et la configuration Destination Heartbeat.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName : comparez le nom existant et le type de règle, sans tenter de contourner le problème par un renommage ou un changement de type à l’aveugle.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction ; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction : clarifiez la responsabilité administrative et la voie de modification autorisée.

Les réponses spécifiques au WAF figurant dans les deux références relèvent du guide WAF ; ne transposez pas leurs conflits de ports, de redirection et de Protected Server aux règles Network/User.

Pour les groupes également, consignez l’opération : Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists ; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. La référence Edit utilise effectivement les mêmes symboles Add. Avant une nouvelle tentative, lisez le nom du groupe enregistré, son appartenance et les deux listes de zones ; ne déduisez pas du nom des symboles qu’une opération Edit a effectué une création.

Pour la suppression, les correspondances sont Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. Le tableau Delete marque Name comme facultatif et le décrit de manière contradictoire comme point d’ancrage pour Before/After. N’en déduisez pas qu’une suppression globale sans nom est possible. Avant Remove, vérifiez la cible exacte, les dépendances, l’appartenance aux groupes, Linked NAT, la responsabilité administrative et la charge utile confirmée dans API help. Pour les anciennes règles dont le rôle est incertain, une désactivation contrôlée avec une période d’observation reste la première étape la plus sûre.

Après chaque réponse, ainsi qu’après un délai d’attente dépassé ou une coupure de connexion, lisez d’abord l’état réellement enregistré avant toute nouvelle tentative : le nom, le type, le statut, la famille de protocoles, la position, les critères, les Exclusions, les références de protection et l’appartenance aux groupes doivent correspondre à l’état cible approuvé. Pour Remove, vérifiez également que seule la règle ciblée a disparu et que les règles nécessaires ainsi que le NAT restent inchangés. Un résultat inconnu peut déjà avoir entraîné une modification. Ne répétez pas l’opération à l’aveugle, n’effectuez pas d’Upsert automatique et n’élargissez pas le périmètre à Any ; en cas d’écart, arrêtez-vous, conservez la réponse expurgée des données sensibles et l’Audit Trail, puis utilisez la procédure de retour arrière confirmée. Ce n’est qu’ensuite que sont exécutés les nouveaux flux de test autorisés et délibérément non autorisés décrits ci-dessous.

Tester et exploiter la règle

Test d’acceptation après l’enregistrement

Après la configuration, il faut enregistrer la règle avec Save. Elle n’est terminée que lorsque le cas de test défini produit les résultats attendus :

Il ne faut effectuer qu’une seule modification par test afin de pouvoir associer clairement la cause et l’effet.

1. Vérifier la position de la règle et le Rule group.
2. Vérifier Log firewall traffic et les destinations sous System services > Log settings.
3. Générer exactement une connexion de test depuis un client défini vers une destination et un Service définis.
4. Vérifier le Firewall Rule ID, le Rule name, l’utilisateur et l’Action dans le Log Viewer.
5. Vérifier le NAT Rule ID et les adresses traduites.
6. Vérifier DNS et le routage séparément.
7. Valider la Web Policy, Application Control, IPS et TLS Inspection par rapport à l’action attendue.
8. Rechercher des rejets inattendus, des erreurs SSL/TLS ou des problèmes de performance.
9. Supprimer la règle de test ou la limiter aux objets de production.

Le Policy Tester simule la sélection des règles, mais ne génère aucun flux de paquets réel et ne confirme ni le routage ni le chemin de retour. Voir Tester une règle Sophos Firewall pour la procédure complète avec Policy Test, Log Viewer et Packet Capture.

Nouvelle règle, règle existante ou désactivation

Une règle existante peut être étendue si la Source, la Destination, l’objectif, l’Owner et la protection nécessaire restent identiques. Une règle distincte est préférable lorsque la journalisation, la date d’expiration, les Security Features, les responsabilités ou les cycles de révision diffèrent.

Les accès d’assistance temporaires, les serveurs, les invités, la VoIP, l’IoT et l’administration ne doivent pas disparaître dans une règle client générale. Pour les anciennes règles peu claires, une désactivation contrôlée est généralement plus sûre qu’une suppression immédiate :

1. Clarifier l’objectif, l’Owner et les dépendances.
2. Définir la journalisation et la fenêtre de test.
3. Informer les équipes concernées.
4. Désactiver la règle et exécuter les tests définis.
5. La supprimer uniquement après une période d’observation traçable.

Une règle d’urgence rarement utilisée peut être importante. Inversement, une règle large fréquemment utilisée n’est pas automatiquement sûre.

Annuler une modification de règle

Avant une modification, il faut noter la position actuelle et tous les champs concernés ou exporter un état de configuration traçable. Une règle existante ne doit pas être réaffectée à un autre usage : une nouvelle règle, initialement désactivée, offre une procédure de retour arrière plus claire et laisse l’autorisation existante inchangée.

Si le test d’acceptation échoue, il faut désactiver la nouvelle règle ou, dans le cas d’une règle modifiée, restaurer les valeurs précédentes et son ancienne position. Il faut ensuite générer à nouveau le flux de test autorisé ainsi qu’un flux de test délibérément non autorisé et vérifier le Firewall Rule ID attendu dans le Log Viewer. Lors d’une modification du chemin d’administration, un accès administratif indépendant doit rester disponible pendant toute la procédure.

Compteur de données, révision et suivi des modifications

Reset data transfer count remet à zéro la quantité de données transférées par une règle. Il ne s’agit pas d’un compteur de sessions ou de correspondances. Dans l’aide SFOS 22, Sophos documente Unused différemment à deux endroits : l’aide de la table des règles indique 24 heures sans trafic correspondant, tandis que le widget Active firewall rules du Control Center indique 12 heures et un contrôle quotidien. Cet état ne constitue donc pas un critère fiable de suppression. New et Changed restent affichés pendant 24 heures à compter de la création ou de la modification, et une règle peut avoir plusieurs états simultanément. Dans l’aide SFOS 23, table et widget indiquent tous deux 12 heures pour Unused.

Les périodes peuvent se chevaucher : une règle créée à 10:00 reste New jusqu’à 10:00 le lendemain. Une modification à 11:00 lui confère le statut Changed jusqu’à 11:00 le lendemain ; entre 11:00 et 10:00 le lendemain, la règle porte les deux statuts. Un statut Unused constaté lors de la vérification quotidienne à 12:00 reste en vigueur jusqu’à la vérification suivante. Si la règle est désactivée à 13:00, elle peut être à la fois Changed et Disabled jusqu’à 13:00 le lendemain, puis uniquement Disabled. Ces exemples de la documentation ne remplacent ni la vérification de l’utilisation réelle ni une décision de suppression. Avant Reset data transfer count, documentez la valeur actuelle : la réinitialisation ne restaure pas une valeur antérieure du compteur et ne modifie aucune autorisation accordée par la règle.

Active firewall rules affiche les règles par type et par état, ainsi que le volume de trafic correspondant en octets sur les dernières 24 heures. La tuile distingue WAF (Webserver Protection), User (avec des utilisateurs ou des groupes) et Network (sans ces critères). Scanned désigne le nombre total de règles dans le graphique, et non le nombre de règles dont le trafic est analysé à la recherche de logiciels malveillants. Disabled signifie que la règle est configurée, mais désactivée ; une règle désactivée peut également être Changed. Le survol permet de consulter le volume de données ; un clic sur le nombre ou sur l’état ouvre le tableau des règles avec le filtre correspondant.

Le widget du Control Center est visible par tous les administrateurs, quels que soient leurs droits. Sa visibilité ne prouve donc pas qu’ils disposent d’un accès en écriture à la page des règles. Ces indicateurs doivent être évalués avec les journaux, la description de la règle et le cas d’utilisation. Reports > Dashboards > Traffic dashboard > Allowed policies permet également d’analyser les données transférées. Si une règle attendue n’apparaît pas dans la table, il faut d’abord réinitialiser le filtre actif ; l’aide SFOS 22 limite aussi les actions de groupe dans une vue filtrée.

Les révisions régulières doivent au minimum contrôler :

• Source, Destination et Services ;
• les objets Any restants ;
• l’Owner, le ticket et la date d’expiration ;
• la journalisation et l’utilisation réelle ;
• NAT, Web Policy, IPS, TLS Inspection et les autres fonctions de protection ;
• les règles désactivées, temporaires et générées automatiquement.

Une sauvegarde doit être disponible avant toute modification importante. Audit Trail Logs et Config Studio montrent les modifications de configuration. Pour les groupes gérés via Sophos Fusion, la Firewall Management Task Queue confirme que la modification est arrivée sur la bonne appliance. Le Firewall Health Check complète la révision de sécurité périodique.

Erreurs typiques

• La règle attendue ne correspond pas ou le Rule ID #0 apparaît : vérifier l’ordre, IPv4/IPv6 et tous les critères Source, Destination, Service, utilisateur et Exclusion.
• Le Firewall Rule ID est correct, mais le NAT Rule ID ou le chemin des paquets ne l’est pas : vérifier l’ordre NAT, le routage, SD-WAN et le chemin de retour.
• La règle correspond, mais la protection est absente ou l’application échoue : vérifier individuellement la licence, l’activation globale, la journalisation, la Web Policy, QUIC, TLS Inspection, IPS et la Traffic Shaping Policy.

Si le Rule ID, le NAT ID ou le chemin des paquets est inattendu, La règle Sophos Firewall ne correspond pas fournit une procédure structurée de recherche des causes.