Contrôles des identifiants Nessus pour Unix et Windows. 17 janvier 2014 (Révision 32)

Transcription

1 Contrôles des identifiants Nessus pour Unix et Windows 17 janvier 2014 (Révision 32)

2 Table des matières Introduction... 4 Normes et conventions... 4 Vue d'ensemble des contrôles des identifiants Nessus... 4 Objet... 4 Niveau d'accès... 5 Technologies utilisées... 5 Systèmes Unix... 5 Nom d'utilisateur et mot de passe... 5 Clés publiques/privées... 6 Kerberos... 6 Systèmes Windows... 6 LANMAN... 6 NTLM et NTLMv Signature SMB... 6 SPNEGO... 7 Kerberos... 7 NTLMSSP (NT Lan Manager Security Support Provider) et LMv Noms d'utilisateur, mots de passe et domaines Windows... 7 Contrôles des identifiants sur les plateformes Unix... 7 Prérequis... 7 Configuration requise pour SSH... 7 Privilèges utilisateur... 8 Configuration requise pour Kerberos... 8 Activation des contrôles locaux de sécurité SSH sur Unix... 8 Création des clés SSH publiques et privées... 8 Création d'un compte d'utilisateur et définition d'une clé SSH... 8 Exemple... 9 Configuration de Nessus pour les contrôles SSH de l'hôte Interface utilisateur Nessus Ligne de commande Nessus Unix Utilisation des fichiers.nessus Utilisation des fichiers.nessusrc Kerberos KDC port : Kerberos KDC Transport : udp Kerberos Realm (SSH Only) : myrealm Utilisation des identifiants SSH avec SecurityCenter de Tenable Contrôles des identifiants sur les plateformes Windows Prérequis Privilèges utilisateur Activation des connections Windows pour les audits locaux et distants Configuration d'un compte local Configuration d'un compte de domaine pour les scans authentifiés Étape 1 : Créez un groupe de sécurité Étape 2 : Créez une stratégie de groupe Étape 3 : Configurez la stratégie pour ajouter le groupe «Nessus Local Access» sous Administrateurs

3 Étape 4 : Assurez-vous que les ports appropriés sont ouverts sur le pare-feu pour permettre à Nessus de se connecter à l'hôte Autorisation de WMI sur le pare-feu Windows sous Windows XP et Autorisation de WMI sur le pare-feu Windows sous Windows Vista, 7, 8, 2008, 2008R2 et Étape 5 : Liez un objet de stratégie de groupe (GPO) Configuration de Windows XP et Configuration de Windows 2008, Vista et Configuration de Nessus pour les connexions Windows Interface utilisateur Nessus Ligne de commande Nessus Unix Utilisation des fichiers.nessus Utilisation des fichiers.nessusrc Détection des échecs d'authentification Dépannage Sécurisation du scanner Pourquoi sécuriser le scanner? Que signifie le verrouillage d'un scanner? Mise en place sécurisée des vérifications SSH d'unix Vérifications Windows sécurisées Pour plus d'informations À propos de Tenable Network Security

4 Introduction Ce document décrit comment effectuer des scans de réseau authentifiés avec le scanner de vulnérabilité Nessus de Tenable Network Security. Les scans de réseau authentifiés permettent à une vérification de réseau à distance d'obtenir des données «de l'hôte» telles que les correctifs manquants et les paramètres du système d'exploitation. Veuillez envoyer vos commentaires et suggestions à Nessus tire parti de la possibilité de se connecter aux hôtes Unix distant par l'intermédiaire de Secure Shell (SSH). Pour les hôtes Windows, Nessus profite des diverses technologies d'authentification de Microsoft. Nessus utilise aussi le protocole SNMP (Simple Network Management Protocol, protocole de gestion de réseau simple) pour envoyer des interrogations de version et d'information aux routeurs et aux commutateurs. Bien qu il s agisse d une forme de «contrôles locaux», elle n'est pas couverte dans ce document. Ce document fait aussi largement référence à «Nessus» mais les concepts de base s'appliquent aussi au SecurityCenter de Tenable. Normes et conventions Dans l'ensemble de la documentation, les noms de fichiers, les démons (daemons) et les exécutables sont indiqués par la police courier bold, par exemple gunzip, httpd et /etc/passwd. Les options de ligne de commande et les mots clés sont aussi indiqués par la police courier bold. Les exemples de ligne de commande peuvent inclure ou non l'invite de ligne de commande et le texte provenant des résultats de la commande. Les exemples de ligne de commande sont affichés en courier bold dans la commande en cours d'exécution afin de montrer la saisie de l'utilisateur, tandis que l'exemple de sortie généré par le système utilisera la police courier (mais pas en gras). Voici ci-dessous un exemple d'exécution de la commande Unix pwd : # pwd /home/test/ # Les remarques et considérations importantes sont mises en évidence avec ce symbole dans une boîte de texte grise. Les conseils, exemples et meilleures pratiques sont mis en évidence avec ce symbole en texte blanc sur fond bleu. Vue d'ensemble des contrôles des identifiants Nessus Le scanner Nessus de Tenable est un scanner de vulnérabilité de réseau très efficace avec une base de données complète de plugins qui recherchent une grande variété de vulnérabilités susceptibles d'être exploitées à distance. En plus du scan à distance, le scanner Nessus peut aussi être utilisé pour scanner les expositions locales. Objet Le scan des vulnérabilités de réseau externe est utile pour obtenir un instantané temporel des services réseau offerts et des vulnérabilités qu'ils peuvent présenter. Toutefois, ce n est qu une perspective externe. Il est important de déterminer quels services locaux sont exécutés et d'identifier les expositions de sécurité aux attaques locales ou les paramètres de configuration susceptibles d'exposer le système aux attaques extérieures qui peuvent ne pas être détectées par un scan externe. Dans une vérification typique des vulnérabilités de réseau, un scan à distance est effectué en fonction des points extérieurs de présence et un scan en ligne est effectué à partir de l'intérieur du réseau. Aucun de ces scans ne peut déterminer les expositions locales du système cible. Certains renseignements obtenus s'appuient sur les informations de bannière affichées, qui peuvent être peu concluantes ou incorrectes. En utilisant des identifiants sécurisés, le scanner 4

5 Nessus peut recevoir un accès local pour scanner le système cible sans nécessiter d'agent. Ceci peut faciliter le scan d'un réseau très vaste pour déterminer les expositions locales ou les violations de conformité. Le problème de sécurité le plus courant pour une entreprise est le fait que les correctifs de sécurité ne sont pas appliqués en temps voulu. Un scan authentifié de Nessus peut déterminer rapidement les systèmes dépassés en ce qui concerne l'installation des correctifs. Ceci est particulièrement important lorsqu'une nouvelle vulnérabilité est publiée et que le personnel de direction veut une réponse rapide concernant l'impact sur l entreprise. L une des autres préoccupations majeures des entreprises est de déterminer la conformité avec la politique du site, les normes industrielles (comme les normes CIS (Center for Internet Security, Centre pour la sécurité d'internet)) ou la législation (Sarbanes-Oxley (SOX), Gramm-Leach-Bliley (GLBA) ou HIPAA). Les entreprises qui acceptent les informations de carte de crédit doivent démontrer leur conformité à PCI DSS (Payment Card Industry Data Security Standards, normes de sécurité des données de l'industrie des cartes de paiement). Il y a eu un grand nombre de cas retentissants où les informations de carte de crédit de millions de clients ont été compromises. Cela représente une perte financière considérable pour les banques qui doivent couvrir les paiements, ainsi que de lourdes amendes voire la résiliation de la possibilité d'accepter les cartes de crédit par le commerçant ou l'organisme de traitement victime de la violation. Niveau d'accès Les scans authentifiés peuvent effectuer les mêmes opérations qu'un utilisateur local. Le niveau de scan dépend des privilèges accordés au compte d'utilisateur que Nessus est configuré pour utiliser. Les utilisateurs non privilégiés avec accès local aux systèmes Unix peuvent déterminer les problèmes de sécurité de base comme les niveaux des correctifs ou les entrées dans le fichier /etc/passwd. Pour des renseignements plus complets, comme les données de configuration du système ou les permissions de fichier sur l'ensemble du système, un compte avec des privilèges «root» (racine) est requis. Les scans authentifiés sur les systèmes Windows exigent l utilisation d'un compte administrateur. Du fait des différents bulletins et mises à jour logicielles de Microsoft, la lecture du registre pour déterminer le niveau des correctifs logiciels n est pas fiable sans privilèges administrateur. L'accès administratif est requis pour effectuer la lecture directe du système de fichiers. Ceci permet à Nessus de s'attacher à un ordinateur et d'effectuer une analyse directe des fichiers pour déterminer le véritable niveau des correctifs sur les systèmes en cours de vérification. Sur Windows XP Pro, cet accès aux fichiers ne fonctionnera qu avec un compte administrateur local si la stratégie «Accès réseau : modèle de partage et de sécurité pour les comptes locaux» est paramétrée sur «Classique les utilisateurs locaux s authentifient eux-mêmes». Un audit, l'audit de conformité SCAP, exige l'envoi d'un exécutable à l'hôte distant. Si les systèmes exécutent un logiciel de sécurité (par exemple, McAfee Host Intrusion Prevention), ce dernier risque de bloquer ou de mettre en quarantaine l'exécutable requis pour l'audit. Pour ces systèmes, il est nécessaire de définir une exception pour l'hôte ou pour l'exécutable envoyé. Technologies utilisées Pour l'exécution d'un scan authentifié, le défi consiste à fournir automatiquement au scanner les identifiants privilégiés de façon sécurisée. Cela nuirait certainement à l'objectif du scan des expositions de sécurité si ce scan causait une exposition encore plus importante! Nessus prend en charge l'utilisation de plusieurs méthodes sécurisées pour résoudre ce problème sur les plateformes Unix et Windows. Systèmes Unix Sur les systèmes Unix, Nessus utilise les programmes basés sur la version 2 du protocole Secure Shell (SSH) (par exemple OpenSSH, Solaris SSH, etc.) pour les contrôles de l'hôte. Ce mécanisme crypte les données en cours de transfert pour les protéger contre la visualisation par des mouchards. Nessus prend en charge trois types de méthodes d'authentification à utiliser avec SSH : nom d utilisateur et mot de passe, clé publique/privée et Kerberos. Nom d'utilisateur et mot de passe Bien qu'elle soit prise en charge, Tenable ne recommande pas d'utiliser la combinaison nom d'utilisateur-mot de passe pour l'authentification avec SSH. Les mots de passe statiques sont sujets aux attaques d'intermédiaire ou aux attaques en force lorsqu'ils sont utilisés pendant une longue période. 5

6 Clés publiques/privées Le cryptage par clé publique, appelé aussi cryptage par clé asymétrique, constitue un mécanisme d'authentification plus sécurisé grâce à l'utilisation d'une paire de clés publique et privée. Dans le cryptage asymétrique, la clé publique est utilisée pour crypter les données et la clé privée est utilisée pour les décrypter. L'utilisation de clés publiques et privées est une méthode d'authentification SSH plus sécurisée et polyvalente. Nessus prend en charge les formats de clé DSA et RSA. Kerberos Développé par le Projet Athena du MIT, Kerberos est une application client/serveur qui utilise un protocole de cryptage par clé symétrique. Dans le cryptage symétrique, la clé utilisée pour crypter les données est la même que la clé utilisée pour les décrypter. Les organisations déploient un KDC (Key Distribution Center, centre de distribution de clés) qui contient tous les utilisateurs et services qui nécessitent une authentification par Kerberos. Les utilisateurs s'authentifient auprès de Kerberos en demandant un TGT (Ticket Granting Ticket, ticket d'octroi de ticket). Une fois qu'un utilisateur reçoit un TGT, ce dernier peut être utilisé pour demander des tickets de service auprès du KDC afin de pouvoir utiliser les autres services basés sur Kerberos. Kerberos utilise le protocole de cryptage DES de la CBC (Cipher Block Chain, chaîne de blocs de cryptogramme) pour crypter toutes les communications. La mise en place par Nessus de l'authentification Kerberos pour SSH prend en charge les algorithmes de cryptage «aescbc» et «aes-ctr». Vous pouvez voir ci-dessous une présentation de l'interaction entre Nessus et Kerberos : L'utilisateur final donne l'ip du KDC nessusd demande à sshd s'il prend en charge l'authentification Kerberos sshd donne une réponse positive nessusd demande un TGT Kerberos, ainsi que des informations de connexion et un mot de passe Kerberos renvoie un ticket à nessusd nessusd donne le ticket à sshd nessusd est connecté Systèmes Windows Nessus prend en charge plusieurs types de méthodes d'authentification pour les systèmes Windows. Ces différentes méthodes utilisent toutes un nom d'utilisateur, un mot de passe et un nom de domaine (parfois facultatif pour l'authentification). LANMAN La méthode d'authentification Lanman était prédominante sur les déploiements des serveurs Windows NT et des premiers serveurs Windows Elle n'est pas vraiment utilisée sur les déploiements Windows plus récents, mais elle est conservée pour assurer la rétrocompatibilité. NTLM et NTLMv2 La méthode d'authentification NTLM introduite avec Windows NT représentait une sécurité améliorée par rapport à l'authentification Lanman. Toutefois, la version améliorée NTLMv2 est plus sécurisée que NTLM d'un point de vue cryptographique et elle constitue la méthode d'authentification que Nessus choisit par défaut lors d une tentative de connexion à un serveur Windows. Signature SMB La signature SMB est une somme de contrôle cryptographique appliquée à l'ensemble du trafic SMB provenant ou à destination d'un serveur Windows. Les administrateurs système activent souvent cette fonction sur leurs serveurs pour assurer que les utilisateurs distants sont 100 % authentifiés et font partie d'un domaine. Elle est automatiquement utilisée par Nessus si elle est requise par le serveur Windows distant. 6

7 SPNEGO Le protocole SPNEGO (Simple and Protected Negotiate, négociation simple et protégée) fournit une capacité SSO (Single Sign On, ouverture de session unique) d'un client Windows vers différentes ressources protégées grâce aux identifiants de connexion Windows des utilisateurs. Nessus prend en charge l'utilisation de SPNEGO avec NTLMSSP et l'authentification LMv2 ou avec Kerberos et le cryptage RC4. Kerberos Nessus prend également en charge l'authentification Kerberos dans un domaine Windows. Pour configurer cette fonction, l'adresse IP du contrôleur de domaine Kerberos (autrement dit, l'adresse IP du serveur Active Directory de Windows) doit être fournie. NTLMSSP (NT Lan Manager Security Support Provider) et LMv2 Si une méthode de sécurité étendue (telle que Kerberos ou SPNEGO) n'est pas prise en charge ou échoue, Nessus essaiera de se connecter à l'aide de l'authentification NTLMSSP/LMv2. En cas d échec, Nessus essaiera ensuite d'entrer en session en utilisant l'authentification NTLM. Noms d'utilisateur, mots de passe et domaines Windows Le champ de domaine SMB est facultatif et Nessus n'aura pas besoin de ce champ pour se connecter avec les identifiants de domaine. Le nom d'utilisateur, le mot de passe et le domaine facultatif se rapportent à un compte que la machine cible connaît. Prenons, par exemple, le nom d'utilisateur «joesmith» et le mot de passe «my4x4mpl3» : un serveur Windows recherche d'abord ce nom d'utilisateur dans la liste des utilisateurs du système local, puis détermine s'il fait partie d'un domaine qui en dépend. Le nom de domaine réel est requis seulement si un nom de compte sur le domaine est différent de celui sur l'ordinateur. Il est tout à fait possible d'avoir un compte administrateur sur un serveur Windows et dans le domaine. Dans ce cas, pour ouvrir une session sur le serveur local, le nom d'utilisateur de l administrateur est utilisé avec le mot de passe pour ce compte. Pour ouvrir une session sur le domaine, le nom d'utilisateur de l administrateur serait aussi utilisé, mais avec le mot de passe du domaine et le nom du domaine. Quels que soient les identifiants utilisés, Nessus essaie toujours de se connecter à un serveur Windows avec les combinaisons suivantes : «Administrateur» sans mot de passe Nom d'utilisateur et mot de passe aléatoires pour tester les comptes invité Pas de nom d'utilisateur ou de mot de passe pour tester les sessions nulles Contrôles des identifiants sur les plateformes Unix Le processus décrit dans cette section permet d'effectuer des contrôles locaux de sécurité sur les systèmes Unix (par exemple, Linux, Solaris, Mac OS X). Le démon SSH utilisé dans cet exemple est OpenSSH. Avec une variante commerciale de SSH, la procédure peut être légèrement différente. Pour activer les contrôles locaux de sécurité, vous disposez de deux méthodes de base : 1. Utilisation d'une paire de clés SSH privée/publique 2. Identifiants utilisateur et accès sudo ou identifiants pour accès su Prérequis Configuration requise pour SSH Nessus 5 prend en charge les algorithmes blowfish-cbc, AESXXX-CBC (AES128, AES192 et AES256), 3DES-CBC et AES-CTR. Certaines variantes commerciales de SSH ne peuvent pas prendre en charge l'algorithme blowfish, probablement pour des raisons d'exportation. Il est aussi possible de configurer un serveur SSH pour accepter seulement certains types de cryptage. Vérifiez votre serveur SSH pour être sûr que le bon algorithme est pris en charge. 7

8 Privilèges utilisateur Pour un maximum d'efficacité, l'utilisateur SSH doit pouvoir exécuter n importe quelle commande sur le système. Sur les systèmes Unix, cette fonction est appelée privilèges «root». Bien qu'il soit possible d'exécuter certains contrôles (comme les niveaux de correctif) avec un accès non privilégié, les contrôles complets de conformité permettant de vérifier la configuration du système et les permissions de fichier exigent un accès root (racine). Pour cette raison, il est fortement recommandé d'utiliser des clés SSH à la place des identifiants, si possible. Configuration requise pour Kerberos Si Kerberos est utilisé, sshd doit être configuré avec l'assistance de Kerberos pour vérifier le ticket avec KDC. Les recherches DNS inverses doivent être configurées correctement pour assurer le bon fonctionnement. La méthode d'interaction Kerberos doit être gssapi-with-mic. Activation des contrôles locaux de sécurité SSH sur Unix Cette section a pour objet de fournir une procédure de haut niveau pour activer SSH entre les systèmes concernés par les contrôles d'identifiants Nessus. Elle n'est pas destinée à fournir un didacticiel approfondi sur SSH. Elle suppose que le lecteur possède une connaissance préalable des commandes des systèmes Unix. Création des clés SSH publiques et privées La première étape consiste à créer une paire de clés privée/publique à l'usage du scanner Nessus. Cette paire de clés peut être créée à partir de n importe quel système Unix, en utilisant n importe quel compte d'utilisateur. Toutefois, il est important que les clés soient la propriété de l'utilisateur Nessus défini. Pour créer la paire de clés, utilisez ssh-keygen et sauvegardez la clé en lieu sûr. Dans l'exemple suivant, les clés sont créées sur une installation Red Hat ES 3. # ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/Users/test/.ssh/id_dsa): /home/test/nessus/ssh_key Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/test/nessus/ssh_key. Your public key has been saved in /home/test/nessus/ssh_key.pub. The key fingerprint is: 06:4a:fd:76:ee:0f:d4:e6:4b:74:84:9a:99:e6:12:ea # Il ne faut pas transférer la clé privée sur un système autre que celui qui exécute le serveur Nessus. Lorsque ssh-keygen demande une phrase de passe, saisissez une phrase de passe forte ou appuyez deux fois sur la touche «Retour» (pour ne pas configurer de phrase de passe). Si une phrase de passe est spécifiée, elle doit l être dans les options Policies -> Credentials -> SSH settings (Stratégies -> Identifiants -> paramètres SSH) pour que Nessus utilise une authentification basée sur les clés. Les utilisateurs de Nessus Windows peuvent souhaiter copier les deux clés dans le répertoire principal de l'application Nessus sur le système qui exécute Nessus (C:\Program Files\Tenable\Nessus par défaut), puis copier la clé publique sur les systèmes cibles si nécessaire. Ceci facilite la gestion des fichiers de clés publique et privée. Création d'un compte d'utilisateur et définition d'une clé SSH Sur chaque système cible à scanner qui utilise des contrôles locaux de sécurité, créez un nouveau compte d'utilisateur dédié à Nessus. Ce compte d'utilisateur doit avoir exactement le même nom sur tous les systèmes. Pour ce document, nous appellerons l'utilisateur «nessus», mais n'importe quel nom peut être utilisé. Une fois que le compte est créé pour l'utilisateur, assurez-vous qu'aucun mot de passe valide n'est défini pour le compte. Sur les systèmes Linux, les nouveaux comptes d'utilisateur sont verrouillés par défaut, sauf si un mot de passe initial a 8

9 été explicitement défini. Si vous utilisez un compte pour lequel un mot de passe a été défini, utilisez la commande «passwd l» pour verrouiller le compte. Il faut également créer le répertoire qui contiendra la clé publique sous le répertoire d'accueil de ce nouveau compte. Pour cet exercice, le répertoire sera /home/nessus/.ssh. Voici un exemple pour les systèmes Linux : # passwd l nessus # cd /home/nessus # mkdir.ssh # Pour les systèmes Solaris 10, Sun a amélioré la commande «passwd(1)» afin de faire une distinction entre les comptes verrouillés et les comptes auxquels aucune connexion n est possible. Ceci permet d'assurer qu'un compte d'utilisateur qui a été verrouillé ne puisse pas être utilisé pour exécuter des commandes (par exemple, les tâches cron). Les comptes auxquels aucune connexion n est possible sont utilisés uniquement pour exécuter les commandes et ne prennent pas de session interactive en charge. Ces comptes comportent le jeton «NP» dans le champ du mot de passe pour /etc/shadow. Pour définir un compte auquel aucune connexion n est possible afin d'entrer en session et de créer le répertoire des clés publiques SSH dans Solaris 10, exécutez les commandes suivantes : # passwd N nessus # grep nessus /etc/shadow nessus:np:13579:::::: # cd /export/home/nessus # mkdir.ssh # Une fois le compte d'utilisateur créé, vous devez transférer la clé au système, la placer dans le répertoire approprié, et définir les permissions correctes. Exemple À partir du système contenant les clés, copiez de façon sécurisée la clé publique sur le système qui sera scanné pour les contrôles d'hôte comme indiqué ci-dessous est un exemple de système distant qui sera testé avec les contrôles de l'hôte. # scp ssh_key.pub root@ :/home/nessus/.ssh/authorized_keys # Vous pouvez aussi copier le fichier à partir du système sur lequel Nessus est installé en utilisant la commande FTP sécurisée «sftp». Le fichier sur le système cible doit être nommé «authorized_keys». Retour sur le système contenant la clé publique Définissez les permissions pour le répertoire /home/nessus/.ssh et le fichier authorized_keys. # chown -R nessus:nessus ~nessus/.ssh/ # chmod 0600 ~nessus/.ssh/authorized_keys # chmod 0700 ~nessus/.ssh/ # Répétez ce processus sur tous les systèmes qui seront testés pour les contrôles SSH (en commençant par «Création d'un compte d'utilisateur et définition d'une clé SSH» ci-dessus). 9

10 Effectuez un test pour vérifier que les comptes et les réseaux sont configurés correctement. À l'aide de la commande Unix simple «id», à partir du scanner Nessus, exécutez la commande suivante : # ssh -i /home/test/nessus/ssh_key nessus@ id uid=252(nessus) gid=250(tns) groups=250(tns) # Si elle renvoie avec succès des informations concernant l'utilisateur Nessus, l'échange de clés a réussi. Configuration de Nessus pour les contrôles SSH de l'hôte Interface utilisateur Nessus Si vous n'avez pas encore fait, copiez de façon sécurisé les fichiers de clés privées et publiques sur le système qui sera utilisé pour accéder au scanner Nessus. Ouvrez le navigateur Internet, connectez-vous à l'interface utilisateur du scanner Nessus comme indiqué ci-dessus et cliquez sur l'onglet «Policies» (Stratégies). Créez une nouvelle stratégie ou éditez une stratégie existante et sélectionnez l'onglet «Credentials» (Identifiants) à gauche. Sélectionnez «SSH settings» (Paramétrage SSH) à partir du menu déroulant en haut, comme illustré ci-dessous : 10

11 Pour l'élément «SSH user name» (Nom d'utilisateur SSH), saisissez le nom du compte dédié à Nessus sur chacun des systèmes cible à scanner. Il est configuré par défaut sur «root» (racine). Si un mot de passe est utilisé pour SSH, saisissez-le dans le champ «SSH password» (Mot de passe SSH). Si des clés SSH sont utilisées à la place d'un mot de passe (ce qui est recommandé), cliquez sur le bouton «Select» (Sélectionner) à côté du champ «SSH public key to use» (Clé publique SSH à utiliser) et recherchez le fichier de clé publique sur le système local. Pour l'élément «SSH private key to use» (Clé privée SSH à utiliser), cliquez sur le bouton «Select» (Sélectionner) et recherchez le fichier de clé privée (associé à la clé publique ci-dessus) sur le système local. Si une phrase de passe est utilisée pour la clé SSH (facultatif), saisissez-la dans le champ «Passphrase for SSH key» (Phrase de passe pour la clé SSH). Les utilisateurs de Nessus et de SecurityCenter peuvent aussi invoquer «su» ou «sudo» avec le champ «Elevate privileges with» (Élever les privilèges avec) et un mot de passe séparé. Si un fichier known_hosts SSH est disponible et fourni dans le cadre de la stratégie de scan dans le champ «SSH known_hosts file», Nessus essaiera de se connecter uniquement sur les hôtes de ce fichier. Ceci permet de garantir que la combinaison nom d'utilisateur et mot de passe utilisée pour vérifier les serveurs SSH connus n'est pas utilisée pour tenter une connexion sur un système que vous pourriez ne pas contrôler. Les scans authentifiés les plus efficaces sont ceux pour lesquels les identifiants fournis ont des privilèges «root». Puisqu'un grand nombre de sites ne permettent pas une ouverture de session à distance au niveau root, les utilisateurs Nessus peuvent invoquer «su» ou «sudo» avec un mot de passe séparé pour un compte qui a été établi avec les privilèges «su» ou «sudo». 11

12 Cette capture d'écran illustre l'utilisation de «sudo» avec les clés SSH. Dans cet exemple, le compte de l'utilisateur est «audit», qui a été ajouté au fichier /etc/sudoers sur le système à scanner. Le mot de passe fourni est celui du compte «audit», et non le mot de passe root. Les clés SSH correspondent aux clés créées pour le compte «audit» : Si Kerberos est utilisé, il faut configurer un scanner Nessus pour l'authentification par KDC. Sélectionnez «Kerberos configuration» (Configuration Kerberos) dans le menu déroulant comme illustré ci-dessous : Le port KDC par défaut est «88» et le protocole de transport par défaut est «udp». L'autre valeur pour le transport est «tcp». Pour finir, le nom du Kerberos Realm (royaume Kerberos) et l'adresse IP du KDC sont requis. 12

13 Si vous voulez utiliser cette méthode d'authentification, vous devez avoir déjà établi un environnement Kerberos. Cliquez alors sur «Submit» (Soumettre) en bas de la fenêtre pour terminer la configuration. La nouvelle stratégie de scan sera ajoutée à la liste des stratégies de scan gérées. Ligne de commande Nessus Unix La prise en charge Nessus pour les contrôles de l'hôte est disponible dans Nessus et les versions plus récentes et elle exige que l'assistance SSL y soit compilée. Exécutez la commande «nessusd d» pour vérifier que la version et les bibliothèques SSL utilisées sont correctes, comme ci-dessous : # nessusd -d [root@squirrel sbin]#./nessusd -d This is Nessus [build R23100] for Linux el5 compiled with gcc version (Red Hat ) Current setup : Flavor : es5-x86 Nasl : Libnessus : SSL support : enabled SSL is used for client / server communication Running as euid : 0 Magic hash: 49edd1433ffad7b87b446a4201faeedf - OpenSSL: OpenSSL 1.0.0g 18 Jan 2012 Utilisation des fichiers.nessus Nessus peut sauvegarder des stratégies de scan configurées, des cibles de réseau et des rapports sous forme de fichiers.nessus. La section ci-dessus, «Interface utilisateur Nessus», décrit la création d'un fichier.nessus qui contient les identifiants SSH. Pour plus d'instructions concernant l'exécution d'un scan de ligne de commande à l'aide du fichier.nessus, voir le «Nessus User Guide» (Guide de l'utilisateur de Nessus) disponible sur : Utilisation des fichiers.nessusrc Dans le cas où des fichiers «.nessusrc» sont créés manuellement, plusieurs paramètres peuvent être configurés pour spécifier l'authentification SSH. Un exemple de liste vide est montré ci-dessous : Use SSH to perform local security checks[entry]:ssh user name : = Use SSH to perform local security checks[file]:ssh public key to use : = Use SSH to perform local security checks[file]:ssh private key to use : = Use SSH to perform local security checks[password]:passphrase for SSH key : = SSH settings[entry]:ssh user name : = SSH settings[password]:ssh password (unsafe!) : = SSH settings[file]:ssh public key to use : = no SSH settings[file]:ssh private key to use : = SSH settings[password]:passphrase for SSH key : = Si Kerberos est utilisé, vous devez configurer un scanner Nessus pour l'authentification par KDC en saisissant les informations suivantes dans le fichier nessusrc du scanner : 13

14 Kerberos KDC port : 88 Kerberos KDC Transport : udp Kerberos Realm (SSH Only) : myrealm Kerberos Key Distribution Center (KDC): Le port KDC par défaut est «88» et le protocole de transport par défaut est «udp». L'autre valeur pour le transport est «tcp». Pour finir, le nom du Kerberos Realm (royaume Kerberos) et l'adresse IP du KDC sont requis. Si vous voulez utiliser cette méthode d'authentification, vous devez avoir déjà établi un environnement Kerberos. Utilisation des identifiants SSH avec SecurityCenter de Tenable Pour utiliser les identifiants SSH avec SecurityCenter, téléchargez sur la console SecurityCenter les clés SSH publique et privée créées. Ne les installez pas directement sur les scanners Nessus puisque SecurityCenter télécharge ces identifiants vers le scanner Nessus lorsque le scan est démarré. Voici un exemple d'une partie de l'écran «Edit Scan Options» (Éditer les options de scan) lors de l'édition des options d'une stratégie. Les trois derniers champs sont utilisés pour spécifier un compte et des clés SSH publique et privée spécifiques à utiliser pour les tests. La clé SSH publique doit être placée sur chaque hôte Unix qui sera testé pour ces «contrôles locaux». SecurityCenter est livré avec plusieurs stratégies de vulnérabilités prédéfinies dont les «contrôles locaux» sont activés pour chaque système d exploitation individuel. Toutefois, l'utilisation de ces stratégies exigent qu'elles soient copiées et qu'elles comportent une paire spécifique de clés SSH publique/privée ainsi qu'un compte d'utilisateur spécifique ajouté. Les paires de clés SSH publiques/privées sont gérées par SecurityCenter et seront transférées à chaque scanner Nessus géré. Une fois que ces clés publiques SSH sont installées sur les hôtes Unix voulus et que les clés privées sont installées sous SecurityCenter, une relation de confiance est créée de sorte qu'un utilisateur peut se connecter à chacun des hôtes Unix à partir des scanners Nessus. Si la sécurité des scanners Nessus est compromise, de nouvelles paires de clés publiques/privées SSH doivent être créées. 14

15 Contrôles des identifiants sur les plateformes Windows Prérequis Privilèges utilisateur Une erreur très fréquente consiste à créer un compte local qui n'a pas suffisamment de privilèges pour pouvoir se connecter à distance et faire quoi que ce soit d utile. Par défaut, Windows attribue aux nouveaux comptes locaux des privilèges d «invité» s'ils sont connectés à distance. Ceci empêche la bonne exécution d'audits des vulnérabilités à distance. Une autre erreur fréquente consiste à améliorer l'accès des utilisateurs «invités». Ceci réduit la sécurité du serveur Windows. Activation des connections Windows pour les audits locaux et distants L'aspect le plus important des identifiants Windows est le fait que le compte utilisé pour effectuer les contrôles doit disposer des privilèges nécessaires pour accéder à tous les fichiers requis et toutes les entrées de registre, soit en général les privilèges administratifs. Si Nessus ne reçoit pas les identifiants pour un compte administratif, il peut être utilisé au mieux pour effectuer des contrôles de registre pour les correctifs. Bien que cette méthode soit toujours valide pour déterminer si un correctif est installé, elle est incompatible avec certains outils de gestion de correctif tiers qui peuvent négliger de définir la clé dans la stratégie. Si Nessus a des privilèges administratifs, il vérifiera effectivement la version de la bibliothèque des liens dynamiques (.dll) sur l'hôte distant, ce qui est beaucoup plus précis. Configuration d'un compte local Pour configurer un serveur Windows autonome qui ne fait pas partie d'un domaine avec des identifiants à utiliser, il suffit de créer un compte unique en tant qu'administrateur. Assurez-vous que la configuration de ce compte n'est pas défini avec une valeur par défaut typique telle que «Invité seul : les utilisateurs locaux s authentifient en tant qu'invités». Utilisez plutôt «Classique les utilisateurs locaux s authentifient eux-mêmes». Pour configurer le serveur afin qu'il accepte les ouvertures de session à partir d'un compte de domaine, le modèle de sécurité «Classique» doit être invoqué. Pour ce faire, suivez les étapes ci-dessous : 1. Ouvrez «Stratégie de groupe» en cliquant sur «Démarrer», puis sur «Exécuter», tapez «gpedit.msc» et cliquez sur «OK». 2. Sélectionnez Configuration ordinateur -> Paramètres Windows -> Paramètres de sécurité -> Stratégies locales -> Options de sécurité. 3. Dans la liste des stratégies, ouvrez «Accès réseau : modèle de partage et de sécurité pour les comptes locaux». 4. Dans cette boîte de dialogue, sélectionnez «Classique les utilisateurs locaux s authentifient eux-mêmes» et cliquez sur «OK» pour enregistrer. Ceci permet aux utilisateurs locaux du domaine de s authentifier eux-mêmes, bien qu'ils ne soient pas vraiment physiquement «locaux» sur le serveur en question. Sans cette manipulation, tous les utilisateurs à distance, même les utilisateurs réels dans le domaine, s authentifieront en tant qu «invité» et n'auront probablement pas suffisamment d'identifiants pour effectuer une vérification à distance. Veuillez noter que l'outil gpedit.msc n'est pas disponible sur certaines versions comme Windows 7 Home, qui n'est pas pris en charge par Tenable. Configuration d'un compte de domaine pour les scans authentifiés Pour créer un compte de domaine pour les audits à distance de l'hôte d'un serveur Windows, le serveur doit d'abord utiliser Windows Vista, Windows XP Pro, Windows 2003, Windows 2008, Windows 7 ou Windows 8 et faire partie d'un domaine. Vous devez effectuer cinq étapes générales pour faciliter ce scanning tout en garantissant la sécurité. Étape 1 : Créez un groupe de sécurité Commencez par créer le groupe de sécurité Nessus Local Access (Accès local Nessus) : Connectez-vous à un contrôleur de domaine, ouvrez Utilisateurs et ordinateurs Active Directory. 15

16 Créez un groupe de sécurité : sous Menu, sélectionnez Action -> Nouveau -> Groupe. Nommez le groupe Nessus Local Access (Accès local Nessus). Assurez-vous que les options «Étendue» et «Type» sont respectivement définies sur Global (Globale) et Security (Sécurité). Ajoutez le compte que vous voulez utiliser pour effectuer les scans Nessus authentifiés sur les systèmes Windows dans le groupe Nessus Local Access (Accès local Nessus). Étape 2 : Créez une stratégie de groupe Vous devez ensuite créer la stratégie de groupe Local Admin GPO (Objet de stratégie de groupe admin local). Ouvrez la Console de gestion des stratégies de groupe. Cliquez avec le bouton droit sur Objets de stratégie de groupe et sélectionnez Nouveau. Tapez le nom de la stratégie : «Nessus Scan GPO». Étape 3 : Configurez la stratégie pour ajouter le groupe «Nessus Local Access» sous Administrateurs Vous allez ajouter le groupe Nessus Local Access à la stratégie Nessus Scan GPO et les placer dans les groupes qui vont les utiliser. Cliquez avec le bouton droit sur la stratégie «Nessus Scan GPO» puis sélectionnez Modifier. Développez Configuration ordinateur\stratégies\paramètres Windows\Paramètres de sécurité\groupes restreints. Dans le volet gauche de la fenêtre Groupes restreints, cliquez avec le bouton droit et sélectionnez «Ajouter un groupe». Dans la boîte de dialogue Ajouter un groupe, sélectionnez Parcourir, tapez Nessus Local Access puis cliquez sur «Vérifier les noms». Cliquez deux fois sur OK pour fermer la boîte de dialogue. Cliquez sur Ajouter sous «Ce groupe est membre de :» Ajoutez le groupe «Administrateurs». Cliquez deux fois sur OK. Étape 4 : Assurez-vous que les ports appropriés sont ouverts sur le pare-feu pour permettre à Nessus de se connecter à l'hôte Puisque Nessus utilise SMB (Server Message Block) et WMI (Windows Management Instrumentation, Infrastructure de gestion Windows), vous devez vous assurer que le pare-feu Windows autorisera l'accès au système. Autorisation de WMI sur le pare-feu Windows sous Windows XP et 2003 Cliquez avec le bouton droit sur la stratégie «Nessus Scan GPO» puis sélectionnez Modifier. Développez Configuration ordinateur\stratégies\modèles d'administration\réseau\connexions réseau\pare-feu Windows\Profil de domaine. - Remarque : La raison principale pour laquelle c'est le profil de domaine qui est configuré et non le profil standard est que le profil de domaine s'applique uniquement lorsque Windows détermine qu'il est connecté à un réseau appartenant au domaine dont il est membre. Le profil standard s'applique lorsque les hôtes ne peuvent pas déterminer s'il se trouve sur un réseau appartenant au domaine ou sur un réseau public ; le fait de limiter l'exposition aux ports WMI réduit donc le risque. 16

17 Sélectionnez Pare-feu Windows : définir les exceptions des programmes en entrée, puis cliquez avec le bouton droit et sélectionnez Modifier (vous pouvez aussi double-cliquer sur cette option avec la souris). - Sélectionnez Activé. - Cliquez sur Afficher. - Dans les définitions pour Exceptions de programmes, saisissez : o o o %windir%\system32\wbem\unsecapp.exe:*:enable:wmi %windir%\system32\dllhost.exe:*:enable:ddlhost Remarque : Dans les entrées ci-dessus, l'astérisque (*) renvoie au caractère générique qui permet d'autoriser n'importe quelle adresse IP du domaine à se connecter à ces services. Vous pouvez sécuriser davantage cette procédure en autorisant uniquement les adresses ou les plages IP pour lesquelles les outils d'administration se connectent au port ou l'adresse IP de scanner Nessus. - Cliquez sur OK. - Cliquez sur OK pour aller à la première liste de stratégies pour le pare-feu. Sélectionnez Pare-feu Windows : autoriser les exceptions de ports locaux, puis cliquez avec le bouton droit et sélectionnez Modifier (vous pouvez aussi double-cliquer sur cette option avec la souris). - Sélectionnez Activé. - Cliquez sur OK. Sélectionnez Pare-feu Windows : définir les exceptions des programmes en entrée, puis cliquez avec le bouton droit et sélectionnez Modifier (vous pouvez aussi double-cliquer sur cette option avec la souris). - Sélectionnez Activé. - Cliquez sur Afficher. - Dans les définitions pour Exceptions de programmes, saisissez : o o 135:TCP:*:enable Remarque : Dans les entrées ci-dessus, l'astérisque (*) renvoie au caractère générique qui permet d'autoriser n'importe quelle adresse IP du domaine à se connecter à ces services. Vous pouvez sécuriser davantage cette procédure en autorisant uniquement les adresses ou les plages IP pour lesquelles les outils d'administration se connectent au port ou l'adresse IP de scanner Nessus. - Cliquez sur OK pour aller à la première liste de stratégies pour le pare-feu. Sélectionnez Pare-feu Windows : définir les exceptions des programmes en entrée, puis cliquez avec le bouton droit et sélectionnez Modifier (vous pouvez aussi double-cliquer sur cette option avec la souris). - Sélectionnez Activé. - Cliquez sur la case correspondant à Autoriser les messages entrants non sollicités provenant des adresses IP suivantes et saisissez *. - Remarque : Dans les entrées ci-dessus, l'astérisque (*) renvoie au caractère générique qui permet d'autoriser n'importe quelle adresse IP du domaine à se connecter à ces services. Vous pouvez sécuriser 17

18 davantage cette procédure en autorisant uniquement les adresses ou les plages IP pour lesquelles les outils d'administration se connectent au port ou l'adresse IP de scanner Nessus. - Cliquez sur OK pour aller à la première liste de stratégies pour le pare-feu. Autorisation de WMI sur le pare-feu Windows sous Windows Vista, 7, 8, 2008, 2008R2 et 2012 Cliquez avec le bouton droit sur la stratégie «Nessus Scan GPO» puis sélectionnez Modifier. Développez Configuration ordinateur\stratégies\paramètres Windows\Pare-feu Windows avec fonctions avancées de sécurité\pare-feu Windows avec fonctions avancées de sécurité\règles de trafic entrant Cliquez avec le bouton droit dans la zone de travail et sélectionnez Nouvelle règle... Choisissez l'option Prédéfini et sélectionnez Windows Management Instrumentation (WMI) (Infrastructure de gestion Windows (WMI)) dans la liste déroulante. Cliquez sur Suivant. Cochez les cases correspondant à : - Windows Management Instrumentation (ASync-In) - Windows Management Instrumentation (WMI-In) - Windows Management Instrumentation (DCOM-In) Cliquez sur Suivant. Cliquez sur Terminer. Remarque : Vous pouvez par la suite modifier la règle prédéfinie ainsi créée afin de limiter la connexion aux ports par adresse IP et utilisateur de domaine pour réduire tout risque d'utilisation abusive de WMI. Étape 5 : Liez un objet de stratégie de groupe (GPO) Dans la Console de gestion des stratégies de groupe, cliquez avec le bouton droit sur le domaine ou l'uo et sélectionnez Lier un objet de stratégie de groupe existant. Sélectionnez la stratégie Nessus Scan GPO. Configuration de Windows XP et 2003 Pour que vous puissiez effectuer des scans authentifiés sur les systèmes Windows XP ou 2003, plusieurs options de configuration doivent être activées : 1. Le service WMI doit être activé sur la cible. 2. Le service de registre à distance doit être activé (il est désactivé par défaut). Il peut être activé manuellement pour l'exécution continue des audits, par Nessus ou par un administrateur. L'utilisation des plugins et permet à Nessus d'activer le service pour la durée du scan uniquement. 3. Le partage de fichiers et d'imprimantes doit être activé dans la configuration réseau de la cible. 4. Les ports 139 et 445 doivent être ouverts entre le scanner Nessus et la cible. 5. Un compte SMB doit être utilisé avec des droits d administrateur locaux sur la cible. Il peut être nécessaire de changer les stratégies de sécurité locales de Windows car elles pourraient bloquer l'accès ou les permissions intégrées. Une stratégie courante qui affectera les scans authentifiés se trouve dans : 18

19 Outils d administration -> Stratégie de sécurité locale -> Paramètres de sécurité -> Stratégies locales -> Options de sécurité -> Accès au réseau : modèle de partage et de sécurité pour les comptes locaux. Si cette stratégie de sécurité locale est définie avec une valeur autre que «Classique - les utilisateurs locaux s authentifient eux-mêmes», un scan de conformité échouera. Configuration de Windows 2008, Vista et 7 Pour effectuer des scans authentifiés sur les systèmes Windows 2008, Vista ou 7, plusieurs options de configuration doivent être activées : 1. Sous Pare-feu Windows -> Paramètres du pare-feu Windows, «Partage de fichiers et d'imprimantes» doit être activé. 2. En utilisant l'outil gpedit.msc (à l'aide de l'invite «Exécuter..»), invoquez l'éditeur d'objet stratégie de groupe. Naviguez vers Stratégie Ordinateur local -> Modèles d administration -> Réseau -> Connexions réseau - > Parefeu Windows -> Profil standard -> Pare-feu Windows : Autoriser l'exception de partage de fichiers et d'imprimantes, et activez-le. 3. Dans l'éditeur d'objet stratégie de groupe, Stratégie de l'ordinateur local -> Modèles d administration -> Réseau -> Connexions réseau - > Interdire l'utilisation de pare-feu de connexion Internet sur le réseau du domaine DNS doit être paramétré sur «Désactivé» ou «Non configuré». 4. Le service de registre à distance doit être activé (il est désactivé par défaut). Il peut être activé manuellement pour l'exécution continue des audits, par Nessus ou par un administrateur. L'utilisation des plugins et permet à Nessus d'activer le service pour la durée du scan uniquement. Nessus peut activer et désactiver le service de registre à distance. Pour garantir la bonne exécution de cette procédure, le service de registre à distance de la cible doit être défini sur «Manual» (Manuel) et non sur «Disabled» (Désactivé). Le Contrôle de compte d'utilisateur (UAC) de Windows peut aussi être désactivé, mais cette solution est déconseillée. Pour désactiver complètement UAC, ouvrez le Panneau de configuration, sélectionnez «Comptes d utilisateurs», puis paramétrez «Activer ou désactiver le contrôle des comptes d utilisateurs» sur désactivé. Vous pouvez aussi ajouter une nouvelle clé de registre appelée «LocalAccountTokenFilterPolicy» et lui attribuer la valeur «1». Cette clé doit être créée dans le registre à l'emplacement suivant : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\ LocalAccountTokenFilterPolicy. Pour de plus amples renseignements sur ce paramétrage du registre, consultez MSDN KB. 19

20 Configuration de Nessus pour les connexions Windows Interface utilisateur Nessus Ouvrez un navigateur Internet et connectez-vous à l'interface utilisateur du scanner Nessus comme indiqué ci-dessus ; cliquez sur l'onglet «Policies» (Stratégies). Créez une nouvelle stratégie ou éditez une stratégie existante et sélectionnez l'onglet «Credentials» (Identifiants) à gauche. Sélectionnez «Windows credentials» (Informations d'identification Windows) à partir du menu déroulant en haut, comme indiqué ci-dessous : 20

21 Précisez le nom de compte SMB, le mot de passe et le domaine facultatif. Cliquez alors sur «Submit» (Soumettre) en bas de la fenêtre pour terminer la configuration. La nouvelle stratégie de scan sera ajoutée à la liste des stratégies de scan gérées. Ligne de commande Nessus Unix Utilisation des fichiers.nessus Nessus peut sauvegarder des stratégies de scan configurées, des cibles de réseau et des rapports sous forme de fichiers.nessus. La section ci-dessus, «Interface utilisateur Nessus», décrit la création d'un fichier.nessus qui contient les identifiants Windows. Pour plus d'instructions concernant l'exécution d'un scan de ligne de commande à l'aide du fichier.nessus, voir le «Nessus User Guide» (Guide de l'utilisateur de Nessus) disponible sur : Utilisation des fichiers.nessusrc Si un fichier «.nessusrc» est créé manuellement, trois entrées permettent de configurer le nom d'utilisateur, le mot de passe et le domaine facultatif comme indiqué ci-dessous : Login configurations[entry]:smb account : = Login configurations[password]:smb password : = Login configurations[entry]:smb domain (optional) : = Détection des échecs d'authentification Lorsque Nessus est utilisé pour effectuer des audits authentifiés des systèmes Unix ou Windows, l'analyse des résultats pour déterminer si les mots de passe et les clés SSH étaient corrects peut être difficile. Les utilisateurs de Nessus peuvent maintenant déterminer facilement si leurs identifiants ne fonctionnent pas. Tenable a ajouté le plugin Nessus n à la famille de plugins «Settings» (Paramètres). Ce plugin détecte si les identifiants SSH ou Windows n'ont pas permis au scan de se connecter à l'hôte distant. Lorsqu'une connexion réussit, ce plugin ne produit pas de résultat. Par exemple, ce rapport a été produit après une tentative de connexion sur une machine distante avec un nom d'utilisateur ou un mot de passe incorrect avec Nessus : 21

22 Dépannage Q. Comment savoir si le scan local fonctionne? R. Sauf en cas de serveur 100 % corrigé, tout scan local communiquera probablement des informations sur les correctifs. En fonction du système d'exploitation, il communiquera aussi diverses vérifications d informations. Il peut aussi être utile de contourner «Nessus» et d effectuer un test pour s'assurer que les comptes et les réseaux sont configurés correctement. À l'aide de la commande Unix simple id, exécutez la commande suivante à partir du scanner Nessus : # ssh -i /home/test/nessus/ssh_key nessus@ id # Veillez à utiliser l'adresse IP du système avec lequel la relation de confiance est configurée ainsi que le compte d'utilisateur (dans ce cas, l utilisateur «nessus»). Si la commande réussit, les résultats de la commande id s afficheront comme si elle était exécutée sur le système distant. Pour les audits Unix, le script ssh_get_info.nasl signalera si l'authentification a réussi. Si les connexions SSH ne fonctionnent pas, vous pouvez changer le paramètre «report_verbosity» (Commentaires des rapports) du scanner Nessus sur «Verbose» (Détaillé). Cette opération permettra d'afficher tous les messages d'erreur ou de diagnostic pendant que ce script spécifique est exécuté. Pour les audits Windows, les scripts smb_login.nasl et smb_registry_access.nasl indiquent si la connexion et le mot de passe ont fonctionné pendant le scan et s'il a été possible de lire le registre distant. smb_registry_full_access.nasl fournit un avertissement seulement s'il n'a pas été possible de lire complètement le registre. L'examen des résultats des contrôles de l'hôte pour les audits d'un serveur Windows montrera le mode de fonctionnement des identifiants. En outre, le script hostlevel_check_failed.nasl détecte si les identifiants SSH ou Windows n'ont pas permis au scan de se connecter à l'hôte distant. Q. Comment savoir si le scan local ne fonctionne pas? R. Sur les systèmes Windows, les événements d'échec de connexion sont générés par le serveur. Si un contrôleur de domaine est utilisé, les événements d'échec de connexion seront également situés sur le serveur. Sur les systèmes Unix, les échecs de connexion seront présents dans les journaux du système (tels que /var/log/messages), sauf si un contrôleur Kerberos à distance est utilisé. En outre, le script hostlevel_check_failed.nasl détecte si les identifiants SSH ou Windows n'ont pas permis au scan de se connecter à l'hôte distant. Q. Quels peuvent être les autres problèmes liés aux contrôles d'hôte? R. Il existe beaucoup de circonstances pouvant bloquer l'accès. En voici quelques-unes : Pare-feu de réseau qui filtrent le port 22 pour SSH sur Unix ou le port 445 pour Windows Pare-feu de l'hôte qui bloquent les connexions aux ports ci-dessus Sur les systèmes Unix, administrateurs qui déplacent SSH sur des ports autres que le port 22 22

23 Certains systèmes IDS hôte et réseau interdisent l'accès à distance La machine scannée n'est pas un serveur Unix ou Windows et pourrait être une imprimante, un routeur, un télécopieur ou un terminal vidéo Q. Je teste les connexions SSH entre l'invite shell des hôtes cibles du scan et le système Nessus pour assurer une bonne connectivité. Mes résultats indiquent qu'il est sujet à un retard lors de la connexion. Pourquoi? R. C'est très probablement parce que le système effectue une recherche DNS lorsque DNS est mal configuré. Si le site utilise DNS, contactez l'administrateur DNS pour résoudre les problèmes de configuration. Certains problèmes qui peuvent exister incluent l'absence de zones de recherche inversée. Pour tester les recherches DNS, procédez comme suit : # host IP_ADRR_OF_NESSUS_SERVER Si «dig» est installé, il est aussi possible d effectuer la vérification au moyen de: # dig -x IP_ADRR_OF_NESSUS_SERVER Si le site n'utilise pas DNS, les étapes suivantes contournent les tentatives d'exécution des recherches DNS. 1. Éditez le fichier /etc/nsswitch.conf de sorte que la ligne «hosts:» (hôtes :) indique «hosts: files» (hôtes : fichiers) Remarque : Ceci peut ne pas s'appliquer à toutes les versions d'openssh. 2. Ajoutez l'ip/nom du serveur exécutant Nessus au fichier /etc/hosts du système. 3. Configurez le serveur OpenSSH à distance pour qu'il n'effectue pas de recherche DNS sur un hôte en utilisant les paramètres suivants : - «UseDNS no» dans le fichier sshd_config (pour la version 3.8), la valeur par défaut est yes (oui) - «VerifyReverseMapping no» Sécurisation du scanner Pourquoi sécuriser le scanner? Si un scanner Nessus est configuré pour utiliser des identifiants afin de se connecter à un serveur Unix ou Windows, le système contiendra des identifiants dont un utilisateur malveillant pourrait tirer avantage. Pour empêcher cela, il faut non seulement assurer la sécurité du système d'exploitation sur lequel le scanner est exécuté, mais aussi prendre conscience de la façon dont un attaquant peut manipuler le scanner pour qu il divulgue des informations de sécurité. Que signifie le verrouillage d'un scanner? Le scanner Nessus idéal devrait être complètement géré à partir d'une console système et n accepter aucune connexion réseau à partir d'un hôte distant. Un tel système sera physiquement sécurisé, de sorte que seules les personnes autorisées aient la permission d'y accéder. Ce serveur pourrait être davantage limité à l aide d un pare-feu ou d un commutateur externe qui lui permet uniquement de scanner des réseaux spécifiques. Il ne faut pas installer de pare-feu personnel directement sur le système de scanner Nessus. Nessus peut être configuré pour scanner uniquement des réseaux spécifiques. Ce type de scanner n'est pas très utile. Envisagez de permettre au serveur d'accéder à des réseaux à distance. Nessus prend en charge les connexions HTTP au port 8834 par défaut. Un pare-feu système peut être configuré pour accepter uniquement au port 8834 des connexions provenant de clients Nessus valides. Si l'appareil doit être géré ou utilisé à distance, l'accès sécurisé distant peut aussi être utilisé. Sur Unix, le protocole Secure Shell (SSH) peut être utilisé. Maintenez le démon SSH à jour, utilisez des mots de passe compliqués et/ou utilisez 23

24 des techniques d'authentification plus renforcées. Sur les serveurs Windows, les services Terminal Server à distance peuvent être utilisés pour assurer les commandes et le contrôle sur les services pour Nessus Windows. Dans les deux cas, veillez à maintenir le système à jour et à ne pas exécuter de services réseau inutiles. Voir les références Center for Internet Security (CIS) benchmarks (Points de référence du Centre de sécurité Internet (CIS)) pour des conseils sur le renforcement des systèmes. Mise en place sécurisée des vérifications SSH d'unix N'utilisez jamais les mots de passe SSH pour effectuer des scans à distance. Si un réseau est scanné, il suffirait à un attaquant ou un utilisateur malveillant d'exécuter un démon SSH modifié et d'enregistrer les tentatives de nom d'utilisateur et de mot de passe. Même si une combinaison unique nom d'utilisateur et mot de passe est utilisée pour chaque hôte, le recours aux mots de passe statiques est toujours vulnérable. Si vous vous connectez par mot de passe à un système compromis, vous devez vous attendre à un risque de vol du mot de passe, puisque le mot de passe est acheminé via la connexion SSH. Une fois qu'il a pris le contrôle du serveur distant, l'attaquant peut remplacer le démon SSH par le sien afin de consigner les mots de passe utilisés pour les connexions entrantes. Vérifications Windows sécurisées Si l'option «Only use NTLMv2» (Utiliser seulement NTLMv2) est désactivée, il est théoriquement possible de manipuler Nessus pour qu il essaie de se connecter à un serveur Windows avec des identifiants de domaine à l'aide du protocole NTLM version 1. Ceci fournit à l'attaquant distant l'opportunité d'utiliser une «empreinte numérique» obtenue auprès de Nessus. Cette «empreinte numérique» peut potentiellement être craquée pour révéler un nom d'utilisateur ou un mot de passe. Elle peut aussi être utilisée pour se connecter directement à d'autres serveurs. Forcez Nessus à utiliser NTLMv2 en activant le paramètre «Only use NTLMv2» (Utiliser uniquement NTLMv2) pour le scan. Ceci empêche un serveur Windows hostile d'utiliser NTLM et de recevoir une «empreinte numérique». NTLMv2 peut utiliser la «Signature SMB». Assurez-vous que la «Signature SMB» est activée sur tous les serveurs Windows afin d'empêcher tout serveur qui obtient une «empreinte numérique» provenant d'un scan de Nessus de la réutiliser. En outre, veillez à mettre en application une stratégie exigeant l'utilisation de mots de passe renforcés qui ne peuvent pas être facilement cassés par des attaques de dictionnaire provenant d'outil tels que John the Ripper et L0phtCrack. Il y a eu un grand nombre de types d'attaques différents contre la sécurité de Windows pour obtenir illégalement des «empreintes numériques» auprès des ordinateurs en vue de les réutiliser en attaquant les serveurs. La «Signature SMB» ajoute un niveau de sécurité pour empêcher ces attaques par intermédiaire. Pour plus d'informations Tenable a créé plusieurs autres documents expliquant en détail l'installation, le déploiement, la configuration, l'utilisation et les tests d'ensemble de Nessus. Nessus 5.2 Installation and Configuration Guide (Guide d'installation et de configuration Nessus 5.2) : explication pas à pas des étapes d'installation et de configuration Nessus 5.2 User Guide (Guide de l'utilisateur Nessus 5.2) : configuration et utilisation de l'interface utilisateur Nessus Nessus Compliance Checks (Contrôles de conformité Nessus) : guide de haut niveau pour comprendre et exécuter les contrôles de conformité au moyen de Nessus et de SecurityCenter Nessus Compliance Checks Reference (Référence pour les contrôles de conformité Nessus) : guide complet sur la syntaxe des contrôles de conformité Nessus Nessus v2 File Format (Format de fichier Nessus v2) : décrit la structure du format de fichier.nessus, qui a été introduit avec Nessus 3.2 et NessusClient

25 Nessus 5.0 REST Protocol Specification (Caractéristique du protocole Nessus 5.0 REST) : décrit le protocole REST et l'interface dans Nessus Nessus 5 and Antivirus (Nessus 5 et les antivirus) : présente le mode d'interaction des progiciels de sécurité les plus courants avec Nessus et fournit des conseils et des solutions qui favoriseront une meilleure coexistence des logiciels, sans compromettre la sécurité ou faire obstacle à vos opérations de scan des vulnérabilités Nessus 5 and Mobile Device Scanning (Nessus 5 et scan des périphériques mobiles) : décrit comment Nessus s'intègre à Microsoft Active Directory et aux serveurs MDM (serveurs de gestion des périphériques mobiles) afin d'identifier les périphériques mobiles utilisés sur le réseau Nessus 5.0 and Scanning Virtual Machines (Nessus 5.0 et scan des machines virtuelles) : présente comment utiliser le scanner de vulnérabilité Nessus de Tenable Network Security pour effectuer l'audit de la configuration des plateformes virtuelles et des logiciels exécutés sur ces plateformes Strategic Anti-malware Monitoring with Nessus, PVS, and LCE (Surveillance stratégique des programmes malveillants avec Nessus, PVS et LCE) : décrit comment la plateforme USM de Tenable peut détecter divers logiciels malveillants, identifier les infections de ces programme malveillants et en déterminer l'étendue Patch Management Integration (Intégration de la gestion de correctifs) : décrit comment Nessus et SecurityCenter peuvent tirer parti des identifiants pour les systèmes de gestion de correctif IBM TEM, Microsoft WSUS et SCCM, VMware Go et Red Hat Network Satellite afin d'effectuer l'audit de correctifs sur les systèmes pour lesquels les identifiants peuvent ne pas être mis à la disposition du scanner Nessus Real-Time Compliance Monitoring (Surveillance de conformité en temps réel) : décrit comment les solutions de Tenable peuvent être utilisées pour faciliter le respect d un grand nombre de types de règlements gouvernementaux et financiers Tenable Products Plugin Families (Familles de plugins des produits Tenable) : fournit la description et le résumé des familles de plugins pour Nessus, Log Correlation Engine et Passive Vulnerability Scanner SecurityCenter Administration Guide (Guide d'administration de SecurityCenter) D'autres ressources en ligne sont répertoriées ci-dessous : Forum de discussions Nessus : Blog Tenable : Podcast Tenable : Vidéos d'exemples d'utilisation : Feed Twitter Tenable : N hésitez pas à contacter Tenable aux adresses support@tenable.com et sales@tenable.com, ou consultez notre site internet sur 25

26 À propos de Tenable Network Security Les solutions de Tenable Network Security sont utilisées par plus de organisations, dont tous les services du Département de la Défense des États-Unis (DOD, Department of Defense) ainsi que de nombreuses grandes entreprises internationales et agences gouvernementales, pour prendre une longueur d'avance sur les vulnérabilités, menaces et risques de conformité émergents. Ses solutions Nessus et SecurityCenter continuent de définir la norme pour l'identification des vulnérabilités, la prévention des attaques et le respect de nombreuses exigences règlementaires. Pour plus d'informations, veuillez consulter SIÈGE MONDIAL Tenable Network Security 7021 Columbia Gateway Drive Suite 500 Columbia, Maryland Copyright Tenable Network Security, Inc. Tous droits réservés. Tenable Network Security et Nessus sont des marques déposées de Tenable Network Security, Inc. 26