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 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 Central 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. Saisir sous External URL l’adresse appropriée provenant de la liste de feeds Avanet ou de son propre fournisseur. Le fichier doit contenir un indicateur par ligne.
9. Configurer une clé API ou Basic Authentication si nécessaire. Les identifiants ne doivent pas apparaître dans les tickets ni dans les captures d’écran.
10. 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.
11. Choisir un Polling interval adapté à l’intervalle de mise à jour du fournisseur.
12. 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.

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.

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 Central. Le guide dédié explique l’intégration Central, 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 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.

Pour le trafic transféré, les feeds de domaines nécessitent également Application Classification ou une politique IPS dans la règle firewall.

Pour une URL HTTPS complète, le firewall doit aussi voir le chemin. Cela nécessite soit Web Proxy avec déchiffrement HTTPS, soit DPI avec une règle d’inspection SSL/TLS appropriée. 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 Central 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

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é, il faut 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

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.

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 propose des feeds sélectionnés afin que les administrateurs n’aient pas à collecter, normaliser et contrôler continuellement plusieurs listes OSINT eux-mêmes. Les données proviennent notamment de sources communautaires et OSINT, de la Threat Intelligence commerciale, de honeypots ainsi que de logs d’attaques et d’anomalies anonymisés issus d’environnements Sophos Firewall administrés.

Avanet a testé plusieurs fournisseurs de Threat Feeds dans des environnements firewall réels. Selon nous, Cybora offre actuellement le meilleur rapport qualité-prix pour Sophos Firewall. L’évaluation a porté sur la qualité des feeds, la couverture, les intervalles de mise à jour et les coûts. Même un tel feed doit d’abord être évalué dans son propre environnement lors d’un pilote en mode Monitor.

Comparer les offres

Free (Basic) convient aux utilisateurs à domicile, aux preuves de concept et aux tests de compatibilité. Standard complète le feed IPv4 avec des domaines de malware et de phishing. Premium étend la couverture aux domaines et URL avec des mises à jour horaires. Ultimate, avec des mises à jour toutes les 15 minutes, vise les infrastructures critiques et les périmètres à haut risque.

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.