Comprendre et configurer les règles Sophos Firewall

Les Firewall Rules sont le coeur de Sophos Firewall. Elles déterminent quel trafic entre zones, réseaux, utilisateurs et services est autorisé ou bloqué, et quelles fonctions de protection sont appliquées.

Cet article explique une Sophos Firewall Rule de haut en bas: ordre, groupes, Action, logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR et analyse des e-mails.

Le chemin de menu est:

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

Navigation rapide

• Principe de base et ordre
• Exemple pratique
• Zone d’en-tête: statut, nom, action et logging
• Source
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Contrôler après l’enregistrement
• Erreurs fréquentes

Principe de base et ordre

Les Firewall Rules contrôlent le trafic entre zones et réseaux. Elles peuvent autoriser, rejeter silencieusement ou bloquer du trafic, et appliquer des Security Features supplémentaires.

Sophos Firewall vérifie les Firewall Rules de haut en bas. Dès qu’une règle correspond, les règles suivantes ne sont plus vérifiées. Ce qui compte n’est donc pas seulement le contenu de la règle, mais aussi sa position dans la liste.

Une règle ne correspond que si tous les critères pertinents correspondent en même temps:

La première règle qui correspond gagne. Si une règle générale LAN_to_WAN_Any se trouve au-dessus d’une règle plus spécifique LAN_to_WAN_Restricted, la règle spécifique ne sera jamais atteinte.

Exemple pratique

L’exemple suivant crée une règle client propre:

Objectif: les clients du LAN interne peuvent accéder à Internet. Web Filtering, Application Control, IPS et logging doivent être actifs. Les serveurs, invités et réseaux de management reçoivent leurs propres règles et ne sont pas mélangés à cette règle client.

Cet exemple n’est volontairement pas un laisser-passer Any. En pratique, réseaux clients, serveurs, Wi-Fi invités, VoIP et management doivent être considérés séparément.

Zone d’en-tête: statut, nom, action et logging

Rule status

Rule status active ou désactive la règle.

Une nouvelle règle est normalement active. Pour des règles préparées, on peut désactiver le statut et activer la règle plus tard. Les règles désactivées doivent être contrôlées régulièrement afin que d’anciennes règles de test ou de migration ne restent pas dans la configuration.

Exemple pratique: une nouvelle règle serveur est préparée, mais activée seulement pendant la fenêtre de maintenance.

Rule name

Le nom doit indiquer immédiatement ce que fait la règle.

Bons noms:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Des noms comme Rule1, Test, Allow ou Internet sont moins utiles, car on ne sait plus plus tard quelle était la tâche de la règle.

Description

La description est importante pour l’exploitation, le support et les audits. Elle doit indiquer:

• pourquoi la règle existe
• qui a demandé la règle
• quelles restrictions ont été définies volontairement
• s’il existe un ticket, un projet ou une date d’expiration

Exemple:

Internet Access for client network 10.10.10.0/24. Web filtering and IPS enabled. Requested by IT, reviewed on 10 June 2026.

L’article Comment documenter facilement une règle Sophos Firewall explique plus en détail comment utiliser proprement ce champ et documenter les Firewall Rules de manière traçable.

Rule position

Rule position définit où la nouvelle règle est insérée.

Règle de base: spécifique avant général. Une règle pour un serveur individuel ou une application précise se place généralement au-dessus d’une règle Internet générale.

Rule group

Rule group est un regroupement organisationnel. Le groupe n’est pas une frontière de sécurité ni un moteur de policy séparé. La firewall vérifie toujours les règles individuelles de haut en bas.

Groupes utiles:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

Dans les petits environnements, None peut suffire. Dans les environnements plus grands, un regroupement clair vaut la peine dès le début, car la base de règles devient vite difficile à lire.

Action

Action détermine ce qui arrive au trafic correspondant.

Pour les règles clients ou serveurs normales, on utilise généralement Accept. Pour les règles de blocage, Drop est plus discret, tandis que Reject est souvent plus confortable pour le troubleshooting.

Log firewall traffic

Log firewall traffic devrait presque toujours être activé sur les règles importantes.

Sans logging, des informations importantes manquent ensuite dans Log viewer. De nombreux cas de troubleshooting échouent non pas à cause de la règle elle-même, mais parce que le logging n’était pas activé et qu’on ne voit pas quelle règle a réellement correspondu.

Important: la firewall journalise généralement les sessions lorsqu’une connexion se termine et qu’un événement Destroy est créé. Toutes les connexions n’apparaissent donc pas exactement au moment où le client les démarre.

Pour que les logs soient visibles localement, dans Sophos Central ou via syslog, System services > Log settings doit aussi être configuré correctement. Pour une conservation plus longue, Sophos Central Firewall Reporting ou un serveur syslog est utile. Plus d’informations: Activer Central Firewall Reporting.

Source

La section Source définit d’où vient le trafic.

Source zones

Source zones est la zone d’origine du trafic.

Exemples:

• LAN pour les réseaux clients internes
• VPN pour les utilisateurs Remote Access
• DMZ pour les réseaux serveurs
• Guest pour le Wi-Fi invités
• WAN pour le trafic entrant depuis Internet

Exemple pratique: pour une règle Internet des clients vers Internet, on choisit LAN. Pour une règle DNAT de l’extérieur vers un serveur interne, la règle Firewall associée utilise généralement WAN comme Source zone.

Source networks and devices

Source networks and devices limite plus précisément la source.

Objets possibles:

• hôtes individuels
• réseaux
• IP ranges
• groupes d’hôtes
• FQDN Hosts
• objets pays

Au début, Any semble pratique, mais il est souvent trop large. Un réseau client concret, un groupe d’hôtes ou un objet réseau clairement nommé est préférable.

Exemple pratique: au lieu de Any comme source, on utilise net_LAN_Clients. Les serveurs, imprimantes, invités et équipements de management reçoivent leurs propres règles.

During scheduled time

During scheduled time définit quand la règle s’applique.

Valeurs typiques:

• All the time
• heures de bureau
• fenêtres de maintenance
• accès temporaires

Les schedules sont utiles lorsqu’un accès ne doit être autorisé qu’à certaines heures. Lors du troubleshooting, il faut toujours vérifier si l’heure de la firewall, le fuseau horaire et le schedule correspondent vraiment.

Exemple pratique: un accès de maintenance externe à un serveur est autorisé uniquement pendant une fenêtre de maintenance définie.

Destination and services

La section Destination and services définit où le trafic peut aller et quels ports ou protocoles sont autorisés.

Destination zones

Destination zones est la zone cible.

Exemples:

• WAN pour l’accès Internet
• DMZ pour les serveurs en DMZ
• LAN pour les destinations internes
• VPN pour les utilisateurs distants ou tunnels Site-to-Site

Exemple pratique: pour le trafic Internet client, on utilise WAN. Pour l’accès de clients à un serveur interne, Server ou DMZ peut être utilisé si ces zones existent.

Destination networks

Destination networks limite plus précisément la destination.

Pour les règles Internet client, Any est souvent un point de départ pratique. Pour les serveurs, réseaux de management ou accès VPN, les destinations doivent être beaucoup plus limitées.

Exemples:

• Any pour l’accès Internet général
• FQDN Host comme updates.vendor.com
• objet hôte d’un serveur interne
• objet réseau d’un site distant via VPN
• objet pays pour règles Geo-IP

Exemple pratique: un serveur de sauvegarde peut accéder uniquement aux destinations cloud backup du fournisseur, pas à Any.

Services

Services définit protocoles et ports.

Exemples:

• HTTP pour TCP 80
• HTTPS pour TCP 443
• DNS pour TCP/UDP 53
• NTP pour UDP 123
• services personnalisés comme Synology_5555

Les services doivent être aussi précis que possible. Any n’a du sens que si tous les protocoles doivent vraiment être autorisés ou si d’autres contrôles sont utilisés volontairement.

Exemple pratique: pour des clients web normaux, un groupe avec HTTP, HTTPS, DNS et NTP suffit souvent. Pour un accès serveur depuis Internet, seul le service réellement publié est autorisé.

Match known users

Avec Match known users, l’identité utilisateur fait partie du matching. La règle ne s’applique alors plus seulement aux adresses IP, mais à des utilisateurs ou groupes connus.

C’est utile lorsque:

• des Web Policies doivent s’appliquer par groupe AD
• le reporting doit être basé sur les utilisateurs
• différents groupes d’utilisateurs ont des droits Internet différents
• MFA, Captive Portal ou SSO sont déjà configurés proprement

Piège: si l’authentification ne fonctionne pas correctement, la règle peut ne pas correspondre. Le trafic tombe alors sur une règle plus générale en dessous ou est rejeté par la règle drop-all.

Pour les premiers tests, il est souvent préférable de commencer sans User Matching et d’ajouter les critères utilisateurs plus tard.

Add exclusion

Avec Add exclusion, du trafic peut être exclu d’une règle. La firewall ignore cette règle uniquement si tous les critères d’exclusion définis correspondent, puis vérifie la règle suivante.

Les exclusions peuvent contenir Source zones, Source networks and devices, Destination zones, Destination networks et Services.

Exemple pratique: une règle Internet client générale utilise Web Filtering. Un serveur de mise à jour spécifique doit toutefois passer par sa propre règle avec d’autres Security Features. Ce serveur peut alors être exclu de la règle générale.

Les exclusions sont puissantes, mais rendent les règles plus difficiles à lire. Si une règle contient beaucoup d’exceptions, une règle spécifique séparée est souvent plus compréhensible.

Create linked NAT rule

Avec Create linked NAT rule, une règle Source NAT peut être créée directement depuis la Firewall Rule. Cette Linked NAT Rule apparaît ensuite dans la table NAT.

Pour les débutants, cela semble pratique, mais en exploitation les règles NAT autonomes sont généralement plus claires. Si une règle NAT générique couvre déjà proprement le même trafic, aucune Linked NAT Rule supplémentaire ne devrait être créée.

Pour une règle client-vers-Internet normale, la règle SNAT par défaut avec MASQ suffit généralement, tant qu’elle est active et correspond à la base de règles.

Important: NAT n’autorise pas le trafic tout seul. NAT traduit des adresses ou des ports. L’autorisation du trafic reste décidée par la Firewall Rule correspondante.

Plus d’informations: Comprendre NAT sur Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

La section Web filtering configure Web Policy, malware scan et le comportement du filtrage web.

Web policy

Web policy contrôle les accès web via catégories, utilisateurs, groupes, URL groups et règles.

Exemple pratique: pour les clients, une Web Policy bloque malware, phishing, adult content et catégories risquées, mais autorise les applications business.

Si aucune Web Policy n’est définie, aucun filtrage web basé sur les catégories n’a lieu via cette option.

Apply web category-based traffic shaping

Cette option applique le Traffic Shaping selon les catégories web. Elle n’est utile que si des règles Traffic Shaping ou des Web Category Policies correspondantes sont utilisées.

Exemple pratique: les catégories streaming sont limitées, les applications business restent prioritaires.

Block QUIC protocol

QUIC utilise UDP 80 et UDP 443. De nombreux navigateurs utilisent QUIC pour les services Google et d’autres applications web modernes.

Si Web Filtering ou Malware Scan sur le trafic web est important, Block QUIC protocol doit rester activé dans beaucoup d’environnements. Les navigateurs reviennent généralement à HTTPS normal via TCP, plus facile à contrôler et inspecter.

Scan HTTP and decrypted HTTPS

Cette option analyse HTTP et HTTPS déjà déchiffré à la recherche de malware.

Important: cette option ne déchiffre pas automatiquement HTTPS. Pour inspecter réellement HTTPS, il faut des SSL/TLS inspection rules adaptées sous Rules and policies > SSL/TLS inspection rules.

Exemple pratique: si TLS Inspection est actif pour LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS peut analyser les fichiers téléchargés dans le trafic HTTPS déchiffré.

Plus d’informations: Déployer TLS Inspection sur Sophos Firewall étape par étape.

Use Zero-day protection

Use Zero-day protection envoie les téléchargements suspects à Sophos Zero-Day Protection pour une analyse approfondie. C’est utile pour les règles clients et serveurs où les téléchargements depuis Internet doivent être contrôlés.

La fonction nécessite une licence adaptée et peut entraîner des délais selon le type de fichier et la policy.

Scan FTP for malware

Cette option analyse le trafic FTP à la recherche de malware. Elle n’est pertinente que si FTP est réellement utilisé et si les services correspondants sont autorisés dans la règle.

FTP est moins fréquent dans les environnements modernes, mais on le trouve encore avec des systèmes legacy, des machines industrielles ou d’anciens mécanismes de mise à jour.

Use web proxy instead of DPI engine

Sophos Firewall peut inspecter le trafic web via le DPI engine ou via le Web Proxy.

Pour les configurations modernes, DPI est généralement le meilleur choix par défaut, car le trafic HTTP et SSL/TLS peut être traité sur tous les ports. Le Web Proxy reste utile si des fonctions proxy spécifiques sont nécessaires, par exemple SafeSearch enforcement, restrictions YouTube, restriction Google app domain, Pharming Protection, Web Cache ou Parent Proxy.

Si Use web proxy instead of DPI engine n’est pas activé, la règle fonctionne en mode DPI.

Decrypt HTTPS during web proxy filtering

Cette option appartient au mode Web Proxy. Elle n’est pertinente que si Use web proxy instead of DPI engine est activé et si HTTPS doit être déchiffré en mode proxy.

En mode DPI, le déchiffrement HTTPS n’est pas contrôlé ici, mais via SSL/TLS inspection rules.

Synchronized Security Heartbeat

Avec Configure Synchronized Security Heartbeat, le statut Sophos Endpoint peut être intégré à la Firewall Rule.

Possibilités typiques:

• définir un statut minimal pour les appareils source
• bloquer les clients sans Heartbeat
• définir un statut minimal pour les appareils destination
• bloquer les requêtes vers des destinations sans Heartbeat

C’est puissant, mais seulement utile si Sophos Endpoint, Sophos Central et Security Heartbeat sont configurés proprement.

Exemple pratique: les clients avec Security Heartbeat rouge n’ont plus accès aux serveurs ou à Internet.

Pour une première règle client, Heartbeat ne doit pas être activé aveuglément, sinon des appareils incapables d’envoyer un Heartbeat peuvent être bloqués.

Other security features

Identify and control applications (App control)

Avec Identify and control applications (App control), on sélectionne une Application Filter Policy.

Cela permet de détecter et contrôler des applications comme:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control nécessite une licence adaptée. En pratique, cette fonction est incluse dans les Sophos Firewall Bundles avec Web Protection, par exemple Standard Protection, Xstream Protection ou Epic Protection.

Pour la détection d’applications dans le trafic chiffré, TLS Inspection est souvent déterminant. Sans déchiffrement, la firewall voit selon le service seulement les hostnames, SNI, informations de certificat ou IPs, mais pas le contenu complet.

Apply application-based traffic shaping policy

Cette option applique le Traffic Shaping défini dans l’Application Policy ou dans l’Application Object.

Exemple pratique: Microsoft Teams doit être détecté et priorisé avec une Traffic Shaping Policy précise. La bonne Application Control Policy doit être sélectionnée et l’application-based traffic shaping policy doit être appliquée.

Si une Traffic Shaping Policy explicite est déjà définie dans Shape traffic, il faut documenter clairement quelle policy doit avoir la priorité et pourquoi.

Detect and prevent exploits (IPS)

Sous Detect and prevent exploits (IPS), on sélectionne une IPS Policy.

IPS vérifie le trafic à la recherche de schémas d’attaque et d’exploits connus. Le trafic client vers Internet utilise une autre policy que le trafic serveur ou les services publiés.

Exemples pratiques:

• règle client LAN_to_WAN: IPS policy client ou LAN-to-WAN
• règle DNAT vers serveur web: IPS policy serveur ou webserver
• règle VoIP: tester prudemment, car des profils IPS agressifs peuvent perturber la VoIP

IPS ne doit pas être activé partout avec la policy la plus stricte. Une policy trop large ou incorrecte peut casser du trafic légitime ou générer une charge inutile.

Shape traffic

Avec Shape traffic, une Traffic Shaping Policy peut être appliquée directement à la règle.

C’est pertinent pour:

• VoIP
• visioconférences
• trafic de sauvegarde
• Wi-Fi invités
• liens WAN lents

Exemple pratique: le Wi-Fi invités reçoit une limit policy afin de ne pas évincer le trafic business.

Plus d’informations: Configurer Application Traffic Shaping sur Sophos Firewall.

DSCP marking

DSCP marking marque les paquets pour Quality of Service sur les équipements réseau en aval.

C’est seulement utile si les switches, routeurs ou équipements WAN évaluent aussi ces valeurs DSCP. Sophos Firewall peut marquer les paquets, mais le reste du réseau doit traiter ces marquages de manière cohérente.

Exemple pratique: le trafic VoIP reçoit un marquage DSCP afin que switches et routeurs WAN le traitent en priorité.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence utilise Sophos NDR Threat Intelligence pour une évaluation supplémentaire du trafic réseau.

Cette option n’est utile que si l’environnement utilise les composants Sophos Central et NDR nécessaires. Dans de nombreux environnements, ce n’est pas la première option pour une règle de base, mais elle peut être un complément précieux dans des réseaux fortement surveillés.

Scan email content

La section Scan email content concerne les protocoles e-mail.

Options possibles:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Si des protocoles sont activés ici, les ports standard correspondants doivent aussi être présents dans les Services de la règle ou ajoutés via Add ports.

Pour les règles web clients normales, cette section n’est souvent pas pertinente. Pour les serveurs mail ou le trafic mail client, elle doit être planifiée consciemment.

Exemple pratique: un serveur mail interne peut envoyer SMTP vers l’extérieur. Une règle serveur séparée est créée, le logging est activé et l’analyse e-mail est vérifiée selon l’architecture mail.

Contrôler après l’enregistrement

Après l’enregistrement, il faut tester la règle au lieu de supposer que tout fonctionne correctement.

À vérifier:

1. La règle est-elle à la bonne position?
2. Log firewall traffic est-il actif?
3. La règle correspond-elle dans Log viewer?
4. La Firewall Rule ID attendue est-elle affichée?
5. La règle NAT attendue s’applique-t-elle?
6. DNS fonctionne-t-il?
7. Web Filtering, IPS, Application Control et TLS Inspection sont-ils appliqués comme prévu?
8. Y a-t-il des drops ou erreurs SSL/TLS inattendus?

Pour un contrôle propre: Tester une Firewall Rule avec Log Viewer, Policy Test et Packet Capture.

Erreurs fréquentes

La règle est trop basse: une règle plus générale au-dessus correspond d’abord au trafic.

Source est trop large: Any fonctionne parfois, mais rend les règles floues et augmente la surface d’attaque.

Destination est trop large: les serveurs ou réseaux de management devraient rarement accéder à Internet avec Any.

Services sont trop larges: Any autorise nettement plus que nécessaire. Des services ou groupes de services concrets sont préférables.

Logging n’est pas activé: les informations les plus importantes manquent alors dans Log Viewer.

HTTPS n’est pas scanné: Scan HTTP and decrypted HTTPS est actif, mais il n’existe pas de SSL/TLS inspection rule adaptée ou pas de déchiffrement.

Web Filtering ne s’applique pas: aucune Web Policy n’est définie, mauvais utilisateur, mauvaise Source zone ou QUIC n’est pas bloqué.

User Matching ne s’applique pas: authentification, AD SSO, Captive Portal ou attribution utilisateur ne fonctionnent pas correctement.

NAT manque: la Firewall Rule autorise le trafic, mais SNAT/MASQ ne correspond pas.

Security Feature ne correspond pas au trafic: une mauvaise IPS Policy, option proxy ou option de scan e-mail peut casser du trafic légitime.