Configurer et vérifier Linux Runtime Detection pour les serveurs Sophos
Linux Runtime Detection (RTD) surveille les processus et applications en cours d’exécution sur les serveurs Linux équipés de Sophos Protection for Linux (SPL). Une détection RTD signale une activité suspecte ; elle ne signifie pas que RTD a bloqué le processus ou l’a éliminé. RTD complète Server Threat Protection, mais ne remplace ni sa protection contre les malwares ni l’analyse en temps réel sous Linux. L’arrêt des processus malveillants lors d’une détection de malware en temps réel relève d’un paramètre distinct de Server Threat Protection, et non de RTD. Le seul enregistrement d’une configuration de profil n’active aucune détection sur un serveur.
En bref : vérifier la licence et les serveurs SPL → activer Linux runtime detections dans la stratégie Server Threat Protection effectivement appliquée → activer une stratégie Linux Runtime Detection pour un petit groupe de serveurs Linux, avec les détections SophosLabs par défaut ou une version de profil choisie explicitement → vérifier l’attribution et les détections → élargir le déploiement seulement ensuite.
Prérequis et choix à faire avant le pilote
Les stratégies RTD ne s’appliquent qu’aux serveurs Linux, et non aux serveurs Windows ni au Sophos Linux Sensor, configuré séparément. Selon la documentation Sophos relative à la stratégie RTD, une licence Sophos XDR - Server ou Sophos MDR Plus - Server est requise. Il ne faut pas en déduire qu’une licence générique Server Protection, Endpoint ou une autre licence MDR donne droit à RTD. Vérifiez la licence serveur précise, la disponibilité de la fonction dans votre tenant et l’agent SPL installé avant d’autoriser le pilote. Si la stratégie ou la licence n’est pas disponible, ne tentez pas de la remplacer par une configuration Endpoint ou Sensor supposée équivalente.
Choisissez un serveur Linux représentatif mais peu critique et créez un groupe pilote dédié, par exemple linux-rtd-pilot. Son nom est libre, mais ses membres doivent correspondre aux serveurs concernés. Consignez les stratégies précédemment appliquées, l’appartenance aux groupes et, le cas échéant, le nom du profil ainsi que sa Profile Version. Vous pourrez ainsi annuler précisément la modification sans toucher à la protection de base. Une règle RTD peut signaler une activité légitime : surveillez donc aussi les opérations de maintenance et d’automatisation du pilote.
Configurer la stratégie et, si nécessaire, un profil
- Dans Sophos Fusion, ouvrez la stratégie Server Threat Protection appliquée aux serveurs pilotes sous My Products > Server > Policies. Affichez les options pertinentes avec Show filters > Operating System > Linux. Sous Runtime Protection, vérifiez que Linux runtime detections est activé, puis enregistrez la stratégie. Si cette stratégie protège aussi d’autres serveurs, créez ou utilisez une stratégie limitée au groupe pilote plutôt que de modifier toute la flotte à son insu. Le commutateur distinct Enable scan for Server Protection for Linux agent contrôle l’analyse en temps réel des fichiers sous Linux ; ce n’est pas le commutateur RTD et il ne doit pas être désactivé pour un test RTD.
- Avant de créer la stratégie RTD, choisissez votre approche : Sophos Labs Default Detection utilise les détections SophosLabs par défaut, sans ajustement personnalisé des règles. Ne choisissez Linux Runtime Detection Profile que si vous devez adapter et versionner délibérément certaines règles ou leurs listes d’autorisation et de blocage. Un profil repose lui aussi sur le contenu SophosLabs ; il ne remplace pas la stratégie.
- Uniquement si vous utilisez un profil : ouvrez My Products > Global Settings > Protection and Remediation > Linux Profiles, cliquez sur Create Profile, donnez-lui par exemple le nom
linux-rtd-pilot, vérifiez Content Version, renseignez éventuellement Change Description et ne modifiez que les règles dont vous comprenez le fonctionnement. Save crée d’abord la version 1. Pour une modification ultérieure, utilisez Create New Version ; notez la Profile Version approuvée pour le pilote. La version du profil (votre configuration) et la Content Version (le contenu SophosLabs) sont deux choses différentes. Consignez donc les deux à chaque modification, au lieu de considérer le numéro de version du profil comme un état complet des détections. SPL récupère toujours la version la plus récente du contenu SophosLabs par défaut ; les profils existants sont également mis à jour avec les nouveaux contenus SophosLabs. En revanche, les mises à jour de contenu sélectionnées manuellement concernent le Sophos Linux Sensor, géré séparément, et non la stratégie serveur SPL. Réexaminez vos adaptations de règles après toute mise à jour ultérieure du contenu. - Sous My Products > Server > Policies, créez une stratégie Linux Runtime Detection. Ouvrez Settings, activez Enable Linux Runtime Detection, puis choisissez Sophos Labs Default Detection ou Linux Runtime Detection Profile. Dans le second cas, sélectionnez explicitement Profile et Version. Activez la stratégie, attribuez-la uniquement au groupe pilote, puis cliquez sur Save. Vérifiez ensuite son attribution : le seul enregistrement d’une stratégie ou d’un profil ne prouve pas que les serveurs ciblés l’appliquent.
Vérifier la portée : un même profil peut être utilisé dans plusieurs stratégies RTD. Avant de créer une version ou de modifier une règle, développez Active sous Linux Profiles et vérifiez les stratégies concernées. Une modification apportée à une stratégie partagée peut toucher plusieurs groupes. Ne désactivez pas une règle à grande échelle et ne créez pas d’exception globale pour répondre rapidement à un seul faux positif.
Vérifier l’application de la stratégie et les détections
Ouvrez My Products > Server > Servers > Server Groups, sélectionnez linux-rtd-pilot et vérifiez dans l’onglet Policies que la stratégie Threat Protection et la stratégie RTD activées s’appliquent au groupe. Vérifiez également sur le serveur concerné la stratégie réellement attribuée ainsi que l’état actuel de l’agent et de sa connexion. Si vous utilisez un profil, les champs Profile et Version de la stratégie RTD doivent correspondre au choix approuvé. Une entrée sous Linux Profiles > Active indique les stratégies utilisant le profil, mais ne prouve pas qu’un test a déclenché une détection sur l’hôte.
Surveillez ensuite les détections du serveur pilote sous Threat Analysis Center > Detections et consignez pour chaque alerte l’heure, le serveur, la règle, le processus observé et le contexte métier. Cette vue nécessite des données téléversées depuis l’appareil ; si aucune donnée n’y parvient, vérifiez également le transfert des données vers le Data Lake applicable au serveur. Une détection RTD pertinente confirme qu’un événement a été signalé, pas que RTD l’a bloqué ou éliminé. L’absence d’alerte en fonctionnement normal ne prouve ni que le dispositif fonctionne ni qu’il est défaillant. Ne déclenchez pas d’actions malveillantes sur les serveurs de production pour effectuer un test.
Si les données attendues manquent, vérifiez d’abord la licence et le tenant, la connexion SPL ainsi que l’attribution effective des deux stratégies activées. Si vous utilisez un profil, vérifiez aussi qu’il contient la règle pertinente et que celle-ci est Enabled. Selon Sophos, des derniers chiffres de build différents entre Content Version dans Fusion et rtd_content_version sur l’appareil Linux ne signifient pas nécessairement que le contenu est obsolète ; ne changez pas la version du profil à l’aveugle. Si un problème de stratégie, d’agent ou de téléversement reste inexpliqué, transmettez les horodatages et l’état des stratégies au support Sophos plutôt que d’utiliser une commande de test non documentée ou de forcer le redémarrage de l’agent. L’analyse d’une détection suspecte relève de votre équipe de sécurité ou de votre prestataire MDR ; en cas d’incident actif, appliquez la procédure de réponse aux incidents.
Limiter les faux positifs et revenir en arrière sans risque
Face à une alerte suspecte, commencez par examiner les faits : le processus est-il autorisé, quel hôte et quelle règle sont concernés, et une maintenance correspondante était-elle prévue ? Ce n’est qu’après cette vérification qu’il faut examiner dans le profil la règle précise et sa Allow/Block List. Préférez un ajustement étroitement ciblé à une désactivation générale de la règle ; documentez sa portée, sa justification et sa version, puis vérifiez-le à nouveau uniquement avec le groupe pilote. Modifier une liste d’autorisation ou de blocage peut réduire ou altérer les détections. Si vous ne pouvez pas confirmer qu’il s’agit d’un faux positif, n’autorisez pas le processus : confiez la suite de l’enquête à l’équipe de sécurité ou au prestataire MDR.
Pour revenir en arrière, rétablissez d’abord l’attribution de la stratégie RTD au groupe pilote ou la sélection de son profil à l’état antérieur documenté, puis vérifiez de nouveau la stratégie réellement appliquée. Si une nouvelle version du profil pose problème, resélectionnez dans la stratégie pilote la Profile Version précédemment consignée et enregistrez ; vérifiez au préalable les autres stratégies qui utilisent ce même profil. Cela ne rétablit que la configuration de profil enregistrée ou l’attribution de la stratégie : avec SPL, cette opération ne restaure pas le contenu de détection SophosLabs mis à jour entre-temps et ne fige pas une ancienne Content Version. Réexaminez les adaptations de règles à la lumière du contenu actuel. Vous ne pouvez remettre Linux runtime detections dans son état précédent que si le pilote a activé ce prérequis, auparavant désactivé, dans une stratégie Threat Protection qui lui était spécifiquement attribuée. Ne désactivez pas l’analyse en temps réel sous Linux, l’ensemble de Server Threat Protection ou SPL pour annuler un pilote RTD : vous retireriez une autre couche de protection. Vérifiez ensuite à nouveau l’état de la connexion, les stratégies effectivement appliquées et les éventuelles nouvelles détections.