Configurer Sophos Firewall ATP : X-Ops Threat Feeds

L’ancienne fonction Advanced Threat Protection (ATP) s’appelle Sophos X-Ops Threat Feeds dans SFOS 22. Le firewall compare le trafic sortant à une base de données gérée par Sophos contenant des adresses IP, des domaines et des URL malveillants connus. Il peut ainsi empêcher, par exemple, qu’un client infecté atteigne un serveur de command-and-control connu.

Un Threat Feed est une liste régulièrement mise à jour de ces indicateurs, appelés IoCs (Indicators of Compromise). X-Ops reçoit automatiquement la base de données mondiale de SophosLabs ; aucune URL de flux personnalisée n’est renseignée. Sous Active Threat Response, il est possible de configurer un ou plusieurs modules : MDR Threat Feeds fournit des informations provenant des analystes MDR sur les menaces actives dans votre réseau ; NDR Essentials analyse le trafic du pare-feu à l’aide du machine learning, évalue les IoCs détectés et les consigne dans les journaux. Avec Third-Party Threat Feeds, en revanche, vous renseignez vos propres URL de flux. Un module X-Ops actif n’active pas automatiquement les autres modules.

Pour une utilisation en production, Log and drop est l’objectif. La fonction est désactivée par défaut et ne bloque le trafic après son activation que si cette action est sélectionnée.

Configurer X-Ops Threat Feeds

Le module X-Ops nécessite Network Protection. La mise en œuvre du contrôle des threat feeds requiert en plus Web Protection. Ces deux licences sont incluses dans les bundles Standard et Xstream Protection ou peuvent être acquises séparément ; X-Ops ne nécessite pas de licence Sophos Fusion (anciennement Sophos Central) supplémentaire.

Avant toute modification, il faut documenter le build du firmware, les licences, la valeur actuelle de Action, le périmètre d’inspection, les destinations des journaux et les exceptions. Pour Synchronized Security, une licence Intercept X dans Sophos Fusion ou Sophos Central est également nécessaire ; la licence X-Ops seule ne fournit pas d’intégration avec les endpoints. Il faut aussi vérifier si les règles de pare-feu réagissent à un Security Heartbeat rouge : le changement d’état documenté dans SFOS 23 peut alors affecter l’accès de l’endpoint, en plus du blocage de la connexion individuelle.

Ouvrir System services > Log settings.
Dans la ligne Active threat response, activer au moins Local reporting. Selon le mode d’exploitation, sélectionner également la destination syslog souhaitée et Central reporting. Enregistrer les destinations de logs prises en charge sur ce modèle dans la page Log settings avec Apply. Recharger la page et confirmer que les destinations sélectionnées sont toujours définies avant de passer à la configuration X-Ops. Les logs d’événements locaux ne sont pas équivalents aux rapports locaux ; les alternatives pour les modèles sans rapports locaux sont indiquées ci-dessous.
Ouvrir Protect > Active threat response > Sophos X-Ops threat feeds.
Activer Sophos X-Ops threat feeds.
Pour Action, choisir Log only pour un pilote court et contrôlé ou Log and drop pour la protection en production.
SFOS 23 : Log only consigne l’événement sans modifier le statut Security Heartbeat de l’endpoint. Log and drop consigne l’événement, bloque la menace et fait passer le statut Security Heartbeat de l’endpoint au rouge.
Sous Advanced security settings, choisir entre Inspect untrusted content et Inspect all content.
Enregistrer avec Apply.
Contrôler ensuite le réglage, les destinations de logs et les exclusions existantes.

Les XGS 87/87w et 88/88w ne prennent pas en charge le reporting local. Sur ces modèles, utiliser à la place Central Reporting ou un serveur syslog. La colonne Central reporting n’apparaît qu’après l’activation de l’option Send reports and logs to Sophos Central sous Sophos Fusion (anciennement Sophos Central).

Sophos recommande de bloquer les IoC connus plutôt que de simplement les consigner. Pour un environnement nouveau ou qui n’était pas encore surveillé, Log only peut néanmoins être utile pendant une phase d’observation courte et clairement limitée dans le temps. Cette phase nécessite un responsable et une date de passage au blocage ; sinon, la fonction risque de rester durablement active sans effet de blocage.

Ce que protège X-Ops – et ce qu’il ne protège pas

X-Ops contrôle les destinations malveillantes connues dans le trafic sortant transféré. Une détection typique se produit lorsqu’un client ou un serveur tente d’accéder à une adresse IP, un domaine ou une URL de malware, de phishing ou de C2 connu. Selon l’action choisie, la tentative est seulement consignée ou immédiatement rejetée.

La vue d’ensemble et la description de X-Ops présentent des contradictions : La matrice de trafic de la vue d’ensemble SFOS 22/23 indique que Destination Match n’est pas pris en charge par X-Ops, tandis que Source Match local l’est. La section de configuration de X-Ops décrit en revanche la recherche de correspondances avec des adresses IP, des domaines et des URL malveillants, sur laquelle repose l’inspection des destinations présentée dans cet article. Cette matrice contradictoire ne permet de déduire ni une garantie pour toutes les destinations du trafic transféré, ni une couverture fiable de Source Match local. Pour établir cette délimitation, une confirmation pour le build utilisé est nécessaire avant de remplacer les règles de protection existantes. Sur les autres points, la matrice indique sans contradiction l’absence de protection X-Ops pour les sources distantes avec DNAT/WAF et pour les sources du trafic destiné au système vers WebAdmin, le portail VPN ou le VPN. Pour ces services, des règles restrictives de pare-feu, de WAF et de Device Access restent nécessaires ; les flux alternatifs sont présentés dans l’article consacré à Third-Party Threat Feeds.

IPS, Malware Scanning et Zero-Day Protection remplissent également d’autres fonctions. X-Ops fonctionne sur la base d’indicateurs : une destination doit déjà être connue comme IoC malveillant. IPS détecte en revanche des schémas d’attaque connus dans le trafic. Les deux fonctions se complètent, mais ne se remplacent pas.

Active Threat Response contrôle les modules dans l’ordre suivant : MDR, NDR Essentials, Sophos X-Ops, puis Third-Party Threat Feeds. Si un module antérieur bloque le même IoC, le firewall arrête le contrôle. L’absence d’un log X-Ops ne signifie donc pas automatiquement qu’aucune protection n’a agi. Le guide sur les Third-Party Threat Feeds détaille l’ordre et les indicateurs qui se chevauchent.

Conditions requises pour une détection

L’activation seule ne garantit pas que le firewall puisse voir chaque indicateur IP, de domaine ou d’URL. Les informations visibles dans le chemin réseau concerné sont déterminantes.

Adresses IP

Pour détecter une adresse IP de destination, le trafic sortant doit passer par une règle de firewall appropriée. Le firewall peut comparer directement l’adresse de destination au feed X-Ops ; le déchiffrement TLS n’est pas nécessaire.

Domaines

Pour la détection des domaines, les paramètres requis liés à l’IPS doivent être effectifs : Application Classification doit être activé, ou une politique IPS doit être sélectionnée dans la règle de pare-feu concernée. Selon la documentation, Application Classification est activé par défaut ; son état réel doit néanmoins être vérifié. Il ne faut pas l’interpréter ici comme une option supplémentaire à activer dans chaque règle de pare-feu. Cette exigence concerne notamment HTTPS et les requêtes DNS adressées à des résolveurs externes via HTTP ou HTTPS. Si la classification requise fait défaut, la recherche de correspondances de domaines peut ne pas avoir lieu sur le chemin de trafic concerné.

Si le firewall répond lui-même aux requêtes DNS des clients, le module DNS effectue la comparaison du domaine. Si les clients utilisent un résolveur externe, ce chemin DNS doit également passer par le firewall et être visible avec les réglages IPS requis. Lorsqu’une détection de domaine manque, contrôler le chemin du résolveur réellement utilisé, et pas seulement la règle du client vers la destination Web.

URL complètes sur HTTPS

Une URL comprend le domaine, mais aussi un chemin, par exemple https://example.invalid/download/payload.exe. Avec du trafic HTTPS chiffré, le firewall ne voit normalement, sans déchiffrement, que le domaine via SNI, et non le chemin /download/payload.exe.

Le contrôle d’un indicateur d’URL complet nécessite Web Proxy avec le déchiffrement HTTPS activé ou une règle SSL/TLS Inspection appropriée avec Decrypt. TLS Inspection ne doit pas être activé globalement sans contrôle uniquement pour X-Ops : la distribution des certificats, la protection des données, les exclusions, la compatibilité des applications et les performances nécessitent un déploiement dédié.

Avec le Web Proxy, il faut sélectionner les options Use web proxy instead of DPI engine et Decrypt HTTPS during web proxy filtering sous Web filtering dans la règle de pare-feu appropriée. Sur le chemin DPI, Use web proxy instead of DPI engine reste désactivé ; la règle de déchiffrement appropriée est configurée sous Rules and policies > SSL/TLS inspection rules, avec Action défini sur Decrypt. Les deux chemins nécessitent également les conditions préalables de classification mentionnées ci-dessus pour une inspection complète des URL HTTPS. Seul le chemin de trafic dont la modification a été approuvée est modifié ; il faut ensuite vérifier la confiance dans les certificats, le fonctionnement normal du processus métier et la règle effectivement appliquée dans Log Viewer.

Choisir consciemment l’étendue de l’inspection

Sous Advanced security settings, l’étendue du trafic inspecté par X-Ops est définie :

Inspect untrusted content limite l’inspection au trafic dont les sources ou les destinations ne sont pas fiables. Ce réglage nécessite moins de ressources et constitue un point de départ pertinent lorsque la charge et les effets secondaires ne sont pas encore connus.
Inspect all content inspecte le trafic fiable et non fiable. La couverture est plus large, mais les performances peuvent être affectées, en particulier dans les environnements fortement sollicités.

Pour les réseaux de clients, de serveurs ou d’administration particulièrement sensibles, Inspect all content peut être pertinent si l’appliance dispose de réserves suffisantes. La modification doit être effectuée pendant une fenêtre de maintenance. L’utilisation du CPU, la latence, le débit et les retours du helpdesk sont ensuite comparés à l’état précédent.

La documentation décrit la différence de performances entre les deux périmètres d’inspection comme généralement faible, mais potentiellement importante en cas de trafic élevé. Avant le changement, la valeur actuelle est consignée. Si la comparaison révèle une dégradation significative, il faut rétablir le périmètre d’inspection précédent sous Advanced security settings, enregistrer avec Apply, puis vérifier à nouveau le processus métier, la charge et la journalisation. Il n’est pas nécessaire de désactiver systématiquement l’action de blocage pour cela.

Lors d’une mise en service, l’action et l’étendue de l’inspection ne doivent pas être modifiées plusieurs fois simultanément. Modifier d’abord la visibilité, puis l’action de blocage permet de mieux déterminer quel réglage a causé un problème.

Contrôler l’efficacité et le logging

Après l’enregistrement, le contrôle ne doit pas se limiter à vérifier que l’interrupteur est actif. Un contrôle d’exploitation fiable couvre trois niveaux :

Configuration : X-Ops est activé, et l’action ainsi que l’étendue de l’inspection souhaitées sont enregistrées.
Visibilité : la règle de firewall, Application Classification ou IPS ainsi que le déchiffrement TLS pour les URL HTTPS complètes correspondent au type d’indicateur.
Preuve : les détections sont visibles sous Log viewer > Active threat response ou dans la destination Central ou syslog configurée.

Pour obtenir une synthèse locale, ouvrez Reports > Network & threats > Active threat response. Le widget du même nom dans le Control Center présente une vue d’ensemble des hôtes concernés et des événements de menace. MDR et X-Ops affichent leur état et les menaces bloquées, NDR Essentials son état et les menaces surveillées ; Third-Party Threat Feeds affiche également les flux configurés et leur état de synchronisation. Configure ouvre la configuration, Reports les rapports et More details développe la vue du widget. Sur les appareils sans rapports locaux le bouton Reports est absent ; les destinations Central ou Syslog configurées sont alors utilisées. Un compteur NDR de menaces surveillées ne constitue pas une preuve de blocage. L’action précise et les détails de connexion doivent être vérifiés dans le rapport ou dans Log Viewer. Pour Third-Party Threat Feeds, le widget affiche également le nombre de menaces bloquées par ces flux.

Le type de log syslog technique reste ATP, même si l’interface utilise aujourd’hui X-Ops et Active Threat Response. Selon le chemin de traitement, log_component peut indiquer Firewall, DNS, IPS ou Web. Pour une analyse, l’horodatage, l’action, la source, la destination, les ports, le domaine ou l’URL, le nom de la menace, le nom du feed et l’Event ID sont particulièrement utiles.

Dans Advanced Shell, ips.log est le principal log du moteur pour Active Threat Response. garner.log aide à analyser le traitement et la transmission des événements, notamment lorsque Central Reporting semble incomplet. Ces fichiers et l’accès SSH sécurisé sont expliqués dans la vue d’ensemble des services et fichiers de logs de Sophos Firewall.

Il n’existe pas d’indicateur de test X-Ops inoffensif documenté de manière générale. Il ne faut donc pas accéder volontairement à un véritable domaine de malware ou à une adresse IP malveillante connue. Si un test fonctionnel reproductible est nécessaire, un Third-Party Threat Feed pilote dédié avec une destination de test contrôlée constitue la méthode la plus sûre. Pour X-Ops lui-même, la configuration et la visibilité sont contrôlées ; la prochaine détection réelle et soigneusement analysée confirme l’effet de blocage effectif.

Lorsqu’un IoC n’est pas bloqué ou qu’aucun log X-Ops n’apparaît

Commencer par le type d’indicateur concerné et le chemin réel du trafic. On évite ainsi des exclusions trop larges ou des modifications TLS globales fondées sur une supposition :

Sous Protect > Active threat response > Sophos X-Ops threat feeds, vérifier que X-Ops est actif et que Action est bien réglé sur Log and drop. Log only crée uniquement une entrée.
Dans Log viewer > Active threat response, vérifier, pour le même IoC, le module, l’action réellement appliquée et les détails de connexion. Seule une action de blocage avérée d’un module antérieur, par exemple MDR avec Log and drop, met fin à l’inspection avant X-Ops. NDR Essentials détecte et journalise les menaces avec Log threats, mais ne les bloque pas. Un événement surveillé par NDR ne suffit pas à interrompre l’inspection X-Ops et n’explique pas l’absence d’une entrée de log X-Ops.
Pour une adresse IP de destination, contrôler la règle LAN-to-WAN qui s’applique réellement. Pour un domaine, contrôler aussi Application Classification, la politique IPS et le chemin du résolveur.
Pour une URL HTTPS complète, rechercher le nom du serveur dans Log viewer > SSL/TLS inspection. Si la SSL/TLS rule correspondante indique Don't decrypt, X-Ops ne peut pas voir le chemin de l’URL. Ne prévoir une règle Decrypt aussi ciblée que possible qu’après avoir identifié cette règle.
Recherchez le domaine ou l’URL dans Log viewer > Web filter ; vérifiez également la colonne Category et la vue détaillée. Vous y trouverez l’ID de la règle de pare-feu et la politique Web sélectionnée correspondants. Si la Web policy responsable indique Allow, vérifiez l’ordre des règles et des politiques. Pour un domaine ou une URL dont le caractère malveillant est confirmé, vous pouvez utiliser un groupe d’URL au périmètre strictement limité avec une action de politique Web Block, dans une règle LAN-to-WAN appropriée placée au-dessus de la règle qui autorisait jusque-là le trafic. Sur le chemin Web Proxy, vérifiez également Web > Exceptions : URL pattern matches, Web categories, Destination IP addresses et Source IP addresses peuvent inclure l’indicateur ou l’endpoint à l’origine de la requête. Sur le chemin DPI, contrôlez les SSL/TLS Exclusion Lists. Une exception ne doit pas être supprimée systématiquement ; il faut d’abord clarifier son objectif, le processus métier concerné et l’approbation.
Sous Protect > Active threat response > Add threat exclusions, rechercher l’IoC ainsi que l’hôte ou le réseau à l’origine de la requête. Ces exclusions s’appliquent à tous les modules.

Après chaque correction, répéter le même processus métier et contrôler les logs concernés. Si la cause reste incertaine, conserver l’horodatage, l’ID de la règle firewall, l’ID de la règle Web ou SSL/TLS et la vue détaillée de l’événement Active Threat Response pour le ticket de support.

Analyser une alerte X-Ops

Un IoC bloqué constitue un signal fort, mais pas une analyse d’incident complète. La destination peut avoir été contactée par un malware, un lien de phishing, une extension de navigateur compromise ou un service légitime mais mal classé.

Une procédure pertinente est la suivante :

Sauvegarder l’horodatage, le firewall ou le nœud HA, l’action et l’intégralité des détails du log.
Relever l’adresse IP source, l’adresse IP de destination, le domaine ou l’URL, les ports, le protocole, le nom de la menace et le nom du feed.
Corréler les logs firewall, DNS, IPS et Web dans la même fenêtre temporelle.
Identifier le client interne au moyen du bail DHCP, de l’affectation utilisateur ou des données Endpoint.
Rechercher sur le système concerné le processus associé, l’historique du navigateur, le téléchargement et d’autres événements de sécurité.
Si la compromission est confirmée, isoler le système et le traiter conformément au runbook interne d’Incident Response.
Décider seulement après l’analyse si une correction, un blocage supplémentaire ou une exclusion strictement limitée est nécessaire.

Avec Synchronized Security, les endpoints Windows pris en charge peuvent également afficher l’utilisateur du processus, l’Endpoint ID et le chemin d’exécution. Ces détails de processus ne sont pas disponibles sur macOS ; l’adresse IP source reste donc particulièrement importante pour l’attribution.

Faux positif HA connu `NC-170292`

Sur un système HA avec SFOS 21.5.1 MR1 Build 261, NC-170292 peut déclencher dans Sophos Fusion une fausse alerte Advanced threat detected avec des Raw Logs. Un e-mail du firewall peut arriver simultanément sans détails exploitables.

Cette limitation ne s’applique pas de manière générale aux autres builds ni aux firewalls standalone. Une alerte doit donc d’abord être sauvegardée et analysée comme décrit ci-dessus. Si le système correspond exactement au build concerné et qu’aucun détail de détection fiable n’est disponible, Sophos indique le redémarrage du service Garner comme workaround temporaire. Comme la liste Known Issues ne fournit aucune commande CLI précise pour cette erreur, le redémarrage ne doit être effectué que dans le cadre d’une procédure de support ou de maintenance approuvée. En cas d’alertes récurrentes, le statut HA, le build du firmware, l’horodatage et garner.log doivent être joints au ticket Sophos Support.

Ajouter des exclusions uniquement après une analyse confirmée

Sous Protect > Active threat response > Add threat exclusions, des Host and network exclusions et des Threat exclusions peuvent être créées pour des adresses IP, des domaines ou des URL. Une entrée Threat exclusions peut contenir au maximum 128 caractères. Une telle exclusion ne s’applique pas seulement à X-Ops, mais à tous les modules Active Threat Response. Une exclusion rapide peut donc également affaiblir la protection assurée par MDR, NDR ou Third-Party Threat Feeds.

Lorsqu’un false positive est confirmé, seul le plus petit indicateur nécessaire doit être exclu. L’exclusion doit inclure le motif, le ticket, le responsable et la date de révision. Exclure par précaution des réseaux clients entiers ou de larges plages de domaines supprime certes l’alerte visible, mais aussi une grande partie de la protection.

Pour une exclusion approuvée, ouvrir Protect > Active threat response > Add threat exclusions et utiliser l’une des alternatives suivantes selon le type d’exclusion :

Hôtes ou réseaux : Sous Host and network exclusions, cliquer sur Add new item et sélectionner uniquement les objets hôte ou réseau approuvés.
Indicateur de menace : À la place, sous Threat exclusions, saisir l’adresse IP, le domaine ou l’URL approuvé et l’ajouter à la liste avec Add. Respecter la limite de 128 caractères par entrée.

Enregistrer ensuite avec Apply. Ouvrir à nouveau la page et vérifier que seules les entrées prévues ont été enregistrées. Add new item ou Add ne remplace pas à lui seul cette étape finale d’enregistrement.

Après la modification, le même processus métier est testé à nouveau et le Log Viewer est contrôlé afin de vérifier que seule la détection prévue disparaît. Les autres événements X-Ops doivent continuer à être consignés ou bloqués.

Pour revenir en arrière, seule la dernière modification effectuée est annulée : le périmètre d’inspection est rétabli à la valeur précédente documentée et enregistré avec Apply ; une règle ou une exception Web/SSL/TLS nouvellement créée est annulée de manière ciblée, sans modifier les règles existantes ni les autres exceptions. Le processus métier, la règle qui correspond effectivement et les logs sont ensuite vérifiés à nouveau. Si une exception est annulée, la correspondance concernée peut à nouveau être bloquée. Si un incident opérationnel nécessite temporairement Log only, le blocage par X-Ops est suspendu pendant cette période ; les responsables et l’heure de fin sont définis, et Log and drop est rétabli une fois la cause clarifiée. Un module désactivé ne constitue pas un retour en arrière équivalent, car l’inspection qu’il effectue est alors également supprimée. Un test contrôlé avec un flux pilote dédié sous Third-Party Threat Feeds valide uniquement le parcours du trafic de ce flux, et non la livraison de la base de données X-Ops ni la correspondance avec ses entrées.

API XML : traiter séparément l’activation, l’action et les exclusions

Pour automatiser X-Ops, il faut distinguer trois paramètres indépendants dans l’objet XML documenté ATP. La référence de l’API SFOS 22/23 décrit les éléments suivants :

ATP/ThreatProtectionStatus : commutateur scalaire du module, avec les valeurs Enable ou Disable. Il active ou désactive X-Ops ; il ne correspond ni à l’action appliquée lors d’une détection, ni à une exclusion individuelle.
ATP/Policy : action scalaire appliquée lors d’une détection. Le tableau des paramètres indique Log Only et Log and Drop, présente Log Only comme valeur par défaut et signale que ce champ est obligatoire lorsque X-Ops est activé. Il s’agit d’une indication du tableau de l’API, et non d’une preuve de l’état enregistré sur votre firewall.
ATP/InspectContent : périmètre d’inspection scalaire, avec les valeurs all ou untrusted. Un périmètre d’inspection différent n’équivaut ni à Disable, ni à un changement de l’action appliquée lors d’une détection.
ATP/HostException/Host : liste de chaînes de caractères pour les hôtes ou réseaux sources à exclure. L’exemple utilise HostName ; pour créer une entrée, il faut disposer de la référence d’objet approuvée dans votre propre configuration.
ATP/ThreatException/Threat : liste distincte de chaînes de caractères pour les indicateurs de destination à exclure. Le tableau de l’API mentionne les adresses IP de destination et les domaines. La saisie d’URL dans l’interface décrite ci-dessus ne prouve pas, à elle seule, l’existence d’une syntaxe de payload XML pour les URL.

Les deux listes d’exclusions sont donc imbriquées sous des éléments parents différents et peuvent contenir plusieurs entrées. Ce ne sont pas des commutateurs de désactivation globale. Le tableau de l’API indique leur effet sur X-Ops, MDR et Third-Party Threat Feeds ; l’avertissement plus large concernant leur portée sur plusieurs modules et les règles d’approbation de la section sur les exclusions restent donc importants.

Clarifier le conflit concernant Policy avant toute requête d’écriture : L’exemple XML utilise le texte alert/drop pour Policy, alors que le tableau des paramètres indique Log Only et Log and Drop. Ces formes ne sont pas converties implicitement les unes dans les autres ; la graphie des libellés de l’interface ne prouve pas non plus qu’une valeur est valide pour l’API. Avant toute automatisation, il faut confirmer la valeur exacte et la structure de la requête à l’aide de l’aide de l’API du build installé ou auprès de Sophos Support. D’ici là, l’exemple ne constitue pas une requête prête à copier dont le fonctionnement a été vérifié.

La configuration sécurisée de l’API XML est traitée séparément. Avant une modification approuvée, il faut sauvegarder l’état du module, l’action, le périmètre d’inspection et les deux listes d’exclusions. Ensuite, il faut relire l’état effectivement enregistré ou ouvrir la page de configuration, puis comparer séparément ces cinq éléments. En cas d’erreur, vérifier d’abord l’état enregistré avant de réessayer ; une exclusion ou un périmètre d’inspection différent ne doit pas entraîner involontairement une désactivation globale.