Utilisez la règle de contournement du pare-feu Sophos en toute sécurité

Une règle de bypass sur Sophos Firewall n’est pas un objet Allow normal et ne remplace pas une règle de firewall propre. Le trafic défini contourne ainsi le chemin Stateful Firewall normal. De nombreuses fonctions sur lesquelles l’exploitation s’appuie volontairement sont alors également contournées: règles de firewall, Log Viewer, IPS, Webfilter, Application Control, Malware-Scanning ou autres Security Features.

Les règles de contournement ne sont donc utiles que pour des cas particuliers étroitement définis, par exemple pour un dépannage à court terme accompagné de conseils, pour une exception de compatibilité très spécifique ou pour une solution de contournement clairement documentée. Pour les versions normales, les problèmes de performances ou les faux positifs, vous devez d’abord vérifier les règles, exceptions ou politiques spécifiques.

⚠️ Une règle de contournement réduit massivement la visibilité et l’effet protecteur du pare-feu. Les règles de contournement doivent toujours être étroitement définies, documentées, testées et supprimées une fois terminées.

Les situations typiques du monde réel sont des cas particuliers avec un routage asymétrique, un comportement de protocole inhabituel ou une analyse à court terme du fournisseur. Une fois la cause claire, la solution doit revenir aux règles normales de pare-feu, aux exceptions NAT, de routage, IPS, Web ou TLS.

De quel type de contournement s’agit-il

Le terme « contourner » apparaît plusieurs fois dans les environnements Sophos. Cet article concerne exclusivement bypass-stateful-firewall-config dans la console du périphérique.

• Contournement du pare-feu avec état: Configuration CLI qui achemine le trafic hôte ou réseau défini au-delà du chemin normal du pare-feu avec état.
• Règle de contournement DoS: Exception sous Protection contre l’usurpation d’identité et paramètres DoS pour les contrôles DoS, différent du contournement du pare-feu avec état.
• IPS Bypass session: Action de règle IPS qui traite un hit IPS différemment pour la session.
• FastPath / Firewall acceleration: accélération normale des flux de confiance sur les appliances ou plateformes prises en charge. Ce n’est pas un contournement manuel du pare-feu stateful et ne doit pas être compris comme un workaround pour des problèmes de règles.
• Contournement LAN/fail-to-wire: Fonction matérielle d’appareils ou de modules spécifiques, pas une règle SFOS.
• Exception normale du pare-feu: Personnalisation du pare-feu, NAT, web, TLS, IPS ou contrôle des applications dans WebAdmin.

Cette séparation est importante car les mesures comportent des risques différents. Une exception DoS ou une action IPS n’est pas automatiquement inoffensive, mais elle est plus étroitement liée à une fonction. En revanche, un contournement de pare-feu avec état peut contourner très largement la visibilité et l’évaluation des politiques si la source ou la cible est choisie trop grande.

Vérifiez les meilleures alternatives au préalable

Avant de définir une règle de contournement, il convient de comprendre pourquoi les mécanismes normaux ne suffisent pas.

• La règle du pare-feu ne correspond pas: Vérifier l’ordre des règles, la source/destination, les services et les journaux.
• IPS bloque une application: Vérifier la politique IPS, la signature, l’exception ou l’analyse des faux positifs.
• L’inspection TLS perturbe une application: Ajuster la règle d’inspection SSL/TLS ou l’exclusion TLS.
• Le filtre Web bloque une URL: Vérifiez la politique Web, la catégorie, le groupe d’URL ou l’exception Web.
• Le contrôle des applications ne fonctionne pas correctement: Vérifiez la politique de contrôle des applications et l’application détectée.
• Le NAT ou le routage ne fonctionnent pas correctement: Vérifiez les règles NAT, la route de retour, le SD-WAN et la capture de paquets.

Pour l’analyse des règles et des journaux, consultez l’aide Tester la règle du pare-feu Sophos avec la visionneuse de journaux et la capture de paquets, La règle du pare-feu ne fonctionne pas : vérifier les causes et Comprendre et configurer correctement les règles du pare-feu Sophos.

Limites de fonctionnement

Une règle de contournement ne doit être définie que si tous les points sont respectés :

• La source et la destination sont des réseaux ou des hôtes spécifiques, et non Any.
• La direction et la direction de retour sont comprises.
• Il y a un ticket, un motif et une personne responsable.
• Une fenêtre de maintenance ou fenêtre de test est définie.
• La configuration existante a été préalablement documentée.
• Une commande rollback est disponible.
• Après le test, on vérifie si la règle a de nouveau été supprimée.

Une règle de contournement ne convient pas pour une « activation rapide » permanente entre réseaux. Si une connexion doit être autorisée en permanence, elle appartient à une règle de pare-feu normale avec journalisation et fonctionnalités de sécurité appropriées.

Il faut être particulièrement prudent avec les chemins NAT. Si SNAT, DNAT, VPN-NAT ou une autre traduction est nécessaire pour le flux, un Stateful-Firewall-Bypass peut contourner la décision NAT réelle ou fausser le test. Dans ces cas, il faut d’abord vérifier avec NAT Rule ID, Firewall Rule ID, Packet Capture et le routage, au lieu de contourner globalement le chemin stateful.

Connexion à la console du périphérique

Les commandes sont exécutées dans la Device Console de Sophos Firewall. Pour ce faire, connectez-vous à l’utilisateur admin via SSH et ouvrez la console de l’appareil dans le menu de la console.

L’accès SSH ne doit être autorisé qu’à partir d’un réseau administrateur de confiance. La préparation se trouve dans Connecter Sophos Firewall via SSH.

Avant d’apporter des modifications, vous devez d’abord afficher et documenter l’état actuel.

show advanced-firewall

Sélectionnez correctement l’hôte ou le réseau

Sophos autorise le contournement des entrées pour des hôtes ou des réseaux individuels. Pour le dépannage, un seul hôte est presque toujours préférable à un sous-réseau entier, car cela signifie que moins de trafic est invisible.

• Hôte source unique vers hôte de destination: dest_host <IP-cible> source_host <IP-source>.
• Réseau source vers hôte de destination: dest_host <IP-cible> source_network <IP-reseau> source_netmask <masque>.
• Hôte source vers réseau cible: dest_network <IP-reseau> dest_netmask <masque> source_host <IP-source>.
• Réseau source vers réseau cible: dest_network <IP-reseau> dest_netmask <masque> source_network <IP-reseau> source_netmask <masque>.

Les réseaux étendus tels que les zones client, serveur ou VPN complètes ne constituent presque jamais un bon point de départ. Il est préférable de faire un test serré avec un hôte source, un hôte de destination et un service clair. Ce n’est que si le scénario de test affecte réellement plusieurs hôtes qu’il faut parler d’un petit réseau.

La direction est également importante. Sophos explique que des entrées dans les deux sens sont souvent nécessaires pour des connexions complètes. Mais cela doit être fait consciemment : ne pas recréer automatiquement la logique Any, mais plutôt comprendre le chemin de retour spécifique.

Sophos n’indique pas de limite pratique pour le nombre d’hôtes ou de réseaux dans cette liste de bypass. C’est précisément ce qui est risqué en exploitation : de nombreux petits enregistrements sont certes techniquement possibles, mais deviennent vite difficiles à suivre. Si plusieurs entrées de bypass semblent nécessaires, c’est généralement le signe que le problème réel de routage, NAT, policy ou application n’est pas encore bien compris.

Définir le changement de cadre avant le contournement

Une règle de contournement ne doit jamais être définie spontanément pendant le dépannage. Avant d’exécuter la commande add, il doit être clair à quel test individuel elle est censée répondre et comment la modification sera annulée.

Pour garantir une fenêtre de maintenance ou de test propre, notez ces points :

• Question d’examen: Le trafic défini fonctionne-t-il sans chemin de pare-feu avec état ?
• Flux concerné: 192.168.33.0/24 à 192.168.46.0/24.
• État de départ: Sortie de show advanced-firewall avant changement.
• Itinéraire de retour prévu: commande del appropriée pour chaque direction définie.
• Critère de résiliation: trafic inattendu, nouvelle perturbation ou zone cible incorrecte.
• Inspection de suivi: show advanced-firewall, capture de paquets et test fonctionnel sans bypass.

L’ordre de retrait est particulièrement important. Il doit être préparé avant la prise et non recherché après le test. Cela signifie que le changement reste contrôlable même si une pression apparaît pendant la fenêtre de maintenance.

Exemple : Créer une règle de contournement

Exemple:

• Réseau source: 192.168.33.0/24.
• Réseau cible: 192.168.46.0/24.
• Masque de réseau source: 255.255.255.0.
• Masque de réseau cible: 255.255.255.0.

La règle pour la première direction :

set advanced-firewall bypass-stateful-firewall-config add dest_network 192.168.46.0 dest_netmask 255.255.255.0 source_network 192.168.33.0 source_netmask 255.255.255.0

Une deuxième règle est requise pour le sens inverse si le trafic du réseau de destination vers le réseau source doit également utiliser le contournement.

set advanced-firewall bypass-stateful-firewall-config add dest_network 192.168.33.0 dest_netmask 255.255.255.0 source_network 192.168.46.0 source_netmask 255.255.255.0

Vérifiez ensuite à nouveau :

show advanced-firewall

Si un seul client et un seul serveur sont testés, il est préférable d’utiliser des hôtes plutôt que des réseaux :

set advanced-firewall bypass-stateful-firewall-config add dest_host 192.168.46.20 source_host 192.168.33.10

Pour le sens inverse en conséquence :

set advanced-firewall bypass-stateful-firewall-config add dest_host 192.168.33.10 source_host 192.168.46.20

Vérifier l’effet

Après le paramétrage, vous ne devez pas seulement tester si l’application fonctionne. Ce qui est crucial, c’est de savoir si le contournement n’affecte réellement que le trafic prévu.

Points de contrôle :

1. show advanced-firewall affiche exactement les réseaux attendus.
2. Il n’y a pas de filets plus larges que prévu.
3. La direction et le retour sont consciemment définis.
4. Le trafic de test ne fonctionne qu’entre les sources et les destinations attendues.
5. Les réseaux non impliqués n’utilisent pas le contournement.
6. Les journaux de pare-feu normaux pour ce trafic ne sont plus attendus comme base de prise de décision.
7. Packet Capture affiche uniquement le trafic pendant le test planifié.
8. Le retrait a été effectué immédiatement après le test.

Si la visionneuse de journaux et le compteur de règles n’affichent plus soudainement les événements, cela peut être dû au contournement lui-même. Dans cette condition, Packet Capture est plus utile que Log Viewer.

Avec le routage asymétrique, vous devez également vérifier si le chemin de retour passe réellement par le pare-feu attendu. Un contournement peut masquer les symptômes si la cause première est une passerelle par défaut incorrecte, une route incomplète ou un NAT du mauvais côté.

En cas de suspicion de performance ou d’offloading, il ne faut pas confondre bypass et FastPath. FastPath, Firewall acceleration, PKI acceleration et IPsec acceleration sont des mécanismes distincts. Selon le trafic et la plateforme, le trafic normal peut être accéléré sans définir de règle de bypass. À l’inverse, une règle de bypass ne transforme pas une mauvaise conception en architecture de performance propre.

Supprimer la règle de contournement

Pour supprimer, utilisez la même commande avec del au lieu de add.

Supprimer la première direction :

set advanced-firewall bypass-stateful-firewall-config del dest_network 192.168.46.0 dest_netmask 255.255.255.0 source_network 192.168.33.0 source_netmask 255.255.255.0

Supprimer le sens inverse :

set advanced-firewall bypass-stateful-firewall-config del dest_network 192.168.33.0 dest_netmask 255.255.255.0 source_network 192.168.46.0 source_netmask 255.255.255.0

Vérifiez ensuite à nouveau :

show advanced-firewall

La sortie ne doit plus contenir d’entrées de contournement inattendues.

Sécurisez à nouveau proprement après le test

Une règle de contournement supprimée ne résout pas automatiquement le problème d’origine. Le test montre uniquement que le chemin normal du pare-feu pour le trafic testé était probablement impliqué. Vous devez alors consciemment transférer la cause dans une configuration prise en charge et visible.

Questions de suivi utiles :

• Une règle de pare-feu normale était-elle trop étroite ou mal placée ?: Vérifiez l’ordre des règles, les zones, la source, la destination, le service et l’affectation des utilisateurs.
• L’IPS, la protection Web ou le contrôle des applications sont-ils bloqués ?: Signature du document, catégorie, politique ou exception ciblée.
• L’inspection TLS a-t-elle été impliquée ?: Vérifiez proprement la règle TLS, le certificat, l’exception et l’application concernée.
• Était-ce un problème de routage ou de NAT ?: Comparez l’ID de règle NAT, la route de retour, la route SD-WAN et la capture de paquets.
• Le trafic sera-t-il nécessaire de manière permanente à l’avenir ?: Créer une règle de pare-feu normale avec journalisation, propriétaire et date de révision.

Après retrait, au moins un test de contrôle sans bypass doit être effectué. Si le trafic ne fonctionne à nouveau qu’avec le contournement, l’affaire n’est pas encore close. Ensuite, vous avez besoin d’une règle, d’une politique, d’un NAT ou d’un ajustement d’inspection propres qui restent visibles dans la visionneuse de journaux et peuvent être vérifiés ultérieurement.

Pour les modifications permanentes, vous devez également documenter quelles fonctionnalités de sécurité sont délibérément laissées actives et quelle exception est réellement nécessaire. Une règle de contournement temporaire ne doit pas s’intégrer silencieusement à l’architecture opérationnelle.

Documentation

Chaque règle de contournement doit être documentée :

• Date et heure
• Administrateur
• raison
• Réseau source et réseau de destination
• application concernée
• durée prévue
• Preuves de tests
• Heure de retrait
• Tâche de suivi au cas où une règle ou une exception propre devrait être créée

Sans documentation, les règles de contournement peuvent facilement passer inaperçues. Ceci est particulièrement dangereux car un examen normal des règles de pare-feu ou des visionneuses de journaux ne suffit pas pour identifier l’écart de protection.

Liste de contrôle

Avant le contournement :

• Règle de pare-feu normale, NAT, routage, IPS, Web, inspection TLS et contrôle des applications vérifiés.
• Question de test spécifique définie.
• Origine, destination, direction et retour documentés.
• Variante la plus étroite possible sélectionnée, préférant l’hôte au lieu du réseau.
• État actuel enregistré avec show advanced-firewall.
• Commande del préparée pour chaque direction prévue.
• Ticket, propriétaire, créneau horaire et délai de démontage déterminés.

Pendant l’épreuve :

• Bypass actif uniquement pour la période prévue.
• Testez le trafic documenté avec la source, la destination, le service et l’heure.
• Capture de paquets ou journal du système cible utilisé comme preuve.
• Aucun réseau ou application supplémentaire affecté involontairement.

Après l’essai :

• Suppression de toutes les entrées de contournement avec del.
• show advanced-firewall n’affiche pas de règles de contournement inattendues.
• Test répété sans contournement ni problème ultérieur documenté.
• Solution permanente planifiée comme ajustement de règle normale, de politique, de NAT, de routage ou d’inspection.
• Billet et documentation opérationnelle mis à jour.

Erreurs typiques

• Filets utilisés trop larges: Un trafic supérieur à celui prévu contourne le pare-feu.
• J’ai oublié le sens inverse: L’application ne fonctionne que partiellement ou asymétriquement.
• Règle non supprimée: Un écart de protection permanent apparaît.
• Pas de ticket ni de commentaire: Plus tard, on ne sait pas pourquoi le contournement existe.
• Visionneuse de journaux attendue comme preuve: Le trafic ne ressemble pas à des décisions normales de pare-feu.
• Contournement utilisé à la place d’une exception ciblée: Les fonctions de sécurité sont désactivées inutilement.
• Changement sans fenêtre de maintenance: Les erreurs ont un effet productif immédiat.

Questions fréquemment posées