Configurer Sophos Firewall ATP : X-Ops Threat Feeds

L’ancienne fonction Advanced Threat Protection (ATP) s’appelle Sophos X-Ops Threat Feeds dans les versions SFOS actuelles. 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.

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

Avant l’activation, Network Protection et Web Protection doivent être sous licence. Ces deux fonctions sont incluses dans les bundles Standard et Xstream Protection ; X-Ops ne nécessite pas de licence Sophos Central supplémentaire.

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.
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.
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 107/107w 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 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.

X-Ops ne prend pas en charge les source matches locaux ou distants. Il ne bloque donc pas automatiquement les adresses IP d’attaquants connus qui accèdent comme source à une publication DNAT ou WAF, au WebAdmin ou à un portail VPN. Pour ces cas d’usage, MDR, NDR, les Third-Party Threat Feeds ainsi que des règles restrictives de firewall, WAF et Device Access sont plus adaptés.

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.

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 détecter un domaine, Application Classification doit être activé dans la règle de firewall concernée ou une politique IPS doit être sélectionnée. En l’absence des deux, la classification nécessaire peut ne pas avoir lieu sur ce chemin de trafic.

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é.

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.

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 afficher un résumé local, ouvrir Reports > Network & threats > Active threat response. Le widget du même nom dans le Control Center affiche l’état et le nombre de menaces bloquées ; l’action précise et les détails de connexion se contrôlent dans le rapport ou le Log Viewer.

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.

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 Central 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 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.

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.