Interpréter correctement les données de performance du Sophos Firewall

Les données de performance d’un Sophos Firewall sont importantes pour le dimensionnement, mais elles sont souvent mal interprétées. Le débit maximal du pare-feu indiqué dans la fiche technique n’est pas automatiquement la performance qu’un site atteindra avec IPS, Web Protection, Inspection TLS, VPN, NAT, Reporting et de nombreux utilisateurs simultanés.

Pour choisir un modèle, il ne faut donc pas se concentrer uniquement sur un chiffre en Gbit/s. Ce qui est crucial, c’est de savoir quelles fonctions de protection sont activées, quel trafic traverse le pare-feu et quelles réserves l’environnement nécessite au quotidien. Le Guide de dimensionnement du Sophos Firewall explique le choix du modèle ; cet article explique comment évaluer les métriques de performance sous-jacentes.

Règle rapide pour le dimensionnement

Dans la pratique, le débit pur du pare-feu n’est généralement pas le meilleur point de départ.

• Seulement routage et règles de pare-feu simples : Considérez le débit du pare-feu et IMIX.
• Réseau d’entreprise normal avec IPS et Application Control : Accordez plus de poids aux valeurs NGFW ou de Protection contre les menaces.
• Beaucoup de connexions HTTPS avec déchiffrement : Prévoyez la performance de l’Inspection TLS et la réserve CPU.
• Beaucoup de connexions VPN : Considérez séparément les exigences IPsec ou d’accès à distance.
• Pare-feu virtuel : Prenez au sérieux l’hyperviseur, le CPU, la RAM, le stockage et les cartes réseau virtuelles autant que la licence Sophos.

Si vous n’êtes pas sûr de savoir si le matériel ou l’appliance virtuelle convient mieux, Sophos Firewall - Matériel ou appliance virtuelle ? peut vous aider à décider.

Pourquoi les valeurs des fiches techniques ne suffisent pas

Les valeurs de performance sont déterminées dans des conditions de laboratoire définies. Cela est utile car cela rend les modèles comparables. Cependant, un environnement productif se comporte différemment :

• Les tailles de paquets sont mélangées.
• Les utilisateurs génèrent des sessions parallèles.
• Les profils de sécurité examinent le trafic à des niveaux de profondeur différents.
• Le trafic HTTPS nécessite beaucoup plus de ressources avec l’Inspection TLS.
• VPN, SD-WAN, NAT, journalisation et reporting fonctionnent en parallèle.
• WLAN, commutateurs, clients, serveurs et fournisseurs influencent la performance perçue.

Une valeur de fiche technique est donc une valeur de comparaison, pas une promesse pour chaque flux individuel. Pour un dimensionnement solide, il faut planifier avec des réserves et ne pas considérer les fonctions opérationnelles futures seulement après l’achat.

Lire les conditions de test avant de comparer les chiffres

Les notes des fiches techniques Sophos font partie intégrante de chaque métrique. Sophos mesure les valeurs maximales avec Keysight-Ixia BreakingPoint dans des conditions idéales. Firewall Throughput utilise du trafic HTTP avec des réponses de 512 Ko, tandis que Firewall IMIX mélange des paquets UDP de 66, 570 et 1518 octets. IPS Throughput repose sur du trafic HTTP, le jeu de règles IPS par défaut et des objets de 512 Ko. TLS Inspection est mesuré avec IPS activé, des sessions HTTPS et différentes suites de chiffrement. Threat Protection combine le pare-feu, IPS, Application Control et Malware Prevention avec l’Enterprise Traffic Mix. Le débit NGFW est mesuré avec IPS et Application Control activés, du trafic HTTP et des objets de 512 Ko. Le VPN IPsec utilise du trafic HTTP sur plusieurs tunnels avec des réponses de 512 Ko.

Ces conditions permettent de comparer les modèles sur une même base. Il ne faut toutefois ni additionner les chiffres ni les considérer comme un engagement pour son propre profil de trafic. Les petits paquets, les sessions courtes, d’autres suites de chiffrement et les services supplémentaires peuvent modifier le résultat.

Les métriques les plus importantes

• Débit du pare-feu : Sert à comparer un traitement simple de couche 3/couche 4. L’erreur classique consiste à y voir le débit Internet réel avec toutes les fonctions de sécurité activées.
• Firewall IMIX : Utilise un mélange plus réaliste de tailles de paquets. Cette valeur est souvent négligée alors qu’un réseau de production ne transporte pas uniquement de gros paquets.
• Débit IPS : Décrit le trafic avec prévention des intrusions. Il devient déterminant quand IPS inspecte une grande partie du trafic.
• Débit NGFW : Décrit les performances avec des fonctions supplémentaires telles qu’IPS et Application Control. Il ne faut pas le confondre avec le débit pur du pare-feu.
• Threat Protection : Se rapproche davantage d’un environnement où plusieurs protections sont actives. Il s’agit toujours d’une valeur comparative, pas d’un minimum garanti.
• TLS Inspection : Concerne le déchiffrement et l’inspection HTTPS. Cette charge, potentiellement élevée, est souvent oubliée lors du dimensionnement.
• VPN IPsec : Concerne les flux chiffrés entre sites. Le pair distant, les tailles de paquets, les paramètres cryptographiques et le CPU comptent autant que la connexion Internet.
• Concurrent Connections : Indique combien de connexions le pare-feu peut suivre simultanément. C’est une limite de capacité, pas une mesure de débit.
• New Connections per second : Indique combien de nouvelles connexions le pare-feu peut traiter par seconde. De nombreuses connexions web, API ou DNS très courtes peuvent solliciter cette limite alors que la bande passante reste faible.

Débit du pare-feu et IMIX

Le débit pur du pare-feu décrit un traitement relativement simple du trafic. Cette valeur est utile lorsqu’un pare-feu effectue principalement du routage, du NAT et traite des règles de pare-feu classiques.

IMIX est plus proche de la charge réseau réelle car il mélange différentes tailles de paquets. C’est important car les petits paquets sollicitent un pare-feu différemment des gros téléchargements. Dans les réseaux d’entreprise, il y a rarement un seul flux de données propre et important. Les accès Web, DNS, VoIP, applications cloud, mises à jour et transferts de fichiers génèrent des modèles différents.

Pour les sites avec un trafic utilisateur normal, IMIX est donc souvent plus significatif que la plus belle valeur maximale.

IPS, NGFW et Protection contre les menaces

Dès que l’IPS, Application Control, Web Protection ou l’analyse des malwares sont activés, le pare-feu doit faire plus que simplement transférer des paquets. Le pare-feu doit classifier le trafic, reconnaître les modèles, appliquer des règles et vérifier les contenus selon la politique.

Les termes sont souvent confondus :

• IPS évalue le trafic en fonction de signatures et de règles pour des modèles d’attaque connus.
• NGFW décrit la performance du pare-feu avec des fonctions supplémentaires comme IPS et Application Control.
• Protection contre les menaces est une valeur approximative plus forte pour les environnements où plusieurs fonctions de protection sont activées simultanément.

Pour une entreprise qui utilise réellement le Sophos Firewall comme passerelle de sécurité, les valeurs NGFW et de Protection contre les menaces sont généralement plus pertinentes que le débit pur du pare-feu.

Planifier l’Inspection TLS de manière réaliste

L’Inspection TLS est l’un des plus grands facteurs de performance. Le pare-feu déchiffre les connexions HTTPS, vérifie le contenu et chiffre à nouveau la connexion. Cela génère une charge CPU et peut être sensiblement perceptible selon la suite de chiffrement, le serveur cible, le client, les exceptions et la politique.

L’Inspection TLS ne doit donc pas être activée à la légère. Un déploiement progressif avec un groupe pilote, des exceptions, une surveillance et une recherche d’erreurs claire est judicieux. L’article Introduire correctement l’Inspection TLS du Sophos Firewall décrit le processus opérationnel.

Le certificat CA doit également être distribué proprement. Pour les clients, Installer le certificat CA du Sophos Firewall pour le scan HTTPS est le point de départ approprié.

Considérer séparément la performance VPN

La performance VPN ne dépend pas seulement du modèle de pare-feu. Sont également pertinents l’autre extrémité, la connexion Internet, la latence, les tailles de paquets, MTU/MSS, les paramètres de chiffrement, le routage et les tunnels parallèles.

Pour les connexions site-à-site, il faut estimer de manière réaliste les flux de données prévus : transferts de fichiers, sauvegardes, ERP, VoIP, RDP, surveillance et réplication se comportent différemment. Pour l’accès à distance, s’ajoutent l’appareil client, le WLAN, le fournisseur et le client VPN.

Si une connexion VPN semble lente, il ne faut pas seulement vérifier la valeur de la fiche technique. Un test de connexion défini avec iPerf est généralement plus significatif qu’un test de vitesse de navigateur.

Ce qui influence la performance réelle

En pratique, plusieurs facteurs agissent simultanément :

• Profils de sécurité actifs par règle de pare-feu
• Inspection TLS et exceptions
• Politique IPS et étendue des signatures
• Web Protection, Application Control et analyse des malwares
• NAT, DNAT, publication de serveurs et WAF
• IPsec, SSL VPN, Sophos Connect et tunnels site-à-site
• Journalisation, reporting, Central Reporting et Syslog
• De nombreuses petites sessions au lieu de quelques gros téléchargements
• Accélération du pare-feu, FastPath, Accélération IPsec et trafic qui ne peut pas être déchargé
• Fonctionnement HA, version du firmware et correctifs
• Ressources virtuelles pour les appliances logicielles ou cloud

Il est donc important de toujours vérifier la performance dans le contexte de la politique concrète. Une règle de pare-feu sans profils de sécurité se comporte différemment d’une règle avec IPS, filtre Web, Application Control et Inspection TLS.

Bien comprendre FastPath et Offloading

Les pare-feux Sophos modernes ne traitent pas tous les flux de données de la même manière. Selon l’appliance, le firmware, la règle, le profil de sécurité et le type de trafic, le trafic peut être partiellement accéléré ou vérifié dans un chemin de traitement plus lent. Les termes importants pour cela sont FastPath, accélération du pare-feu, accélération PKI et accélération IPsec.

La classification initiale a toujours lieu dans SlowPath : le noyau et, le cas échéant, le moteur DPI inspectent la connexion. Une fois le handshake TCP terminé ou après le passage d’un paquet dans chaque direction, SFOS peut placer un flux éligible dans le cache de connexions FastPath. FastPath n’est donc pas un bypass non inspecté ; il traite uniquement l’état programmé par le noyau. Les protocoles non éligibles, tels qu’IP-in-IP, restent dans SlowPath.

Il existe deux niveaux d’offloading : Si seul le traitement du noyau est déchargé, FastPath transmet les paquets directement au moteur DPI et l’inspection de contenu requise continue. Ce n’est que lorsque le moteur DPI autorise l’offloading complet du flux que le traitement ultérieur par SlowPath et le moteur DPI cesse. Le trafic FastPath peut donc encore générer une charge d’inspection et de CPU ; accéléré ne signifie pas automatiquement entièrement déchargé.

Pour le dimensionnement, c’est important, car un test rapide ne prouve pas que chaque flux de production utilise le même chemin. Sophos indique Firewall et IPsec Acceleration pour toutes les XGS Appliances. La PKI Acceleration dédiée au traitement des certificats des flux TLS inspectés n’est documentée que pour les XGS 4300, 4500, 5500, 6500, 7500 et 8500. Les modèles desktop Gen. 2 XGS 88/88w, 108/108w, 118/118w et 128/128w utilisent Virtual FastPath dans le noyau x86 au lieu d’un Xstream Flow Processor dédié.

Les limites sont plus strictes pour les appliances virtuelles et logicielles. Ces déploiements proposent uniquement Firewall Acceleration sur le même CPU x86, sans PKI ni IPsec Acceleration. Selon l’aide SFOS 22, Virtual FastPath n’est pris en charge qu’avec VMware ESXi et les pilotes NIC igc, e1000, e1000e et vmxnet3. VFP est automatiquement désactivé sur les autres hyperviseurs, dans les déploiements cloud ou avec des pilotes non pris en charge. Le pare-feu continue de fonctionner, mais sans cette amélioration FastPath. Pour e1000 et e1000e, Sophos indique une MTU maximale de 3500 octets, et pour les autres pilotes pris en charge une MTU maximale de 9000 octets. Il s’agit de limites de plateforme, pas d’une raison d’activer les jumbo frames sans test de bout en bout.

PKI Acceleration n’accélère pas l’ensemble du traitement TLS. Pour les flux TLS 1.2 et TLS 1.3 inspectés par le moteur DPI, elle décharge uniquement la resignature des certificats de serveur X.509 avec une authentification RSA jusqu’à 4096 bits. Le chiffrement symétrique, le trafic web proxy et les connexions SSL VPN qui se terminent sur le pare-feu n’en bénéficient pas.

En plus de l’authentification RSA du flux TLS négocié, la CA utilisée pour la resignature doit être éligible. Sous Rules and policies > SSL/TLS inspection rules > SSL/TLS settings, les champs Re-sign RSA with et Re-sign EC with doivent tous deux utiliser une CA RSA avec une clé d’au plus 4096 bits. Si un profil configuré sous Profiles > Decryption profiles et sélectionné dans la règle d’inspection SSL/TLS remplace ces CA globales, la même condition s’applique aux deux champs du profil. Même Re-sign EC with exige une CA RSA pour PKI Acceleration ; le nom du champ ne remplace ni la vérification de la CA ni la condition distincte d’authentification du flux. Les CA de resignature par défaut du pare-feu utilisent RSA ; une CA personnalisée doit néanmoins être vérifiée selon les exigences indiquées.

Certaines fonctions ou certains types de trafic peuvent limiter ou empêcher l’offloading, par exemple :

• SSL VPN
• WAF et trafic proxy
• QoS et DoS
• Sans fil, RED, LAG et PPPoE
• Trafic IP fragmenté
• Certains scénarios de pont, HA ou virtualisation

Pour IPsec, la pile XFRM décharge l’encapsulation, le chiffrement, la désencapsulation et le déchiffrement ESP en fonction de la SA de phase 2. Les SA utilisant 3DES, BlowFish ou MD5, les SA sur des interfaces virtuelles telles que les VLAN et le trafic IPsec sur des interfaces VLAN ou sans fil ne sont pas déchargés. Les adresses IP source et destination doivent également correspondre aux adresses attendues pour la SA ; sinon, la SA n’est pas déchargée. Le tunnel peut néanmoins fonctionner, mais il consomme alors davantage de CPU hôte.

Même avec une SA déchargée, l’étendue dépend du trafic interne : S’il est éligible à FastPath, l’encapsulation et le traitement cryptographique sont entièrement déchargés. Sinon, FastPath continue à chiffrer ou déchiffrer les paquets, tandis que SlowPath traite le trafic interne, y compris l’encapsulation et la désencapsulation ; FastPath finalise l’encapsulation après le chiffrement. Sans SA déchargée, tout le traitement a lieu dans SlowPath. Un tunnel fonctionnel ou un état global enabled ne distingue pas ces trois états.

Les politiques de sécurité n’empêchent pas systématiquement l’offloading. Une règle sans IPS, filtrage web, antivirus ni contrôle des applications peut basculer après le handshake ou les premiers paquets ; avec le contrôle des applications, Sophos indique que la décision intervient après environ huit paquets. Pour STARTTLS avec Don’t decrypt, elle intervient après environ 15 paquets. Les premiers paquets peuvent donc encore apparaître dans SlowPath alors que le flux ultérieur est accéléré.

SlowPath comprend le noyau, les modules en espace utilisateur et le module d’offloading des flux de confiance. FastPath fournit une architecture logicielle commune ; le Xstream Flow Processor est la Network Processing Unit (NPU) dédiée des modèles XGS éligibles. Les améliorations d’offloading sont intégrées aux versions SFOS.

Les décisions sont réparties : le moteur d’inspection SSL/TLS décide de l’offloading PKI, et la pile XFRM de celui d’IPsec. À partir de la couche 4, le moteur DPI traite l’inspection SSL/TLS, IPS, le contrôle des applications, le filtrage web et l’antivirus, y compris Zero-day Protection et File Reputation. Les paquets passent par la Data Acquisition Layer (DAQ) pour les contrôles de sécurité ; les décisions d’offloading interviennent à chaque étape d’inspection. Les politiques IPS contenant des signatures d’offloading intelligent de SophosLabs peuvent libérer les flux éligibles. Bypass session dans une règle IPS peut aussi permettre un offloading complet, mais ce n’est pas une recommandation générale d’optimisation. Le filtrage web sans analyse des malwares et du contenu ni paramètres du moteur DPI, ainsi que l’absence de règles d’inspection SSL/TLS ou Don’t decrypt, peuvent permettre un offloading complet. Avec une analyse ou Decrypt, FastPath continue en revanche de transmettre directement au moteur DPI. Sous Rules and policies > Firewall rules > Web filtering, l’utilisation du web proxy au lieu du moteur DPI empêche ce chemin d’offloading DPI décrit ici.

L’accélération IPsec s’applique aux VPN IPsec basés sur des politiques et sur des routes. Sophos recommande AES-GCM 128 pour les performances. Les champs de phase 2 Encryption et Authentication sous Profiles > IPsec profiles sont concernés. Cela ne signifie pas qu’il faut modifier un profil cryptographique fonctionnel uniquement pour obtenir un meilleur chiffre : le pair distant, les exigences de sécurité et la fenêtre de maintenance doivent permettre cette modification. Ne pas choisir 3DES, BlowFish ou MD5 comme solution de performance.

Règle pratique : L’offloading n’est pas un objectif de sécurité. Les profils de protection et l’inspection ne sont pas supprimés uniquement pour atteindre FastPath. Ce sont la protection nécessaire et les mesures reproductibles du débit, du CPU et de l’application qui comptent.

DoS n’est pas seulement un type de trafic non déchargé : son activation désactive Firewall Acceleration. Il faut donc consigner l’état DoS dans le contexte des mesures ; la protection n’est pas désactivée uniquement pour améliorer le débit mesuré.

En HA, il faut être particulièrement attentif. Active-Active HA ne prend pas en charge Firewall Acceleration. Sophos prend en revanche en charge IPsec Acceleration en HA Active-Active et Active-Passive sur le nœud primaire ; en Active-Passive, Firewall Acceleration reste elle aussi limitée au nœud primaire. Un dimensionnement HA ne doit donc pas simplement extrapoler aux deux nœuds les valeurs de laboratoire d’un appareil autonome.

Le dépannage peut également influencer les mesures. Avec Packet Capture ou iftop, SFOS envoie temporairement le trafic par SlowPath par défaut. Si l’offloading reste actif pendant la capture, un Packet Capture standard ne peut pas enregistrer le trafic FastPath. L’absence d’un paquet ne prouve donc pas que le pare-feu n’a pas traité le flux ; Sophos renvoie vers Support lorsqu’une capture FastPath est nécessaire. Les mesures de performance et les résultats de capture sont toujours documentés avec l’heure, la méthode de test, la version du firmware, le type d’interface et la politique active.

Les accélérations sont actives par défaut sur les plateformes prises en charge. L’activation ou la désactivation de Firewall ou PKI Acceleration redémarre le service IPS (moteur DPI) ; une modification d’IPsec Acceleration redémarre tous les tunnels IPsec. Ces changements doivent être effectués dans une fenêtre de maintenance, pas comme test de performance improvisé. Il faut d’abord confirmer l’hypothèse avec Log Viewer, Packet Capture, Dépannage IPsec et un cas de test clair.

Pour les trois sous-sections d’accélération suivantes, se connecter à Sophos Firewall avec des droits administratifs et ouvrir la Device Console. Ces commandes s’exécutent dans cette console, pas dans l’Advanced Shell ni dans le shell de son ordinateur.

Lire et contrôler correctement PKI Acceleration

L’état configuré et l’état effectif ne sont pas identiques. La configuration se lit avec :

show ips-settings

PKI Acceleration est activée par défaut sur les modèles XGS Appliance compatibles. enabled n’est effectif que si Firewall Acceleration fonctionne également. Si PKI Acceleration est activée mais que Firewall Acceleration est désactivée, SFOS affiche enabled (inactive). Sur les versions SFOS ou les modèles non compatibles, elle apparaît comme disabled ; une modification dans la CLI ne peut pas remplacer la prise en charge matérielle ou de plateforme manquante.

Avant de modifier PKI Acceleration : Le changement redémarre le service IPS (moteur DPI) et doit donc être effectué pendant une fenêtre de maintenance. Consigner d’abord la valeur actuelle de show ips-settings et l’état de Firewall Acceleration fourni par system firewall-acceleration show. Les commandes suivantes sont des alternatives, pas une séquence à exécuter. Ne pas les exécuter toutes deux consécutivement comme un test improvisé.

La configuration globale se modifie dans l’arborescence de commandes IPS. Choisir uniquement le sens nécessaire :

Désactiver :

set ips pki-acceleration disable

Ou, pour activer :

set ips pki-acceleration enable

Après la modification réellement effectuée, vérifier à nouveau show ips-settings, l’état d’IPS et de DPI ainsi qu’un flux TLS réel déchiffré par le moteur DPI. C’est la seule manière de confirmer que la nouvelle signature des certificats, la latence, le CPU et l’application restent corrects. Si l’effet attendu n’apparaît pas, la valeur précédemment consignée est restaurée.

Vérifier IPsec Acceleration de manière contrôlée

Lire d’abord l’état global :

system ipsec-acceleration show

IPsec Acceleration est enabled par défaut et décharge du SlowPath les SA de phase 2 éligibles. Un état global activé ne prouve pas qu’une SA précise est offloaded. 3DES, BlowFish et MD5 sont exclus, et les limites d’interface et de plateforme décrites plus haut restent applicables.

Une modification s’applique à tout le pare-feu et redémarre tous les tunnels IPsec. disable n’est donc pas un test pour un seul tunnel. Si une erreur claire justifie un test A/B, documenter d’abord la valeur globale d’origine indiquée par system ipsec-acceleration show, ainsi que l’état des tunnels, les SA, le CPU, le débit et le trafic de test. Pendant la fenêtre de maintenance, choisir uniquement le sens de modification nécessaire : l’activation et la désactivation sont des alternatives, pas une séquence à exécuter. Ne pas exécuter les deux commandes consécutivement comme bloc de test ; après la modification choisie, effectuer d’abord les contrôles décrits ci-dessous.

Désactiver :

system ipsec-acceleration disable

Ou, pour activer :

system ipsec-acceleration enable

Après chaque modification réellement effectuée, vérifier de nouveau show, l’établissement des tunnels, les SA de phase 2, le routage, les règles et le trafic réel dans les deux sens. Restaurer la valeur d’origine en l’absence d’amélioration reproductible. Ne pas conserver un profil cryptographique obsolète uniquement pour permettre une comparaison de performances.

Basculer Firewall Acceleration uniquement pendant une fenêtre de maintenance

L’état actuel est d’abord lu dans la Device Console :

system firewall-acceleration show

Avant le premier changement, consigner la sortie complète et l’état initial exact : Firewall Acceleration était-elle activée ou désactivée ? Cela détermine la commande appropriée pour revenir en arrière ultérieurement, avec enable ou disable ; la valeur par défaut documentée ne remplace pas cet état de référence. Pour la comparaison, documenter également le flux concerné, l’accessibilité du WAN, les connexions VPN, l’état IPS et DPI, les nouvelles sessions, les services publiés, le débit, le CPU et Log Viewer. En HA, consigner aussi le mode, le nœud primaire et l’état du cluster, y compris la synchronisation, afin de pouvoir répéter les mêmes vérifications après le changement et après une restauration.

Sur les plateformes prises en charge, Firewall Acceleration est en enable par défaut. Selon Sophos, chaque modification provoque une interruption et redémarre le service IPS (moteur DPI). disable ne constitue donc pas un test A/B anodin en production. Le pare-feu continue de traiter entièrement le trafic, mais sans les avantages de performance de FastPath.

Ces deux commandes sont disponibles pour une modification planifiée. Elles ne sont pas exécutées immédiatement l’une après l’autre comme un bloc de test, car chaque transition peut à nouveau interrompre le trafic :

system firewall-acceleration disable
system firewall-acceleration enable

Après chaque transition réellement nécessaire, vérifier à nouveau show, l’état IPS et DPI, les nouvelles sessions, les services publiés, le VPN, le débit, le CPU et Log Viewer. Une valeur disabled affichée n’est pas remplacée aveuglément par enable : DoS, le HA active-active, un FastPath qui ne se charge pas ou une combinaison VM, hyperviseur ou pilote NIC non prise en charge peuvent également empêcher l’accélération. enable ne peut pas forcer un FastPath fonctionnel sur une plateforme techniquement non prise en charge.

Si la comparaison n’était prévue que temporairement ou si aucune amélioration reproductible n’est obtenue, rétablir, pendant la fenêtre d’interruption autorisée, uniquement le réglage de Firewall Acceleration modifié dans ce cas à son état initial enregistré : avec system firewall-acceleration enable s’il était auparavant activé, ou avec system firewall-acceleration disable s’il était auparavant désactivé. Il s’agit de deux possibilités de retour en arrière, et non d’une séquence à exécuter ; PKI et IPsec Acceleration ne sont pas basculées en plus à cette fin. Le retour en arrière provoque lui aussi une interruption et doit être planifié. Ensuite, lire à nouveau l’état avec system firewall-acceleration show, comparer la sortie avec l’état de référence enregistré et répéter les mêmes vérifications pour le flux concerné, le WAN, le VPN, IPS/DPI, les sessions, les services publiés, le débit, le CPU et les journaux, ainsi que, en HA, pour le mode, le nœud primaire et l’état du cluster, y compris la synchronisation. Si l’état ou le trafic ne correspond pas à l’état initial, rechercher la cause plutôt que de modifier aveuglément d’autres réglages. Si le nouvel état doit être conservé délibérément, une décision d’exploitation explicitement documentée est nécessaire ; ni la valeur par défaut ni un test isolé supposément réussi ne la remplacent.

Vérifier la performance en opération

Les valeurs des fiches techniques aident avant l’achat. En opération, d’autres outils sont nécessaires. Il est important de distinguer les notions : le Control Center n’affiche pas une performance de fiche technique, mais des indicateurs d’exploitation actuels. La tuile Performance repose sur le load average réparti sur les coeurs CPU. Des valeurs supérieures au nombre de coeurs disponibles signifient qu’il y a plus de travail en attente que le système ne peut en traiter à ce moment-là.

La couleur de la tuile suit des seuils Sophos fixes : Normal pour un load average inférieur à 2, Warning de 2 à 5 et Alert au-delà de 5 coeurs CPU. Ce feu tricolore est un indicateur rapide, mais il ne correspond pas au seuil de surcharge propre à l’appliance. Il faut donc interpréter ensemble l’état de la tuile, le nombre réel de coeurs et l’évolution dans le temps.

CPU, mémoire, bande passante, sessions, Decryption Capacity et Decrypt Sessions sont aussi pertinents. Decryption Capacity est particulièrement utile avec TLS Inspection, car elle montre dans quelle mesure le déchiffrement SSL/TLS actuel utilise la capacité de déchiffrement disponible. Les détails de déchiffrement ne sont pas mis à jour comme une mesure live à la seconde, mais typiquement toutes les cinq minutes. Ces valeurs doivent toujours être lues avec la policy, la règle, le profil de sécurité, l’heure et le type de trafic.

Utiliser System Graphs comme chronologie

Sous Diagnostics > System graphs, il est possible de comparer CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone et les différentes interfaces sur plusieurs périodes. Il faut d’abord sélectionner la période de l’incident, puis uniquement les graphiques correspondant à la fonction concernée.

Un pic constitue une corrélation, pas encore une cause. CPU, mémoire ou load average doivent donc être comparés au trafic des interfaces, au nombre d’utilisateurs, aux journaux, à la policy et à l’heure exacte du test. La chronologie aide surtout à distinguer une brève valeur aberrante d’une charge élevée récurrente ou persistante ; à elle seule, elle ne prouve ni que l’appliance est sous-dimensionnée ni qu’un service précis est défaillant.

Lire correctement les unités et l’agrégation

Le graphique CPU distingue l’utilisation par les processus utilisateur, les composants système et le temps d’inactivité restant. Memory affiche Used, Free et Total en MB. Load Average n’est en revanche pas un pourcentage : ses trois courbes représentent les moyennes sur une, cinq et quinze minutes. Il doit donc être interprété avec le nombre de cœurs CPU disponibles.

Disk Usage indique en pourcentage l’espace occupé par les signatures, les fichiers de configuration, les rapports et les données temporaires. Il s’agit d’une répartition fonctionnelle dans le graphique, différente des partitions affichées par df -kh ou du watermark des rapports. Live Users compte les utilisateurs connectés à Internet pendant la période choisie et affiche aussi le minimum, le maximum et la moyenne. Ce n’est pas le nombre de comptes utilisateur configurés.

Pour la zone WAN, des graphiques distincts présentent l’upload et le download, le débit total combiné et le débit par gateway. Selon la vue, les valeurs actuelle, minimale, maximale et moyenne apparaissent. Sophos documente une erreur d’étiquetage importante : WebAdmin affiche KBps, alors que les valeurs sont réellement en kbit/s. Une lecture en kilo-octets par seconde entraîne une erreur d’un facteur huit.

Utiliser la même période pour les graphiques WAN : selon la sélection, l’axe x représente les minutes, heures, jours ou mois, et l’axe y le débit en kbit/s, pas un volume transféré. Dans le graphique upload/download séparé, l’orange représente l’upload et le violet le download ; minimum, maximum, moyenne et valeur actuelle s’appliquent séparément à chaque sens. Dans le graphique combiné, l’orange représente la somme de l’upload et du download, avec les mêmes quatre indicateurs. Dans le graphique par gateway, chaque gateway possède sa propre couleur et ses propres indicateurs. On peut ainsi repérer les différences entre sens et gateways sans assimiler le débit combiné à la capacité d’un seul sens. L’avertissement sur KBps figure dans les textes d’aide SFOS 22 et SFOS 23 examinés ; une correction future annoncée ne prouve pas que le firmware utilisé porte déjà une autre étiquette.

Dans le graphique Disk Usage, l’orange correspond aux signatures, le violet aux fichiers de configuration, le vert aux rapports et le bleu au stockage temporaire. L’axe y affiche des pourcentages et l’axe x les minutes, heures, jours ou mois selon la période choisie. Une part verte croissante indique ici davantage de stockage des rapports, pas directement une charge CPU plus élevée.

Important pour les VLAN : Des graphiques d’interface séparés existent pour les interfaces physiques, Wireless LAN, les interfaces WAN et les interfaces VLAN de la zone WAN. Les VLAN des autres zones sont regroupés dans le graphique de leur interface physique parente. Un pic sur le port parent ne peut donc pas être attribué à un seul VLAN interne sans mesure supplémentaire.

Les graphiques d’interface affichent les bits reçus et transmis ainsi que les drops, erreurs et collisions. La résolution est agrégée sur les périodes plus longues : aujourd’hui et hier reposent sur des moyennes de cinq minutes, la semaine sur 15 minutes, le mois sur six heures et l’année sur un jour. Les pics brefs peuvent donc disparaître dans une vue mensuelle ou annuelle ; pour un incident, commencer par la période adaptée la plus courte.

Procédure pratique :

1. Vérifier le Control Center : Observer le CPU, la RAM, l’utilisation des interfaces et les alertes.
2. Ouvrir le Log Viewer : La règle de pare-feu attendue est-elle appliquée et la journalisation est-elle activée ?
3. Contrôler la politique et les profils de sécurité : Quelles fonctions agissent sur le trafic concerné ?
4. Utiliser Packet Capture : Peut-on voir les paquets, les paquets de réponse, le NAT et les pertes ?
5. Effectuer un test de connexion : Avec iPerf ou un téléchargement défini, vérifier quel chemin est vraiment lent.
6. Noter le contexte de déchargement : Le type d’interface, le mode HA, le type de VPN, PPPoE, WAF, SSL VPN ou Packet Capture peuvent influencer la mesure.
7. Noter le moment : Les pics de charge, les sauvegardes, les mises à jour ou les rapports peuvent fausser les résultats.

Pour une délimitation rapide de la connexion WAN, Effectuer un test de vitesse Internet du Sophos Firewall via SSH est utile. Pour des tests de bout en bout entre deux systèmes, Tester la performance du Sophos Firewall avec iPerf est mieux adapté. Si une règle ne s’applique pas comme prévu, Tester spécifiquement les règles du Sophos Firewall est approprié.

La checklist quotidienne d’administration de Sophos Firewall montre comment regrouper le Control Center, les System graphs, les rapports et les événements administrateur dans une procédure courte et récurrente.

Erreurs typiques de dimensionnement

• Seul le débit maximal du pare-feu est comparé.
• L’Inspection TLS est planifiée, mais pas incluse dans la réserve de performance.
• Le VPN et l’accès à distance sont évalués en fonction du nombre d’utilisateurs plutôt que de l’utilisation réelle.
• La connexion Internet est prise en compte, mais pas le trafic interne Est-Ouest.
• Les pare-feux virtuels sont exploités sur des hôtes surchargés.
• Le reporting, la journalisation et la connexion Central sont considérés après coup.
• La croissance, les nouveaux sites, les VLAN supplémentaires ou la publication de serveurs manquent dans la planification.
• Aucune distinction n’est faite entre la valeur de laboratoire, la valeur réelle et l’expérience utilisateur.

Liste de vérification pratique pour le dimensionnement

Avant de choisir un modèle, ces points doivent être clarifiés :

1. Bande passante Internet actuelle et prévue pour les prochaines années.
2. Nombre d’utilisateurs, d’appareils, de serveurs et de sites.
3. Part de trafic Web, d’applications cloud, de VoIP, de sauvegardes et de transferts de fichiers.
4. Fonctions de sécurité prévues par groupe de trafic.
5. Étendue de l’Inspection TLS et exceptions nécessaires.
6. Nombre et utilisation des connexions IPsec, SSL VPN et Sophos Connect.
7. Besoin de WAF, Mail Protection, RED, WLAN ou Central Reporting.
8. Réserves attendues pour les mises à jour, la croissance et les pics de charge.
9. Modèle d’exploitation : XGS Appliance, appliance virtuelle, cloud ou cluster HA.

FAQ