Nmap et Nikto : le guide pour auditer son réseau et ses services web

1. Nmap et Nikto : deux rôles complémentaires

Nmap sert à l’exploration réseau et à l’audit de sécurité. Nikto se concentre sur les serveurs web. Une séquence logique consiste à repérer un service HTTP ou HTTPS, à confirmer le site réellement présenté, puis à choisir les contrôles web pertinents.

Un scan de ports ne constitue pas un pentest complet. Un scanner web ne prouve pas l’absence de faille d’autorisation dans une API. Les tests d’accès entre comptes, de logique métier, de session et de transactions nécessitent une méthode complémentaire. L’article pentest, audit et red team explique ces différences de périmètre.

2. Cadrer la cible avant de choisir des options

Établissez une liste d’adresses, de noms de domaine, de ports autorisés et d’exclusions. Identifiez les propriétaires, les plages de test, les seuils de charge et le contact capable de demander un arrêt. Précisez si les contrôles passent par le pare-feu de production, un VPN, une zone interne ou une plateforme de préproduction.

Un domaine peut résoudre vers un CDN ou un hébergement partagé. L’autorisation d’auditer votre application ne s’étend pas automatiquement aux autres services de cette infrastructure. Évitez d’élargir une cible à tout un sous-réseau parce qu’un nom DNS pointe vers l’une de ses adresses. Contrôlez également les destinations des redirections.

Préparez la surveillance des erreurs HTTP, de la latence et de la consommation de ressources pendant l’exercice. Définissez un seuil d’arrêt avec l’exploitant. Un scanner peut provoquer des alertes, des journaux volumineux ou une charge significative même lorsqu’aucune exploitation n’est recherchée.

3. Architecture et prérequis du laboratoire

L’exemple utilise un poste Linux d’audit et un serveur de laboratoire à l’adresse 192.168.56.20. Le service web de test écoute sur 8080. Préparez ce service et un contenu factice avant les commandes. L’adresse privée n’est pas une garantie d’isolement : vérifiez le routage et l’absence de chevauchement avec vos réseaux habituels.

Installez Nmap et Nikto depuis leurs sources officielles ou les paquets de confiance de votre distribution. Les commandes ci-dessous supposent les lanceurs nmap et nikto. Une installation Nikto depuis les sources peut nécessiter perl nikto.pl depuis le bon répertoire. Sous Windows, les modes réseau disponibles dépendent aussi de Npcap et des privilèges.

nmap --version
nikto -Version
nikto -Help

Notez la version du logiciel, celle des bases de tests lorsqu’elle est disponible, le système et le point réseau utilisé. Avant chaque commande, relisez la cible. Les exemples créent des fichiers de rapport dans le répertoire courant ; utilisez un dossier dédié et accessible uniquement aux personnes concernées.

4. Découvrir un hôte sans confondre silence et absence

La découverte d’hôtes Nmap cherche à déterminer quels systèmes répondent avant les scans de ports. -sn demande une découverte sans scan de ports. -n évite la résolution DNS inverse. Sur un réseau local, les mécanismes utilisés peuvent notamment inclure ARP ; le comportement dépend du contexte et des privilèges.

nmap -sn -n 192.168.56.20

Si la machine ne répond pas, vérifiez d’abord son état, l’adresse, les routes et les filtres. Un pare-feu peut bloquer une sonde tout en autorisant HTTPS. L’option -Pn saute la phase qui décide si l’hôte est actif et demande de traiter la cible comme disponible. Elle ne contourne pas un pare-feu et peut considérablement allonger un scan sur de nombreuses adresses.

Dans un inventaire, enregistrez les hôtes injoignables avec leur niveau d’incertitude. Ne les supprimez pas automatiquement du périmètre : vous risqueriez de produire une carte rassurante précisément là où votre point d’observation est incomplet.

5. Lire les ports et leurs états correctement

Ces états sont décrits dans le guide des états de ports. Ils qualifient une observation depuis un emplacement et à un instant donnés. Le même service peut être accessible depuis le réseau d’administration et filtré depuis le réseau des postes utilisateurs : c’est parfois exactement le résultat souhaité.

Un scan Nmap standard ne teste pas tous les ports : sa sélection habituelle porte sur les 1 000 ports TCP les plus courants. Un rapport doit annoncer les ports réellement examinés. L’option -p- élargit la sélection aux ports 1 à 65535 du protocole scanné ; elle ne rajoute pas à elle seule UDP.

6. TCP, UDP et identification des services

Le scan TCP connect, demandé avec -sT, utilise les connexions du système. Le scan SYN -sS travaille à un niveau plus bas et nécessite des capacités adaptées. Aucun ne garantit la discrétion : les équipements et les agents peuvent enregistrer les tentatives.

nmap -sT -n -p 22,80,443,8080 --reason -oA labo-tcp 192.168.56.20

Cette sélection vérifie quatre ports connus, affiche la raison de l’état et produit des rapports. Elle ne mesure pas toute l’exposition du serveur. Pour approfondir un service web déjà identifié, on peut ensuite demander une détection de version limitée :

nmap -sT -sV --version-light -n -p 8080 -oA labo-web 192.168.56.20

La détection de version envoie des sondes applicatives. Le nom de service déduit d’un numéro de port et le produit reconnu après sondage ne sont pas la même information. Un logiciel peut écouter sur un port inhabituel ; un proxy peut répondre à la place du serveur d’origine.

UDP mérite un lot distinct, sur des services attendus et une cible connue. Le silence peut rester ambigu et les limitations de débit des réponses compliquent l’analyse. Dans un laboratoire Linux disposant des privilèges requis, une vérification ciblée peut s’écrire :

sudo nmap -sU -n -p 53,123 --reason -oA labo-udp 192.168.56.20

Les ports retenus correspondent ici à DNS et NTP habituels, sans prouver qu’ils sont présents. Si ces services ne font pas partie du laboratoire, ce test n’apporte pas grand-chose. Choisissez les ports à partir de l’inventaire et des hypothèses de l’audit.

7. NSE : sélectionner les scripts, pas une promesse de sécurité

Le Nmap Scripting Engine ajoute des contrôles applicatifs. L’option -sC sélectionne les scripts par défaut ; -A active plusieurs fonctions, dont des scripts. Ces raccourcis ne conviennent pas automatiquement à un périmètre sensible.

Consultez l’aide de chaque script avant d’autoriser son exécution. Les catégories telles que safe ou vuln ne remplacent pas une analyse de ses actions, paramètres et destinations. Les scripts ne sont pas exécutés dans un bac à sable ; une source tierce non vérifiée constitue aussi un risque pour le poste d’audit.

nmap --script-help http-title,http-headers

Cette commande affiche l’aide sans lancer de scan de cible. Pour un examen réel, choisissez une liste précise après revue, puis fixez les hôtes et les ports. Un script qui obtient le titre d’une page renseigne sur le contenu reçu ; il ne valide ni l’authentification ni l’absence de vulnérabilité.

Les fonctions de détection du système d’exploitation, de traceroute ou de mesure TLS peuvent être utiles dans une mission, mais leur ajout doit répondre à une question. Accumuler les options rend plus difficile l’attribution d’un effet et la reproduction d’un résultat.

8. Passer du port ouvert au bon site web

Une adresse IP peut héberger plusieurs sites. Le nom envoyé dans la requête HTTP et, pour TLS, le nom transmis lors de la négociation peuvent déterminer la réponse. Scanner uniquement l’adresse peut afficher un site par défaut et manquer l’application recherchée.

Établissez donc une correspondance entre nom, adresse, port, protocole et chemin applicatif. Vérifiez le certificat et la destination après redirection. Un CDN ou un reverse proxy peut masquer les caractéristiques de l’origine, ce qui est une limite d’observation à noter, pas une invitation à chercher une origine hors périmètre.

IPv4 et IPv6 doivent être inventoriés séparément. Une application peut être filtrée correctement sur l’un et exposée différemment sur l’autre. Nmap propose -6 pour IPv6, mais seules les adresses explicitement autorisées doivent être ajoutées. Une vérification IPv4 réussie n’atteste pas le comportement IPv6.

9. Nikto : choisir un contrôle web et comprendre sa portée

Le guide de prise en main Nikto accepte notamment une URL complète comme cible. Pour notre service HTTP de laboratoire, un contrôle ciblé sur la catégorie de configuration peut être préparé ainsi :

nikto -h http://192.168.56.20:8080 -Tuning 2 -output labo-nikto.htm -Format htm

Dans la documentation du réglage des tests, 2 correspond aux erreurs de configuration et fichiers par défaut. Ce choix réduit le champ des contrôles : il ne représente pas un scan complet et ne garantit pas l’absence d’effet sur le service. Le rapport est au format HTML et le format demandé à Nikto est htm ; vérifiez les formats disponibles dans l’aide de votre version.

Les familles de tests couvrent des sujets différents, dont certains sont plus intrusifs. Définissez une liste adaptée à la mission plutôt qu’un lancement systématique de toutes les catégories. Évaluez d’abord la charge sur une seule instance de test, puis déterminez la cadence avec l’exploitant.

Une réponse HTTP inhabituelle, un chemin sensible apparent ou une bannière ancienne est un point de départ. Conservez l’URL, le statut, la réponse utile et les conditions du test. N’enregistrez pas des pages entières contenant des données personnelles si un extrait expurgé suffit à démontrer le constat.

10. Authentification, TLS, API : les angles morts

Une page de connexion peut donner la même réponse à tous les chemins demandés. Un WAF peut renvoyer un blocage générique. Une application peut répondre 200 à un fichier inexistant avec sa page d’accueil. Dans ces cas, le scanner risque de confondre une réponse standard avec une ressource réelle.

Les applications avec authentification fédérée, jetons courts, MFA ou parcours JavaScript complexes demandent une préparation supplémentaire. Une option d’authentification basique ne reproduit pas automatiquement une session utilisateur moderne. Ne placez pas de secrets dans des commandes copiées dans un rapport ; utilisez un compte de test et vérifiez ce que la session voit effectivement.

L’examen TLS exige de distinguer certificat, protocoles autorisés et configuration du frontal. La découverte d’un port 443 ouvert n’atteste aucun de ces points. De même, une API peut présenter peu de pages tout en autorisant des actions sensibles. Les droits sur les objets, les rôles et les quotas se testent avec des scénarios applicatifs dédiés.

La couverture doit donc expliciter les comptes utilisés, les pages accessibles, les tests exclus et les obstacles rencontrés. « Aucun résultat » peut signifier « rien de détecté dans les réponses accessibles », pas « application sans faille ».

11. Qualifier les faux positifs et les priorités

Ces exemples sont des scénarios pédagogiques, pas des constats de mission. Pour chaque résultat, distinguez une information, une faiblesse confirmée et une vulnérabilité exploitable dans le contexte. Un identifiant CVE associé à une version ne remplace pas l’analyse d’applicabilité.

La priorité combine l’exposition, les privilèges nécessaires, les actifs concernés et les conséquences. Une interface d’administration accessible sans nécessité peut mériter une correction rapide même sans CVE. Le guide KEV, EPSS et CVSS v4 explique comment compléter cette appréciation pour les vulnérabilités connues.

12. Rapports, automatisation et contre-tests

Nmap propose plusieurs sorties. -oA crée les formats normal, XML et grepable avec un même préfixe. Pour une intégration logicielle, privilégiez le XML et un parseur adapté plutôt qu’une extraction fragile de colonnes à l’écran.

Une automatisation utile conserve l’horodatage, les versions, la cible, le point d’observation, les options et le statut de fin. Un traitement interrompu n’est pas un rapport vide réussi. Protégez les exports : l’inventaire des services peut lui-même être sensible. Fixez une rétention et des droits d’accès.

Comparez des campagnes comparables. Si la liste de ports ou les scripts changent, une nouvelle alerte peut refléter une nouvelle couverture plutôt qu’une régression du système. Une base de signatures actualisée peut aussi produire de nouveaux constats sans modification de l’application.

Après correction, rejouez le contrôle ciblé depuis le même emplacement, puis vérifiez un parcours utilisateur légitime. Conservez les preuves avant et après. Si un filtre a été modifié, testez aussi la source autorisée : un résultat « tout est fermé » peut simplement signifier que vous avez interrompu le service.

13. Questions fréquentes et checklist de fin

Nmap ou Nikto : lequel choisir ?

Commencez par la question. Pour savoir quels services sont accessibles, Nmap convient. Pour examiner des réponses web avec des contrôles connus, Nikto complète l’analyse. Un audit peut avoir besoin des deux et d’autres méthodes.

Peut-on automatiser un scan régulier ?

Oui, avec un périmètre stable, une cadence validée, des contrôles de charge et un traitement des erreurs. Les résultats doivent être attribués à un responsable et comparés à une référence. Accumuler des rapports sans suivi n’améliore pas la sécurité.

Une bannière suffit-elle pour annoncer une CVE ?

Non. Un frontal peut modifier la réponse et un éditeur peut rétroporter un correctif sans changer la version majeure affichée. Confirmez le logiciel réellement installé et l’avis applicable.

Qu’apporte Impacket en complément ?

Dans un audit Windows autorisé, Impacket aide à examiner des interactions de protocole et des permissions. Il répond à d’autres questions que l’inventaire des ports ou la recherche de configurations web.

• Périmètre, propriétaires et exclusions documentés.
• Versions, source réseau et options conservées.
• Résultats ambigus ou tests interrompus signalés.
• Constats confirmés et preuves expurgées.
• Correction attribuée, puis contre-test et vérification métier.
• Comptes temporaires retirés et rapports protégés.

Pour aller plus loin : maîtriser sa surface d’attaque et organiser la remédiation après un pentest.

Sources et références

Documentation consultée le 24 octobre 2026. Les architectures et scénarios sont pédagogiques ; les exemples restent illustratifs et ne reproduisent pas les journaux du rejeu confirmé.

• Nmap - manuel de référence
• Nmap - découverte d’hôtes
• Nmap - états des ports
• Nmap - techniques de scan
• Nmap - détection de versions
• Nmap - moteur NSE
• Nmap - formats de sortie
• Nikto - tests de base
• Nikto - sélection des tests
• Nikto - formats de rapport
• Nikto - documentation officielle