Configurer et exploiter Sophos Firewall Threat Feeds

Les Sophos Firewall Threat Feeds de Cybora fournissent des flux continus de Threat Intelligence qui importent automatiquement des indicateurs de compromission (IoC) dans Sophos Firewall. Ces IoC peuvent être par exemple des adresses IP malveillantes, des domaines malveillants, des URL de phishing ou des serveurs C&C de botnets connus.

Pour le contexte global de hardening, consulter le hub Sophos Firewall Hardening : bonnes pratiques pour une configuration sécurisée.

Cela supprime une grande partie de l’effort de maintenance manuel. Au lieu de suivre manuellement des IP ou domaines individuels d’attaquants dans les objets hôtes, règles firewall ou blocklists, la firewall récupère automatiquement les données d’un feed curaté et peut bloquer le trafic correspondant.

C’est particulièrement utile dès qu’une firewall est visible depuis l’extérieur. Les IP publiques, règles DNAT, publications WAF, portails VPN ou accès WebAdmin sont souvent trouvés très vite par des bots, scanners et frameworks d’exploitation automatisés. Un bon Threat Feed réduit ce trafic indésirable avant qu’il n’atteigne plus profondément l’environnement.

En bref : les Threat Feeds sont puissants lorsqu’ils sont compris comme un processus d’exploitation. Choisir le feed, définir correctement le type d’indicateur, tester d’abord en visibilité, bloquer ensuite, contrôler régulièrement les hits et traiter proprement les faux positifs. Brancher simplement une très grande liste n’est pas une bonne stratégie de sécurité.

Classement

Ce que sont les Threat Feeds

Les Threat Feeds ou flux de menaces sont des listes d’indicateurs de compromission. En pratique, ce sont des indices sur une infrastructure malveillante connue :

• Adresses IP : scanners, botnets, systèmes compromis ou serveurs Command and Control.
• Domaines : domaines malware, phishing ou C2.
• URL : chemins malveillants précis ou liens de téléchargement.

Selon le fournisseur, ces feeds proviennent d’organisations de sécurité, de consortiums industriels, de communautés open source, de Threat Intelligence commerciale, de honeypots ou de capteurs propres. Dans Sophos Firewall v21, la fonction a été étendue avec des Third-Party Feeds intégrés via Active Threat Response Framework.

Les avantages sont clairs :

• Protection proactive : bloquer des menaces avant qu’elles ne causent des dommages.
• Flexibilité : utiliser différents feeds selon les besoins.
• Automatisation : la firewall bloque automatiquement, sans intervention manuelle permanente.
• Réduction de charge : le trafic indésirable est rejeté plus tôt et n’atteint pas les services internes.

Ne pas mélanger les modules Threat Feed

Sous Active threat response, plusieurs fonctions se trouvent côte à côte. Les noms se ressemblent, mais les tâches sont différentes.

• Sophos X-Ops Threat Feeds : indicateurs Sophos pour menaces connues. En exploitation, activer la fonction Network Protection et vérifier les logs.
• MDR Threat Feeds : renseignements issus du contexte Sophos MDR/XDR. En exploitation, relier processus MDR/Central et firewall logging.
• Third-Party Threat Feeds : listes IoC externes comme Cybora sous forme de feed IP, domaine ou URL. En exploitation, gérer qualité du feed, action, synchronisation et exceptions.
• NDR Essentials / NDR Active Threat Intelligence : détection de modèles de trafic suspects plutôt que simple liste IoC. En exploitation, analyser les signaux de détection et ne pas les confondre avec une blocklist.

Cet article traite surtout des Third-Party Threat Feeds. Pour NDR et Active Threat Intelligence, voir Exploiter Sophos Firewall NDR et Active Threat Response.

Cas d’utilisation typiques

Les Threat Feeds ne sont pas seulement intéressants pour le trafic client sortant. Dans la pratique, on voit très rapidement des accès automatisés sur les services exposés publiquement.

• DNAT vers des serveurs internes : les port-forwardings sont rapidement scannés. Un feed IPv4 peut bloquer des mauvaises sources connues avant qu’elles n’atteignent le serveur interne.
• Publications WAF : les serveurs Web voient souvent du trafic bot, des scans CVE, des probes CMS et du credential stuffing. Les Threat Feeds ajoutent une couche de réputation aux règles WAF.
• VPN Portal, User Portal et WebAdmin : les portails doivent d’abord être protégés par Device Access, MFA et réseaux sources. Les Threat Feeds réduisent en plus les sources d’attaque connues.
• Trafic client sortant : les feeds de domaines et d’URL peuvent bloquer des destinations malware, phishing ou C2 connues.
• Adresses WAN fortement scannées : si une IP publique reçoit durablement du trafic bot, un bon feed IPv4 peut réduire sensiblement la charge sur la firewall et les logs.

Depuis SFOS 22, les Threat Feeds sont particulièrement intéressants pour le trafic entrant transféré comme DNAT et WAF. La firewall peut ainsi reconnaître de mauvaises sources connues aussi devant des services publiés. Pour les anciennes installations ou les environnements mixtes, ce point doit être vérifié consciemment avant de supposer le même niveau de protection.

Les Threat Feeds ne remplacent toutefois pas une publication propre. Si un service est accessible via DNAT ou WAF, seuls les ports nécessaires doivent rester ouverts, les réseaux ou pays sources doivent être restreints, les règles IPS/WAF activées et les logs vérifiés. Les Threat Feeds sont un bloc de protection supplémentaire, pas un laissez-passer pour de larges règles Any.

Prérequis et licence

Pour utiliser les Third-Party Threat Feeds, Sophos Firewall nécessite le Xstream Protection Bundle. Aucune licence Sophos Central supplémentaire n’est nécessaire pour ce module. Les autres modules Threat Feed ont leurs propres exigences : Sophos X-Ops Threat Feeds nécessite Network Protection, MDR Threat Feeds nécessite en plus Sophos MDR Essentials ou MDR Complete dans Sophos Central, et NDR Essentials nécessite le Xstream Appliance Bundle.

Avant le rollout, vérifier aussi :

• La firewall fonctionne sur une version SFOS avec prise en charge Third-Party Threat Feeds.
• La firewall peut atteindre l’URL du feed via DNS et HTTPS.
• Un Indicator type clair est utilisé par feed, par exemple IPv4 address, Domain ou URL.
• Le feed est un fichier texte brut avec un indicateur par ligne.
• Les plages IP, adresses IPv6, adresses réseau, domaines wildcard et expressions régulières ne sont pas le bon format pour les Third-Party Threat Feeds.
• Le logging pour Active Threat Response est activé.
• Il est clair si le feed doit d’abord être observé ou directement bloquer.

Recommandation pratique : introduire de nouveaux feeds de manière contrôlée. Si la firewall le permet, commencer par une phase d’observation, contrôler les hits dans le Log Viewer, puis passer au blocage. Cela permet de voir tôt si des systèmes légitimes seraient touchés.

URL-Feeds et TLS Inspection

Les IP-Feeds et Domain-Feeds sont généralement faciles à comprendre. Les URL-Feeds sont plus exigeants, car la firewall doit voir le chemin URL pertinent. Avec du trafic HTTPS, ce n’est pas toujours possible sans déchiffrement adapté.

Si les URL-Feeds doivent être utilisés en production, il faut donc vérifier si Web Proxy, DPI Engine et TLS Inspection conviennent à l’environnement. Sans visibilité propre sur le trafic HTTPS, un URL-Feed peut être moins efficace que prévu.

Pour les feeds de domaines et d’URL, la configuration du feed seule ne suffit pas toujours. La firewall a besoin d’une règle firewall adaptée au trafic et, selon le trafic, d’Application Classification ou d’une policy IPS. Pour les chemins URL complets en HTTPS, il faut aussi un déchiffrement Web Proxy ou DPI avec une règle SSL/TLS inspection correspondante. Si un feed ne semble générer aucun hit, il faut donc vérifier non seulement l’URL du feed, mais aussi la règle firewall, le chemin d’inspection et les exclusions.

Planification avant le rollout

Monitor ou Block ?

Selon la version SFOS et la configuration, un Threat Feed peut surveiller ou bloquer. Pour la sécurité productive, bloquer est souvent l’objectif, mais chaque feed ne doit pas passer aveuglément en mode Block dès le départ.

• Monitor : rendre les hits visibles sans bloquer directement le trafic. Vérifier volume de logs, sources/cibles touchées et hits inattendus.
• Block : stopper activement les indicateurs malveillants connus. Préparer processus de faux positifs, alerting et exceptions.
• Review : vérifier efficacité et effets secondaires. Évaluer qualité du feed, anciens hits, cas de support et risque métier.

Pour des services fortement exposés, un feed IPv4 bien curaté peut réduire directement beaucoup de bruit. Pour les Domain-Feeds ou URL-Feeds, il faut être plus prudent, car des services légitimes peuvent plus souvent utiliser une infrastructure partagée, des CDNs ou des redirections.

Sophos évalue les feeds Block et Monitor dans l’ordre affiché. Le premier hit correspondant est journalisé dans les deux types de feed ; le blocage se base sur le premier hit de la liste Block. L’ordre a donc une importance pratique : un feed Block productif et bien curaté ne doit pas se retrouver entre des feeds de test, des listes d’incident temporaires et des sources expérimentales.

Ordre et position des feeds

Lors de l’ajout d’un Third-Party Feed, on peut définir la position du feed. Cela semble banal, mais c’est utile en exploitation : les feeds critiques et bien curatés doivent être nommés et ordonnés clairement. Les feeds de test, feeds temporaires ou sources avec risque de faux positifs plus élevé ne doivent pas être cachés entre les feeds productifs.

Convention de nommage pratique :

• Feed IPv4 de blocage productif : cybora-premium-ipv4-block
• Domain-Feed en mode Monitor : cybora-standard-domain-monitor
• Feed temporaire d’incident : incident-2026-06-c2-ipv4

Un bon nom indique fournisseur, plan ou objectif, type d’indicateur et action. Cela fait gagner du temps dans le Log Viewer et lors des revues ultérieures.

Synchronisation et Storage Quota

Pour les Third-Party Threat Feeds, Sophos Firewall affiche les feeds actifs, le nombre total de Threat Indicators, le Storage Quota et le statut de synchronisation. Ces valeurs ne doivent pas être ignorées après la configuration.

Contrôles importants :

• Sync status : Success, Fetching ou Disabled sont rapides à classer. Pour Authentication error, Connection error, Storage full, SSL/TLS error ou Failed, il faut vérifier précisément la cause et le feed.
• Last updated : l’horodatage correspond à l’intervalle de polling attendu.
• Storage quota : la firewall dispose encore de suffisamment d’espace pour les IoC chargés.
• Threat indicators : le nombre correspond grossièrement à l’attente du fournisseur.
• Synchronize now : la synchronisation manuelle fonctionne lorsqu’une modification ne doit pas attendre le prochain intervalle de polling.

Si le Storage Quota est plein, le fournisseur du feed n’est pas automatiquement en cause. Les petites appliances ont moins de marge que les grands modèles. La firewall continue de récupérer les IoC à l’intervalle configuré et met à jour la liste dès que de l’espace redevient disponible. Il faut tout de même vérifier périmètre du feed, types d’indicateurs et priorité, au lieu d’ajouter toujours plus de listes.

Sur les petits modèles XGS, l’intervalle de polling peut aussi être limité. Selon Sophos, les XGS 87/87w, 88/88w et 107/107w ne prennent en charge que 24h, 7d et 30d comme options de polling interval pour les Third-Party Threat Feeds. Si un feed souscrit est mis à jour plus souvent, cette différence de plateforme doit être intégrée dans les attentes d’actualité et d’effet de blocage.

Du Free au Ultimate Threat Feed - by Cybora

Des informations de menace fiables et actuelles sont décisives. Avanet utilise donc des plans Threat Feed curatés de Cybora, spécialement adaptés à l’utilisation sur Sophos Firewalls.

Les feeds sont composés à partir de différentes sources afin d’obtenir une détection de menace aussi large et fiable que possible. Cela comprend des données community et OSINT, des informations commerciales, des résultats de honeypots ainsi que des logs anonymisés d’attaques, d’erreurs et d’anomalies issus d’environnements Sophos Firewall réellement exploités.

Free (Basic) convient aux home users, PoC et tests de compatibilité. Standard complète le feed IPv4 avec des domaines malware et phishing importants. Premium étend la couverture aux domaines et URL avec mises à jour horaires. Ultimate est conçu pour les infrastructures critiques et périmètres à haut risque avec mises à jour toutes les 15 minutes.

Avec Sophos Firewall Threat Feeds, une infrastructure malveillante connue peut être filtrée plus tôt. Selon l’environnement, le plan Basic gratuit suffit aux tests, tandis que Standard, Premium et Ultimate visent des exigences productives avec une couverture et une actualité croissantes.

Cybora convient surtout lorsqu’il faut un feed concret et achetable pour Sophos Firewall sans collecter, formater, vérifier et exploiter soi-même plusieurs listes OSINT. La valeur pratique réside moins dans la plus grande liste que dans des indicateurs curatés, des plans de feed clairs et un chemin d’exploitation adapté à la fonction Third-Party Threat Feed de Sophos Firewall.

Comparer les Threat Feeds

Lors de la comparaison, il ne faut pas regarder seulement le nombre d’entrées. Une liste immense n’est pas automatiquement meilleure si elle produit beaucoup de faux positifs ou si elle est mal entretenue. L’important est que le feed soit actuel, curaté et exploitable par la firewall.

Critères importants :

• Actualité des données
• Types d’indicateurs pris en charge
• Qualité et curation des sources
• Intervalle de mise à jour
• Risque de faux positifs
• Traçabilité dans le Log Viewer
• Processus d’exception pertinent

Avanet Firewall Network

Une partie du Premium Feed contient des données issues d’un réseau de firewalls distribué. Cette vue est particulièrement intéressante pour des modèles d’attaque peu visibles sur une seule firewall.

De nombreux outils détectent correctement les attaques brute-force d’une seule adresse IP, mais échouent avec des attaques distribuées par botnets. Dans ces cas, chaque hôte contrôlé par l’attaquant ne réalise que quelques tentatives de connexion infructueuses à basse fréquence et évite ainsi la détection et le blocage.

Certains botnets comprennent des centaines de milliers d’hôtes infectés, ce qui permet aux cybercriminels de mener des attaques brute-force massives sans être bloqués.

De tels modèles alimentent un Threat Intelligence Feed constamment mis à jour avec des IP remarquées sur plusieurs systèmes. En fusionnant ces données et en les injectant continuellement dans le Threat Intelligence Feed, les adresses IP qui attaquent spécifiquement l’infrastructure sont identifiées et automatiquement bloquées.

Ce que les Threat Feeds ne remplacent pas

Les Threat Feeds sont puissants, mais ne remplacent pas les bases d’une firewall propre.

Ils ne remplacent pas :

• règles firewall restrictives
• MFA pour VPN, portails et accès administrateur
• Device Access et Local Service ACL, comme décrit dans Sécuriser l’accès à Sophos Firewall
• IPS, WAF, Web Protection et TLS Inspection
• Patchmanagement et Hotfixes
• Logging, reporting et revue régulière

Par exemple, si un serveur Web est publié via DNAT, la règle firewall doit tout de même utiliser des sources aussi étroites que possible, des services précis et du logging activé. Un Threat Feed bloque de mauvaises sources connues, mais des attaquants nouveaux ou inconnus peuvent toujours arriver.

Configurer Sophos Firewall Threat Feed

L’intégration des Cybora Threat Feeds est simple et se fait en quelques minutes. Tous les feeds sont entièrement compatibles avec la fonction Third-Party Threat Feed de Sophos Firewall et peuvent être ajoutés comme suit via l’interface Web de la firewall :

1. Ouvrir le menu : Protect > Active threat response > Third-party threat feeds > Add
2. Saisir les données de base
   • Name : cybora-premium-ipv4
   • Description : Cybora Feed - Premium
3. Définir le type d’indicateur
   • Indicator type : IPv4 address, Domain ou URL
   • Créer un feed séparé par type d’indicateur si la même source propose des IP, des domaines et des URL.
4. Choisir l’action
   • Pour un blocage productif : Block.
   • Pour un démarrage prudent : choisir Monitor ou une action d’observation, si disponible et pertinente.
5. Saisir l’URL du feed
   • Dans le champ External URL, coller l’adresse appropriée depuis la liste de feeds Avanet.
   • L’URL doit fournir un fichier texte avec un indicateur par ligne.
6. Définir l’intervalle d’interrogation
   • Choisir Polling interval en fonction du feed réservé.
   • Un intervalle plus court n’aide pas si le feed lui-même n’est mis à jour qu’à un intervalle plus long.
7. Configurer l’authentification si nécessaire
   • Selon le feed, sans authentification, avec une clé API ou avec Basic Authentication.
   • Ne pas exposer les identifiants ni les clés de feed dans des tickets, captures d’écran ou documentations publiques.
8. Tester la connexion et enregistrer
   • Lancer Test connection.
   • Enregistrer ensuite avec Save.

Après l’enregistrement, il ne faut pas passer tout de suite au sujet suivant. Vérifier d’abord si le feed se synchronise, si le nombre attendu d’IoC est visible et si le Log Viewer affiche les hits avec nom du feed, action, source et destination de manière traçable.

Contrôle en exploitation

Après la configuration, il ne faut pas simplement supposer que tout fonctionne. Les hits doivent être visibles et explicables.

1. Vérifier System services > Log settings et activer le logging Active Threat Response.
2. Filtrer Active threat response dans le Log viewer.
3. Vérifier quel feed a matché.
4. Contrôler source, destination, service et règle firewall concernée.
5. En cas de faux positif, ne pas poser une exception large, mais vérifier et documenter l’indicateur concret.

Surtout pour DNAT, WAF et portails VPN, on voit souvent très vite après activation quelle quantité de trafic indésirable provient de mauvaises sources connues. Les Threat Feeds conviennent donc particulièrement bien comme bloc de protection supplémentaire pour des services exposés.

Si un feed ne montre aucun hit

Aucun hit ne signifie pas automatiquement que le feed est mauvais. Un autre composant Active Threat Response peut détecter le même IoC plus tôt, le trafic pertinent peut ne pas passer par la bonne règle firewall ou la firewall peut manquer de contexte pour les domaines et les URL.

Contrôles utiles :

1. Ouvrir Threat indicators et rechercher un indicateur de test connu.
2. Vérifier si le feed est actif et si le Sync status affiche Success.
3. Pour Authentication error, vérifier les identifiants ou la clé API.
4. Pour Connection error, vérifier DNS, accès internet, statut HTTP et serveur du feed.
5. Pour SSL/TLS error, vérifier le certificat CA et la chaîne de certificats du serveur du feed.
6. Pour Failed, vérifier le format du feed, l’accès au fichier dans le navigateur et les indicateurs invalides.
7. Vérifier la règle firewall et le Log Viewer pour le trafic attendu.
8. Pour les feeds de domaines, vérifier Application Classification ou la policy IPS.
9. Pour les feeds URL, vérifier Web Proxy, DPI et la règle SSL/TLS inspection.
10. Contrôler Threat Exclusions, Web Exclusions et SSL/TLS Exclusion Lists.
11. Si aucun hit pertinent n’apparaît après une phase d’observation, réévaluer périmètre ou position du feed.

Traiter les faux positifs

Des faux positifs sont possibles avec toute blocklist dynamique. L’essentiel est de les traiter proprement.

Processus pratique :

1. Ouvrir l’entrée concernée dans le Log Viewer.
2. Noter feed name, indicator type, action, source, destination et service.
3. Vérifier si le trafic est attendu et légitime du point de vue métier.
4. Vérifier ou signaler l’indicateur auprès du fournisseur du feed.
5. Définir l’exception aussi étroitement que possible.
6. Documenter ticket, raison et date de revue.

Une exception large pour des réseaux entiers n’est pas une bonne solution simplement parce qu’un utilisateur “ne peut pas ouvrir une page”. Pour les hits URL ou domaine, il faut aussi vérifier si TLS Inspection, Web Policy, DNS Protection ou une autre fonction de sécurité est impliquée.

Checklist d’exploitation

• Nom du feed, fournisseur, plan et owner documentés.
• Type d’indicateur défini clairement par feed.
• Action Monitor ou Block choisie consciemment.
• Polling interval adapté au feed.
• Validation de certificat et authentification testées.
• Statut de synchronisation et Storage Quota vérifiés.
• Active-Threat-Response-Logs visibles.
• Processus de faux positifs défini avec date de revue.
• Scénarios DNAT, WAF et VPN évalués selon la version SFOS.
• Alertes ou reports pour les hits récurrents planifiés.

FAQ