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

Les Sophos Firewall (avec SFOS) recevront prochainement une nouvelle mise à jour majeure avec SFOS v18. Nous avons déjà installé la bêta chez nous et je vous montre dans cet article quelles sont les fonctions de la nouvelle version.

Tests en direct

En fait, nous ne testons pas la bêta sur un quelconque dispositif de test dans un environnement de laboratoire. Nous acquérons tout de suite notre expérience dans l’entreprise productive. Mais ce n’est pas tout. Nous testons également la version bêta auprès de clients sélectionnés, avec plus de 650 utilisateurs, afin de recueillir un maximum d’informations sur la nouvelle version. Je ne me contente donc pas de copier-coller les textes du matériel d’information de Sophos, mais je vous parle du nouveau SFOS v18 EAP1 et EAP2 avec plusieurs semaines d’expérience. Cela se reflète bien sûr dans la longueur de cet article, dans lequel j’aborderai plus en détail de nombreuses fonctions. Commençons donc tout de suite avec l’architecture Xstream.

Architecture Xstream

Un point fort particulier de la v18 est la nouvelle architecture de traitement des paquets. Celle-ci offre plus de performance, de sécurité et de visibilité pour le trafic crypté. La v18 a beaucoup évolué.

Info: Le « X » dans « Xstream » signifie NextGerneation et le ‘Stream’ pour le nouveau moteur DPI, qui est une solution de numérisation basée sur le streaming.

Inspection SSL/TLS Xstream

Nous avons déjà parlé de l’inspection SSL ou, plus souvent, du « contrôle SSL » ou du « contrôle HTTPS » : Contrôle HTTPS : pourquoi l’activer sur Sophos ?

En résumé, il n’y a pas de problème : Le trafic HTTP peut être contrôlé sans problème par le pare-feu, car il n’est pas crypté. En revanche, le trafic HTTPS doit d’abord être brisé. Ce n’est qu’alors que le pare-feu peut le scanner. Le problème jusqu’à présent était que le proxy web ne pouvait décrypter que le trafic HTTPS passant par le port 443. Si le trafic passait par un autre port, par exemple https://www.example.com:8000, le pare-feu était à nouveau aveugle.

Avec la v18, on est à nouveau armé contre les technologies les plus récentes et on peut vérifier aussi bien le trafic SSL que TLS 1.3. Peu importe par quels ports ou protocoles le trafic passe. 🤩 Mais sous le capot (architecture), beaucoup de choses ont dû changer pour cela, ce dont l’administrateur de pare-feu n’a heureusement pas à souffrir.

D’une part, il faut un profil de décryptage, qui est à son tour rattaché à une règle d’inspection SSL/TLS. Cette règle définit ensuite quel trafic doit être contrôlé.

Ainsi, il est possible de définir quel trafic doit être contrôlé indépendamment des règles de pare-feu.

A ce stade, il existe également des profils de décryptage et des règles d’exception pour l’inspection SSL/TLS déjà prédéfinis. Dans ces règles d’exception, il y a une liste gérée par Sophos pour que les sites web et les applications qui posent problème ne soient pas contrôlés.

La vidéo suivante de Sophos vous présente brièvement le moteur d’inspection SSL Xstream dans XG Firewall v18 :

Moteur Xstream DPI

Le moteur DPI est la partie qui s’occupe de l’inspection SSL/TLS. Une fois le trafic décrypté, il le scanne également pour détecter les directives de politique web, l’analyse de contenu (AV), le contrôle des applications et l’IPS.

Il est important de comprendre ici que le nouveau moteur DPI est en concurrence avec le proxy web utilisé jusqu’à présent. C’est donc le proxy web qui s’occupe du trafic HTTP / HTTPS, de la politique web et de l’analyse de contenu ou du nouveau moteur DPI.

Si l’on passe de la version 17.5 à la version 18.0, les paramètres du proxy web sont bien sûr repris. Mais si l’on souhaite utiliser le moteur DPI, il faut d’abord procéder à quelques modifications. Pour cela, créez une règle d’inspection SSL/TLS et désactivez le proxy web dans les paramètres du pare-feu.

Il n’y a que peu de raisons de ne pas miser sur le nouveau moteur DPI. Néanmoins, il y a des fonctions que le proxy web offre et que le moteur DPI ne propose pas. Il s’agit par exemple de SafeSearch pour les moteurs de recherche ou YouTube, ainsi que de la mise en cache ou de la protection contre le pharming. Mais pour tous les pare-feux que nous gérons, nous pouvons sans problème nous passer de ces fonctions, c’est pourquoi le moteur DPI sera certainement utilisé chez nous.

La vidéo suivante de Sophos vous donne une brève introduction au moteur DPI de Xstream et vous aide à décider quand utiliser le moteur DPI par rapport au proxy web obsolète :

Xstream Network Flow FastPath

Vous connaissez certainement le problème du pare-feu qui ralentit quelque peu le trafic. Certains processus paraissent alors un peu plus lents. Grâce à la nouvelle architecture, il existe ce que l’on appelle un FastPath. Celui-ci permet au pare-feu de transférer le trafic inoffensif directement sur le noyau et de maintenir ainsi des performances extrêmement élevées.

Au début, le trafic passe par la pile du pare-feu. Il s’agit ici de vérifier si une règle de pare-feu correspondante existe et si le trafic est même autorisé. Si le trafic est par exemple contrôlé par IPS, il passe encore par le moteur DPI. Si le moteur IPS décide que le trafic n’est pas dangereux, il est transféré sur le FastPath et acheminé directement via le noyau.

En regardant ce graphique, j’ai voulu tester en pratique comment cela fonctionnait exactement. On sait assez rapidement si le trafic est autorisé ou non et ce processus ne doit plus être vérifié pour chaque paquet provenant de cette source et de ce port. Mais comment le système dans le moteur DPI sait-il quand le trafic peut être transféré sur le FastPath ? Par exemple, si le balayage SSL/TSL est activé, cela ne fonctionne pas. Sinon, le trafic ne serait plus contrôlé. En revanche, dans le cas de l’IPS ou du contrôle des applications, on travaille avec des listes connues et on peut ainsi décider si le trafic est inoffensif ou non.

Analyse du renseignement sur les menaces

Si tu as une licence pour le module Sophos Sandstrom de ton pare-feu, les fichiers sont contrôlés dans une sandbox selon certains critères avant d’être téléchargés. Si tu veux en savoir plus sur Sophos Sandstorm, tu peux aussi consulter le PDF de la FAQ Sophos Sandstorm. Grâce à l’inspection SSL/TLS, le pare-feu voit davantage de trafic et peut examiner les téléchargements web de plus près. En dernier recours, la protection des systèmes d’extrémité serait toujours disponible pour stopper une menace.

Avec la v18, l’analyse des renseignements sur les menaces vient s’ajouter à Sandstorm. Pendant que Sophos Sandstorm contrôle les téléchargements Web ou les pièces jointes des courriels, Threat Intelligence vérifie les fichiers à l’aide de l’apprentissage automatique. C’est là qu’intervient l’analyse des SophosLabs, qui est utilisée dans Sophos Intercept X avec EDR.

Comme le fait EDR, on établit ensuite un rapport détaillé pour l’analyse. Pour Sophos Firewall avec SFOS v18 EAP2, un tel rapport se présente comme suit :

Le rapport un peu plus joli n’est disponible qu’à partir de l’EAP3.

Enterprise NAT

Outre l’architecture xStream, les règles NAT ont également subi d’importantes modifications. Jusqu’à la version 17.5, il y avait un point de menu « Pare-feu » et toutes les règles de pare-feu, de NAT et de WAF y étaient listées. Dans une règle de pare-feu, il était alors possible de définir, entre autres, l’interface / IP sortante pour le trafic.

Nouveauté de la v18, les règles NAT sont listées dans un TAB séparé.

Cela a pour conséquence qu’en mettant à jour la v17.5 à la v18, les règles NAT sont migrées. Cela semble tout d’abord un peu désagréable, car pour chaque règle de pare-feu pour laquelle « NAT & routing » était activé, une règle « linked NAT Rule » est créée. Ces quelques règles NAT créées automatiquement peuvent toutefois être remplacées assez rapidement.

Désormais, il n’y a plus seulement une règle de pare-feu qui fait également du NAT. Il y a une règle NAT et pour cela, il faut une règle de pare-feu qui autorise également le trafic. Mais cette transformation était nécessaire, car la NAT en SFOS (Network Address Translation) est désormais beaucoup plus flexible.

Ce que certains clients attendaient, c’est par exemple la possibilité d’interdire toutes les requêtes DNS ou NTP sur les serveurs publics, ou de les rediriger vers un serveur interne. C’est donc aussi la solution pour ceux qui manquent encore sur XG le serveur NTP qui était encore présent sur l’UTM.

Le thème de la TAO est également expliqué ici dans une vidéo :

Gestion des règles de pare-feu

De version majeure en version majeure, la gestion des règles de pare-feu s’améliore légèrement. Il est désormais possible de sélectionner plusieurs règles de pare-feu pour les supprimer, les activer/désactiver ou les ajouter à un groupe ou les en retirer. De plus, les règles de pare-feu sont désormais numérotées afin que l’on sache combien il y en a. L’ID de la règle reste toutefois le même. Par ailleurs, l’élément de menu « Firewall » a également été renommé « Rules and policies ».

Il est désormais possible d’ajouter des filtres, ce qui simplifie considérablement la recherche de certaines règles. Le filtre reste même si l’on passe à un autre point du menu et inversement.

Pour ceux qui pensent que Sophos va éventuellement laisser les groupes de pare-feu ouverts après l’enregistrement d’une règle, je dois malheureusement les décevoir. Rien n’a changé à ce sujet. 😖

Une fonction souvent demandée est enfin disponible. Le compteur du trafic traité par une règle de pare-feu peut être remis à zéro.

Lorsque l’on crée une nouvelle règle de pare-feu, il est désormais possible de la désactiver immédiatement.

Il est désormais possible de définir des exclusions dans une règle de pare-feu. Cela aide énormément à ne pas alourdir inutilement toute la structure des règles.

Visionneuse de journaux

Ceux qui ont lu l’article 7 raisons pour lesquelles le pare-feu XG (SFOS) est meilleur que l’UTM savent à quel point la visionneuse de logs est utile. Dans la nouvelle version, l’outil reçoit également quelques nouvelles fonctions utiles.

En cliquant sur une entrée dans le Log Viewer, il est possible de définir immédiatement un filtre, de définir des exceptions SSL/TSL ou de modifier les directives IPS, Application Control ou Webfilter.

Alertes et notifications

Sous « Administration » > « Notifications settings », on pouvait tout juste activer deux options pour une notification par e-mail :

• Tunnel IPsec haut/bas
• Notifications d’alerte par e-mail

Si un RED n’était pas accessible ou si un utilisateur saisissait trop souvent un mot de passe erroné, il n’y avait jusqu’à présent aucune possibilité d’en être averti.

Sous la v18, la liste se trouve désormais dans le menu sous « System Services » > « Notification list ». Il y a ici dès à présent 36 actions pour lesquelles on peut être averti par e-mail ou SNMP.

Surveillance des flux

Actuellement, on ne voit pas vraiment grand-chose sur le pare-feu en ce qui concerne les connexions en direct et les données ne sont pas non plus en temps réel. De plus, il n’est pas présenté de manière très attrayante à mon avis. Avec la v18, il y a maintenant une vue géniale qui affiche les IP actives, les utilisateurs et les applications avec l’utilisation correspondante de la bande passante en temps réel. Il est également possible de bloquer des connexions ou de leur donner la même priorité.

Je ne peux pas tester cette fonction moi-même, car elle ne sera prête qu’avec EAP3. Mais ce que j’ai vu jusqu’à présent est très bien mis en œuvre ! 😍

Routage des politiques SD-WAN

Avant d’en dire plus sur le SD-WAN Policy Routing, une remarque tout d’abord : l’élément de menu a été rebaptisé v18 :

• v17.5 : Routage > Policy routing
• v18.0 : Routage > Routage de la politique SD-WAN

Mais en dehors de cela, il est désormais possible de créer un routage sur la base de davantage de critères. Si vous souhaitez, par exemple, router un utilisateur, un groupe ou une application via une autre interface, vous pouvez maintenant le faire. De nombreuses applications sont reconnues grâce à la Synchronized Security et au Synchronized Application Control.

Email Protection – DKIM & BATV

Pour la lutte contre le spam, les deux solutions de protection contre le spam suivantes sont désormais également prises en charge :

• DKIM (DomainKeys Identified Mail)
• BATV (validation des balises d’adresse de rebond)

Support DDNS

• Il n’est plus nécessaire de définir la fréquence de mise à jour de l’IP WAN. La valeur est maintenant fixée à 5 minutes.
• Le service Sophos, qui posait quelques problèmes dans le passé, a été remplacé par une solution OpenSource.
• Le nombre de fournisseurs de DDNS a doublé, passant de 5 à 10. Les nouveaux venus sont : DNS-O-Static, FreeDNS, Google DNS, Namecheap, No-IP

Petites rénovations / améliorations

• Améliorations de la haute disponibilité (HA): Les appliances peuvent désormais être reliées plus rapidement et plus facilement en un cluster. Il est également possible d’effectuer un rollback du firmware.
• Support de SNMPv3: meilleure sécurité par rapport à SNMPv1 et SNMPv2, si tant est que l’on puisse parler de « sécurité » dans les deux premières versions. Le fichier MIB est bien sûr disponible en téléchargement.
• Changement de nom des interfaces: les interfaces étaient auparavant nommées Port1, Port2, etc. et cela ne pouvait pas être modifié. C’est désormais possible dans la v18. Mais il n’est malheureusement toujours pas possible de personnaliser IPsec, IPS, les réseaux sans fil, etc.
• Mises à jour de la base de données GeoIP: la base de données IP des pays peut désormais être mise à jour indépendamment des mises à jour du firmware.
• Mise à niveau des outils VMware: les outils VMware sont désormais préinstallés dans la version v10.3.10 et le Site Recovery Manager (SRM) est également pris en charge.

Mise à niveau vers SFOS v18

Conditions préalables

Tu es maintenant très excité et tu as hâte de passer à la v18 ? Si tu as déjà un pare-feu XG ou même un SG avec SFOS, tu dois avoir la version v17.5 MR6 ou supérieure pour pouvoir mettre à jour vers la v18. Un retour en arrière est bien entendu pris en charge comme toujours. Si quelque chose ne fonctionne pas pour vous avec la v18, vous pouvez revenir à la version précédente.

SG à XG

Si tu as encore un pare-feu UTM, tu peux également passer au SFOS. Nous avons rédigé des instructions à ce sujet : Installation de Sophos XG Firewall OS sur une SG Appliance

Si tu as besoin d’aide pour la migration, n’hésite pas à nous contacter. Nous avons déjà retiré un grand nombre d’UTM de la circulation. 😎

XG 85 et XG 105

Pour que la v18 puisse être installée, il faut au moins 4 Go de RAM. Par conséquent, la future version de SFOS ne pourra pas non plus être exécutée sur un pare-feu XG 85 ou XG 105. Ceux qui misent sur leur propre matériel et y ont encore installé 2 Go de RAM sont confrontés au même problème. Cyberoam n’est d’ailleurs plus pris en charge.

Les propriétaires d’un XG 85 ou d’un XG 105 devraient jeter un coup d’oeil aux modèles suivants : Sophos XG 86 et XG 106. En ce moment, une promotion de Sophos est encore en cours jusqu’au 30.09.2020, où vous pouvez économiser 50 % sur le nouveau matériel lors du renouvellement.

Rapports et gestion Sophos Central Firewall

J’ai rédigé un blog post séparé sur ce sujet : Gestion de Sophos Central Firewall – Fonctionnalités avec SFOS v18

FAQ

Plus d’informations

• Le pare-feu XG : Quoi de neuf dans la v18