Sophos SFOS v18 – aperçu des nouvelles fonctionnalités
Les Sophos Firewalls avec SFOS recevront bientôt une mise à jour majeure vers SFOS v18. Nous utilisons déjà la bêta en production. Dans cet article, vous découvrirez les nouvelles fonctions de cette version et la manière dont elles se comportent au quotidien.
Tests en production
Nous ne testons pas la bêta sur un appareil isolé dans un environnement de laboratoire, mais directement en production. En complément, certains clients comptant plus de 650 utilisateurs utilisent eux aussi cette version, afin que nous puissions recueillir des retours aussi complets que possible. Dans cet article, nous ne reprenons donc pas simplement les supports officiels de Sophos : nous parlons de SFOS v18 EAP1 et EAP2 sur la base de plusieurs semaines d’expérience pratique. L’article est donc volontairement détaillé, car nous examinons de nombreuses fonctions de près. Commençons par l’architecture Xstream.
Architecture Xstream
L’un des points forts de la v18 est la nouvelle architecture de traitement des paquets. Elle apporte davantage de performances, une sécurité accrue et une visibilité nettement meilleure sur le trafic chiffré. Avec la v18, Sophos a vraiment beaucoup fait évoluer ce domaine.
Info : le « X » de « Xstream » signifie Next Generation, et « Stream » fait référence au nouveau moteur DPI, une solution d’analyse basée sur le streaming.
Moteur Xstream SSL/TLS Inspection
Nous avons déjà parlé de SSL Inspection, souvent appelée aussi « SSL Scanning » ou « HTTPS Scanning » : Pourquoi activer le HTTPS Scanning sur Sophos
En résumé : le trafic HTTP peut être contrôlé sans difficulté par le pare-feu, car il n’est pas chiffré. Le trafic HTTPS doit en revanche d’abord être déchiffré avant que le pare-feu puisse l’analyser. Jusqu’ici, le problème venait du fait que le Web Proxy ne pouvait déchiffrer que le trafic HTTPS passant par le port 443. Si le trafic utilisait un autre port, par exemple https://www.example.com:8000, le pare-feu restait aveugle.
Avec la v18, le pare-feu est de nouveau prêt pour les technologies actuelles et peut inspecter le trafic SSL comme le trafic TLS 1.3, quels que soient les ports ou protocoles utilisés. 🤩 Sous le capot, cela a nécessité d’importants changements d’architecture, heureusement sans effort supplémentaire pour les administrateurs.
Les éléments centraux sont ici un Decryption Profile, qui est associé à une SSL/TLS Inspection Rule. Cette règle définit quel trafic doit être inspecté.
Il est important de comprendre que le nouveau moteur DPI entre directement en concurrence avec l’ancien Web Proxy. Le Web Proxy est responsable du trafic HTTP/HTTPS, des Web Policies et du Content Scanning ; ces tâches peuvent désormais être prises en charge par le nouveau moteur DPI.
Lors d’une mise à niveau de la version 17.5 vers la 18.0, les paramètres du Web Proxy sont repris. Si vous souhaitez utiliser le moteur DPI, vous devez toutefois effectuer quelques ajustements : configurer une SSL/TLS Inspection Rule et désactiver le Web Proxy dans les paramètres du pare-feu.
Il y a peu de raisons de ne pas passer au nouveau moteur DPI. Le Web Proxy offre néanmoins quelques fonctions qui ne sont pas encore disponibles dans le moteur DPI, par exemple SafeSearch pour les moteurs de recherche ou YouTube, Caching ou Pharming Protection. Sur tous les pare-feu que nous gérons, nous pouvons toutefois nous passer sans problème de ces fonctions supplémentaires ; le moteur DPI sera donc clairement utilisé chez nous.
La vidéo suivante de Sophos donne une introduction compacte au Xstream DPI Engine et aide à décider quand utiliser le moteur DPI plutôt que le Web Proxy classique :
Xstream Network Flow FastPath
De nombreux administrateurs connaissent le problème du pare-feu qui ralentit sensiblement le trafic et donne l’impression que certains processus deviennent plus lents. Grâce à la nouvelle architecture, il existe désormais ce que l’on appelle le FastPath. Il permet au pare-feu de déléguer le trafic non critique directement au noyau, ce qui améliore nettement les performances.
Le trafic traverse d’abord la Firewall Stack. Celle-ci vérifie s’il existe une règle de pare-feu correspondante et si le trafic est autorisé. Si le trafic est par exemple inspecté par l’IPS, il passe d’abord par le moteur DPI. Dès que le moteur IPS considère le trafic comme inoffensif, celui-ci peut être déplacé vers le FastPath et transmis directement par 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
Quand la version GA (finale) sera-t-elle disponible ?
Où en est le nouveau matériel ?
Let’s Encrypt sera-t-il intégré ?
Informations supplémentaires
