Comprendre et exploiter Sophos Firewall Zero-Day Protection

Sophos Firewall Zero-Day Protection analyse les téléchargements suspects et les pièces jointes aux e-mails via SophosLabs Intelix. Le pare-feu envoie les fichiers appropriés et risqués au service cloud, où l’apprentissage automatique, la réputation, l’analyse sandbox et la recherche sur les menaces fonctionnent ensemble. L’objectif n’est pas seulement de bloquer les malwares connus, mais aussi de mieux classer les fichiers nouveaux ou inhabituels.

Pour les administrateurs, la distinction est importante : Zero-Day Protection ne remplace pas des règles bien définies, Web Protection, Mail Protection, TLS Inspection, la journalisation ou la protection des terminaux. Cette fonction ajoute une couche de protection et d’analyse, particulièrement utile lorsque les fichiers entrent sur le réseau par des téléchargements Web ou des pièces jointes et que les signatures classiques ne permettent pas encore une évaluation claire.

Quel article de protection convient ?

Zero-Day Protection explique surtout comment les fichiers suspects sont analysés. Selon le problème, il peut être préférable de commencer par l’accès Web, le flux de messagerie, les attaques réseau, le trafic chiffré ou l’analyse des événements :

• Vérifier les téléchargements suspects ou les pièces jointes avec Intelix : cet article.
• Configurer et tester l’analyse antimalware web classique avec Single ou Dual Engine : Configurer et tester l’analyse antimalware de Sophos Firewall.
• Planifier les catégories Web, les groupes d’URL, SafeSearch ou les règles de téléchargement : Configurer Web Protection avec des politiques Web sur Sophos Firewall.
• Rendre le trafic HTTPS visible et planifier les exceptions : Déployer correctement TLS Inspection sur Sophos Firewall.
• Distribuer le certificat CA pour l’analyse HTTPS aux clients : Sophos Firewall Installer le certificat CA pour l’analyse HTTPS.
• Vérifier le trafic de messagerie en mode MTA et exploiter Mail Protection : Configurer Mail Protection en mode MTA sur Sophos Firewall.
• Bloquer les exploits et les modèles d’attaque dans le trafic réseau : Sophos Firewall Configurez IPS et testez-le en toute sécurité.
• Gérer les adresses IP, domaines ou URL malveillants via les listes IoC : Sophos Firewall Configurer des flux de menaces et les exploiter en toute sécurité.
• Comprendre NDR, Active Threat Response, XDR, MDR et l’analyse SIEM : Exploiter NDR et Active Threat Response sur Sophos Firewall.
• Comprendre les rejets ou blocages inattendus : Analyser les paquets rejetés par Sophos Firewall.

Cette distinction évite les fausses attentes : Zero-Day Protection évalue les fichiers, mais ne remplace ni une politique Web, ni un IPS, ni la planification des relais de messagerie, ni l’analyse centralisée des journaux. La protection est la plus efficace lorsque les couches fichiers, Web, messagerie, réseau et journalisation fonctionnent ensemble.

Où Zero-Day Protection aide dans la pratique

Zero-Day Protection est particulièrement pertinent dans ces scénarios :

• Les utilisateurs téléchargent des fichiers exécutables, des archives ou des documents depuis Internet.
• Les pièces jointes des e-mails doivent être vérifiées plus attentivement avant leur livraison ou leur libération.
• Un fichier est encore mal connu, mais semble suspect.
• Un téléchargement doit non seulement être analysé localement, mais également surveillé dans un bac à sable.
• Un incident de sécurité doit être mieux évalué à l’aide d’un rapport détaillé.

La fonctionnalité s’intègre dans un modèle de sécurité à plusieurs niveaux : les règles de pare-feu limitent le trafic autorisé, TLS Inspection permet d’inspecter le trafic Web chiffré, Web Protection et Mail Protection évaluent le contenu, et Zero-Day Protection complète ces contrôles par l’analyse cloud et les rapports sandbox.

Exigences et limites dans SFOS 22

Zero-Day Protection exige une souscription dédiée, incluse dans Xstream Protection ; Base License ou Web Protection seules ne suffisent pas. Dans Administration > Licensing, l’état doit être Subscribed ou Evaluating (évaluation de 30 jours). Elle couvre Machine Learning, Sandboxing File Analysis et Threat Intelligence. Le service n’est pas pris en charge en déploiement air gap, car la connexion cloud manque. Un firewall connecté à Internet synchronise automatiquement les licences toutes les 24 heures. Si une souscription Zero-Day récemment modifiée semble encore obsolète, attendez ce cycle ou déclenchez la synchronisation des licences avant de dépanner le chemin de policy.

Les modules de protection et les policies du chemin de données concerné doivent également être actifs. Une simple règle Allow sans profils de sécurité adaptés n’offre pas la même protection. Pour les téléchargements web, Single engine exige Sophos comme moteur antivirus principal ; l’alternative est Dual engine. La même exigence s’applique dans la SMTP Route and Scan Policy lorsque Single antivirus est sélectionné. Ces réglages se trouvent sous Web > General settings et dans la policy SMTP correspondante sous Email > Policies and exceptions.

Limites importantes en fonctionnement :

• Le pare-feu n’envoie pas tous les types de fichiers à Intelix, mais principalement les types de fichiers à risque.
• De nombreux types de fichiers non dangereux, par exemple les formats d’image typiques, ne sont pas envoyés pour détonation.
• Des exceptions peuvent exclure des fichiers de l’analyse et ainsi réduire l’effet protecteur.
• L’analyse cloud nécessite une connectivité aux services Sophos et peut retarder les téléchargements.
• Le pare-feu a besoin d’un accès TCP 443 sortant à *.sandbox.sophos.com ; TLS interception ou un upstream proxy ne doivent pas interrompre cette connexion.
• La libération avant la fin de l’analyse peut exposer du contenu malveillant.
• Zero-Day Protection ne remplace ni Endpoint Detection and Response, ni MDR, ni un processus de réponse aux incidents rigoureux.

Si le pare-feu voit peu de choses parce que HTTPS n’est pas déchiffré ou que les règles s’exécutent sans profils de sécurité, Zero-Day Protection reste également restreint. L’article Sophos Firewall Journaux : quelle fonction écrit dans quel journal ? aide à l’affectation des journaux et des modules.

Activer dans les règles firewall

Pour les téléchargements Web, il ne suffit pas que Zero-Day Protection soit généralement licencié. La règle firewall concernée doit réellement matcher le trafic Web et activer les options de Web scanning nécessaires.

Le chemin typique est le suivant :

Rules and policies > Firewall rules

Dans la règle client-Internet concernée, vérifier :

1. Source zone, Source network, Destination zone et Services matchent le trafic de test.
2. Log firewall traffic est actif.
3. Dans la section Web filtering, une Web Policy adaptée est sélectionnée.
4. Scan HTTP and decrypted HTTPS est actif.
5. Use zero-day protection est actif.
6. Pour les téléchargements HTTPS, TLS Inspection est planifiée et effective pour le trafic de test.
7. QUIC/HTTP/3 ne contourne pas le chemin d’inspection HTTPS attendu.
8. Les Web Exceptions n’excluent pas involontairement l’analyse des malwares, les contrôles de politiques ou l’analyse Zero-Day Protection.

Cela ne garantit pas encore que chaque téléchargement apparaisse dans la vue Zero-Day Protection. Des fichiers connus, des types de fichiers non critiques ou des téléchargements hors du chemin inspecté peuvent être évalués autrement auparavant. Pour l’acceptation, il ne faut donc pas seulement vérifier si la case est active, mais si un téléchargement concret est traçable dans Log Viewer, Web log, SSL/TLS inspection log et Downloads and attachments.

Important : Scan HTTP and decrypted HTTPS scanne HTTP et le trafic HTTPS déjà déchiffré. L’option n’active pas automatiquement le déchiffrement HTTPS. Dans les setups DPI, il faut pour cela des Rules and policies > SSL/TLS inspection rules adaptées ; dans le chemin Web Proxy, Decrypt HTTPS during web proxy filtering est pertinent. Sans cette visibilité, Zero-Day Protection voit moins de choses pour les téléchargements chiffrés, même si la règle firewall semble formellement correcte.

Où Zero-Day Protection prend effet

Zero-Day Protection ne doit pas être considéré isolément. La fonction ne devient pertinente que si un fichier passe effectivement par un chemin de protection approprié.

Chemins typiques :

• Téléchargement Web : la règle firewall adaptée, Web Protection, Scan HTTP and decrypted HTTPS, Use zero-day protection et souvent TLS Inspection pour HTTPS doivent intervenir au préalable. Les contrôles se font dans le Web log, le SSL/TLS inspection log et la vue Downloads and attachments.
• Pièce jointe à un e-mail : Le flux de courrier doit passer par la protection du courrier, une politique de pièce jointe appropriée et une vérification des logiciels malveillants. Vous pouvez contrôler les journaux de courrier, la quarantaine et l’affichage des téléchargements et des pièces jointes.
• Téléchargement FTP : Scan FTP for malware active l’analyse antivirus, mais pas l’analyse cloud Zero-Day. Dans SFOS 22, Use zero-day protection est explicitement limité aux téléchargements HTTP et HTTPS.
• Libération ou statut d’erreur : Le rapport n’est pas encore terminé ou l’analyse a échoué. Le processus de libération, le contexte utilisateur, le hash et les autres journaux sont alors importants.
• Aucune visibilité : Le trafic ne passe pas par le chemin de protection ou le type de fichier n’est pas pertinent. Vérifiez ensuite d’abord la règle de pare-feu, la politique, TLS, le flux de messagerie et le type de fichier.

Pour les téléchargements Web, vérifiez d’abord que la bonne politique Web est active dans la règle de pare-feu. Pour les pièces jointes, le flux de messagerie doit réellement passer par Mail Protection en mode MTA ou un chemin vérifié équivalent. Une simple règle Allow ne suffit pas à garantir une analyse complète des fichiers par Zero-Day Protection.

Les Web Exceptions exigent une prudence particulière. Une exception peut, en mode DPI comme en mode Proxy, faire sauter Decryption, Malware and content scanning, Zero-Day Protection ou Policy Checks pour le trafic correspondant. Les exceptions doivent donc être plus étroites que la règle de protection elle-même et être vérifiées avec Log Viewer, SSL/TLS inspection log et un téléchargement réel.

Activer pour les pièces jointes aux e-mails

En mode MTA, accédez à Email > Policies and exceptions > SMTP route and scan. Modifiez la policy qui correspond réellement à l’expéditeur, au destinataire et au domaine protégé, puis ouvrez Malware protection :

1. Activez Malware protection.
2. Sous Scanning, choisissez Single antivirus avec Sophos comme moteur principal, ou Dual antivirus. Sur XGS 87/87w et 88/88w, seul le moteur principal est disponible.
3. Activez Use zero-day protection.
4. Définissez la taille maximale du fichier dans le champ associé. Il s’agit d’une limite de policy choisie par l’administrateur, et non d’une valeur universelle : les pièces jointes plus volumineuses ne sont pas envoyées à Zero-Day Protection.
5. Enregistrez la policy et vérifiez son ordre afin qu’une policy plus large ne corresponde pas en premier.

Choisissez cette limite selon le profil de messagerie réel, la bande passante et le délai acceptable. Commencez, par exemple, par la limite de pièces jointes déjà autorisée dans l’organisation plutôt que de copier une valeur externe. Vérifiez ensuite une pièce jointe de test autorisée par heure, expéditeur et destinataire dans Email > Mail logs, Email > Mail spool et Monitor & analyze > Zero-day protection > Downloads and attachments. Un élément du spool à l’état Zero-day protection attend l’analyse. SFOS retente la livraison pendant trois jours et supprime le message après quatre jours supplémentaires ; les messages supprimés restent visibles dans les mail logs.

Flux d’analyse

1. Détection sur le pare-feu

Un fichier passe à travers le pare-feu via un téléchargement ou sous forme de pièce jointe à un e-mail. Si la politique, le type de fichier et le contexte correspondent, le fichier est marqué pour Zero-Day Protection. Les fichiers connus et clairement classifiés peuvent être évalués au préalable par d’autres modules de protection.

2. Remise à SophosLabs Intelix

Les fichiers éligibles sont envoyés à un service Intelix SophosLabs via une connexion cryptée. Là, le fichier est non seulement vérifié par rapport à des modèles connus, mais est également évalué à l’aide de plusieurs niveaux d’analyse.

3. Apprentissage automatique et réputation

SophosLabs Intelix utilise plusieurs modèles d’apprentissage automatique pour évaluer les caractéristiques, la structure, la réputation globale et la « génétique » d’un fichier, c’est-à-dire ses similitudes avec d’autres fichiers. Les nouveaux fichiers sont comparés à des millions de fichiers connus, sains ou malveillants. Cela est particulièrement utile pour les nouveaux fichiers qui n’ont pas encore été largement observés.

4. Analyse du bac à sable

L’analyse Sandbox examine le fichier dans un environnement isolé. L’évaluation combine l’analyse dynamique et statique, l’apprentissage en profondeur, la détection d’exploits, CryptoGuard et la surveillance des activités sur les fichiers, la mémoire vive, le registre et le réseau. CryptoGuard détecte en temps réel les ransomwares actifs qui chiffrent des fichiers à l’intérieur de la sandbox ; cela ne garantit pas que le chiffrement sera empêché sur les terminaux en production. L’analyse surveille également les techniques utilisées par un fichier pour tenter d’échapper à la détection de la sandbox. Pour les administrateurs, le terme marketing est moins important que la question : qu’a réellement tenté de faire le fichier ?

5. Décision et rapport

L’analyse aboutit à une classification, par exemple sain, probablement sain, suspect, malveillant ou PUA. Selon le résultat, le fichier est libéré, bloqué ou reste visible avec un état d’erreur ou d’analyse. Le rapport permet de justifier une libération, un blocage ou d’autres mesures de réponse à un incident.

Lire correctement les rapports

L’aperçu se trouve dans Sophos Firewall sous Monitor & analyze > Zero-day protection > Downloads and attachments. Il affiche les données d’activité sur les téléchargements suspects et les pièces jointes aux e-mails, l’état de l’analyse, les détails du rapport et les options de libération.

Dans la liste, il ne faut pas seulement chercher le nom du fichier. Les filtres par période, utilisateur, source, statut et composant sont utiles. Techniquement, les événements Zero-Day Protection apparaissent dans les rapports et Syslog comme un Log Type propre ; selon le chemin, le composant est Web ou Mail, et les subtypes peuvent être Allowed, Denied ou Pending. Cela rend la corrélation avec SIEM ou Central Reporting plus propre.

Lorsque l’on survole le Detection Status d’une entrée avec le pointeur de la souris, une vue succincte affiche les résultats relatifs aux menaces à chaque étape de l’analyse. View report permet d’ouvrir le rapport complet. On peut également sélectionner More options > Show report pour l’entrée afin d’ouvrir les détails de l’analyse, plutôt que de lire uniquement l’entrée de liste. En particulier avec Pending, un statut d’erreur ou une autorisation ultérieure, le rapport détaillé constitue la base de la décision.

Pour restreindre la liste, sélectionnez Filter et définissez les critères souhaités.

Un rapport peut contenir, entre autres, les domaines suivants :

• Download details: source, moment et utilisateur concerné.
• Analysis summary: évaluation globale et aperçu ; les classifications sont clean, likely clean, suspicious, malicious ou Potentially Unwanted Application (PUA).
• Machine learning analysis: résultat global de l’apprentissage automatique, ainsi qu’analyse des caractéristiques individuelles du fichier, de leurs combinaisons et de la structure du fichier.
• Reputation analysis: évaluation basée sur la distribution mondiale.
• Detonation results: comportement du fichier lors de l’exécution dans la sandbox, captures d’écran du fichier en cours d’exécution, détails des processus utilisés et activités générées dans le registre. Ces artefacts permettent d’examiner le comportement suspect de manière traçable.
• Full file analysis: signatures, certificats, ressources, importations et exportations.
• VirusTotal report: informations complémentaires sur la détection externe. Les données indiquent combien de rapports concernant la menace en question figurent dans la base de données VirusTotal et combien de produits de détection de logiciels malveillants détectent le fichier. Ces deux chiffres décrivent des éléments distincts : les rapports existants et les produits qui détectent le fichier.

Lorsqu’il s’agit d’un fichier suspect, vous ne devez pas vous contenter de regarder son statut final. La source, l’utilisateur, le nom du fichier, l’URL cible, le comportement du processus, l’activité du réseau et si d’autres systèmes ont vu le même téléchargement sont également pertinents. Si cela entraîne un incident, le rapport doit être fusionné avec les journaux des points finaux, de la messagerie, du Web et du pare-feu.

Processus pour les rapports suspects

Une détection de Zero-Day Protection doit être traitée comme un dossier de sécurité, pas comme un simple blocage du filtre Web.

Processus pratique :

1. Ouvrez le rapport et enregistrez l’état, le nom du fichier, la source, l’utilisateur, l’heure et la note.
2. Vérifiez s’il s’agit d’un téléchargement Web, d’une pièce jointe à un e-mail ou d’un autre chemin.
3. Comparez les journaux Web, de messagerie et de pare-feu pour la même période.
4. Le cas échéant, vérifiez les événements de point de terminaison ou EDR pour le client concerné.
5. Documentez le hash du fichier, l’expéditeur, l’URL ou le domaine.
6. Décidez s’il s’agit d’un faux positif, d’une attaque bloquée, d’un soupçon non résolu ou d’un incident.
7. N’envisagez la libération que s’il existe une raison métier justifiable.
8. Documentez la décision et, si nécessaire, définissez une action sur un URL Group, une politique de messagerie, un Threat Feed ou une mesure de protection des terminaux.

Lorsque plusieurs utilisateurs voient le même fichier ou domaine, une seule décision ne suffit souvent pas. Vous devez ensuite vérifier si un ajustement de la politique Web, une règle de politique de messagerie, une entrée dans le flux de menaces ou une réponse à un incident est nécessaire.

Libérer des fichiers

Sophos Firewall permet une libération uniquement pour les fichiers ou messages e-mail qui sont encore en cours d’analyse ou qui sont revenus avec un statut d’erreur. Une telle libération peut être nécessaire si un processus métier est bloqué. Comme workaround normal, elle est toutefois inadaptée.

Avant de libérer un fichier, vérifiez au moins :

• La source est-elle fiable et attendue ?
• L’utilisateur ou le service a-t-il été consulté sur le contexte ?
• Existe-t-il un hachage, un nom de fichier ou un expéditeur qui peut être vérifié en plus ?
• Existe-t-il des journaux de points de terminaison ou de messagerie pour le même processus ?
• Le fichier peut-il être examiné dans un environnement isolé ou avec un outil d’analyse distinct ?
• A-t-on documenté qui a décidé de le libérer et pour quelle raison ?

⚠️ Une libération avant la fin de l’analyse peut entraîner le téléchargement ou la diffusion de contenu malveillant. Dans les environnements de production, cette décision doit être documentée et ne pas être déléguée à une routine de premier niveau.

Si la libération a été explicitement approuvée après ces vérifications, sélectionnez Release now pour l’entrée concernée. Dans le cas d’un fichier, les utilisateurs peuvent le télécharger immédiatement après ; le clic n’attend pas le résultat de l’analyse.

Après une libération, l’analyse continue. C’est important pour l’exploitation : un fichier libéré peut ensuite tout de même être évalué comme suspect ou malveillant. Les libérations doivent donc être contrôlées a posteriori et, en cas d’évaluation négative ultérieure, les logs Endpoint, Mail, Web et Firewall doivent être rapprochés à nouveau.

Pour les fichiers individuels, le billet de blog Avanet SophosLabs Intelix - L’outil de détection des cybermenaces peut vous aider. Cependant, cela ne remplace pas l’évaluation dans le contexte spécifique du réseau et de l’utilisateur.

Centre de données et protection des données

Vous pouvez spécifier le centre de données pour l’analyse sous Monitor & analyze > Zero-day protection > Protection settings. Par défaut, Sophos Firewall choisit le centre de données le plus proche. Vous pouvez également choisir consciemment un centre de données. Les fichiers sont transférés vers le cloud Sophos via une connexion SSL sécurisée.

Ce réglage est important pour la confidentialité, la résidence des données et les exigences internes. Un changement de datacenter peut entraîner la perte de l’analyse des fichiers en cours de traitement. Avant le changement, documentez les entrées ouvertes et choisissez une fenêtre de maintenance calme ; ensuite, vérifiez la connectivité et les nouvelles analyses. Le choix de la région ne règle pas à lui seul toutes les questions de confidentialité : la conservation, les accords de traitement et les contenus autorisés doivent aussi être évalués.

Utilisez les exceptions avec précaution

Sous Monitor & analyze > Zero-day protection > Protection settings, vous pouvez exclure des types de fichiers de l’analyse de la protection Zero Day. Pour cela, sous Exclude file types > Add new item, sélectionnez le type de fichier souhaité dans la liste. La détection du type de fichier repose sur l’extension du fichier et l’en-tête MIME. Si une archive contient un fichier d’un type exclu, l’ensemble de l’archive est automatiquement exclu de l’analyse de la protection Zero Day, même si elle contient également des fichiers de types non exclus. Une exception de type de fichier s’applique donc aussi aux archives à contenu mixte ; leur contenu restant n’est pas protégé par cette analyse de la protection Zero Day. Ce paramètre est à distinguer de l’exception Web décrite plus bas.

Les exceptions sont techniquement pratiques, mais importantes pour la sécurité. Chaque exception doit être clairement justifiée :

• Quelle application ou quel processus crée les fichiers ?
• Pourquoi l’analyse perturbe-t-elle le processus ou n’est-elle pas utile ?
• Existe-t-il une exception plus étroite qu’un type de fichier entier ?
• L’exception est-elle vérifiée régulièrement ?
• Sait-on quel effet protecteur est perdu en conséquence ?

Les exceptions générales concernant les archives, les scripts, les fichiers Office ou les fichiers exécutables doivent être évitées. Lorsque Zero-Day Protection perturbe un processus légitime, la première étape consiste souvent à vérifier la stratégie, le chemin source, le groupe d’utilisateurs concerné ou une mise à disposition alternative.

Pour une exception Web, accédez à Web > Exceptions > Add an exception. Les critères de types différents sont combinés par ET, et plusieurs valeurs d’un même type par OU. Pour HTTPS, les motifs de chemin URL ne correspondent que si le trafic est déchiffré ; sans déchiffrement, utilisez donc le nom d’hôte. Ignorer Malware and content scanning ignore automatiquement Zero-Day Protection. Si seule Zero-day protection est ignorée, les rapports d’analyse des fichiers concernés ne sont pas générés, même lorsque l’analyse antimalware détecte une menace. Il s’agit d’un changement d’état persistant : limitez l’exception à un nom d’hôte ou motif d’URL, sélectionnez Save, activez son commutateur et documentez le responsable et la date d’expiration. Pour revenir en arrière, désactivez ou supprimez l’exception et revalidez le même chemin de données.

API XML : modifier les paramètres de protection en toute sécurité

Dans le cadre de l’automatisation, l’objet XML ZeroDayProtectionSettings correspond aux paramètres sous Monitor & analyze > Zero-day protection > Protection settings : DataCenterLocation désigne le centre de données utilisé pour l’analyse, et ExcludeFileTypes les types de fichiers exclus, et non les Web Exceptions. La référence XML pour SFOS 22/23 décrit ces deux champs comme des valeurs scalaires STRING facultatives et laisse les colonnes des valeurs par défaut vides. Cela n’indique ni une valeur par défaut XML documentée, ni que l’omission d’un champ ou une valeur vide conserve ou supprime les paramètres existants. Avant toute modification, lisez l’état enregistré et sauvegardez les valeurs précédentes pour permettre un retour arrière ciblé ; vérifiez les valeurs de la requête à l’aide de la référence de la version installée.

Les codes de statut de cette opération de mise à jour figurent dans le résultat XML et ne doivent pas être confondus avec le statut du transport HTTP. La référence leur associe les identifiants de message suivants, qui sont des clés de message source et non le texte affiché des messages :

• 200 : Language.SandboxSettingsUpdateSuccess (mise à jour réussie).
• 500 : Language.SandboxSettingsUpdateFailed (échec de la mise à jour).
• 502 : Language.SandboxSettingsFileTypesExceeded (limite de types de fichiers dépassée), et non, de manière générique, « nom déjà existant ». Cette référence ne précise aucun maximum numérique.

En cas de 500, de 502 ou de réponse ambiguë, ne déclenchez aucune répétition automatique de la requête d’écriture. Commencez par relire l’état effectivement enregistré et comparez-le aux valeurs sauvegardées ainsi qu’aux valeurs prévues. En cas de 502, vérifiez les exclusions de types de fichiers demandées et les choix autorisés pour la version installée, plutôt que de renommer des objets ou de deviner une limite. Même après un 200, contrôlez le centre de données et les exclusions dans Protection settings, puis vérifiez la connectivité ainsi qu’un téléchargement autorisé ou une pièce jointe de test autorisée d’un type de fichier éligible et non exclu, à l’aide des journaux et de Downloads and attachments. Si un retour arrière est nécessaire, restaurez uniquement les paramètres modifiés aux valeurs sauvegardées auparavant et répétez les mêmes contrôles, sans désactiver globalement la protection. En cas de changement de centre de données, la fenêtre de maintenance et le risque de perte des analyses en cours décrits ci-dessus s’appliquent également au retour arrière ; celui-ci ne restaure pas les analyses déjà perdues.

Annuler une modification en toute sécurité

Une annulation doit restaurer le chemin de données précédent, et non désactiver précipitamment toutes les couches de protection :

1. Documentez les anciennes valeurs de règle, policy, moteur, limite de taille, data center et exception.
2. En cas de problème web, désactivez d’abord la nouvelle exception ciblée ou restaurez l’ordre des règles. N’annulez Scan HTTP and decrypted HTTPS et TLS Inspection que si cette modification précise a causé le problème et si la protection réduite est acceptée.
3. En cas de problème de messagerie, restaurez les anciennes valeurs de la SMTP Route and Scan Policy modifiée ; ne libérez pas aveuglément les messages en attente. Release now rend immédiatement disponible un fichier non vérifié, même si l’analyse continue.
4. Après l’annulation, vérifiez la correspondance de la règle, le log web ou mail et un téléchargement ou une pièce jointe de test autorisé. Si *.sandbox.sophos.com:443 reste inaccessible ou si les nouveaux objets restent Pending, l’annulation n’a pas réussi.

Vérifier régulièrement les libérations et les exceptions

Zero-Day Protection n’est pas une fonction à activer une seule fois. Sa valeur opérationnelle apparaît lorsque les rapports, les libérations et les exceptions sont vérifiés régulièrement. Dans le cas contraire, les décisions risquées restent actives longtemps après la disparition de la raison métier initiale.

Ces points sont particulièrement utiles pour la révision :

• Fichier libéré : Vérifiez le motif de la libération, l’utilisateur ou le service concerné, le hash, la source du fichier, la date d’expiration et l’évaluation ultérieure.
• Exception de type de fichier : Vérifiez l’application concernée, le responsable, la date de révision, une alternative plus ciblée et le risque pour les archives, les scripts ou les fichiers Office.
• Statut d’erreur récurrente : Vérifiez la connectivité Sophos, la taille du fichier, le type de fichier, la politique, le centre de données et l’éventuel cas de support.
• De nombreuses détections provenant d’une même source : Vérifiez la politique Web ou de messagerie, l’URL, l’expéditeur, le groupe d’utilisateurs, le Threat Feed, l’URL Group ou la liste de blocage.

Une exception ne relève pas d’un simple nettoyage des règles de pare-feu. Ces entrées doivent avoir un responsable, un motif et une date de révision. En cas de libérations récurrentes, comparez aussi les journaux des terminaux, de la messagerie, du Web et du pare-feu afin qu’une exception ponctuelle ne devienne pas un contournement permanent inaperçu.

Dépannage

Aucune entrée visible

Si aucune entrée n’apparaît sous Downloads and attachments, vérifier d’abord si le trafic passe réellement par la règle firewall et le profil de sécurité adaptés. Pour les téléchargements Web, Scan HTTP and decrypted HTTPS et Use zero-day protection dans la règle firewall sont particulièrement importants. Pour le trafic HTTPS, l’absence de TLS Inspection peut expliquer pourquoi le firewall voit moins de contenu. Vérifier ensuite les paramètres Web, Mail, Malware et Zero-Day.

Vérifier aussi si une Web Exception exclut le trafic pertinent de Decryption, Malware and content scanning ou Zero-Day Protection. Si une exception s’applique, la configuration Zero-Day Protection peut sembler correcte et pourtant ne produire aucune entrée.

Pour les tests, il ne faut pas créer de fausses attentes avec des fichiers déjà connus localement ou globalement. Si Reputation ou d’autres modules de protection évaluent déjà clairement un fichier, une nouvelle analyse Sandbox complète n’est pas forcément visible. Pour les tests d’acceptation, fenêtre temporelle, client de test, Rule ID, URL, nom de fichier et hash sont plus importants qu’un seul téléchargement navigateur sans corrélation de logs.

Les téléchargements prennent trop de temps

Une analyse sandbox peut prendre du temps. Si les utilisateurs attendent régulièrement pendant de longues périodes, vous devez vérifier si de nombreux fichiers volumineux ou changeant fréquemment sont analysés, si les processus concernés sont légitimes et si une exception technique étroite est justifiable. Une désactivation globale n’est généralement pas une bonne première étape.

Beaucoup de faux positifs

En cas de faux positifs récurrents, vérifiez les détails du rapport, la source du fichier, les hachages, la réputation, les utilisateurs et l’application concernés. Ne définissez des exceptions qu’après avoir compris le schéma observé. Pour les listes de blocage dynamiques et la gestion des IoC, consultez Configurer et exploiter les Threat Feeds en toute sécurité sur Sophos Firewall.

Une libération a été demandée

Une libération doit être considérée comme une décision de sécurité. Si le service métier signale seulement « urgent », cela ne suffit pas. Il faut une source, un objectif, un fichier, un utilisateur, une évaluation des risques et une décision documentée.

L’analyse reste sur Pending ou se termine par Error

Vérifiez d’abord System services > Log settings : le Log Type Zero-day protection doit être sélectionné pour Local reporting, le serveur syslog voulu ou Central reporting. Contrôlez ensuite le DNS, le routage et l’accès TCP 443 sortant à *.sandbox.sophos.com ; une exception TLS générale pour le trafic utilisateur ne résout pas la connectivité du service. Pour la messagerie, Email > Mail spool affiche séparément les messages en attente. Si l’erreur se répète avec différents types de fichiers admissibles, relevez les horodatages, le hash, le composant, la Policy/Rule ID et l’état du rapport pour Sophos Support.

Consulter les Release Notes et Known Issues de SFOS 22

Utilisez le guide de mise à jour du firmware Sophos Firewall pour vérifier les Release Notes et Known Issues. Son instantané du 8 septembre 2026 indique 22.0 MR2 Build 546 comme version courante à cette date. SFOS 22 introduit un nouveau moteur antimalware Sophos avec des recherches de réputation globale et des détections AI/ML. Ce changement de moteur ne remplace ni la souscription Zero-Day dédiée ni les commutateurs de politique.

Avant une mise à niveau ou un déploiement général, suivez ce guide pour rechercher à nouveau dans les Release Notes et la Known Issues List Sophos Firewall, Zero-day, sandbox, email et la version cible, plutôt que de vous fier à un résultat antérieur. MR2 corrige notamment un problème de mail spool ; les installations qui analysent la messagerie doivent donc aussi examiner les correctifs Email, pas seulement les pages Zero-Day.

Liste de contrôle opérationnelle

• Licence et état du module Zero-Day Protection vérifiés.
• Politiques Web et de messagerie vérifiées pour l’analyse antimalware et les contrôles de sécurité.
• Dans les règles Web firewall, Scan HTTP and decrypted HTTPS et Use zero-day protection vérifiés.
• TLS Inspection ou déchiffrement par le proxy Web prévu là où les téléchargements Web chiffrés doivent être inspectés.
• Web Exceptions vérifiées pour éviter des contournements Zero-Day involontaires.
• Data center volontairement choisi pour analyse ou documenté en standard.
• Aucune exception générale de type de fichier sans propriétaire et date de révision.
• La vue des téléchargements et des pièces jointes est vérifiée régulièrement.
• Processus de libération défini uniquement pour les fichiers en cours d’analyse ou revenus avec un statut d’erreur.
• Rapports corrélés aux journaux des points de terminaison, de la messagerie, du Web et du pare-feu.
• Prise en compte de Syslog, Central Reporting ou SIEM pour une traçabilité plus longue.

FAQ