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.
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.
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.
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.
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 :
- Source zone et Source networks correspondent au réseau client.
- Destination zone est
WAN, et les Services couvrent le trafic web prévu. - Log firewall traffic est activé.
- Scan HTTP and decrypted HTTPS est activé.
- Block QUIC protocol est activé si le trafic web doit utiliser le chemin TCP contrôlé.
- DPI ou Web Proxy a été choisi délibérément.
- 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: Any
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. Les noms et les réseaux doivent être adaptés à l’environnement. Une règle plus générale placée au-dessus de LAN_USERS_WEB peut traiter le trafic en premier ; la Rule ID et l’ordre des règles doivent donc toujours faire partie de 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.
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 le test fonctionnel, utiliser la page SophosTest pour Web Security ou le fichier de test antimalware EICAR. EICAR n’est pas un véritable malware, mais les produits antivirus le détectent intentionnellement comme tel. Il ne faut jamais introduire de logiciel malveillant réel dans un réseau de production.
Procédure pratique :
- Définir un client de test isolé et la Rule ID attendue du pare-feu.
- Noter l’heure, l’adresse IP du client, l’URL et le chemin d’analyse attendu.
- Ouvrir les modules Firewall, SSL/TLS inspection, Web filter et Malware dans Log Viewer.
- Pour HTTPS, vérifier que la connexion est réellement traitée avec
Decrypt. - Exécuter l’Anti-virus EICAR test pour Sophos Firewall sur SophosTest ou télécharger le fichier de test EICAR.
- Vérifier que le pare-feu bloque le téléchargement et que le Malware log affiche une détection antivirus pour le même client, la même Rule ID et la même heure.
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.
Log Viewer, Policy Tester et Packet Capture permettent de déterminer quelle règle de pare-feu et quelle policy s’appliquent réellement.
Cas particulier lors de la mise à niveau vers SFOS 22.0 GA
Sophos répertorie sous NC-177529 un défaut de mise à niveau très circonscrit pour SFOS 22.0 GA Respin Build 411. 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.
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.