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

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 de correspondance d’une règle sont satisfaits, 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.

Une règle peut notamment établir une correspondance selon Source zone, Source network, la planification, Destination zone, Destination network, Service, l’utilisateur et les Exclusions. Tous les critères configurés doivent correspondre à la connexion.

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.

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.

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.

Pour une nouvelle installation, les aides SFOS 22/23 mentionnent une règle LAN-to-WAN et la règle MTA avec Linked NAT créée automatiquement à l’activation de MTA, activé par défaut selon ces aides. Vérifier néanmoins sa propre installation. La règle implicite #0 ne peut être modifiée, supprimée ni déplacée et reste exclue des filtres. Réinitialiser Sophos Firewall explique l’état différent après un Factory Reset sous SFOS 22.

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: la rejette et envoie un reset TCP ou une réponse ICMP appropriée pour UDP et ICMP.
• 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.

⚠️ 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.

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.

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.

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.

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 recherche des logiciels malveillants dans le trafic HTTP et HTTPS déjà déchiffré. Cette option n’active pas le déchiffrement. Il faut pour cela une SSL/TLS inspection rule correspondante sous Rules and policies > SSL/TLS inspection rules.

Use Zero-day protection soumet les téléchargements suspects à une analyse supplémentaire après la recherche de logiciels malveillants. Cette fonction nécessite Zero-Day Protection et peut entraîner un délai selon le type de fichier et la politique.

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.

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 malware scanning et ATP sont 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.

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.

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. Il s’agit d’une comparaison documentaire, pas d’une mesure testée sur un build d’appliance.

Active firewall rules affiche le nombre de règles actives et le trafic correspondant en octets sur les dernières 24 heures. Le widget distingue WAF (Webserver Protection), User (avec utilisateurs ou groupes) et Network (sans ces critères). Scanned représente le total des règles du graphique, pas le nombre de règles analysant les malwares. Disabled signifie configurée mais désactivée ; une telle règle peut aussi être Changed. Survoler affiche le volume ; cliquer sur un nombre ou un état ouvre la table 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.