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

Les règles de pare-feu sont au cœur du Sophos Firewall. Ces règles 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 règle Sophos Firewall de haut en bas : Ordre, Groupes, Action, Journalisation, Source, Destination, Services, Correspondance utilisateur, Exclusions, NAT, Filtrage Web, TLS Inspection, Security Heartbeat, Application Control, IPS, Mise en forme du trafic, DSCP, NDR et Analyse des e-mails.

Le chemin du menu est :

Rules and policies > Règles de pare-feu > Ajouter une règle de pare-feu > Nouvelle règle de pare-feu

Le masque de règles est divisé en plusieurs zones : zone d’en-tête, source, destination, Services, référence utilisateur, lien NAT et fonctionnalités de sécurité. En pratique, il est important de ne pas voir le masque comme un ensemble de crochets individuels. Une règle ne fonctionne correctement que si la source, la destination, le service, la séquence, la journalisation et les fonctions de protection activées correspondent.

Avant de la créer, il convient également de préciser s’il s’agit d’une règle IPv4 ou IPv6. La vue des règles est sélectionnée en conséquence dans le WebAdmin. Dans les environnements à double pile, IPv4 et IPv6 doivent être intentionnellement planifiés et testés séparément ; une règle IPv4 fonctionnelle ne prouve pas automatiquement que IPv6 est également sécurisé.

Navigation rapide

• Quelles sont les règles de pare-feu qui contrôlent et ce qu’elles ne contrôlent pas
• Principe de base et séquence
• Base de règles du plan avant création
• Types de règles clairement séparés
• Exemple pratique fictif
• Zone d’en-tête : Statut, Nom, Action et Journalisation
• Source, Zone et Horaire
• Destination et services
• Match known users
• Ajouter une exclusion
• Create linked NAT rule
• Filtrage Web
• Battement cardiaque Synchronized Security
• Autres fonctionnalités de sécurité
• Analyser le contenu des e-mails
• Vérifier après l’enregistrement
• Fonctionnement et examen réguliers
• Nouvelle règle, modifier ou désactiver une règle existante ?
• Erreurs typiques
• FAQ

Quel article sur la politique de réseau correspond ?

Les règles de pare-feu, NAT, WAF, VLAN et le routage sont étroitement liés dans le Sophos Firewall. Il est donc important que les administrateurs choisissent d’abord le bon sujet :

• Comprendre la règle de pare-feu à partir de zéro: Cet article.
• Classer NAT, SNAT, DNAT, MASQ ou PAT: Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT
• Publier le serveur interne via la redirection de port: Serveur de publication via DNAT vers Sophos Firewall
• Sécuriser une application web publique: Sophos Firewall Configuration et organisation de WAF
• La règle ne s’applique pas ou un Rule ID incorrect apparaît: La règle Sophos Firewall ne s’applique pas : vérifiez les causes
• Tester la règle spécifiquement: Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture
• WebAdmin, VPN Portal, User Portal, SSH, DNS sécurisé ou SNMP du pare-feu: Sophos Firewall Sécuriser l’accès : configurer correctement le Device Access
• Planifier des zones, des interfaces ou des VLAN: Sophos Firewall Configurer les zones et les interfaces
• Faire fonctionner le pont avec les balises VLAN: Utiliser le pont Sophos Firewall avec le balisage VLAN
• Vérifiez l’ordre de routage ou les chemins SD-WAN: Sophos Firewall Ajuster la priorité de routage
• Les paquets de réponse ou le trafic système empruntent un mauvais chemin: Routage SD-WAN pour les paquets de réponse et le trafic système

Cette séparation empêche le dépannage typique. Une règle NAT n’autorise pas le trafic, une règle de pare-feu ne traduit pas une adresse et une règle WAF n’est pas la même chose qu’une redirection de port DNAT classique.

Quelles règles de pare-feu contrôlent et ce qu’elles ne contrôlent pas

Les règles de pare-feu contrôlent le trafic qui traverse le pare-feu. Mais ces règles ne constituent pas le seul point de contrôle du SFOS. De nombreux dépannages se produisent parce que vous recherchez un comportement dans la liste des règles de pare-feu, même si une autre zone en est responsable.

• Trafic entre zones, réseaux, utilisateurs et services: Règles de pare-feu. C’est ici qu’il est décidé si le trafic de transit est autorisé, rejeté ou contrôlé à l’aide de fonctions de sécurité.
• WebAdmin, User Portal, VPN Portal, SSH, DNS ou SNMP au pare-feu lui-même: Device Access et Local Service ACL. Les services de pare-feu locaux ne sont pas traités comme le trafic normal LAN vers WAN ou WAN vers DMZ.
• Traduction adresse ou port: Règles NAT. NAT traduit le trafic mais ne l’autorise pas automatiquement.
• Sélection d’itinéraire, itinéraire de retour, itinéraires SD-WAN et VPN: Routage, configuration SD-WAN, Route Precedence et VPN. Une règle de pare-feu appropriée ne constitue pas un moyen efficace de revenir en arrière.
• Catégories Web, groupes d’URL et politique Web: Filtrage Web et politique Web. La règle de pare-feu intègre la politique, mais la véritable logique Web réside dans la politique Web.
• Décryptage HTTPS: Règles d’inspection SSL/TLS et distribution des CA. Scan HTTP and decrypted HTTPS analyse uniquement le trafic déjà déchiffré.
• Identité de l’utilisateur: Authentification, STAS, portail captif, Entra ID SSO ou RADIUS. Une règle utilisateur ne correspond que si le pare-feu peut affecter l’utilisateur au trafic.

Pour les services de gestion et de portail, Device Access et Local Service ACL est l’article central. Si une règle correspond mais que la connexion échoue toujours, La règle Sophos Firewall ne fonctionne pas : vérifier les causes et Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture vous aideront. En particulier dans les réseaux mixtes IPv4/IPv6, vous devez également vérifier si une application via IPv6 contourne une règle IPv4 plus stricte. Si IPv6 n’est pas activement utilisé, la stratégie IPv6 doit néanmoins être consciemment documentée : désactiver, bloquer, réglementer correctement ou introduire de manière contrôlée.

Principe de base et séquence

Les règles de pare-feu contrôlent le trafic entre les zones et les réseaux. Les règles autorisent, rejettent ou bloquent le trafic et peuvent appliquer des fonctionnalités de sécurité supplémentaires.

Sophos Firewall vérifie les règles de pare-feu de haut en bas. Dès qu’une règle correspond, les règles de pare-feu suivantes ne sont plus vérifiées. Ce qui est important n’est pas seulement ce qui se trouve dans une règle, mais aussi sa place dans la liste des règles.

Une règle n’est valable que si tous les critères pertinents s’appliquent en même temps :

• Zone source: Oui. LAN.
• Source networks and devices: Oui. net_LAN_Clients.
• Calendrier: Oui. All the time.
• Zone de destination: Oui. WAN.
• Destination networks: Oui. Any ou un hôte FQDN.
• Services: Oui. HTTP, HTTPS, DNS.
• Correspondance d’utilisateur: Uniquement si activé. Groupe AD Internet-Users.
• Exclusions: Si elle est définie, la règle peut être ignorée. Exclure le serveur de sauvegarde.

La première règle correspondante gagne. Si une règle générale LAN_to_WAN_Any est supérieure à une règle spécifique LAN_to_WAN_Restricted, la règle spécifique ne sera jamais atteinte.

Planifier la base de règles avant de créer

Une seule règle de pare-feu peut être créée rapidement. Ce qui est plus difficile, c’est d’avoir une base de règles qui soit encore compréhensible, testable et sécurisée après deux ans. Par conséquent, avant d’introduire de nouvelles règles, vous devez d’abord clarifier à quelle zone de sécurité, groupe et logique de fonctionnement la règle appartient.

Questions d’orientation utiles :

• Quel type de trafic faut-il réellement autoriser ?: Notez la source, la destination et Services avant de créer.
• Le trafic appartient-il à sa propre zone ?: Séparez consciemment les serveurs, les clients, les invités, la gestion, VPN et DMZ.
• Existe-t-il déjà une règle spécifique ?: Vérifiez les règles existantes au lieu de créer une deuxième règle similaire.
• Le NAT est-il impliqué ?: Planifiez les règles de pare-feu et les règles NAT ensemble, mais ne les mélangez pas.
• Comment sera-t-il vérifié plus tard ?: Activez la journalisation et définissez un trafic de test spécifique.
• La libération est-elle temporaire ?: Documentez la date d’expiration ou le billet dans la description.

Pour les zones et interfaces propres, Sophos Firewall Configurer les zones et les interfaces convient en premier. Si une règle existante ne fonctionne pas, la liste de contrôle La règle Sophos Firewall ne fonctionne pas : vérifier les causes vous aidera.

⚠️ Une règle Any large est souvent pratique, mais constitue rarement une bonne configuration finale. Cela peut aider à court terme pour les tests. Il doit ensuite être remplacé ou supprimé à nouveau par des sources, des destinations et des services spécifiques.

## Types de règles clairement séparés

Une bonne base de règles sépare visiblement les différents risques les uns des autres. L’erreur la plus courante n’est pas une seule option incorrecte, mais une règle générale qui couvre à la fois les clients, les serveurs, les invités et la gestion. Cela fonctionne rapidement au début, mais devient ensuite difficile à tester et à durcir.

• Client Internet: Source typique: Réseaux clients; Cible typique: WAN; A quoi faut-il faire attention ?: Politique Web, Application Control, IPS, TLS Inspection, QUIC, journalisation.
• Serveur Internet: Source typique: Réseaux de serveurs; Cible typique: cibles définies de mise à jour, de sauvegarde ou de cloud; A quoi faut-il faire attention ?: plus strictes que les règles client, souvent sans référence utilisateur.
• Invité-WLAN: Source typique: Zone invités; Cible typique: WAN; A quoi faut-il faire attention ?: aucun contrôle conscient des cibles internes, de la bande passante et du DNS.
• Gestion: Source typique: Réseaux d’administration; Cible typique: Pare-feu, serveurs, commutateurs, hyperviseurs; A quoi faut-il faire attention ?: ne pas mélanger avec les règles normales du client.
• VPN Accès à distance: Source typique: VPN ou propre zone d’accès à distance; Cible typique: zones cibles internes; A quoi faut-il faire attention ?: uniquement les cibles et services requis, connexion dans la phase d’introduction.
• Site à site: Source typique: zones VPN locales et distantes ou zones XFRM; Cible typique: Réseaux de partenaires ou de localisation; A quoi faut-il faire attention ?: Vérifiez le routage, le NAT, le chemin de retour et la connexion ensemble.
• Système publié: Source typique: WAN ou sources définies; Cible typique: DMZ ou zone serveur; A quoi faut-il faire attention ?: DNAT/WAF, IPS, journalisation, niveau de correctif et limitation de source.
• Accès temporaire: Source typique: support défini ou source de projet; Cible typique: cible étroite; A quoi faut-il faire attention ?: Document ticket, date d’expiration, propriétaire et démontage.

Si deux connexions ont des propriétaires, des fonctions de protection ou des cycles de révision différents, des règles distinctes sont généralement plus claires. Si seule une prestation supplémentaire est requise pour le même objectif professionnel, une règle existante peut être étendue.

Exemple pratique fictif

À titre d’exemple, une règle client propre est créée :

Cible : Les clients du LAN interne sont autorisés à accéder à Internet. Le filtre Web, Application Control, IPS et la journalisation doivent être actifs. Les serveurs, les invités et les réseaux de gestion ont leurs propres règles et ne sont pas mélangés à cette règle client.

• Nom de la règle: LAN_to_WAN_Clients. Effacer le nom avec la source et la destination.
• Descriptif: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Plus tard, vous saurez pourquoi la règle existe.
• Rule position: Sous des règles de blocage et de serveur spécifiques. Des règles spécifiques devraient d’abord entrer en vigueur.
• Rule group: Internet Access. Meilleur aperçu.
• Actions: Accept. La circulation est autorisée.
• Journaliser le trafic du pare-feu: Activé. Dépannage du Log Viewer.
• Source zones: LAN. Le trafic provient de la zone LAN.
• Source networks and devices: net_LAN_Clients. Pas tous les réseaux LAN, juste des clients.
• Pendant l’heure prévue: All the time. L’accès à Internet doit être permanent.
• Destination zones: WAN. La cible est Internet.
• Destination networks: Any. Surtout pratique pour les clients internet.
• Services: HTTP, HTTPS, DNS, NTP. Uniquement les services de base requis.
• Web policy: Default Workplace Policy. Contrôler l’accès au Web en fonction des catégories.
• Block QUIC protocol: Activé. Le filtrage et l’analyse Web restent efficaces.
• IPS: Politique client. Protection contre les exploits pour le trafic client sortant.
• Contrôle des applications: Politique de candidature client. Bloquer les applications indésirables.
• Façonner le trafic: Facultatif. Uniquement si la bande passante est requise.
• DSCP marking: Vide. Uniquement nécessaire si les appareils en aval évaluent DSCP.

Cet exemple n’est délibérément pas un ticket gratuit Any. En pratique, les réseaux clients, les réseaux serveurs, les réseaux invités, la VoIP et la gestion doivent être considérés séparément. Pour le premier test productif, cet exemple doit inclure un court scénario de test : client défini, adresse cible spécifique, Rule ID attendu, NAT Rule ID attendu et un aperçu de Log Viewer ou Central/Syslog. Sans cette étape d’approbation, il reste difficile de savoir si la règle traite réellement la connexion attendue.

Zone d’en-tête : Statut, Nom, Action et Journalisation

État de la règle

Statut de la règle active ou désactive la règle.

Une nouvelle règle est généralement active. Pour les règles préparées, vous pouvez désactiver le statut et n’activer la règle que plus tard. Les règles désactivées doivent être vérifiées régulièrement afin qu’aucune ancienne règle de test ou de migration ne reste dans la configuration.

Exemple pratique : Une nouvelle règle pour un serveur est préparée mais n’est activée que dans la fenêtre de maintenance.

Nom de la règle

Le nom doit immédiatement indiquer clairement 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

Les noms tels que Rule1, Test, Allow ou Internet sont moins utiles car vous ne pouvez plus déterminer la tâche de la règle.

Description

La description est importante pour les opérations, le support et les audits. Il faudrait dire :

• pourquoi la règle existe
• qui a demandé la règle
• quelles restrictions ont été délibérément fixées
• s’il y a un ticket, un projet ou une date d’expiration

Exemple :

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

La manière d’utiliser correctement ce champ et de documenter les règles de pare-feu de manière compréhensible est décrite plus en détail dans l’article Sophos Firewall documentant raisonnablement les règles.

Rule position

Rule position spécifie où la nouvelle règle sera insérée.

• Top: Uniquement pour des règles très spécifiques, des règles de bloc ou des tests.
• Bottom: Souvent utile pour les nouvelles règles standard.
• Above rule: Si une règle doit spécifiquement prendre effet avant une règle existante.
• Below rule: Si une règle doit spécifiquement suivre une règle existante.

Règle de base : le spécifique avant le général. Une règle pour un serveur individuel ou une application spécifique est généralement plus élevée qu’une règle Internet générale.

Rule group

Rule group est un regroupement organisationnel. Le groupe lui-même ne constitue pas une frontière de sécurité ni son propre moteur de politique. Le pare-feu continue de vérifier chaque règle de haut en bas.

Voici des exemples de groupes utiles :

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

Dans les petits environnements, le None peut suffire. Dans les environnements plus vastes, un regroupement clair est utile dès le début, sinon la base de règles devient rapidement confuse.

Action

Action détermine ce qui arrive au trafic correspondant.

• Accept: La circulation est autorisée. Règles d’autorisation normales.
• Drop: Le trafic est supprimé en silence. Bloquer les règles pour lesquelles le client ne doit pas recevoir de réponse.
• Reject: Le trafic est rejeté et le client reçoit une réponse. Dépannage ou règles de blocage internes.
• Protect with web server protection: La protection WAF est appliquée. Protection du serveur Web, pas pour les règles normales LAN-à-WAN.

Pour les règles client ou serveur normales, vous utilisez généralement Accept. Pour les règles de blocage, Drop est plus silencieux, Reject est souvent plus agréable pour le dépannage.

Consigner le trafic du pare-feu

Le trafic du pare-feu de journalisation doit presque toujours être activé pour les règles importantes.

Sans journalisation, des informations importantes seront manquantes ultérieurement dans la Visionneuse de journaux. De nombreux cas de dépannage échouent non pas à cause de la règle elle-même, mais parce qu’il n’y a pas eu de journalisation et qu’il n’est pas possible de voir quelle règle est réellement appliquée.

Important : Le pare-feu enregistre généralement les sessions de pare-feu lorsqu’une connexion est interrompue et qu’un événement Destroy se produit. Toutes les connexions n’apparaissent pas au moment exact où le client les démarre.

Pour que les journaux soient visibles localement, dans Sophos Central ou via Syslog, System services > Log settings doit également être configuré de manière appropriée. Pour un stockage plus long, le rapport de pare-feu Sophos Central ou un serveur Syslog sont judicieux. Pour en savoir plus : Activer le reporting central du pare-feu et Envoyer Sophos Firewall Syslog en toute sécurité à SIEM.

Pour les règles productives, la journalisation ne doit pas être considérée uniquement comme un outil de dépannage. C’est également la base des examens : la règle est-elle toujours utilisée, à quelles sources s’appliquent-elles, quels objectifs sont réellement visés et si une règle est trop large.

Source, zone et horaire

Dans la zone Source, vous définissez la provenance du trafic.

Source zones

Source zones est la zone d’où provient le trafic.

Exemples :

• LAN pour les réseaux clients internes
• VPN pour les utilisateurs d’accès à distance
• DMZ pour les réseaux de serveurs
• Guest pour les invités-WLAN
• WAN pour le trafic Internet entrant

Exemple pratique : LAN est sélectionné pour une règle Internet depuis les clients vers Internet. Pour une règle DNAT externe vers un serveur interne, WAN est généralement utilisé comme zone source dans la règle de pare-feu associée.

Source networks and devices

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

Les objets possibles sont par exemple :

• hôtes individuels
• Réseaux
• Plages IP
• Groupes d’accueil
• Hôtes FQDN
• Objets de pays

Pour commencer, le Any semble confortable, mais est souvent trop large. Un réseau client spécifique, un groupe d’hôtes ou un objet réseau clairement nommé est préférable.

Exemple pratique : Au lieu de Any dans la source, utilisez net_LAN_Clients. Les serveurs, imprimantes, invités et appareils de gestion ont leurs propres règles.

Pendant l’heure programmée

Pendant l’heure programmée détermine le moment où la règle s’applique.

Valeurs typiques :

• All the time
• Horaires de travail
• Fenêtre de maintenance
• libérations temporaires

Les horaires sont utiles si l’accès ne doit être autorisé qu’à certaines heures. Lors du dépannage, vous devez toujours vérifier si l’heure, le fuseau horaire et la programmation du pare-feu sont vraiment corrects.

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

Destinations et services

Dans la zone Destination et services, vous définissez où le trafic est autorisé 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 dans un DMZ
• LAN pour les cibles internes
• VPN pour les utilisateurs distants ou les itinéraires site à site

Exemple pratique : WAN est utilisé pour le trafic Internet client. Server ou DMZ peuvent être utilisés pour que les clients accèdent à un serveur interne si ces zones sont créées en conséquence.

Destination networks

Destination networks affine la cible plus précisément. Pour les règles Internet client, Any est souvent un début viable. Pour les serveurs, les réseaux de gestion ou les accès VPN, les cibles devraient être beaucoup plus limitées.

Exemples :

• Any pour un accès Internet général
• Hôte FQDN comme updates.vendor.com
• Objet hôte d’un serveur interne
• Objet réseau d’une station distante via VPN
• Objet Pays pour les règles Geo-IP

Exemple pratique : un serveur de sauvegarde ne peut accéder qu’aux destinations de sauvegarde cloud du fabricant, et non à Any.

Services

Services sont des définitions de protocole et de port.

Exemples :

• HTTP pour TCP80
• HTTPS pour TCP 443
• DNS pour TCP/UDP 53
• NTP pour UDP 123
• posséder Services comme Synology_5555

Services doit être choisi aussi étroitement que possible. Any n’a de sens que si tous les protocoles doivent être réellement autorisés ou si vous travaillez consciemment avec d’autres commandes.

Exemple pratique : pour les clients Web normaux, un groupe avec HTTP, HTTPS, DNS et NTP est souvent suffisant. Seul le service effectivement publié est autorisé pour l’accès au serveur depuis Internet.

Match known users

Avec Match known users, l’identité de l’utilisateur fait partie de la correspondance. La règle ne s’applique alors plus uniquement aux adresses IP, mais aux utilisateurs ou groupes connus.

Cela a du sens si :

• Les politiques Web doivent s’appliquer par groupe AD
• Les rapports doivent être liés à l’utilisateur
• différents groupes d’utilisateurs obtiennent des droits Internet différents
• MFA, Captive Portal ou SSO sont déjà correctement configurés

Pierre d’achoppement : si l’authentification ne fonctionne pas correctement, la règle peut ne pas correspondre. Ensuite, le trafic passe à une règle plus générale ci-dessous ou est supprimé par la règle de suppression totale.

Pour les tests initiaux, il est souvent préférable de commencer sans correspondance d’utilisateur et d’ajouter des critères utilisateur ultérieurement.

Si la correspondance d’utilisateurs est utilisée, il ne devrait pas y avoir de règle de repli générale autorisant le même trafic sans référence à l’utilisateur. Sinon, la règle utilisateur semble propre, mais les utilisateurs inconnus se retrouvent toujours avec la règle générale. Une fois accepté, le Log Viewer doit donc afficher l’utilisateur, le groupe et le Rule ID.

Ajouter une exclusion

Avec Ajouter une exclusion, le trafic peut être exclu d’une règle. Le pare-feu 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 inclure Source zones, Source networks and devices, Destination zones, Destination networks et Services.

Exemple pratique : Une règle Internet client générale utilise des filtres Web. Cependant, un serveur de mise à jour spécifique doit exécuter sa propre règle avec d’autres fonctionnalités de sécurité. Vous pouvez alors exclure ce serveur de la règle générale.

Les exclusions sont puissantes, mais elles rendent les règles plus difficiles à lire. Si une règle contient de nombreuses exceptions, une règle spécifique distincte est souvent plus compréhensible.

Create linked NAT rule

Avec Create linked NAT rule, une règle NAT source peut être créée directement à partir de la règle de pare-feu. Cette règle NAT liée apparaît ensuite dans le tableau des règles NAT.

Cela semble pratique pour les débutants, mais dans la pratique, les règles NAT indépendantes sont généralement plus claires. Si une règle NAT générique couvre déjà le même trafic, vous ne devez pas créer de règle NAT liée supplémentaire.

Pour une règle client vers Internet normale, la règle SNAT par défaut avec MASQ est généralement suffisante, à condition qu’elle soit active et qu’elle corresponde correctement à la base de règles. Important : NAT n’autorise pas le trafic par lui-même. NAT traduit les adresses ou les ports. La règle de pare-feu appropriée décide toujours si le trafic est autorisé.

En savoir plus : Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

Filtrage Web

Dans la zone Filtrage Web, la politique Web, l’analyse des logiciels malveillants et le comportement du filtre Web sont configurés.

Web policy

Web policy contrôle l’accès au Web via des catégories, des utilisateurs, des groupes, des groupes d’URL et des règles.

Exemple pratique : une politique Web est utilisée pour les clients qui bloquent les logiciels malveillants, le phishing, le contenu réservé aux adultes et les catégories à risque, mais autorisent les applications professionnelles.

Si aucune politique Web n’est définie, le filtrage Web basé sur les catégories n’aura pas lieu via cette option.

La façon de planifier ensemble des catégories, des groupes d’URL, des stratégies Web et des alertes instantanées est décrite dans Sophos Firewall Utilisation de catégories Web et d’alertes instantanées.

Appliquer une gestion du trafic basée sur les catégories Web

Cette option applique une gestion du trafic basée sur les catégories Web. Cela n’a de sens que si des règles de gestion du trafic ou des politiques de catégories Web appropriées sont utilisées.

Exemple pratique : Les catégories de streaming sont limitées, les applications métiers restent privilégiées.

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 le filtrage Web ou l’analyse des logiciels malveillants pour le trafic Web sont importants, Block QUIC protocol doit rester activé dans de nombreux environnements. Les navigateurs reviennent alors généralement au HTTPS normal sur TCP, qui est plus facile à contrôler et à vérifier.

Pour en savoir plus : Sophos Firewall Bloquer correctement QUIC et HTTP/3.

Scan HTTP and decrypted HTTPS

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

Important : Cette option ne déchiffre pas automatiquement HTTPS. Pour que HTTPS soit réellement vérifié, des règles d’inspection SSL/TLS appropriées sont requises sous Rules and policies > Règles d’inspection SSL/TLS.

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

Pour en savoir plus : Déployer progressivement TLS Inspection vers Sophos Firewall.

Utiliser la protection Zero Day

Utiliser la protection Zero-day envoie les téléchargements suspects à Sophos Zero-Day Protection pour une analyse plus approfondie. Ceci est utile pour les règles client et serveur qui souhaitent vérifier les téléchargements depuis Internet.

La fonction nécessite une licence appropriée et peut entraîner des retards en fonction du type de fichier et de la politique.

Analyser FTP à la recherche de logiciels malveillants

Cette option analyse le trafic FTP à la recherche de logiciels malveillants. Cela n’est pertinent que si FTP est réellement utilisé et que le Services correspondant est généralement autorisé.

FTP est devenu moins courant dans les environnements modernes, mais il est toujours présent dans les systèmes existants, les commandes de machines ou les anciens mécanismes de mise à jour.

Utilisez un proxy Web au lieu de DPI engine

Sophos Firewall peut vérifier le trafic Web via DPI engine ou via Web Proxy.

Pour les configurations modernes, DPI est généralement le meilleur choix par défaut car il peut gérer le trafic HTTP et SSL/TLS sur tous les ports. Le proxy Web reste utile si des fonctions de proxy spéciales sont requises, par exemple l’application de SafeSearch, les restrictions YouTube, les restrictions de domaine d’application Google, la protection contre le pharming, le cache Web ou le proxy parent.

Si Utiliser un proxy Web au lieu de DPI engine n’est pas activé, la règle fonctionne en mode DPI.

Décrypter HTTPS pendant le filtrage du proxy Web

Cette option appartient au mode proxy Web. Cela n’est pertinent que si Utiliser un proxy Web au lieu de DPI engine est activé et que HTTPS doit être déchiffré en mode proxy.

En mode DPI, le décryptage HTTPS n’est pas contrôlé ici, mais plutôt via des règles d’inspection SSL/TLS.

Synchronized Security Battement de coeur

Avec Configurer Synchronized Security Heartbeat, l’état du Sophos Endpoint peut être inclus dans la règle de pare-feu.

Options typiques :

• Définir l’état minimum pour les appareils sources
• Bloquer les clients sans battement de coeur
• Définir l’état minimum pour les appareils cibles
• Bloquer les demandes vers des destinations sans un battement de coeur

C’est fort, mais n’a de sens que si Sophos Endpoint, Sophos Central et Security Heartbeat sont correctement configurés.

Exemple pratique : les clients avec un Security Heartbeat rouge ne sont plus autorisés à accéder aux serveurs ou n’ont plus accès à Internet.

Pour une première règle client, vous ne devez pas activer aveuglément le battement de cœur, sinon vous risquez de bloquer les appareils qui ne peuvent pas du tout envoyer de battement de cœur.

Autres fonctionnalités de sécurité

Identifier et contrôler les applications (Contrôle des applications)

Une politique de filtrage des applications est sélectionnée via Identifier et contrôler les applications (Contrôle des applications).

Cela permet de reconnaître et de contrôler les applications, par exemple :

• Visionneuse d’équipe
• Porte
• Messagers
• Diffusion
• Stockage en nuage
• Outils de contrôle à distance

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

TLS Inspection est souvent crucial pour la détection d’applications dans le trafic chiffré. Sans décryptage, selon le service, le pare-feu ne voit que les noms d’hôtes, les SNI, les informations de certificat ou les IP et non le contenu complet.

Le processus personnalisé pour les filtres, la liaison de règles, les journaux et la vérification des faux positifs est disponible dans Sophos Firewall Configuration et test de Application Control.

Apply application-based traffic shaping policy

Cette option applique la mise en forme du trafic définie dans la stratégie d’application ou l’objet d’application.

Exemple pratique : Microsoft Teams doit être reconnu et priorisé avec une politique spécifique de gestion du trafic. Ensuite, la stratégie Application Control appropriée doit être sélectionnée et la stratégie de mise en forme du trafic basée sur l’application doit être appliquée.

Si vous avez déjà défini une politique explicite de gestion du trafic dans le champ Former le trafic, il convient d’indiquer clairement quelle politique doit être prioritaire et pourquoi.

Détecter et prévenir les exploits (IPS)

Une stratégie IPS est sélectionnée sous Détecter et prévenir les exploits (IPS).

IPS vérifie le trafic à la recherche de modèles d’attaques et d’exploits connus. Une stratégie différente est utilisée pour le trafic client vers Internet et pour le trafic serveur ou les services publiés.

Exemples pratiques :

• Règle client LAN_to_WAN : politique IPS client ou LAN vers WAN
• Règle DNAT vers le serveur web : politique IPS du serveur ou du serveur web
• Règle VoIP : testez attentivement car les profils IPS agressifs peuvent perturber la VoIP

IPS ne devrait pas être activé partout avec la politique la plus dure. Une politique IPS trop large ou incorrecte peut interrompre le trafic légitime ou créer une charge inutile.

L’article dédié Sophos Firewall Configurer IPS et tester en toute sécurité explique plus en détail l’activation globale, l’état de la licence, la sélection de la politique, la journalisation et l’analyse des faux positifs.

Façonner le trafic

Avec Shape traffic, une stratégie de gestion du trafic peut être appliquée directement à la règle. Ceci est pertinent pour :

• VoIP
• Réunions en ligne
• Trafic de sauvegarde
• Invité WLAN
• itinéraires lents WAN

Exemple pratique : l’invité WLAN bénéficie d’une stratégie de limite afin de ne pas évincer le trafic professionnel.

Pour en savoir plus : Configurer la mise en forme du trafic d’application sur Sophos Firewall.

DSCP marking

DSCP marking marque les paquets pour la qualité de service sur les périphériques réseau en aval.

Cela n’a de sens que si les commutateurs, routeurs ou appareils WAN évaluent également ces valeurs DSCP. Le Sophos Firewall peut marquer, mais le reste du réseau doit traiter ces marques de manière cohérente.

Exemple pratique : le trafic VoIP reçoit un marquage DSCP afin que les commutateurs et routeurs WAN traitent préférentiellement ce trafic.

Analysez avec NDR Intelligence active sur les menaces

Analysez avec NDR Active Threat Intelligence utilise Sophos NDR Threat Intelligence pour évaluer en outre le trafic réseau.

Cette option n’est utile que si l’environnement utilise les composants Sophos Central et NDR requis. Dans de nombreux environnements, il ne s’agit pas de la première option pour une règle de base, mais elle peut constituer un complément précieux dans des réseaux plus hautement surveillés.

Analyser le contenu des e-mails

La zone Analyser le contenu des e-mails concerne les protocoles de messagerie.

Options possibles :

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

Si vous activez des protocoles ici, les ports standard appropriés doivent également être inclus dans le Services de la règle ou ajoutés via Ajouter des ports.

Cette zone n’est souvent pas pertinente pour les règles normales du client Web. Vous devez le planifier consciemment pour les serveurs de messagerie ou le trafic de messagerie des clients.

Exemple pratique : Un serveur de messagerie interne est autorisé à envoyer du SMTP en externe. Une règle de serveur distincte est ensuite créée, la journalisation est activée et l’analyse des e-mails est vérifiée pour correspondre à l’architecture de messagerie.

Vérifiez après avoir enregistré

Après avoir enregistré, vous devez tester la règle et ne pas simplement supposer que tout fonctionne correctement.

Pour vérifier :

1. La règle est-elle dans la bonne position ?
2. Le trafic du pare-feu de journalisation est-il actif ?
3. Lorsque les règles ont changé, le compteur d’accès a-t-il été réinitialisé ou un nouveau test clair a-t-il été créé ?
4. La règle correspond-elle dans la Visionneuse de journaux ?
5. Le pare-feu attendu Rule ID apparaît-il ?
6. La règle NAT souhaitée s’applique-t-elle ?
7. Le DNS fonctionne-t-il ?
8. Les filtres Web IPS, Application Control et TLS Inspection sont-ils appliqués comme prévu ?
9. Y a-t-il des baisses inattendues ou des erreurs SSL/TLS ?

L’article Test de la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture permet une vérification propre.

Lorsque vous apportez des changements productifs, une petite comparaison avant et après est logique :

• Un point de sauvegarde ou de restauration existe: Le démantèlement reste possible si la règle produit des effets secondaires.
• Piste d’audit ou ticket de modification noté: plus tard, on saura clairement qui a effectué le changement et quand.
• Cas de test défini au préalable: Le succès ne se juge pas seulement au ressenti.
• Un seul changement par test: La cause et l’effet restent compréhensibles.
• Log Viewer ou journaux centraux vérifiés: les vrais Rule ID et NAT ID sont visibles.
• Décision de démantèlement documentée: les règles de test temporaires ne restent pas actives en permanence.

Si vous disposez de plusieurs pare-feu ou de groupes gérés de manière centralisée, vous devez également vérifier si la modification a atteint le bon appareil ou le bon groupe. Pour Sophos Central, la File d’attente des tâches de gestion du pare-feu est utile ; les modifications locales peuvent être suivies avec Journaux de piste d’audit.

Fonctionnement et examen réguliers

Une règle de pare-feu n’est pas prête simplement parce qu’elle a été enregistrée. Les bonnes règles ont un objectif clair, sont enregistrées, sont testables et peuvent être vérifiées à nouveau ultérieurement. Surtout dans les environnements matures, de nombreux risques proviennent non pas d’une seule règle incorrecte, mais d’anciennes exceptions, de règles trop larges ou de règles sans propriétaire.

Une routine simple vaut la peine pour des examens réguliers :

• La règle sera-t-elle toujours faite ?: Les règles inutilisées peuvent souvent être désactivées et supprimées ultérieurement.
• La source est-elle toujours correcte ?: Les réseaux clients, les réseaux serveurs et les zones VPN évoluent au fil du temps.
• Le Any est-il toujours justifié ?: Les sources, objectifs ou Services généraux doivent être délibérément documentés.
• La journalisation est-elle active et utile ?: Sans journaux, les analyses et audits ultérieurs sont nettement plus faibles.
• NAT, filtre Web, IPS et TLS Inspection conviennent-ils toujours ?: Les fonctionnalités de sécurité peuvent fonctionner différemment après des mises à niveau, des modifications d’application ou de certificat.
• Y a-t-il une date d’expiration ?: Dans le cas contraire, les règles temporaires de projet ou de support restent actives en permanence.

Pour les règles critiques, vous devez également indiquer qui est techniquement responsable. Ceci est particulièrement important pour les services publiés, les règles VPN, l’accès à la gestion, les partages du fournisseur de services et les règles avec Any à Services ou à destination.

Nouvelle règle, modifier ou désactiver une règle existante ?

Toutes les nouvelles requêtes ne nécessitent pas immédiatement une nouvelle règle de pare-feu. Trop de règles similaires rendent la liste confuse, mais les règles trop résumées deviennent rapidement trop larges. Une décision simple est utile avant d’enregistrer quelque chose dans le WebAdmin :

• Même source, même destination, même objectif, un seul service supplémentaire: Étendre la règle existante. La règle reste techniquement cohérente et plus simple à tester.
• Mêmes réseaux, mais exigences de protection différentes, journalisation différente ou propriétaire différent: Créez votre propre règle. Les filtres Web, IPS, TLS Inspection, NDR ou la journalisation peuvent être vérifiés séparément.
• Fournisseur de services temporaire ou accès au support: Créez votre propre règle temporaire. Le propriétaire, le ticket, la date d’expiration et la fenêtre de test restent clairement visibles.
• Les serveurs, les invités, la VoIP, l’IoT ou la gestion sont concernés: Vérifiez votre propre règle ou zone. Différents risques ne doivent pas disparaître dans une seule règle Internet client.
• Une règle n’est pas claire ou est ancienne: Désactivez d’abord et observez. La suppression directe supprime la possibilité de vérifier les accès, les journaux et les dépendances de manière contrôlée.
• Une règle est certainement superflue après un examen: Supprimer après sauvegarde et documentation. L’ensemble des règles devient plus petit sans rompre aveuglément les dépendances qui fonctionnent.

Pour les changements opérationnels normaux, ce processus est robuste :1. Notez le but, le propriétaire, le ticket et le trafic attendu. 2. Vérifiez les règles existantes pour la même source, destination, service et Rule group. 3. Décidez si une règle existante est étendue ou si votre propre règle est plus propre. 4. Pour des changements productifs, planifiez la sauvegarde, la piste d’audit et le scénario de test. 5. Après avoir enregistré Log Viewer, Rule ID, vérifiez la décision NAT et les fonctionnalités de sécurité concernées.

Si la décision échoue principalement en raison d’un manque de documentation, les règles Sophos Firewall doivent être documentées de manière significative doivent être suivies en premier. S’il n’est pas clair si une règle existante est toujours nécessaire, un test contrôlé avec Test de la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est utile.

Organisez correctement les compteurs d’accès

Les compteurs d’accès aident au nettoyage, mais ne constituent pas une preuve complète. Une règle d’urgence rarement utilisée peut néanmoins s’avérer importante. À l’inverse, une règle générale peut avoir de nombreuses conséquences même si elle en autorise trop.

Pour les évaluations, vous devez toujours combiner les compteurs d’accès avec Log Viewer, la description de la règle et le cas d’utilisation réel. Si une règle n’est pas claire, elle ne doit pas être supprimée immédiatement. Un processus contrôlé est préférable : clarifiez l’objectif, activez la journalisation, définissez les fenêtres de test, informez les parties prenantes et ensuite seulement désactivez-le ou supprimez-le.

Rendre les modifications traçables

Une sauvegarde doit être disponible avant les changements majeurs de règles. Audit Trail et Config Studio aident ensuite à vérifier les différences de manière compréhensible. Le processus pratique se trouve dans Sophos Firewall Vérifier les journaux de piste d’audit et Sophos Firewall Utiliser Config Studio.

Si de nombreuses règles sont ajustées, vous devez non seulement comparer la configuration, mais également exécuter de véritables cas de test. Une règle peut être syntaxiquement correcte tout en autorisant un trafic incorrect, en utilisant un mauvais chemin NAT ou en perturbant une application via IPS, un filtrage Web ou TLS Inspection.

Erreurs typiques

La règle est trop avancée : Une règle plus générale ci-dessus correspond en premier au trafic.

La source est trop large : Any fonctionne, mais rend les règles peu claires et augmente la surface d’attaque.

La destination est trop large : Les serveurs ou les réseaux de gestion doivent rarement être autorisés à accéder à Internet avec Any.

Les Services sont trop larges : Le Any permet beaucoup plus que nécessaire. Des groupes Services ou services spécifiques sont préférables.

La journalisation n’est pas active : Les informations les plus importantes sont alors manquantes dans le Log Viewer.

IPv6 a été oublié : IPv4 est correctement réglementé, mais IPv6 fonctionne selon d’autres règles ou reste ouvert inconsciemment.

Rule group est certainement confus : Un groupe de règles ne fait qu’améliorer la vue d’ensemble. Un groupe de règles ne constitue pas sa propre limite de sécurité et ne modifie pas la logique d’évaluation.

HTTPS n’est pas analysé : Scan HTTP and decrypted HTTPS est actif, mais il n’existe aucune règle d’inspection SSL/TLS ou de déchiffrement approprié.

Le filtre Web ne fonctionne pas : Aucune stratégie Web définie, mauvais utilisateur, mauvaise zone source ou QUIC non bloqué.

La correspondance des utilisateurs ne fonctionne pas : L’authentification, le SSO AD, le portail captif ou le mappage des utilisateurs ne fonctionnent pas correctement.

NAT manquant : La règle de pare-feu autorise le trafic, mais SNAT/MASQ ne convient pas.

La fonctionnalité de sécurité ne correspond pas au trafic : Une politique IPS, une option de proxy ou une option d’analyse des e-mails incorrectes peuvent interrompre le trafic légitime. Si, après ces points, vous ne comprenez toujours pas pourquoi le trafic s’exécute différemment que prévu, vous devez effectuer des tests structurés supplémentaires avec Log Viewer, Policy Tester et Packet Capture. La procédure appropriée se trouve dans Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

FAQ