Configurer et exploiter Sophos Firewall Threat Feeds en toute sécurité

Les Sophos Firewall Threat Feeds importent automatiquement des adresses IP, des domaines et des URL malveillants connus sous forme d’indicateurs de compromission (IoC). Pour un déploiement sûr, il faut d’abord observer le feed en mode Monitor, contrôler les détections et leurs effets secondaires, puis seulement passer à Block.

Cet article traite principalement des Third-Party Threat Feeds, tels que les feeds de Cybora. Cette fonction a été introduite avec Sophos Firewall v21.

Configurer un Threat Feed

Les Third-Party Threat Feeds nécessitent le Xstream Protection Bundle, mais aucune licence Sophos Fusion (anciennement Sophos Central) supplémentaire. Le firewall doit pouvoir atteindre l’URL du feed via DNS et HTTPS.

1. Ouvrir System services > Log settings.
2. Sous Active threat response, activer au moins une destination de logs prise en charge. Pour le Log Viewer local, il s’agit de Local reporting. Les XGS 87/87w et 107/107w ne prennent pas en charge le reporting local ; il faut alors utiliser Sophos Fusion ou un serveur syslog.
3. Pour voir les détections sur le trafic DNAT et WAF entrant, activer également Remote source match (inbound traffic). Cette option est désactivée par défaut.
4. Ouvrir Protect > Active threat response > Third-party threat feeds > Add.
5. Saisir un nom et une description explicites, par exemple :
   • Pilote : Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Feed de production validé : Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. Pour Indicator type, choisir IPv4 address, Domain ou URL. Si une source fournit plusieurs types, créer un feed distinct pour chacun.
7. Régler Action sur Monitor pour la mise en service. Après une période d’observation validée, il est possible de passer à Block.
8. Sous Position, choisir Top pour un feed pilote afin que sa correspondance ne soit pas masquée par un autre feed tiers. Bottom convient à un feed de priorité inférieure dont les chevauchements sont déjà connus.
9. Sous External URL, saisir l’adresse appropriée provenant de la liste de feeds Avanet ou de son fournisseur. L’URL doit renvoyer directement le fichier texte brut. Si le point de terminaison répond par exemple avec un statut HTTP 302, SFOS le classe comme Connection error. Le fichier contient un indicateur par ligne.
10. Sous Authorization, sélectionner No authentication, API key ou Basic authentication. Une clé API peut être transmise dans le Header ou dans les Query parameters ; sa valeur et le mot de passe de Basic Authentication sont chacun limités à 64 caractères. Les identifiants ne doivent pas apparaître dans les tickets ni dans les captures d’écran.
11. Activer Validate server certificate. Pour un certificat public, l’autorité de certification émettrice doit être présente sous Certificates > Certificate authorities ; pour une CA privée, importer d’abord son certificat.
12. Choisir un Polling interval adapté à l’intervalle de mise à jour du fournisseur.
13. Exécuter Test connection, puis enregistrer avec Save.

Contrôler ensuite Sync status, Last updated, le nombre de Threat indicators et la Storage quota disponible. Success confirme le téléchargement, mais pas que le trafic attendu est réellement détecté ou bloqué. Cet effet doit être validé séparément dans le Log Viewer.

Choisir correctement le feed et l’action

Indicateurs pris en charge

Un feed contient exactement l’un des types suivants :

• IPv4 address: scanners, botnets, systèmes compromis ou serveurs C2
• Domain: domaines de malware, de phishing ou de commande et contrôle
• URL: chemins malveillants précis ou liens de téléchargement

Le feed doit être un fichier texte brut contenant un indicateur par ligne. Les plages IP, adresses IPv6, réseaux, domaines avec caractères génériques et expressions régulières ne peuvent pas remplacer des IoC individuels pris en charge dans les Third-Party Threat Feeds.

SFOS n’impose aucun nombre fixe d’IoC par Third-Party Feed. La taille réellement utilisable est limitée par la Storage quota propre au modèle. Après l’importation, contrôler ensemble la capacité disponible, le nombre de Threat indicators et la bonne récupération du feed.

Une grande liste n’est pas automatiquement une bonne liste. L’origine, l’actualité, l’intervalle de mise à jour, le risque de faux positifs et les détections dans l’environnement concerné comptent davantage que le nombre brut d’entrées. Un feed qui n’apporte durablement aucune valeur ne fait qu’occuper de l’espace.

Monitor avant Block

Monitor consigne les détections, mais autorise le trafic. Il montre ainsi les sources, destinations et services qui seraient concernés. Block consigne et rejette le trafic correspondant.

Pour un nouveau feed, la procédure suivante est judicieuse :

1. Placer le feed en haut de la liste Third-Party.
2. Commencer avec Monitor.
3. Contrôler les détections et les éventuels faux positifs pendant une période représentative.
4. Documenter le responsable et le processus d’exception.
5. Passer ensuite seulement à Block.

Un feed IPv4 bien sélectionné pour des services très exposés peut être mis en production plus rapidement qu’un feed de domaines ou d’URL. Ces derniers correspondent plus souvent à des infrastructures partagées, des CDN ou des redirections et exigent donc un contrôle particulièrement attentif.

Avant de passer à Block, consigner le nom du feed, le nombre d’IoC, sa position et les détections observées jusque-là. Si la modification provoque une interruption inattendue, remettre immédiatement Action du même feed sur Monitor, puis tester à nouveau le trafic concerné. Un feed défectueux ou incontrôlable peut être temporairement désactivé. Une Threat Exclusion globale n’est pas un rollback équivalent, car elle affecte aussi MDR, NDR et Sophos X-Ops.

Ordre et noms

Active Threat Response traite les modules dans l’ordre suivant : MDR, NDR Essentials, Sophos X-Ops, puis Third-Party Threat Feeds. Avec Log and drop, une correspondance dans un module antérieur met fin aux contrôles suivants. Avec Log only ou Monitor, le firewall consigne en revanche des événements distincts pour MDR, X-Ops et Third-Party Threat Feeds.

Dans Third-Party Threat Feeds, le firewall évalue séparément les listes Block et Monitor, dans l’ordre affiché. Il consigne la première correspondance de chaque liste et bloque selon la première correspondance de la liste Block. Les feeds de production, les feeds pilotes et les listes d’incident temporaires doivent donc être clairement nommés et ordonnés :

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

Un bon nom indique le fournisseur ou l’objectif, le type d’indicateur et l’action. Cela fait gagner du temps lors de l’analyse des logs et des contrôles.

Distinguer les modules Threat Feed

Sous Active threat response figurent plusieurs fonctions aux objectifs et aux licences différents :

• Sophos X-Ops Threat Feeds: indicateurs Sophos ; nécessitent Network Protection et, pour leur mise en œuvre, Web Protection. Les deux sont inclus dans les bundles Standard ou Xstream ou peuvent être concédés sous licence séparément.
• MDR Threat Feeds : IoC issus de Sophos MDR ; nécessitent le Xstream Protection Bundle ainsi que MDR Essentials ou MDR Complete dans Sophos Fusion. Le guide dédié explique l’intégration à Sophos Fusion, l’action locale, l’Audit ID, la Task Queue et la validation de l’incident.
• Third-Party Threat Feeds: listes externes d’adresses IPv4, de domaines ou d’URL ; nécessitent le Xstream Protection Bundle.
• NDR Essentials: analyse le trafic par machine learning et nécessite le Xstream Appliance Bundle.
• NDR Active Threat Intelligence: consigne des modèles NDR sélectionnés par Sophos, nécessite le Xstream Protection Bundle et doit être activé pour chaque règle firewall avec Scan with NDR Active threat intelligence. Les XGS 87/87w et 88/88w ne sont pas pris en charge.

Pour Synchronized Security et le contexte supplémentaire du terminal dans les journaux Active Threat Response, une licence Intercept X dans Sophos Fusion est également requise. Cette licence n’est pas nécessaire au Threat Feed lui-même, mais à l’enrichissement de l’événement avec les informations sur l’hôte, l’utilisateur et le processus.

Synchronized Security est facultatif pour la correspondance avec les Threat Feeds. Si un Sophos Endpoint administré envoie un Security Heartbeat rouge après avoir contacté un serveur malveillant, une règle Heartbeat correctement configurée peut bloquer son trafic ; Lateral Movement Protection peut en plus isoler l’endpoint compromis du réseau interne. Cette réaction de l’endpoint complète le feed et ses journaux, mais ne remplace ni la configuration du feed ni la règle firewall.

Pour NDR, consulter le guide distinct Exploiter Sophos Firewall NDR et Active Threat Response.

Comprendre l’effet sur le trafic

Trafic IPv4, de domaine et d’URL

Le trafic IPv4 transféré nécessite une règle firewall qui traite le trafic concerné. Le trafic destiné au système pour des services sous Administration > Device access, comme WebAdmin, VPN Portal et VPN, est comparé séparément aux indicateurs d’IP source et ne passe pas par une règle firewall de transit.

Les requêtes DNS auxquelles le firewall répond lui-même en tant que serveur DNS sont comparées aux IoC de domaine par le module DNS. Si les clients utilisent un autre serveur DNS, IPS doit voir le trafic DNS. Un feed de domaines ne prouve donc pas à lui seul que le chemin réel du résolveur est inspecté.

Pour le trafic transféré, les feeds de domaines nécessitent également Application Classification ou une politique IPS dans la règle firewall. Application Classification est activée par défaut, mais doit tout de même être vérifiée dans le chemin de règle concerné.

Pour une URL HTTPS complète, le firewall doit aussi voir le chemin. Pour le chemin Web Proxy, sélectionner Use web proxy instead of DPI engine et Decrypt HTTPS during web proxy filtering sous Web filtering dans la règle firewall. Pour le chemin DPI, désactiver Use web proxy instead of DPI engine et ajouter une règle d’inspection SSL/TLS appropriée avec Action: Decrypt. Sans déchiffrement, le firewall ne voit via SNI que le domaine, pas le chemin complet de l’URL.

DNAT et WAF à partir de SFOS 22

Depuis SFOS 22, le firewall peut comparer l’adresse IP source du trafic entrant transféré pour DNAT et WAF aux MDR, NDR et Third-Party Threat Feeds. Cela permet de détecter les scanners et botnets connus avant qu’ils n’atteignent les services publiés.

Pour que ces détections apparaissent dans le log Active Threat Response, l’option Remote source match (inbound traffic) doit être activée sous System services > Log settings > Active threat response. Elle est désactivée par défaut. Sans ce réglage, le blocage peut fonctionner alors que les événements DNAT ou WAF attendus n’apparaissent pas dans le Log Viewer.

Cas d’utilisation typiques

Les Threat Feeds ne servent pas uniquement à protéger le trafic client sortant. Les services accessibles au public, en particulier, sont souvent scannés automatiquement en très peu de temps.

• DNAT vers des serveurs internes : un feed IPv4 peut bloquer les sources malveillantes connues avant qu’elles n’atteignent le serveur publié.
• Publications WAF : les données de réputation complètent les règles WAF contre le trafic de bots, les scans de CVE, les sondes visant les CMS et le credential stuffing.
• VPN Portal, User Portal et WebAdmin : ces services doivent d’abord être protégés par MFA, les réseaux sources ainsi que Device Access et Local Service ACL. Les Threat Feeds réduisent en plus le trafic provenant de sources d’attaque connues.
• Trafic client sortant : les feeds de domaines et d’URL peuvent bloquer les destinations connues de malware, de phishing et de C2.
• Adresses WAN fortement scannées : un bon feed IPv4 réduit le bruit automatisé et allège la charge du firewall et des logs.

Les Threat Feeds complètent le hardening de base, mais ne le remplacent pas. Les services publiés nécessitent toujours des règles DNAT ou WAF restrictives, uniquement les ports nécessaires, des restrictions pertinentes par source ou par pays, IPS ou WAF ainsi que le logging activé. Un feed n’autorise pas pour autant des règles Any trop larges. Le processus général est décrit dans le hub de hardening Sophos Firewall.

Vérifier la synchronisation et l’exploitation

Tester séparément la récupération du feed et son effet sur le trafic

Une connexion réussie et Sync status: Success prouvent uniquement que le firewall a pu télécharger et lire la liste. Une vérification complète comprend trois niveaux :

1. Récupération: Test connection, Sync status, Last updated et Storage quota sont plausibles.
2. Contenu: un IoC attendu figure sous Threat indicators.
3. Effet: un trafic de test contrôlé génère une détection dans Log viewer > Active threat response ou sur la destination Sophos Fusion ou syslog configurée. Selon la correspondance, il est possible de retracer le nom du feed, Log/Drop, le sens de la correspondance, la source et la destination ou l’URL, ainsi que le protocole et les ports.

Pour un test reproductible, il est possible d’utiliser un court feed pilote personnalisé sur un serveur HTTPS contrôlé. Il contient l’adresse IPv4 d’une destination de test également contrôlée. Le feed reste sur Monitor, un client de laboratoire se connecte à la destination de test et l’administrateur contrôle l’entrée de log. Il ne faut pas accéder à des destinations de malware en production ni à des systèmes tiers pour effectuer des tests.

Synchronisation et Storage Quota

Les valeurs suivantes de la vue d’ensemble des feeds sont importantes pour l’exploitation courante :

• Success, Fetching ou Disabled sous Sync status
• l’horodatage attendu sous Last updated
• un nombre plausible de Threat indicators
• une Storage quota disponible suffisante
• une mise à jour manuelle réussie avec Synchronize now

Le Summary affiche Active feeds, Total threat indicators et Storage quota. Refresh actualise uniquement ces compteurs affichés. Synchronize now récupère en revanche immédiatement le feed sélectionné. Les IoC individuels peuvent être ouverts et recherchés via Threat indicators ou par le nombre d’indicateurs du feed concerné.

En cas d’Authentication error, contrôler la clé API ou les identifiants ; en cas de Connection error, contrôler le DNS, l’accès Internet, le statut HTTP et le serveur du feed. Une SSL/TLS error indique un problème de certificat ou de chaîne de certificats, tandis que Failed signale souvent le format du feed ou des indicateurs non valides.

Si l’espace est saturé, le pare-feu continue à récupérer le feed selon l’intervalle de polling configuré, mais ne met à jour la liste d’IoC stockée que lorsqu’un espace redevient disponible. Il faut donc revoir la taille, la qualité et la priorité des feeds plutôt que d’ajouter d’autres listes. Sur les XGS 87/87w, 88/88w et 107/107w, seuls les intervalles de polling 24h, 7d et 30d sont disponibles pour les Third-Party Threat Feeds. Un feed de fournisseur mis à jour plus fréquemment ne supprime pas cette limite du matériel.

Si aucune détection n’apparaît

Ordre de contrôle recommandé :

1. Feed activé, Sync status: Success et IoC attendu sous Threat indicators
2. une détection MDR, NDR ou X-Ops de priorité supérieure pour le même IoC
3. le logging Active Threat Response et, pour DNAT/WAF, Remote source match
4. la règle firewall correspondante et son logging
5. pour les domaines, Application Classification ou une politique IPS
6. pour les URL, Web Proxy ou DPI et SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions et SSL/TLS Exclusion Lists

Pour remonter d’un IoC de domaine ou d’URL autorisé jusqu’à la règle responsable, ouvrir Log viewer > Web filter, rechercher l’IoC dans Category ou directement le domaine, puis ouvrir la vue détaillée. Elle affiche la Firewall Rule ID et la Web policy sélectionnée dans cette règle. Si l’action de la politique correspondante est Allow, contrôler l’ordre des règles et de la politique. Un blocage volontaire utilise un URL Group strictement limité dans une Web Policy de blocage affectée à une règle LAN-to-WAN plus prioritaire. Répéter ensuite le même test de trafic.

Pour le chemin DPI, ouvrir également Log viewer > SSL/TLS inspection, rechercher l’URL dans Server name, puis contrôler Action et SSL/TLS rule. Un IoC d’URL nécessite Decrypt. Si la correspondance indique Don't decrypt, la Rule ID identifie l’exception ou la règle qui contourne le déchiffrement. N’ajouter un URL Group limité à une règle Decrypt plus prioritaire qu’après cette attribution. Déployer TLS Inspection progressivement décrit la méthode contrôlée.

Si un feed ne produit aucune détection pertinente pendant une période d’observation représentative, il faut réévaluer son utilité.

Traiter les faux positifs

En cas de blocage erroné, ouvrir d’abord l’entrée de log et documenter le nom du feed, Log/Drop, le sens de la correspondance, la source et la destination ou l’URL, le protocole et les ports. Vérifier ensuite que le trafic est légitime, signaler l’indicateur concerné au fournisseur du feed et ne créer qu’une exception aussi étroite que possible, avec un motif, un responsable et une date de contrôle.

Une exception large pour des réseaux entiers n’est pas une solution propre. Pour les correspondances de domaine ou d’URL, TLS Inspection, une Web Policy, DNS Protection ou une autre fonction de sécurité peut également intervenir.

Une exclusion contrôlée se crée sous Protect > Active threat response > Add threat exclusions. Host and network exclusions utilise des objets hôte ou réseau existants. Sous Threat exclusions, saisir une seule adresse IP, un domaine ou une URL ; chaque entrée peut comporter au maximum 128 caractères. Après Add et Apply, répéter le même test de trafic et vérifier dans Log Viewer que seule la détection attendue n’apparaît plus.

⚠️ Une Threat Exclusion s’applique à tous les modules Active Threat Response, pas uniquement au feed à l’origine du faux positif. Avant de cliquer sur Apply, évaluer l’effet sur MDR, NDR, Sophos X-Ops et Third-Party Threat Feeds. Documenter l’entrée, la raison, le responsable et la date de révision, puis supprimer l’exclusion dès qu’elle n’est plus nécessaire.

Backup et restore

Un backup du firewall contient la configuration des Third-Party Threat Feeds, mais pas les listes téléchargées. Après un restore, le firewall récupère immédiatement les sources et applique l’action configurée. Le DNS, l’accès Internet, la validation des certificats et les identifiants doivent donc fonctionner dès la restauration.

Les configurations Threat Feed ne peuvent pas être importées ou exportées séparément ; les Threat Exclusions, en revanche, le peuvent. Après un restore, il faut à nouveau contrôler la récupération du feed, le nombre d’IoC et l’effet sur le trafic.

Cybora Threat Feeds pour Sophos Firewall

Cybora fournit ses feeds IPv4, de domaines et d’URL sous forme de fichiers texte HTTPS contenant un indicateur par ligne. Sa description publique indique qu’ils combinent des sources OSINT et communautaires, de la Threat Intelligence commerciale, des honeypots, des capteurs et des signaux de firewalls. Le format correspond donc directement à l’interface tierce de SFOS, mais un pilote en mode Monitor doit toujours confirmer sa valeur sur le réseau concerné.

Cybora sert ici d’exemple concret de fournisseur. Les mêmes critères techniques s’appliquent à tout autre fournisseur : types d’indicateurs adaptés, fichier directement récupérable, fraîcheur des données, faux positifs acceptables, détections traçables et processus de correction accessible.

Comparer les offres

Free (Basic) ne contient que des indicateurs IPv4 et est actualisé toutes les 24 heures ; il permet ainsi de valider la livraison et la compatibilité SFOS avant l’achat. Standard fournit des IPv4 et un ensemble de domaines plus restreint toutes les six heures. Premium fournit des IPv4, domaines et URL chaque heure, et Ultimate les mêmes types toutes les 15 minutes. Sur les XGS 87/87w, 88/88w et 107/107w, le plus court intervalle SFOS disponible reste toutefois 24h, quel que soit le plan du fournisseur.

Au-delà du nombre et du prix, l’actualité, les types d’indicateurs pris en charge, la qualité des sources, l’intervalle de mise à jour, le risque de faux positifs et la traçabilité dans le Log Viewer sont déterminants. Le feed adapté est celui qui génère des détections pertinentes avec des effets secondaires acceptables dans l’environnement concerné.

Avanet Firewall Network

Une partie du feed Premium provient d’un réseau distribué de firewalls. Cette perspective aide à identifier des schémas d’attaque à peine visibles sur un seul firewall.

Lors d’attaques par force brute distribuées, chaque bot n’effectue que quelques tentatives de connexion infructueuses et reste souvent sous un seuil local. Le regroupement de signaux anonymisés révèle les adresses IP qui attaquent délibérément l’infrastructure sur plusieurs systèmes. Il en résulte un Threat Intelligence Feed actualisé en continu pour la défense automatisée.