Configurer et tester l'analyse antimalware de Sophos Firewall

L’analyse antimalware de Sophos Firewall contrôle les fichiers du trafic web à l’aide des moteurs antivirus intégrés. L’activation de Web Filtering ou la sélection d’une Web Policy ne suffit pas : la règle de pare-feu correspondante doit utiliser Scan HTTP and decrypted HTTPS, et le trafic chiffré doit être déchiffré pour permettre l’inspection du contenu.

Cet article se concentre sur les téléchargements via HTTP et HTTPS. Pour les catégories, les URL Groups et les règles utilisateur, consulter Web Protection avec Web Policies. Zero-Day Protection peut analyser en plus les fichiers inconnus, tandis que le trafic de messagerie est protégé séparément par Mail Protection.

Clarifier le périmètre, les prérequis et les licences

L’analyse antimalware classique dépend des protocoles et des règles. Les téléchargements web nécessitent Web Protection ; la Base License seule n’inclut pas Web Malware Protection. Zero-Day Protection est une subscription distincte qui complète l’antivirus sans le remplacer. SMTP, POP3 et IMAP nécessitent Email Protection. Vérifier l’état et la date d’expiration sous Administration > Licensing : le module requis doit afficher Subscribed ou Evaluating. Un pare-feu connecté à Internet synchronise automatiquement les licences toutes les 24 heures. Si l’état semble obsolète, Administration > Licensing > Synchronize force une actualisation.

Avant toute modification :

• relever la règle firewall, sa Rule ID, sa position et l’état actuel de ses options d’analyse ;
• pour HTTPS, choisir DPI Engine ou Web Proxy pour le déchiffrement et s’assurer que le client de test fait confiance à la Signing CA ;
• identifier les Web Exceptions et SSL/TLS Exclusion Rules du chemin testé ;
• préparer un client isolé, une fenêtre pilote et l’accès à Log Viewer ;
• créer une sauvegarde sous Backup and firmware > Backup and restore, puis noter aussi les quelques valeurs concernées afin de ne pas restaurer inutilement toute la configuration.

FTP et la messagerie utilisent d’autres contrôles. Activer Scan FTP for malware dans la règle correspondante ; sa limite globale est Web > General settings > Maximum file scan size for FTP. Pour la messagerie, sélectionner en fin de règle les protocoles réellement utilisés (IMAP, IMAPS, POP3, POP3S, SMTP et/ou SMTPS) ; Add ports ajoute les ports standard manquants. Les policies MTA et Legacy, la quarantaine et les actions sur les pièces jointes se gèrent ensuite sous Email. Le moteur principal de messagerie se trouve sous Email > General settings > Malware protection. Leur configuration complète reste dans l’article Mail Protection lié.

Le contrôle du type de fichier ne prouve pas non plus une détection antivirus. Une Web Policy peut autoriser ou bloquer un téléchargement par type, et une policy de messagerie peut agir sur une pièce jointe. Seule une entrée Malware corrélée prouve la détection par le moteur antivirus.

Ce qui doit fonctionner ensemble pour une analyse efficace

Le résultat dépend de plusieurs niveaux :

• La bonne règle de pare-feu doit réellement traiter le trafic client.
• Scan HTTP and decrypted HTTPS active l’analyse antimalware pour le chemin de cette règle.
• Web > General settings détermine le moteur, le comportement de l’analyse, les limites de taille et le traitement du contenu non analysable.
• Le contenu HTTPS n’est inspecté que si DPI ou Web Proxy déchiffre la connexion.
• Les Web Exceptions ne doivent pas contourner involontairement l’analyse antimalware.
• QUIC doit être contrôlé, car son trafic ne peut pas être analysé comme le trafic HTTP et HTTPS classique.

Une Web Policy et l’analyse antimalware remplissent des fonctions différentes. La Web Policy décide, par exemple, du traitement des catégories ou des types de fichiers. L’analyse antivirus inspecte le contenu des fichiers à la recherche de malwares connus et de PUAs. L’analyse antimalware peut donc être active dans une règle de pare-feu même avec Web policy: None. Inversement, la sélection d’une Web Policy ne signifie pas automatiquement que les téléchargements sont analysés à la recherche de malwares.

Choisir Single ou Dual Engine

Le moteur antivirus principal est défini sous System services > Malware protection. Sophos Firewall utilise Sophos et Avira ; le moteur sélectionné comme Primary Engine analyse seul avec Single engine et intervient en premier avec Dual engine.

La sélection globale pour le trafic web se trouve sous :

Web > General settings > Malware and content scanning

• Single engine : utilise uniquement le Primary Engine. Ce mode nécessite moins de ressources et offre les meilleures performances. Pour Zero-Day Protection, Sophos doit être le Primary Engine.
• Dual engine : utilise d’abord le moteur principal, puis le second moteur. Ce mode élargit la couverture de détection, mais nécessite plus de temps et de ressources.

Pour les réseaux clients normaux, Single engine avec Sophos comme Primary Engine constitue un point de départ cohérent lorsque le débit et la latence sont importants. Dual engine convient lorsque la couverture de détection maximale est prioritaire et que l’appliance peut supporter la charge supplémentaire en conditions réelles. La décision ne doit pas reposer uniquement sur les valeurs d’une fiche technique : un pilote avec des téléchargements habituels, des visioconférences et une distribution de logiciels montre mieux l’impact réel.

⚠️ Le changement de Primary Engine ou le passage de Single à Dual a un effet global sur les chemins d’analyse correspondants. Avant toute modification, tenir compte des Web, FTP et Mail Policies existantes ainsi que de Zero-Day Protection, et documenter une possibilité de retour arrière. Modifier le moteur antivirus principal global peut aussi modifier un moteur antivirus défini localement. Vérifier les sélections locales de moteur après le changement.

Contrôler la détection par machine learning du moteur d’analyse

SFOS 22 peut activer le machine learning, ou ML, globalement pour le moteur d’analyse Sophos, puis séparément pour différents groupes de fonctions. ML recherche des motifs suspects qui peuvent ne pas encore figurer dans la base de signatures. Il étend ainsi la détection des menaces nouvelles ou à propagation rapide, mais augmente aussi le risque de faux positifs.

Commencer par enregistrer l’état actuel avec la commande en lecture seule :

show scanengine

Les valeurs par défaut documentées sont ml_scan on globalement, ml_web_detection off pour Web Proxy et DPI Engine, ml_email_detection on pour Email et ml_legacy_detection off pour WAF et FTP Proxy. Lorsque ml_scan global est off, ML ne peut pas être activé effectivement pour les différents groupes de fonctions. Les commutateurs par fonction déterminent si une détection ML peut y déclencher une action de blocage.

La syntaxe CLI complète est la suivante :

set scanengine ml_scan <on|off>
set scanengine ml_web_detection <on|off>
set scanengine ml_email_detection <on|off>
set scanengine ml_legacy_detection <on|off>
set scanengine thread_count <1-128|default>

thread_count s’applique à chaque moteur d’analyse. La plage va de 1 à 128 ; default calcule dynamiquement le nombre à partir des CPU disponibles. Un nombre fixe de threads ne doit pas devenir un réglage de performance générique. Il nécessite une charge d’analyse reproductible, des mesures CPU et mémoire, un test de débit et, en général, une instruction précise du support. L’ancienne option max_buffer_size est obsolète et ne doit plus être modifiée.

⚠️ ML peut bloquer à tort des fichiers ou du trafic légitimes, et ses détections génèrent de la télémétrie pour Sophos Labs. L’activation, la protection des données, les chemins de données concernés et le traitement des faux positifs doivent donc être clarifiés avant le déploiement. Désactiver ML globalement sur un simple soupçon n’est pas plus propre qu’une exception non vérifiée.

Le pilote commence avec un seul groupe de fonctions et un flux client ou de messagerie contrôlé. Comparer avant et après show scanengine, la policy, l’action de blocage, Log Viewer, le résultat applicatif, le CPU et la durée d’analyse. EICAR confirme l’analyse antimalware normale, mais ne prouve pas la détection ML d’un nouveau motif. Le retour arrière restaure les valeurs enregistrées avec show scanengine et ne les remplace pas aveuglément par les valeurs par défaut du produit.

Définir le comportement de l’analyse

Outre le moteur, d’autres décisions de protection sont prises sous Web > General settings.

Contenu non analysable

Action on malware scan failure définit le traitement du contenu qui ne peut pas être inspecté complètement. Cela peut se produire avec des archives chiffrées ou endommagées ainsi qu’avec des fichiers imbriqués trop profondément. Sophos Firewall analyse les archives jusqu’à 16 niveaux de compression.

Block offre une meilleure protection, mais peut arrêter des fichiers légitimes protégés par mot de passe ou défectueux. Allow préserve le processus métier, mais laisse passer du contenu non inspecté. Block constitue le point de départ le plus sûr pour les réseaux clients normaux. Si une application métier ne fonctionne plus, examiner d’abord le chemin concret du fichier avant d’assouplir le réglage global.

Tailles de fichiers et streaming

Do not scan files larger than définit la taille d’analyse maximale pour HTTP et HTTPS. Les fichiers plus volumineux ne sont pas analysés. Pour les fichiers compressés, c’est la taille de l’archive qui compte, et non sa taille potentielle après extraction. FTP dispose d’une limite distincte avec Maximum file scan size for FTP.

Une petite limite n’améliore pas automatiquement la sécurité, car elle peut laisser passer de grands programmes d’installation ou de grandes archives sans analyse. Une valeur très élevée peut en revanche augmenter la durée des téléchargements et la consommation de ressources. Elle doit donc être adaptée à la distribution des logiciels, aux packages de mise à jour et aux performances de l’appliance.

Sous Web > General settings, ouvrir Advanced settings pour accéder à Scan audio and video files. Scan audio and video files étend l’analyse au contenu multimédia, mais peut perturber le streaming. Activer cette option uniquement si le besoin de protection justifie la charge supplémentaire et les interruptions possibles. Après avoir sélectionné les réglages d’analyse web souhaités, cliquer sur Apply pour enregistrer les modifications.

Traiter les PUAs

Block potentially unwanted applications détecte des programmes qui ne sont pas nécessairement des malwares, mais peuvent inclure des adwares, un contrôle à distance indésirable ou des modifications risquées du système. N’ajouter une entrée sous Authorized PUAs qu’après avoir vérifié le fichier, sa source, son objectif et son responsable. Une autorisation générale affaiblit la protection de tous les chemins d’analyse correspondants.

Activer l’analyse antimalware dans la règle de pare-feu

La règle se trouve sous :

Rules and policies > Firewall rules

Pour une règle d’accès Internet client typique, contrôler les éléments suivants sous Web filtering :

1. Source zone et Source networks correspondent au réseau client.
2. Destination zone est WAN, et les Services couvrent le trafic web prévu.
3. Log firewall traffic est activé.
4. Scan HTTP and decrypted HTTPS est activé.
5. Block QUIC protocol est activé si le trafic web doit utiliser le chemin TCP contrôlé.
6. DPI ou Web Proxy a été choisi délibérément.
7. Use Zero-day protection n’est activé en plus que si les fichiers inconnus doivent être analysés.

Exemple compact de règle :

Rule name: LAN_USERS_WEB
Source zones: LAN
Source networks and devices: LAN_CLIENTS
Destination zones: WAN
Destination networks: Any
Services: HTTP, HTTPS
Web policy: LAN_STANDARD_WEB
Scan HTTP and decrypted HTTPS: On
Block QUIC protocol: On
Use web proxy instead of DPI engine: Off
Log firewall traffic: On

L’exemple utilise le DPI Engine. LAN_USERS_WEB, LAN_CLIENTS et LAN_STANDARD_WEB sont des noms d’exemple à remplacer. Pour la seule analyse antimalware, Web policy peut aussi être None. Les Services doivent se limiter aux protocoles nécessaires ; Any serait trop large pour cet exemple web. Une règle plus générale placée au-dessus peut traiter le trafic en premier ; la Rule ID et l’ordre restent donc indispensables à la validation. Les principes sont expliqués dans Comprendre et structurer correctement les règles de pare-feu.

Compléter correctement HTTPS avec DPI ou Web Proxy

Scan HTTP and decrypted HTTPS ne déchiffre pas HTTPS lui-même. Cette option analyse uniquement le trafic HTTP non chiffré et le contenu HTTPS déjà déchiffré par une autre partie de la configuration.

DPI Engine

Avec le DPI Engine, le déchiffrement est configuré sous :

Rules and policies > SSL/TLS inspection rules

Une règle SSL/TLS Inspection correspondante doit traiter le client de test et la destination et utiliser Action: Decrypt. Les clients doivent faire confiance à la Signing CA utilisée. Déployer TLS Inspection étape par étape décrit la planification, le pilote et les exceptions ; la distribution du certificat est expliquée dans Installer le certificat CA pour HTTPS Scanning.

Web Proxy

Pour le chemin proxy, activer Use web proxy instead of DPI engine et, pour HTTPS, Decrypt HTTPS during web proxy filtering dans la règle de pare-feu. Sous Web > General settings, le proxy peut ensuite analyser selon deux modes :

• Batch : télécharge d’abord le fichier complet sur le pare-feu et ne le transmet qu’après l’analyse. Ce mode offre une inspection plus stricte, mais peut retarder sensiblement les téléchargements.
• Real-time : transmet des parties du téléchargement, mais ne termine le transfert qu’une fois le contenu évalué comme propre.

Avec Batch, le téléchargement en amont vers le pare-feu peut utiliser toute la bande passante et affecter les autres accès Web. Sur le chemin général d’analyse par proxy, Traffic Shaping s’applique lors de la transmission au navigateur, aussi bien en Batch qu’en Real-time ; cela ne garantit pas la limitation du téléchargement Batch en amont. Direct Web Proxy constitue une exception explicite : une Traffic Shaping Policy ne s’applique pas à ce chemin. Avant de changer de mode d’analyse, documenter la valeur précédente ; comparer l’utilisation du WAN, la durée du téléchargement côté client, le résultat d’analyse et Rule ID avec les mêmes téléchargements représentatifs. En cas de régression, restaurer le mode précédent plutôt que de modifier simultanément l’engine ou la politique.

Le DPI Engine fonctionne toujours en mode Real-time. Ne pas passer de Proxy à DPI ou inversement uniquement en raison d’une erreur isolée, car leur étendue fonctionnelle, leurs ports, leurs logs et le comportement utilisateur diffèrent.

Le choix entre DPI Real-time, proxy Batch ou Real-time et le changement pilote sécurisé est expliqué dans Bien choisir entre DPI Engine et Web Proxy.

Contrôler les exceptions et QUIC

Une Web Exception peut contourner Malware and content scanning. Pour le trafic correspondant, elle contourne alors aussi automatiquement l’analyse Zero-Day. Les exceptions doivent donc être limitées à un hôte ou une URL précis, disposer d’un responsable clair et d’une date de révision.

QUIC, ou HTTP/3, utilise généralement UDP 443. Sophos Firewall ne peut pas analyser ce trafic comme le trafic web classique. Block QUIC protocol bloque les flux UDP sortants sur les ports 80 et 443 dans la règle de pare-feu correspondante afin que les clients compatibles reviennent à TCP et HTTPS. Le contexte et les tests sont disponibles dans Bloquer correctement QUIC et HTTP/3.

Tester le fonctionnement en toute sécurité

Un Policy Test vert ou une case cochée ne prouve pas que le contenu est inspecté. Le test doit provenir d’un client situé derrière la règle de pare-feu concernée ; un téléchargement effectué directement depuis le pare-feu contrôle un autre chemin de trafic.

Pour vérifier le chemin web du Sophos Firewall, utiliser précisément l’action Anti-virus EICAR test sur la page SophosTest pour Web Security. Pour tester le transport du fichier de test standardisé indépendamment de ce site, utiliser plutôt une variante du fichier de test antimalware EICAR. EICAR n’est pas un véritable malware, mais les antivirus le détectent intentionnellement comme tel. Ne jamais introduire de logiciel malveillant réel dans un réseau de production, ni ouvrir ou exécuter le fichier de test.

Procédure pratique :

1. Définir un client de test isolé et la Rule ID attendue du pare-feu. Aucune exception Allow temporaire n’est nécessaire. Si Endpoint Protection intervient d’abord, ne pas le désactiver ; considérer plutôt le résultat comme non concluant pour le pare-feu.
2. Noter l’heure, l’adresse IP du client, l’URL de test choisie et le chemin d’analyse attendu.
3. Ouvrir les modules Firewall, SSL/TLS inspection, Web filter et Malware dans Log Viewer.
4. Pour HTTPS, vérifier que la connexion est réellement traitée avec Decrypt.
5. Exécuter Anti-virus EICAR test sur SophosTest ou télécharger exactement une variante EICAR. Le pare-feu doit interrompre le transfert avant la fin du téléchargement.
6. Vérifier que le Malware log affiche une détection antivirus pour le même client, la même Rule ID, la même URL et la même heure.
7. Fermer la page de test et supprimer tout fichier partiel ou de test ainsi que les artefacts du cache du navigateur selon la procédure Endpoint ; ne pas restaurer ni exécuter un objet en quarantaine. Annuler les réglages de test temporaires et confirmer avec un téléchargement normal que l’accès web fonctionne toujours.

Une page de blocage seule ne suffit pas. La Web Policy, une règle de type de fichier, un produit Endpoint ou la catégorie même de la page de test peut également bloquer l’accès. L’entrée Malware corrélée du pare-feu est déterminante. Dans Syslog, une détection de malware web apparaît avec log_type="Anti-Virus" ; les composants sont HTTP ou HTTPS selon le protocole, et le Subtype d’une détection est Virus.

Si Log Viewer ne permet pas de déterminer si le service antivirus local fonctionne, son Service Log peut également être observé dans l’Advanced Shell pendant un test contrôlé :

tail -f /log/avd.log

La combinaison Ctrl+C arrête l’affichage. avd.log aide à diagnostiquer les erreurs de service et de moteur, mais ne remplace pas les données de policy et de connexion dans Log Viewer. Un fichier silencieux ne prouve pas non plus que l’analyse est inactive. Services et logs de Sophos Firewall explique l’affectation des logs.

Isoler méthodiquement les erreurs courantes

• Web Policy active, mais aucune inspection antimalware : Scan HTTP and decrypted HTTPS manque dans la règle de pare-feu réellement appliquée.
• Le test HTTP fonctionne, mais pas le test HTTPS : la règle SSL/TLS Inspection ne correspond pas, n’utilise pas Decrypt, ou Web Proxy ne déchiffre pas HTTPS.
• Le navigateur utilise un autre chemin : QUIC est autorisé ou une autre règle de pare-feu s’applique d’abord.
• Le fichier n’est pas analysé malgré la bonne règle : une Web Exception contourne Malware and content scanning, ou le fichier dépasse la limite de taille configurée.
• EICAR est bloqué, mais pas par le pare-feu : Endpoint Protection, une règle de type de fichier ou une catégorie web a réagi auparavant. Contrôler la Rule ID et le Malware log du pare-feu.
• Des archives légitimes sont bloquées : contrôler Action on malware scan failure, le chiffrement, les dommages et l’imbrication. Ne pas basculer immédiatement le réglage global sur Allow.
• Dual Engine ralentit les téléchargements : comparer la charge de l’appliance, la taille des fichiers, la simultanéité et le mode Proxy ou DPI avec Single Engine dans le cadre d’un pilote contrôlé.
• Zero-Day Protection n’affiche rien : contrôler séparément l’analyse antimalware classique, le déchiffrement HTTPS, le type de fichier, les exceptions et Use Zero-day protection.
• Une option manque ou ne s’enregistre pas : contrôler l’état et l’expiration de Web Protection, Email Protection ou Zero-Day Protection sous Administration > Licensing, puis synchroniser les licences. Ne pas contourner le problème par une règle Allow plus large.
• Un fichier FTP n’est pas analysé : contrôler ensemble la Rule ID, Scan FTP for malware, le Service et Maximum file scan size for FTP. L’option HTTP/HTTPS n’active pas FTP.
• Une pièce jointe n’est pas détectée : déterminer d’abord le chemin MTA, Legacy SMTP ou POP/IMAP, puis corréler protocoles et ports de la règle, policy de messagerie, Single/Dual Antivirus, exceptions et logs Mail ou Malware.

Log Viewer, Policy Tester et Packet Capture permettent de déterminer quelle règle de pare-feu et quelle policy s’appliquent réellement.

Revenir en arrière sans perdre l’état initial

Un rollback restaure uniquement les valeurs modifiées pendant le pilote, dans l’ordre inverse : règle SSL/TLS Inspection et sa position, règle firewall avec sa Rule ID et sa position, choix Proxy/DPI, options d’analyse et QUIC, choix global Single/Dual Engine et valeurs de show scanengine. Ne pas supprimer une règle ni désactiver globalement l’analyse parce qu’un téléchargement échoue.

Enregistrer puis répéter deux contrôles : un téléchargement représentatif normal doit fonctionner et le test EICAR isolé doit retrouver exactement le comportement antérieur. Si la Rule ID, l’état de déchiffrement ou l’action du log diffère de la référence, le rollback n’est pas terminé. La sauvegarde complète reste le recours d’urgence pour une erreur plus large, pas la première réponse à une case.

Cas particulier lors de la mise à niveau vers SFOS 22.0 GA

Un défaut de mise à niveau très circonscrit pour SFOS 22.0 GA Respin Build 411 est documenté sous NC-177529. Pendant cette mise à niveau, des messages tels que Malware Unscannable peuvent apparaître temporairement, souvent pour www.msftconnecttest.com. À ce moment-là, le nouveau moteur d’analyse Sophos n’est pas encore disponible lorsqu’il est le seul moteur sélectionné en mode Single Engine. Legacy Web Proxy affiche alors des pages de blocage, tandis que le chargement des pages peut échouer avec le DPI Engine ; l’interruption peut durer environ une minute de plus. Avant chaque mise à niveau, vérifier aussi la Maintenance Release actuelle et les chemins pris en charge ; la vérification liée ci-dessous couvre ce contrôle dépendant de la version.

Pour une mise à niveau ciblée vers cette version GA, passer de Single engine à Dual engine sous Web > General settings avant la mise à niveau, puis revenir au Single engine utilisé auparavant une fois la mise à niveau terminée. Cette mesure temporaire n’est pas une recommandation générale pour MR1, MR2 ou les versions ultérieures. La vérification avant mise à niveau vers SFOS 22 décrit le chemin complet et les autres blocages.

FAQ