Sophos Managed Risk : configurer les identifiants pour les scans authentifiés

Lors d’un scan interne authentifié des vulnérabilités, le scanner se connecte au système cible. Il peut ainsi examiner les fichiers locaux, les entrées du Registre, les logiciels installés et les configurations qui ne sont pas visibles lors d’un scan sans identifiants. Il détecte donc généralement davantage de vulnérabilités. Un scan non authentifié reste néanmoins utile : il reflète mieux ce qu’un attaquant externe dépourvu de compte pourrait atteindre.

La procédure sécurisée se déroule en quatre étapes :

Préparer un compte de scan dédié disposant des autorisations requises pour les contrôles prévus.
Rendre le système d’exploitation cible accessible via SMB/WMI ou SSH.
Créer le type d’identifiant approprié sous Managed Risk > Settings > Credentials > Add credential.
Attribuer l’identifiant à un scan interne des vulnérabilités avec Scan type: Authenticated, puis valider le résultat lors du scan suivant.

Préparer les systèmes cibles avant d’utiliser Sophos Fusion

La préparation s’effectue directement sur la cible Windows, macOS ou Linux, indépendamment de la saisie ultérieure des identifiants dans Sophos Fusion. Même un formulaire Fusion correctement rempli ne peut compenser l’absence de partages, de services ou d’autorisations sur la cible.

Windows

Pour les terminaux et serveurs Windows autres que les contrôleurs de domaine, utilisez un compte local dédié appartenant au groupe Administrateurs local. Les contrôleurs de domaine nécessitent en revanche un administrateur de domaine et doivent faire l’objet d’un scan distinct avec leurs propres identifiants. Le compte doté des privilèges les plus élevés ne sera ainsi pas utilisé sur les serveurs membres ou les clients.

Vérifiez les points suivants avant l’attribution :

Les stratégies de sécurité telles que Deny access to this computer from the network et Access this computer from the network, les autres stratégies locales, la protection des terminaux et les systèmes IPS/IDS ne doivent pas bloquer les contrôles d’identifiants prévus.
Certains contrôles locaux nécessitent PowerShell 5.0 ou une version ultérieure.
Le scanner nécessite un accès SMB et WMI. Le pare-feu de l’hôte doit autoriser les connexions provenant de l’adresse IP de l’appliance de scan Managed Risk ; les ports TCP 139 et 445 sont requis pour File and Printer Sharing. Les ports des autres services à contrôler doivent également être accessibles depuis le scanner.
Les partages administratifs IPC$, ADMIN$ et C$ doivent être disponibles.
Remote Registry doit être en cours d’exécution ou pouvoir être démarré avec les droits d’administration utilisés pour le scan.
Pour les scénarios de comptes Windows décrits ici, Network access: Sharing and security model for local accounts doit être défini sur Classic - local users authenticate as themselves. Cette exigence s’applique aussi bien à un compte de domaine utilisé pour les audits locaux qu’à un compte local ; une connexion en tant qu’invité ne suffit pas pour les contrôles de sécurité locaux.
Pour les comptes locaux, l’UAC ne doit pas filtrer le jeton d’administrateur distant. Les options documentées consistent à désactiver l’UAC ou à définir sur 1 la valeur DWORD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy. N’appliquez une telle modification de sécurité que dans le cadre du processus interne de gestion des changements et limitez-la aux systèmes concernés.
Pour WMI, activez les règles entrantes prédéfinies Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) et Windows Management Instrumentation (DCOM-In). Dans la mesure du possible, limitez ces règles à l’adresse IP de l’appliance de scan.

Ne remplacez pas ces exigences par une règle de pare-feu générale ouverte à n’importe quelle source. Si l’appliance de scan et une cible se trouvent dans des VLAN différents, les spécifications du scan imposent à l’appliance un accès bidirectionnel complet à tous les ports et protocoles du VLAN cible. Le routage et les pare-feu intermédiaires doivent autoriser cet accès ; limitez toutefois les règles à l’appliance et aux plages de cibles prévues.

macOS

Les cibles macOS sont contrôlées via SSH, soit avec une paire de clés, soit avec des identifiants utilisateur et sudo ou su. Pour effectuer tous les contrôles locaux, le compte de scan doit appartenir au groupe des administrateurs et disposer de l’autorisation Full Disk Access. Des droits plus restreints permettent tout de même certains contrôles, comme la détermination du niveau de correctifs, mais pas une inspection aussi approfondie. Le compte dédié doit porter le même nom d’utilisateur sur toutes les cibles macOS prévues ; privilégiez l’accès par clé aux identifiants utilisateur lorsque cela est possible.

Les conditions suivantes doivent être remplies avant le scan :

Activez Remote Login et autorisez le compte de scan dédié.
Dans le réglage système Remote Login, activez Allow full disk access for remote users. Accordez également Full Disk Access sous Privacy & Security aux deux processus documentés : /usr/libexec/sshd-keygen-wrapper et /Library/NessusAgent/run/sbin/nessus-service.
Pour Kerberos, sshd doit prendre en charge Kerberos et utiliser la méthode d’interaction gssapi-with-mic, et la résolution DNS inverse doit fonctionner.
Le serveur SSH et le scanner doivent prendre en charge un algorithme de chiffrement commun. Les algorithmes documentés sont blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc et AES-CTR. N’activez pas de manière générale un chiffrement obsolète uniquement pour le scan ; vérifiez d’abord si une option commune sécurisée est déjà disponible.
Pour un accès par clé, placez la clé publique dans le fichier authorized_keys du compte dédié et ne fournissez la clé privée au scanner que sous une forme protégée.

Linux

Les cibles Linux sont également contrôlées via SSH, avec une paire de clés ou avec des identifiants utilisateur et sudo ou su. Pour obtenir l’inspection la plus approfondie possible, le compte doit pouvoir exécuter des commandes avec les privilèges root. Un compte moins privilégié peut fournir des résultats partiels, mais ne permet pas de couvrir entièrement les contrôles de configuration et de fichiers.

Vérifiez les points suivants avant le scan :

Créez un utilisateur SSH dédié portant exactement le même nom sur toutes les cibles prévues. Si l’authentification repose exclusivement sur une clé, le compte ne doit pas avoir de mot de passe valide ; placez la clé publique dans authorized_keys et conservez la clé privée protégée sur le scanner.
Autorisez la connexion SSH et l’élévation de privilèges prévue depuis le réseau de l’appliance de scan.
Pour Kerberos, sshd doit prendre en charge Kerberos et utiliser gssapi-with-mic, et la résolution DNS inverse doit fonctionner.
La configuration du shell du compte de scan doit définir une variable PS1 d’au moins quatre caractères. Une invite très courte telle que PS1='$ ' peut ralentir considérablement le scan.
Les options de chiffrement SSH documentées sont les mêmes que pour macOS. Utilisez les algorithmes communs sécurisés déjà disponibles et n’élargissez pas inutilement la configuration de l’hôte.

La préparation générale d’un hôte SSH peut prendre en charge des types de clés plus modernes. Toutefois, dans Managed Risk > Settings > Credentials, Public Key n’accepte actuellement que les clés RSA et DSA au format OpenSSH. Modifier le système cible ne permettra donc pas d’utiliser un type de clé qui n’est pas pris en charge à cet endroit.

Créer un identifiant dans Sophos Fusion

Sous Managed Risk > Settings, ouvrez l’onglet Credentials et sélectionnez Add credential. Dans Create credential, commencez par sélectionner le type. L’authentification Plaintext n’est pas prise en charge.

SNMPv3

SNMPv3 est destiné aux équipements réseau qui utilisent SNMP version 3. Renseignez les champs suivants :

Credential type: SNMPv3.
Credential name: un nom unique, par exemple snmpv3-core-switches.
Description: une indication facultative sur le périmètre d’équipements concerné.
Username: l’utilisateur du compte SNMPv3.
Port: 161 par défaut ; ne le modifiez que si la cible fournit SNMPv3 sur un autre port.
Security Level: Authentication and privacy. Cette combinaison d’authentification et de chiffrement est actuellement la seule option disponible.
Authentication algorithm: SHA-256, SHA-384 ou SHA-512, selon la configuration de la cible.
Authentication password: le mot de passe d’authentification du compte SNMPv3.
Privacy algorithm: AES-256 ou AES-256C, selon la configuration de la cible.
Privacy password: le mot de passe de confidentialité du compte SNMPv3.
Sélectionnez Create pour enregistrer.

Windows

Pour Credential type: Windows, commencez par saisir un Credential name unique et, si vous le souhaitez, une Description. Sélectionnez ensuite l’une des trois options proposées sous Authentication method :

Kerberos: renseignez Username, Password, Domain, Key Distribution Center (KDC), KDC Port (88 par défaut), KDC Transport (TCP ou UDP) et Realm.
NTLM Hash: renseignez Username, Hash et Domain. Traitez un hachage NTLM comme un mot de passe et ne l’incluez jamais dans des éléments de diagnostic.
Password: renseignez Username, Password et, si nécessaire, le champ facultatif Domain.

Sélectionnez Create pour enregistrer. Pour les comptes locaux, l’utilisateur doit correspondre à la cible concernée ; pour les scans de contrôleurs de domaine, utilisez les identifiants d’administrateur de domaine réservés à cet usage.

SSH pour Linux et macOS

Pour Credential type: SSH, saisissez un Credential name unique, éventuellement une Description, puis sélectionnez l’Authentication method :

Kerberos: renseignez Username, Key Distribution Center (KDC), KDC Port (88 par défaut), KDC Transport (TCP ou UDP) et Realm.
Password: renseignez Username et Password. Ne sélectionnez Elevate privileges with que si la configuration préparée sur la cible l’exige.
Public Key: renseignez Username. Sous Private key, utilisez Add File pour charger le fichier de clé privée ou collez directement la clé. Seules les clés RSA et DSA au format OpenSSH sont prises en charge. Si la clé est protégée, renseignez également Private key passphrase.

Pour Public Key, sélectionnez Nothing ou sudo sous Elevate privileges with. Avec sudo, renseignez également sudo user et, si nécessaire, sudo password. Le compte et la méthode d’élévation sélectionnée doivent correspondre à la configuration préparée sur la cible.

Vous pouvez également saisir des noms d’hôtes, des adresses IP ou des blocs CIDR sous Targets afin de donner la priorité à cet identifiant par clé publique pour ces cibles. Séparez les valeurs par des virgules ou des espaces. Cette priorité ne remplace ni la définition des cibles du scan ni la sélection des identifiants dans le scan.

Sélectionnez Create pour enregistrer.

VMware ESX SOAP API

Ce type est destiné aux hôtes VMware ESX/ESXi :

Credential type: VMware ESX SOAP API.
Credential name: un nom unique.
Description: une indication facultative sur les hôtes concernés.
ESX SOAP API Authentication Method: Username and Password. Il s’agit actuellement de la seule option disponible.
Username: un compte VMware disposant d’un accès administratif à l’hôte ESX/ESXi.
Password: le mot de passe de ce compte.
Sélectionnez Create pour enregistrer.

Pour effectuer des contrôles complets, ce compte doit disposer d’un accès administratif à l’hôte. Cet identifiant est destiné aux environnements de virtualisation VMware, et non aux cibles Windows ou SSH à l’intérieur des machines virtuelles.

Attribuer l’identifiant à un scan authentifié

Les identifiants enregistrés ne déclenchent pas de scan à eux seuls. Sous My Products > Managed Risk > Scans > Internal, créez un scan interne des vulnérabilités, puis configurez-le comme suit sur la page Create Vulnerability Scan :

Sous Select scanner, sélectionnez l’appliance de scan connectée.
Sous Configure scan details, saisissez un nom et une description.
Définissez Scan type sur Authenticated.
Sous Select credentials, sélectionnez les identifiants appropriés. Chaque scan peut utiliser au maximum dix identifiants.
Sous Add scan targets, saisissez les adresses IP, les plages CIDR ou les noms d’hôtes prévus, puis sélectionnez Add. Validez chaque valeur saisie individuellement avec la touche Entrée ; les listes collées doivent être séparées par des virgules.
Sous Schedule the weekly scan, définissez le jour, l’heure et le fuseau horaire, puis sélectionnez Save dans le coin supérieur droit.

Séparez les identifiants selon le système d’exploitation, la zone de confiance et le niveau de protection requis. En particulier, un identifiant d’administrateur de domaine ne doit pas être utilisé dans un scan étendu de postes clients Windows ordinaires. Si plus de dix identifiants sont nécessaires, divisez le périmètre cible en scans clairement délimités plutôt que de regrouper les identifiants ou d’étendre les autorisations.

Tester l’identifiant Windows avant le prochain scan

Les tests d’identifiants documentés ne s’appliquent actuellement qu’à Windows. Exécutez-les depuis un système Windows situé dans le même sous-réseau que l’appliance de scan, en utilisant exactement les mêmes identifiants. Vous reproduirez ainsi au plus près les conditions réseau du scanner.

Ouvrez une Command Prompt ou PowerShell en tant qu’administrateur. Dans l’exemple, 192.0.2.25 est une adresse réservée à la documentation et doit être remplacée par l’adresse IP interne du système cible. LAB-SRV-025\svc_mrisk est un exemple de compte local ; pour un compte de domaine, utilisez plutôt votre propre format DOMAIN\User.

Vérifier IPC$ et ADMIN$

net use \\192.0.2.25\ipc$ /user:LAB-SRV-025\svc_mrisk *
net use \\192.0.2.25\admin$ /user:LAB-SRV-025\svc_mrisk *

Après chaque commande, saisissez le mot de passe à l’invite masquée. The command completed successfully confirme, pour ce test, la validité des identifiants et l’accès au partage SMB concerné. La réussite du test pour ADMIN$ indique également que le compte peut accéder aux partages administratifs.

Vérifier Remote Registry

reg query \\192.0.2.25\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir

L’affichage d’une ligne du Registre pour ProgramFilesDir confirme que Remote Registry est accessible via la session existante. En cas de message The network path was not found, vérifiez d’abord le service, le chemin SMB et le pare-feu ; en cas de message Access is denied, vérifiez les autorisations du compte, le jeton UAC distant et l’identité réellement utilisée.

Vérifier WMI

wmic /node:"192.0.2.25" /user:"LAB-SRV-025\svc_mrisk" /password:* os get name

Ne saisissez le mot de passe qu’à l’invite. L’affichage d’un nom de système d’exploitation sous Name confirme l’accès WMI pour ce test. Si wmic n’est pas disponible dans la version de Windows utilisée, ne le remplacez pas par une commande qui n’a pas été testée. Vérifiez plutôt les règles de pare-feu WMI et la préparation de l’hôte, puis effectuez la validation proprement dite lors du prochain scan Managed Risk.

Toujours fermer les sessions

Après le test, supprimez les deux connexions, même si une étape intermédiaire a échoué :

net use \\192.0.2.25\ipc$ /delete
net use \\192.0.2.25\admin$ /delete

Utilisez ensuite net use pour vérifier qu’aucune connexion à la cible de test n’est encore répertoriée, puis fermez le terminal ouvert avec les droits d’administration.

Valider le résultat lors du prochain scan

Après la prochaine exécution planifiée, vérifiez sous Managed Risk > Report History que le rapport interne des vulnérabilités a bien été créé. Les résultats authentifiés sont généralement plus détaillés que les résultats non authentifiés. Un nombre précis de détections ne constitue toutefois pas un critère de réussite : le système d’exploitation, les ports ouverts, les logiciels installés, les plug-ins utilisés et le type de scan influencent tous le résultat.

Pour effectuer une vérification fiable :

Confirmez que Scan type: Authenticated est défini et que les identifiants prévus sont sélectionnés dans le scan.
Assurez-vous que les systèmes cibles se trouvent dans le périmètre du scan et sont accessibles depuis l’appliance de scan.
Sous Windows, vérifiez d’abord les quatre éléments IPC$, ADMIN$, Remote Registry et WMI.
Sous Linux et macOS, vérifiez l’accessibilité SSH, la configuration de la clé ou de Kerberos, ainsi que l’élévation de privilèges prévue.
Vérifiez si les pare-feu des hôtes et les pare-feu intermédiaires bloquent le trafic provenant de l’adresse IP de l’appliance de scan.
Ne modifiez les champs d’identification qu’après ces vérifications, puis validez-les à nouveau lors du scan suivant.

Si les résultats ressemblent toujours à ceux d’un scan non authentifié ou restent anormalement incomplets, créez une demande destinée à l’équipe Managed Risk sous Threat Analysis Center > Cases > Create case > Managed Risk service request. Indiquez le nom du scan, le créneau horaire avec le fuseau correspondant, le nom du scanner, le type de cible, le type d’identifiant, les cibles concernées sous une forme anonymisée, le résultat observé et les contrôles déjà effectués. Ne joignez aucun mot de passe, hachage, clé privée ou sortie de console complète contenant des données sensibles.

Modifier ou supprimer des identifiants

Pour modifier un identifiant, accédez à Managed Risk > Settings > Credentials, ouvrez le menu à trois points de la colonne Actions, sélectionnez Edit, modifiez les champs, puis sélectionnez Update pour enregistrer. Validez la modification lors du prochain scan prévu.

Avant de supprimer un identifiant, vérifiez d’abord toutes les configurations de scan qui l’utilisent. Sélectionnez ensuite Delete dans le même menu à trois points, puis confirmez la suppression définitive avec Confirm dans la boîte de dialogue. La suppression retire l’identifiant de toutes les configurations de scan dans lesquelles il était utilisé et peut compromettre leurs prochaines exécutions authentifiées. Ouvrez ensuite chaque scan concerné, vérifiez les identifiants encore sélectionnés et attribuez, si nécessaire, un identifiant de remplacement préalablement préparé.

L’icône d’actualisation située dans le coin supérieur droit recharge la liste des identifiants. Elle confirme que l’affichage de la liste a été mis à jour, mais pas qu’un identifiant fonctionne sur une cible ; seuls le test ou le scan suivant peuvent le démontrer.