Sophos SFOS v18 – aperçu des nouvelles fonctionnalités

Avec la version SFOS v18, Sophos a considérablement élargi et remanié le firmware. De nombreuses nouvelles fonctionnalités ont été ajoutées dans différents domaines.

Il convient de préciser que la v18 se trouve encore en phase d’accès anticipé et que certaines fonctions ont déjà évolué. Grâce aux retours de nombreux utilisateurs et partenaires Sophos, la solution a été continuellement optimisée. Il est donc possible que certaines captures d’écran diffèrent légèrement dans la version GA.

Dans cet article, nous nous concentrons exclusivement sur les nouvelles fonctionnalités de Sophos XG Firewall v18 et n’évoquons la console web que brièvement. Pour en savoir plus, il existe un autre article de blog : Sophos Central Firewall Management – fonctionnalités avec SFOS v18

Deep Packet Inspection et architecture Xstream

Le principal changement dans Sophos Firewall SFOS v18 est l’introduction de la Deep Packet Inspection (DPI). Jusqu’à présent, le trafic – en particulier le trafic web – était analysé au moyen d’un proxy. C’est justement ce point qui faisait l’objet de critiques, notamment dans le monde UTM, car XG Firewall n’analysait pas le trafic HTTP/HTTPS directement via le pare-feu, mais via un proxy séparé. Les clients qui avaient déjà migré vers XG ont constaté que des utilisateurs étaient bloqués parce qu’un proxy tentait d’atteindre l’authentification des utilisateurs. Même si ce problème ne devenait réellement visible que dans de grands environnements, il constituait souvent une raison de repousser la migration de UTM vers XG.

Important : le proxy reste présent dans le firmware et ne disparaît pas avec la v18. Le moteur DPI ajoute toutefois une nouvelle option pour inspecter le trafic web.

Qu’est-ce que la Deep Packet Inspection ?

Sans Deep Packet Inspection, le pare-feu fonctionne comme un pare-feu classique à inspection avec état et vérifie les informations d’en-tête ainsi que l’état de la connexion. Avec la Deep Packet Inspection, l’intégralité de la charge utile est analysée, ce qui permet de filtrer plus précisément les attaques et les logiciels malveillants.

Moteur Xstream SSL/TLS Inspection

Ces dernières années, SSL/TLS a gagné une importance considérable. Le projet « Let’s Encrypt » a simplifié l’émission de certificats gratuits et contribué à ce que même les sites web privés soient chiffrés. De nombreux navigateurs avertissent désormais lorsqu’un site non chiffré est consulté.

Sophos recommande donc d’inspecter le trafic SSL/TLS pour garantir une sécurité HTTP complète. Sous sa forme actuelle, la fonction devrait plutôt s’appeler « SSL/TLS Inspection » et non « SSL (TLS) Inspection », mais dans le secteur, on parle encore très souvent de SSL.

Ressources externes sur l’inspection SSL/TLS :

• Warum ist eine SSL-Inspection Pflicht? – Teil 1
• Warum ist eine SSL-Inspection Pflicht? – Teil 2
• Why Host a CA on Your XG Firewall with SFOS v18?

Avec la v18, l’inspection SSL est désormais gérée de manière centralisée via des profils de déchiffrement, et l’inspection est appliquée au moyen de règles de pare-feu dédiées.

Les principaux paramètres peuvent être définis pour chaque profil de déchiffrement. Ils incluent, par exemple, des options permettant de contourner certains flux de trafic, lorsque l’authentification mutuelle est configurée entre le client et le serveur et que le pare-feu ne peut pas inspecter le certificat.

De prime abord, cette zone paraît assez complexe. Pour celles et ceux qui aiment se plonger dans la documentation, il vaut la peine de lire l’article suivant dans la communauté XG Firewall : SFOS v18: HTTPS Scanning and Xstream SSL Inspection

Malheureusement, au moment de la rédaction de cet article, il n’existait pas encore de documentation en français pour Sophos XG Firewall v18 via le Central Partner Portal ou l’aide du navigateur Sophos XG (HV System). On peut toutefois s’attendre à ce qu’au moment où cet article sera publié, davantage de documentation en anglais soit disponible : \https://docs.sophos.com

Moteur DPI

Outre le moteur d’inspection SSL/TLS, le nouveau moteur DPI constitue le deuxième pilier de Xstream. Il déplace plusieurs contrôles de sécurité au niveau du pare-feu, notamment Advanced Threat Protection, IPS et filtre d’applications.

Pour le trafic web, avec la v18 il est possible de choisir si le trafic est géré par le moteur DPI ou par le proxy. Pour le trafic email, il faut pour l’instant continuer à utiliser le proxy. Dans de futures versions du firmware, Sophos prévoit de déplacer d’autres groupes de flux du proxy vers le moteur DPI. Au moins pour SFOS v18, l’accent a été mis sur le trafic HTTP et HTTPS.

Le moteur DPI apporte également plusieurs avantages en termes de performances. Quelques exemples sont mentionnés dans la section suivante.

Xstream FastPath

L’architecture Xstream a été conçue pour améliorer les performances. Une appliance de pare-feu ne peut fournir qu’une puissance limitée, il est donc essentiel de l’optimiser aux bons endroits.

L’appliance Sophos XG Firewall n’est que du matériel – ce qui compte, c’est la façon dont le firmware exploite efficacement l’appliance.

Dans l’architecture Xstream, chaque paquet passe d’abord par le moteur DPI, qu’il provienne du LAN ou du WAN. Le flux réseau passe ensuite dans le « FastPath », qui est implémenté dans le noyau Linux. Si le moteur DPI détermine qu’un flux peut être considéré comme sûr, celui-ci est transféré vers le FastPath et est ensuite transmis directement via le noyau.

En regardant le schéma de l’architecture, une question se pose naturellement : comment cela fonctionne-t-il concrètement dans la pratique ? Il est relativement rapide de déterminer si le trafic est fondamentalement autorisé – cette étape n’a pas besoin d’être répétée pour chaque paquet de la même source et du même port. Mais comment le moteur DPI sait-il à quel moment basculer un flux vers le FastPath ? Si, par exemple, l’inspection SSL/TLS est activée, cela n’est pas possible, car le trafic ne serait alors plus inspecté. En revanche, pour IPS ou le contrôle des applications, on travaille avec des listes connues qui servent de base pour décider si un flux de données peut être considéré comme inoffensif.

Threat Intelligence Analysis

Si le module Sophos Sandstorm est licencié pour le pare-feu, les fichiers sont déjà examinés dans un environnement sandbox avant d’être téléchargés. Celles et ceux qui souhaitent en savoir plus sur Sophos Sandstorm peuvent consulter le PDF Sophos Sandstorm avec FAQ. Grâce à l’inspection SSL/TLS, le pare-feu obtient une vue plus approfondie du trafic et peut contrôler les téléchargements web avec encore plus de précision. En plus de cela, la protection endpoint reste la dernière ligne de défense.

Avec la v18, le nouveau module Threat Intelligence Analysis vient compléter le module Sandstorm existant. Alors que Sophos Sandstorm analyse les téléchargements web ou les pièces jointes des emails, Threat Intelligence examine les fichiers à l’aide du machine learning. L’analyse des SophosLabs est également utilisée – la même technologie que celle employée dans Sophos Intercept X avec EDR.

Comme pour l’EDR, un rapport d’analyse détaillé est généré. Dans SFOS v18 EAP2, un tel rapport se présente par exemple comme suit :

Le rapport légèrement plus soigné ne sera disponible qu’à partir d’EAP3.

Enterprise NAT

En plus de l’architecture Xstream, les règles NAT ont également été totalement repensées. Jusqu’à la version 17.5, il existait le menu « Firewall », dans lequel toutes les règles de pare-feu, les règles NAT et les règles WAF étaient regroupées. Dans une règle de pare-feu, il était possible de définir, entre autres, l’interface de sortie ou l’adresse IP de sortie pour le trafic.

Avec la v18, les règles NAT sont désormais gérées dans un onglet séparé, ce qui rend l’administration nettement plus flexible.

Beaucoup de clients attendaient ce changement depuis longtemps : il est désormais possible, par exemple, de bloquer toutes les requêtes DNS ou NTP vers des serveurs publics et de les rediriger vers un serveur interne. Cela offre également une solution pour ceux qui regrettaient le serveur NTP intégré dans la UTM mais absent dans la XG.

Le sujet NAT est également expliqué dans la vidéo suivante :

Gestion des règles de pare-feu

À chaque nouvelle version majeure, Sophos améliore la gestion des règles de pare-feu. Dans la v18, il est désormais possible de sélectionner plusieurs règles de pare-feu en même temps afin de les supprimer, de les activer ou de les désactiver, ou encore de les ajouter à un groupe ou de les en retirer. De plus, les règles de pare-feu sont maintenant numérotées, ce qui permet de voir immédiatement leur nombre total. L’ID de règle reste, quant à lui, inchangé. Enfin, le menu « Firewall » a été renommé « Rules and policies ».

De nouveaux filtres peuvent être définis, ce qui simplifie considérablement la recherche de règles spécifiques. Le filtre reste actif même lorsque l’on change de section de menu et que l’on revient ensuite au jeu de règles.

Ceux qui espéraient que Sophos laisserait désormais les groupes de règles ouverts après l’enregistrement d’une règle seront malheureusement déçus. Rien n’a changé à ce niveau. 😖

Une fonctionnalité très demandée a également été ajoutée : le compteur du trafic traité par une règle de pare-feu peut désormais être réinitialisé à zéro.

Lors de la création d’une nouvelle règle de pare-feu, il est maintenant possible de l’ajouter d’abord à l’état désactivé.

En outre, il est désormais possible de définir des exclusions directement dans les règles de pare-feu. Cela contribue à maintenir un jeu de règles épuré et à éviter des règles supplémentaires inutiles.

Log Viewer

Celles et ceux qui ont lu l’article 7 Gründe, warum die XG Firewall (SFOS) besser ist als die UTM savent à quel point le Log Viewer est utile. Dans la nouvelle version, l’outil reçoit encore quelques fonctionnalités pratiques supplémentaires.

En cliquant sur une entrée du Log Viewer, il est possible de définir directement un filtre, de créer une exception SSL/TLS ou d’ajuster une règle IPS, un contrôle d’applications ou une politique de filtre web.

Alertes et notifications

Sous « Administration » > « Notification settings », seules deux options pouvaient jusqu’à présent être activées pour les notifications par email :

• IPsec tunnel up/down
• Email alert notifications

Si une RED était injoignable ou si un utilisateur saisissait trop souvent un mot de passe erroné, il n’existait jusqu’ici aucun moyen de recevoir une notification.

Améliorations : il est désormais plus rapide et plus simple de regrouper des appliances en cluster. Il est en outre possible d’effectuer un rollback du firmware.

• Support SNMPv3 : sécurité nettement accrue par rapport à SNMPv1 et SNMPv2 – si tant est que l’on puisse parler de « sécurité » pour ces deux versions. Le fichier MIB est comme d’habitude disponible en téléchargement.
• Renommer les interfaces : jusqu’à présent, les interfaces portaient les noms Port1, Port2, etc., sans possibilité de les modifier. Dans la v18, ces noms peuvent désormais être adaptés. En revanche, il reste impossible de renommer IPsec, IPS, les réseaux sans fil, etc.
• Mises à jour de la base de données GeoIP : la base de données des adresses IP par pays peut désormais être mise à jour indépendamment des mises à jour de firmware.
• Mise à jour de VMware Tools : VMware Tools est désormais disponible en version 10.3.10 et prend également en charge Site Recovery Manager (SRM).

Mise à niveau vers SFOS v18

Conditions préalables

Envie de passer à la v18 ? Si vous utilisez déjà un pare-feu XG ou une SG avec SFOS, vous devez au minimum disposer de la version v17.5 MR6 pour effectuer la mise à niveau vers la v18. Comme d’habitude, un rollback est possible. Si quelque chose ne fonctionne pas comme prévu avec la v18, vous pouvez à tout moment revenir à la version précédente.

De SG à XG

Si vous utilisez encore un pare-feu UTM, vous pouvez également migrer vers SFOS. Une procédure détaillée est disponible ici : Installer Sophos XG Firewall OS sur une appliance SG

Si vous avez besoin d’assistance pour la migration, nous nous ferons un plaisir de vous aider. Nous avons déjà remplacé avec succès de nombreux systèmes UTM. 😎

XG 85 et XG 105

L’installation de la v18 nécessite au minimum 4 Go de RAM. La prochaine version de SFOS ne sera donc plus compatible avec les modèles XG 85 et XG 105. Ceux qui utilisent leur propre matériel avec seulement 2 Go de RAM se heurteront au même problème. Cyberoam ne sera plus pris en charge non plus.

Les propriétaires d’une XG 85 ou XG 105 devraient se pencher sur les modèles suivants : Sophos XG 86 et XG 106. Jusqu’au 30/09/2020, Sophos propose d’ailleurs une promotion permettant de bénéficier de 50 % de réduction sur le nouveau matériel lors d’un renouvellement.

Sophos Central Firewall Reporting and Management

Un article de blog séparé est consacré à ce sujet : Sophos Central Firewall Management – fonctionnalités avec SFOS v18

FAQ

Informations supplémentaires

• XG Firewall: What’s New in v18