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. Local reporting stocke les logs d’événements localement pour le Log Viewer ; ces logs ne sont pas des rapports générés sur l’appliance. Il est également possible d’utiliser Sophos Fusion (anciennement Sophos Central) ou un serveur syslog comme destination de logs.
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 à la place, 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 selon les indications du fournisseur. Avec API key, saisir séparément le nom de l’en-tête ou du paramètre indiqué par le fournisseur et la valeur secrète, puis choisir Header ou Query parameters comme emplacement de transmission. Si un fournisseur exige par exemple l’en-tête X-API-Key, il s’agit du nom, et non de la clé secrète. Avec Basic authentication, saisir le nom d’utilisateur et le mot de passe. La valeur de la clé API et le mot de passe 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 une connexion ou une requête HTTP GET réussie, mais ni le traitement complet de la liste ni la détection ou le blocage effectif du trafic attendu. Le contenu et l’effet doivent être validés séparément.

Choisir correctement le feed et l’action

Indicateurs pris en charge

Chaque configuration de feed traite exactement l’un des types d’indicateurs 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. Si le fichier du fournisseur contient plusieurs types, SFOS ne prend en compte que le type sélectionné sous Indicator type. Une configuration distincte est donc nécessaire pour chaque type souhaité ; il n’est pas nécessaire de scinder un fichier mixte pour cette seule raison. 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.

Voici un exemple de format contenant uniquement des adresses IPv4 :

192.0.2.10
198.51.100.20

Ces adresses de documentation illustrent uniquement le format ; elles ne représentent ni de véritables menaces ni des destinations de test accessibles. Pour le test contrôlé décrit plus bas, utiliser à la place l’adresse IPv4 individuelle de sa propre destination de test, et non son réseau avec un suffixe CIDR. Pour Cybora, les fichiers de feed fournis sont utilisés directement.

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. L’intégration n’est pas limitée à une liste prédéfinie de fournisseurs : tout Third-Party Feed peut être intégré s’il respecte les exigences de fichier décrites. Sophos cite par exemple GreyNoise Intelligence, CrowdSec et Q-Feeds comme fournisseurs ; cette mention ne remplace ni la vérification du point de terminaison concerné ni un pilote en mode Monitor dans son propre environnement.

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. La vue d’ensemble des licences des modules mentionne le Xstream Appliance Bundle, tandis que l’aide de configuration mentionne le Xstream Protection Bundle. Avant un achat ou un déploiement, consultez la comparaison précise des licences et des sources NDR Essentials et faites confirmer les droits pour le pare-feu concerné.
• 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 et d’URL 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.

Le module chargé de l’inspection est alors le module Web pour le Web Proxy, ou IPS pour le moteur DPI avec des règles d’inspection SSL/TLS. Cela s’applique au trafic HTTPS chiffré comme déchiffré ; les IoC détectables dépendent toujours de la visibilité du seul domaine ou également du chemin 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

Sync status: Success confirme une connexion ou une requête HTTP GET réussie vers External URL, mais pas l’exhaustivité ni le traitement réussi de tous les indicateurs attendus. Test connection ne vérifie lui aussi que la connexion. 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 comme nombre de feeds actifs et de feeds configurés au total, Total threat indicators comme nombre d’indicateurs IPv4, de domaines et d’URL, ainsi que Storage quota comme espace occupé dans le quota propre au modèle. Les appliances de plus grande taille disposent de davantage d’espace que les modèles de bureau. Refresh actualise uniquement ces compteurs affichés. Synchronize now, sous Manage, 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 affiché dans Total indicators pour le feed concerné. Fetching signifie que le téléchargement est en cours ; Disabled signifie que le feed est désactivé.

En cas d’Authentication error, vérifier d’abord le nom de la clé API, sa valeur secrète et son emplacement de transmission, ou le nom d’utilisateur et le mot de passe. Si ces informations sont correctes, rechercher également un échec de négociation TLS : contrôler le certificat et la chaîne de confiance du serveur du feed et, si nécessaire, clarifier le problème avec le fournisseur. Une erreur d’authentification n’est pas toujours une erreur TLS. Validate server certificate reste activé ; l’absence de confiance envers la CA se corrige avec le certificat de CA approprié, et non en désactivant la vérification.

En cas de Connection error, contrôler le DNS, l’accès Internet, le serveur du feed et le statut HTTP ; les statuts 404, 500 et 302 peuvent également en être la cause. SSL/TLS error est un statut distinct pour les problèmes de certificat. En cas de Failed, vérifier que le fichier réellement fourni est en texte brut, contient un indicateur par ligne et utilise les types pris en charge appropriés ; d’autres erreurs sont également possibles. Après correction, exécuter à nouveau Test connection et Synchronize now, contrôler l’horodatage et l’IoC attendu, puis seulement répéter le test de trafic contrôlé. Si l’erreur persiste, consigner le statut, l’heure et les informations du feed expurgées de tout secret pour le fournisseur ou le support.

Storage full signifie que l’espace disponible ne suffit pas à stocker la liste complète. Le firewall 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 et les URL, 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é. Confirmer d’abord que la récupération et le chemin d’inspection fonctionnent, puis vérifier si MDR, NDR ou X-Ops détectent déjà les mêmes IoC. Un test bref sans détection ne justifie pas une suppression. Si le feed s’avère ensuite réellement redondant, documenter avant de le supprimer son nom, son URL, son type d’indicateur, son action, sa position, son intervalle de polling et l’emplacement sécurisé de ses identifiants. Sous Protect > Active threat response > Third-party threat feeds, supprimer le feed vérifié pour libérer de l’espace. Contrôler ensuite Refresh, Storage quota et Active feeds, puis récupérer à nouveau avec Synchronize now un feed qui avait échoué en raison de Storage full. Pour revenir en arrière, recréer le feed supprimé avec les valeurs documentées, d’abord en mode Monitor. La désactivation temporaire à des fins de rollback reste une opération distincte ; elle ne constitue pas une preuve que de l’espace a été libéré.

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 exception contrôlée se crée sous Protect > Active threat response > Add threat exclusions. Sous Host and network exclusions > Add new item, sélectionner 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 le 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.

Automatiser ThirdPartyFeed via XML

Pour automatiser cette même configuration de flux, l’interface XML utilise l’objet ThirdPartyFeed. Celui-ci configure la récupération et l’action, et non les IoC téléchargés individuellement. L’accès, l’opération d’écriture explicite, la structure de requête dépendant de la version et l’interprétation sécurisée de la réponse sont expliqués dans Sécuriser l’accès à l’API XML. Les noms de champs et les limites ci-dessous concernent SFOS 22 et 23 ; ils ne constituent pas encore une requête d’écriture complète. Avant toute utilisation, confirmer l’opération Add/Edit précise et sa charge utile dans API help du build installé. Si la syntaxe reste incertaine ou en cas de conflit entre les sources, ne pas effectuer d’écriture et demander une clarification au support.

Avant toute modification, identifier le flux existant dans WebAdmin à l’aide de son Name et sauvegarder son nom, son type d’indicateur, son URL, son action, son activation, sa position et son intervalle d’interrogation. Le nom désigne la configuration du flux, et non le fournisseur ou un IoC individuel. Un même fournisseur peut avoir plusieurs configurations portant des noms distincts pour IPv4, les domaines et les URL. Ne pas déduire du nom de l’objet une sémantique de renommage, d’upsert ou d’écrasement non vérifiée.

• Identité et source : Name est obligatoire, autorise au maximum 63 caractères et uniquement des lettres, des chiffres, des traits de soulignement et des traits d’union. Description est facultatif et limité à 255 caractères. ExternalURL est obligatoire et limité à 1024 caractères ; continuer à utiliser un flux HTTPS en texte brut directement accessible, avec un indicateur par ligne.
• Action et ordre : Action exige exactement block ou monitor, correspondant respectivement à Block ou Monitor dans l’interface utilisateur. monitor journalise les correspondances sans blocage par le flux ; block journalise et bloque. Les libellés Log only et Log and drop d’autres modules ne sont pas des valeurs de remplacement pour ce champ. Position autorise top ou bottom, correspondant à Top ou Bottom. Ce champ définit la position au sein des Third-Party Feeds, et non leur priorité par rapport à MDR, NDR Essentials ou Sophos X-Ops. Les listes de blocage et de surveillance restent distinctes ; la première correspondance de chaque liste fait foi.
• Type d’indicateur : IndicatorType exige ip, domain ou url, correspondant à IPv4 address, Domain ou URL. Ici, ip n’est pas un type IPv6, réseau ou plage. Créer une configuration distincte pour chaque type d’indicateur souhaité.
• Authentification : Authorization exige noAuthentication, basicAuthentication ou apiKey. Username et Password ne s’appliquent qu’à Basic Authentication, avec au maximum 64 caractères chacun. Key, Value et AddTo ne s’appliquent qu’à l’authentification par clé API : le nom de la clé et la valeur secrète sont distincts et limités chacun à 64 caractères ; l’emplacement de transmission est exactement header ou queryParam, correspondant à Header ou Query parameters. Les exigences du fournisseur sont déterminantes, et non une valeur par défaut supposée. Utiliser uniquement les champs propres à la méthode choisie ; récupérer les secrets depuis un magasin de secrets protégé et les exclure des fichiers XML du dépôt, des URL dans les tickets, de l’historique du shell, des captures d’écran et des journaux. Avec les paramètres de requête, veiller tout particulièrement à masquer les URL de flux journalisées.
• Vérification du certificat : ValidateServerCertificate est obligatoire ; l’exemple d’objet présente true et false. Pour un fonctionnement sécurisé, activer explicitement la vérification et établir au préalable la confiance envers l’autorité de certification appropriée. Une erreur TLS ou d’authentification ne justifie pas la désactivation de la vérification.
• Intervalle d’interrogation : PollingInterval est obligatoire et autorise exclusivement 5m, 15m, 30m, 1h, 6h, 24h, 7d ou 30d. Il s’agit de jetons fixes, et non d’un nombre de minutes librement définissable. Sur les XGS 87/87w, 88/88w et 107/107w, le choix reste limité à 24h, 7d et 30d. Par exemple, 1h convient à une mise à jour horaire du fournisseur uniquement sur un modèle prenant en charge cet intervalle.
• Activation et valeurs par défaut : Pour Enabled, le tableau des paramètres indique 1 et 0, tandis que l’exemple d’objet indique true et false. Il s’agit d’une différence de représentation non résolue, et non d’une preuve que ces notations sont interchangeables. Avant toute tentative d’écriture, clarifier la forme valide dans le build installé. Le tableau indique également monitor, top, ip et noAuthentication comme valeurs par défaut des champs correspondants ; contrôler les valeurs réellement enregistrées sur l’objet cible. Définir délibérément l’action, la position, le type et l’authentification plutôt que de se fier à des valeurs omises.

Interpréter les réponses Add/Edit de manière sûre

Les associations suivantes sont documentées pour Add Third-party threat feed et Edit Third-party threat feed. Les valeurs Message.* sont des symboles de message non résolus, et non des textes d’erreur littéraux ni des instructions suffisantes à elles seules pour agir :

En particulier, 409 / Message.CPResourceConflict correspondent à Add et 404 / Message.CPRecordNotFound à Edit. Ne pas assimiler ces associations propres à l’objet à des codes XML généraux ou à un statut de transport HTTP ; la réponse réelle et Status Message Information dans le build sont déterminants. Après chaque modification, comparer le flux enregistré dans WebAdmin aux valeurs attendues et vérifier l’Audit Trail. En cas d’erreur, de délai d’attente dépassé ou de réponse ambiguë, contrôler d’abord l’état effectivement enregistré avant de renvoyer un Add ou un Edit. Ne déduire d’un symbole aucune répétition automatique, aucun renommage ni aucune correction supposée.

Une réponse de configuration conforme ne prouve ni la récupération du flux, ni le contenu en IoC, ni l’effet sur le trafic. Ensuite, continuer à vérifier Test connection, Synchronize now, Last updated, Storage quota, un IoC attendu et un test de trafic contrôlé en Monitor. Ne passer à Block qu’après cette vérification ; en cas d’interruptions inattendues, rétablir l’action sauvegardée ou désactiver le flux de manière contrôlée comme décrit ci-dessus, sans utiliser une Threat Exclusion globale comme solution de remplacement.

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.