Comment tester la configuration de votre pare-feu avec Nmap et Tcpdump

Introduction

La configuration d'un pare-feu pour votre infrastructure est un excellent moyen d'assurer une sécurité de base pour vos services. Une fois que vous avez développé une politique qui vous convient, l'étape suivante consiste à tester vos règles de pare-feu. Il est important d'avoir une bonne idée de savoir si vos règles de pare-feu font ce que vous pensez qu'elles font et d'avoir une idée de ce à quoi ressemble votre infrastructure pour le monde extérieur.

Dans ce guide, nous allons passer en revue quelques outils et techniques simples que vous pouvez utiliser pour valider vos règles de pare-feu. Ce sont quelques-uns des mêmes outils que les utilisateurs malveillants peuvent utiliser, vous pourrez donc voir quelles informations ils peuvent trouver en faisant des requêtes à vos serveurs.

Conditions préalables

Dans ce guide, nous supposerons que vous avez un pare-feu configuré sur au moins un serveur. Vous pouvez commencer à créer votre stratégie de pare-feu en suivant un ou plusieurs de ces guides :

• Iptables

• UFW

• FirewallD

Dans ce guide, nous appellerons le serveur contenant les politiques de pare-feu que vous souhaitez tester la cible. En plus de votre cible, vous devrez également avoir accès à un serveur à partir duquel tester, situé en dehors du réseau protégé par votre pare-feu. Dans ce guide, nous utiliserons un serveur Ubuntu 14.04 comme machine d'audit.

Une fois que vous avez un serveur à tester et les cibles que vous souhaitez évaluer, vous pouvez continuer avec ce guide.

Avertissement

Vous ne devez effectuer les activités décrites dans ce guide que sur l'infrastructure que vous contrôlez, à des fins d'audit de sécurité. Les lois entourant la numérisation des ports sont incertaines dans de nombreuses juridictions. Les FAI et autres fournisseurs sont connus pour interdire les utilisateurs qui sont trouvés en train de scanner les ports.

Les outils que nous utiliserons pour tester les stratégies de pare-feu

Il existe de nombreux outils différents que nous pouvons utiliser pour tester nos politiques de pare-feu. Certains d'entre eux ont des fonctionnalités qui se chevauchent. Nous ne couvrirons pas tous les outils possibles. Au lieu de cela, nous couvrirons certaines catégories générales d'outils d'audit et passerons en revue les outils que nous utiliserons dans ce guide.

Analyseurs de paquets

Les analyseurs de paquets peuvent être utilisés pour surveiller de manière très détaillée tout le trafic réseau passant par une interface. La plupart des analyseurs de paquets ont la possibilité de fonctionner en temps réel, d'afficher les paquets au fur et à mesure qu'ils sont envoyés ou reçus, ou d'écrire des informations sur les paquets dans un fichier et de les traiter ultérieurement. L'analyse des paquets nous donne la possibilité de voir, à un niveau granulaire, quels types de réponses nos machines cibles renvoient aux hôtes sur le réseau ouvert.

Pour les besoins de notre guide, nous utiliserons l'outil tcpdump. C'est une bonne option car elle est puissante, flexible et plutôt omniprésente sur les systèmes Linux. Nous l'utiliserons pour capturer les paquets bruts pendant que nous exécutons nos tests au cas où nous aurions besoin de la transcription pour une analyse ultérieure. Certaines autres options populaires sont Wireshark (ou tshark, son cousin en ligne de commande) et tcpflow qui peuvent rassembler des conversations TCP entières de manière organisée.

Scanners de ports

Afin de générer le trafic et les réponses à capturer par notre analyseur de paquets, nous utiliserons un scanner de ports. Les scanners de ports peuvent être utilisés pour créer et envoyer différents types de paquets à des hôtes distants afin de découvrir le type de trafic que le serveur accepte. Les utilisateurs malveillants l'utilisent souvent comme un outil de découverte pour essayer de trouver des services vulnérables à exploiter (une partie de la raison d'utiliser un pare-feu en premier lieu), nous allons donc l'utiliser pour essayer de voir ce qu'un attaquant pourrait découvrir.

Pour ce guide, nous utiliserons l'outil de cartographie réseau et d'analyse des ports nmap. Nous pouvons utiliser nmap pour envoyer des paquets de différents types pour essayer de déterminer quels services se trouvent sur notre machine cible et quelles règles de pare-feu la protègent.

Configuration de la machine d'audit

Avant de commencer, nous devons nous assurer que nous disposons des outils décrits ci-dessus. Nous pouvons obtenir tcpdump à partir des dépôts d'Ubuntu. Nous pouvons également obtenir nmap avec cette méthode, mais la version du référentiel est probablement obsolète. Au lieu de cela, nous installerons des packages pour nous aider dans la compilation du logiciel, puis nous le créerons nous-mêmes à partir de la source.

Mettez à jour l'index de package local et installez le logiciel s'il n'est pas déjà disponible. Nous purgerons également nmap de notre système s'il est déjà installé pour éviter les conflits :

sudo apt-get update
sudo apt-get purge nmap
sudo apt-get install tcpdump build-essential libssl-dev

Maintenant que nous avons nos outils de compilation et la bibliothèque de développement SSL, nous pouvons obtenir la dernière version de nmap à partir de la page de téléchargement sur le site officiel. Ouvrez la page dans votre navigateur Web.

Faites défiler jusqu'à la section "Distribution du code source". En bas, vous verrez un lien vers le code source de la dernière version de nmap. Au moment d'écrire ces lignes, cela ressemble à ceci:

Faites un clic droit sur le lien et copiez l'adresse du lien.

De retour sur votre machine d'audit, accédez à votre répertoire personnel et utilisez wget pour télécharger le lien que vous avez collé. Assurez-vous de mettre à jour le lien ci-dessous pour refléter la version la plus récente que vous avez copiée à partir du site :

cd ~
wget https://nmap.org/dist/nmap-6.49BETA4.tar.bz2

Décompressez le fichier que vous avez téléchargé et déplacez-vous dans le répertoire résultant en tapant :

tar xjvf nmap*
cd nmap*

Configurez et compilez le code source en tapant :

./configure
make

Une fois la compilation terminée, vous pouvez installer les exécutables résultants et les fichiers de support sur votre système en tapant :

sudo make install

Confirmez votre installation en tapant :

nmap -V

Le résultat doit correspondre à la version que vous avez téléchargée depuis le site Web nmap :

OutputNmap version 6.49BETA4 ( https://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.2.3 openssl-1.0.1f nmap-libpcre-7.6 nmap-libpcap-1.7.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Ensuite, nous allons créer un répertoire dans lequel nous pourrons stocker nos résultats d'analyse :

mkdir ~/scan_results

Pour vous assurer d'obtenir des résultats corrects, quittez toutes les sessions ouvertes entre votre système d'audit et le système cible. Cela inclut les sessions SSH, toutes les connexions HTTP(S) que vous avez pu établir dans un navigateur Web, etc.

Analysez votre cible pour les ports TCP ouverts

Maintenant que notre serveur et nos fichiers sont prêts, nous allons commencer par analyser notre hôte cible pour les ports TCP ouverts.

Il existe en fait quelques scans TCP que nmap sait faire. Le meilleur pour commencer est généralement un scan SYN, également connu sous le nom de «scan semi-ouvert», car il ne négocie jamais réellement une connexion TCP complète. Ceci est souvent utilisé par les attaquants car il ne parvient pas à s'enregistrer sur certains systèmes de détection d'intrusion car il ne termine jamais une poignée de main complète.

Configuration de la capture de paquets

Avant de scanner, nous allons configurer tcpdump pour capturer le trafic généré par le test. Cela nous aidera à analyser plus en profondeur les paquets envoyés et reçus plus tard si nous en avons besoin. Créons un répertoire dans ~/scan_results afin que nous puissions conserver ensemble les fichiers liés à notre analyse SYN :

mkdir ~/scan_results/syn_scan

Nous pouvons démarrer une capture tcpdump et écrire les résultats dans un fichier de notre répertoire ~/scan_results/syn_scan avec la commande suivante :

sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets

Par défaut, tcpdump s'exécutera au premier plan. Afin d'exécuter notre analyse nmap dans la même fenêtre, nous devrons mettre en pause le processus tcpdump, puis le redémarrer en arrière-plan.

Nous pouvons mettre en pause le processus en cours en appuyant sur CTRL-Z :

CTRL-Z

Cela mettra en pause le processus en cours :

Output^Z
[1]+  Stopped                 sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets

Maintenant, vous pouvez redémarrer le travail en arrière-plan en tapant bg :

bg

Vous devriez voir une ligne de sortie similaire, cette fois sans l'étiquette "Stopped" et avec une esperluette à la fin pour indiquer que le processus sera exécuté en arrière-plan :

Output[1]+ sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets &

La commande s'exécute maintenant en arrière-plan, surveillant tous les paquets passant entre notre audit et les machines cibles. Nous pouvons maintenant exécuter notre analyse SYN.

Exécutez l'analyse SYN

Avec tcpdump enregistrant notre trafic vers la machine cible, nous sommes prêts à exécuter nmap. Nous utiliserons les drapeaux suivants pour que nmap effectue les actions dont nous avons besoin :

• -sS : Cela démarre un balayage SYN. Il s'agit techniquement de l'analyse par défaut que nmap effectuera si aucun type d'analyse n'est donné, mais nous l'inclurons ici pour être explicite.
• -Pn : cela indique à nmap de sauter l'étape de découverte de l'hôte, ce qui annulerait le test plus tôt si l'hôte ne répondait pas à un ping. Puisque nous savons que la cible est en ligne, nous pouvons ignorer cela.
• -p- : par défaut, les analyses SYN n'essaieront que les 1 000 ports les plus couramment utilisés. Cela indique à nmap de vérifier chaque port disponible.
• -T4 : Cela définit un profil de synchronisation pour nmap, lui indiquant d'accélérer le test au risque d'obtenir des résultats légèrement moins précis. 0 est le plus lent et 5 est le plus rapide. Étant donné que nous analysons chaque port, nous pouvons l'utiliser comme référence et revérifier ultérieurement tous les ports qui auraient pu être signalés de manière incorrecte.
• -vv : Cela augmente la verbosité de la sortie.
• --reason : cela indique à nmap de fournir la raison pour laquelle l'état d'un port a été signalé d'une certaine manière.
• -oN : Cela écrit les résultats dans un fichier que nous pouvons utiliser pour une analyse ultérieure.

Noter

Une chose à garder à l'esprit est que pour vérifier IPv6, vous devrez ajouter le drapeau -6 à vos commandes. Étant donné que la plupart des didacticiels prérequis n'acceptent pas le trafic IPv6, nous allons ignorer IPv6 pour ce guide. Ajoutez cet indicateur si votre pare-feu accepte le trafic IPv6.

Ensemble, la commande ressemblera à ceci :

sudo nmap -sS -Pn -p- -T4 -vv --reason -oN ~/scan_results/syn_scan/nmap.results target_ip_addr

Même avec le modèle de synchronisation défini sur 4, l'analyse prendra probablement un certain temps car elle passe par 65 535 ports (mon test a duré environ quarante minutes). Vous verrez des résultats commencer à s'imprimer qui ressemblent à ceci :

OutputStarting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-26 16:54 EDT
Initiating Parallel DNS resolution of 1 host. at 16:54
Completed Parallel DNS resolution of 1 host. at 16:54, 0.12s elapsed
Initiating SYN Stealth Scan at 16:54
Scanning 198.51.100.15 [65535 ports]
Discovered open port 22/tcp on 198.51.100.15
Discovered open port 80/tcp on 198.51.100.15
SYN Stealth Scan Timing: About 6.16% done; ETC: 17:02 (0:07:52 remaining)
SYN Stealth Scan Timing: About 8.60% done; ETC: 17:06 (0:10:48 remaining)

. . .

Arrêtez la capture de paquets tcpdump

Une fois l'analyse terminée, nous pouvons ramener notre processus tcpdump au premier plan et l'arrêter.

Sortez-le de l'arrière-plan en tapant :

fg

Arrêtez le processus en maintenant la touche contrôle enfoncée et en appuyant sur "c":

CTRL-C

Analyse des résultats

Vous devriez maintenant avoir deux fichiers dans votre répertoire ~/scan_results/syn_scan. Un appelé packets, généré par l'exécution tcpdump, et un généré par nmap appelé nmap.results.

Regardons d'abord le fichier nmap.results :

less ~/scan_results/syn_scan/nmap.results

~/scan_results/syn_scan/nmap.results

# Nmap 6.49BETA4 scan initiated Wed Aug 26 17:05:13 2015 as: nmap -sS -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/syn_scan/nmap.results 198.51.100.15
Increasing send delay for 198.51.100.15 from 0 to 5 due to 9226 out of 23064 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 5 to 10 due to 14 out of 34 dropped probes since last increase.
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.00097s latency).
Scanned at 2015-08-26 17:05:13 EDT for 2337s
Not shown: 65533 closed ports
Reason: 65533 resets
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63
80/tcp open  http    syn-ack ttl 63

Read data files from: /usr/local/bin/../share/nmap
# Nmap done at Wed Aug 26 17:44:10 2015 -- 1 IP address (1 host up) scanned in 2336.85 seconds

La zone en surbrillance ci-dessus contient les principaux résultats de l'analyse. Nous pouvons voir que le port 22 et le port 80 sont ouverts sur l'hôte scanné afin d'autoriser le trafic SSH et HTTP. Nous pouvons également voir que 65 533 ports ont été fermés. Un autre résultat possible serait "filtré". Filtré signifie que ces ports ont été identifiés comme étant arrêtés par quelque chose sur le chemin du réseau. Il peut s'agir d'un pare-feu sur la cible, mais il peut également s'agir de règles de filtrage sur l'un des hôtes intermédiaires entre les machines d'audit et cible.

Si nous voulons voir le trafic de paquets réel qui a été envoyé et reçu de la cible, nous pouvons relire le fichier packets dans tcpdump, comme ceci :

sudo tcpdump -nn -r ~/scan_results/syn_scan/packets | less

Ce fichier contient l'intégralité de la conversation qui a eu lieu entre les deux hôtes. Vous pouvez filtrer de plusieurs manières.

Par exemple, pour afficher uniquement le trafic envoyé à la cible, vous pouvez saisir :

sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'dst target_ip_addr' | less

De même, pour afficher uniquement le trafic de réponse, vous pouvez changer le "dst" en "src":

sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr' | less

Les ports TCP ouverts répondraient à ces demandes avec un paquet SYN. Nous pouvons rechercher directement des réponses pour ce type avec un filtre comme celui-ci :

sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr and tcp[tcpflags] & tcp-syn != 0' | less

Cela vous montrera uniquement les réponses SYN réussies et devrait correspondre aux ports que vous avez vus dans l'exécution nmap :

Outputreading from file packets, link-type EN10MB (Ethernet)
17:05:13.557597 IP 198.51.100.15.22 > 198.51.100.2.63872: Flags [S.], seq 2144564104, ack 4206039348, win 29200, options [mss 1460], length 0
17:05:13.558085 IP 198.51.100.15.80 > 198.51.100.2.63872: Flags [S.], seq 3550723926, ack 4206039348, win 29200, options [mss 1460], length 0

Vous pouvez faire plus d'analyse des données comme bon vous semble. Tout a été capturé pour un traitement et une analyse asynchrones.

Analysez votre cible pour les ports UDP ouverts

Maintenant que vous savez comment exécuter ces tests, nous pouvons effectuer un processus similaire pour rechercher les ports UDP ouverts.

Configuration de la capture de paquets

Encore une fois, créons un répertoire pour contenir nos résultats :

mkdir ~/scan_results/udp_scan

Redémarrez une capture tcpdump. Cette fois, écrivez le fichier dans le nouveau répertoire ~/scan_results/udp_scan :

sudo tcpdump host target_ip_addr -w ~/scan_results/udp_scan/packets

Mettez le processus en pause et mettez-le en arrière-plan :

CTRL-Z

bg

Exécutez l'analyse UDP

Maintenant, nous sommes prêts à exécuter l'analyse UDP. En raison de la nature du protocole UDP, cette analyse prendra généralement considérablement plus longtemps que l'analyse SYN. En fait, cela peut prendre plus d'une journée si vous analysez tous les ports du système. UDP est un protocole sans connexion, donc ne recevoir aucune réponse peut signifier que le port de la cible est bloqué, qu'il a été accepté ou que le paquet a été perdu. Pour essayer de les distinguer, nmap doit retransmettre des paquets supplémentaires pour essayer d'obtenir une réponse.

La plupart des drapeaux seront les mêmes que ceux que nous avons utilisés pour le scan SYN. En fait, le seul nouveau drapeau est :

• -sU : Cela indique à nmap d'effectuer une analyse UDP.

Accélération du test UDP

Si vous vous inquiétez de la durée de ce test, vous ne voudrez peut-être tester qu'un sous-ensemble de vos ports UDP dans un premier temps. Vous pouvez tester uniquement les 1000 ports les plus courants en omettant l'indicateur -p-. Cela peut raccourcir considérablement votre temps de numérisation. Si vous voulez une image complète, vous devrez revenir plus tard et analyser toute votre plage de ports.

Étant donné que vous analysez votre propre infrastructure, la meilleure option pour accélérer les analyses UDP consiste peut-être à désactiver temporairement la limitation de débit ICMP sur le système cible. En règle générale, les hôtes Linux limitent les réponses ICMP à 1 par seconde (c'est généralement une bonne chose, mais pas pour notre audit), ce qui signifie qu'une analyse UDP complète prendrait plus de 18 heures. Vous pouvez vérifier ce paramètre sur votre machine cible en tapant :

sudo sysctl net.ipv4.icmp_ratelimit

Outputnet.ipv4.icmp_ratelimit = 1000

Le "1000" est le nombre de millisecondes entre les réponses. Nous pouvons temporairement désactiver cette limitation de débit sur le système cible en tapant :

sudo sysctl -w net.ipv4.icmp_ratelimit=0

Il est très important de rétablir cette valeur après votre test.

Exécution du test

Assurez-vous d'écrire les résultats dans le répertoire ~/scan_results/udp_scan. Tous ensemble, la commande devrait ressembler à ceci :

sudo nmap -sU -Pn -p- -T4 -vv --reason -oN ~/scan_results/udp_scan/nmap.results target_ip_addr

Même avec la désactivation de la limitation du débit ICMP sur la cible, cette analyse a pris environ 2 heures et 45 minutes lors de notre test. Une fois l'analyse terminée, vous devez rétablir votre limite de débit ICMP (si vous l'avez modifiée) sur la machine cible :

sudo sysctl -w net.ipv4.icmp_ratelimit=1000

Arrêtez la capture de paquets tcpdump

Ramenez le processus tcpdump au premier plan sur votre machine d'audit en tapant :

fg

Arrêtez la capture de paquets en maintenant le contrôle et en appuyant sur "c":

CTRL-c

Analyse des résultats

Maintenant, nous pouvons jeter un œil aux fichiers générés.

Le fichier nmap.results résultant devrait ressembler assez à celui que nous avons vu précédemment :

less ~/scan_results/udp_scan/nmap.results

~/scan_results/udp_scan/nmap.results

# Nmap 6.49BETA4 scan initiated Thu Aug 27 12:42:42 2015 as: nmap -sU -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/udp_scan/nmap.results 198.51.100.15
Increasing send delay for 198.51.100.15 from 0 to 50 due to 10445 out of 26111 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 50 to 100 due to 11 out of 23 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 100 to 200 due to 3427 out of 8567 dropped probes since last increase.
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.0010s latency).
Scanned at 2015-08-27 12:42:42 EDT for 9956s
Not shown: 65532 closed ports
Reason: 65532 port-unreaches
PORT    STATE         SERVICE REASON
22/udp  open|filtered ssh     no-response
80/udp  open|filtered http    no-response
443/udp open|filtered https   no-response

Read data files from: /usr/local/bin/../share/nmap
# Nmap done at Thu Aug 27 15:28:39 2015 -- 1 IP address (1 host up) scanned in 9956.97 seconds

Une différence clé entre ce résultat et le résultat SYN précédent sera probablement le nombre de ports marqués open|filtered. Cela signifie que nmap n'a pas pu déterminer si l'absence de réponse signifiait qu'un service acceptait le trafic ou s'il avait été abandonné par un pare-feu ou un mécanisme de filtrage le long du chemin de livraison.

L'analyse de la sortie tcpdump est également beaucoup plus difficile car il n'y a pas d'indicateurs de connexion et parce que nous devons faire correspondre les réponses ICMP aux requêtes UDP.

Nous pouvons voir comment nmap a dû envoyer de nombreux paquets vers les ports signalés comme open|filtered en demandant à voir le trafic UDP vers l'un des ports signalés :

sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 22'

Vous verrez probablement quelque chose qui ressemble à ceci :

Outputreading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet)
14:57:40.801956 IP 198.51.100.2.60181 > 198.51.100.15.22: UDP, length 0
14:57:41.002364 IP 198.51.100.2.60182 > 198.51.100.15.22: UDP, length 0
14:57:41.202702 IP 198.51.100.2.60183 > 198.51.100.15.22: UDP, length 0
14:57:41.403099 IP 198.51.100.2.60184 > 198.51.100.15.22: UDP, length 0
14:57:41.603431 IP 198.51.100.2.60185 > 198.51.100.15.22: UDP, length 0
14:57:41.803885 IP 198.51.100.2.60186 > 198.51.100.15.22: UDP, length 0

Comparez cela aux résultats que nous voyons de l'un des ports analysés qui a été marqué comme "fermé":

sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 53'

Outputreading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet)
13:37:24.219270 IP 198.51.100.2.60181 > 198.51.100.15.53: 0 stat [0q] (12)

Nous pouvons essayer de reconstruire manuellement le processus suivi par nmap en compilant d'abord une liste de tous les ports auxquels nous envoyons des paquets UDP en utilisant quelque chose comme ceci :

sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets "udp" | awk '{print $5;}' | awk 'BEGIN { FS = "." } ; { print $5 +0}' | sort -u | tee outgoing

Ensuite, nous pouvons voir quels paquets ICMP nous avons reçus indiquant que le port était inaccessible :

sudo tcpdump -nn -Q in -r ~/scan_results/udp_scan/packets "icmp" |  awk '{print $10,$11}' | grep unreachable | awk '{print $1}' | sort -u | tee response

Nous pouvons voir alors prendre ces deux réponses et voir quels paquets UDP n'ont jamais reçu de réponse ICMP en tapant :

comm -3 outgoing response

Cela devrait principalement correspondre à la liste des ports signalée par nmap (elle peut contenir des faux positifs provenant de paquets de retour perdus).

Découverte d'hôtes et de services

Nous pouvons exécuter des tests supplémentaires sur notre cible pour voir s'il est possible pour nmap d'identifier le système d'exploitation en cours d'exécution ou l'une des versions de service.

Créons un répertoire pour contenir nos résultats de versionnage :

mkdir ~/scan_results/versions

Découverte des versions des services sur le serveur

Nous pouvons tenter de deviner les versions des services exécutés sur la cible via un processus appelé empreinte digitale. Nous récupérons les informations du serveur et les comparons aux versions connues dans notre base de données.

Un tcpdump ne serait pas très utile dans ce scénario, nous pouvons donc l'ignorer. Si vous voulez quand même le capturer, suivez le processus que nous avons utilisé la dernière fois.

L'analyse nmap que nous devons utiliser est déclenchée par le drapeau -sV. Comme nous avons déjà effectué des analyses SYN et UDP, nous pouvons transmettre les ports exacts que nous voulons examiner avec le drapeau -p. Ici, nous allons examiner 22 et 80 (les ports qui ont été affichés dans notre analyse SYN) :

sudo nmap -sV -Pn -p 22,80 -vv --reason -oN ~/scan_results/versions/service_versions.nmap target_ip_addr

Si vous affichez le fichier qui en résulte, vous pouvez obtenir des informations sur le service en cours d'exécution, selon le degré de "bavardage" ou même le caractère unique de la réponse du service :

less ~/scan_results/versions/service_versions.nmap

~/scan_results/versions/service_versions.nmap

# Nmap 6.49BETA4 scan initiated Thu Aug 27 15:46:12 2015 as: nmap -sV -Pn -p 22,80 -vv --reason -oN /home/user/scan_results/versions/service_versions.nmap 198.51.100.15
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.0011s latency).
Scanned at 2015-08-27 15:46:13 EDT for 8s
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    syn-ack ttl 63 nginx 1.4.6 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/local/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Aug 27 15:46:21 2015 -- 1 IP address (1 host up) scanned in 8.81 seconds

Ici, vous pouvez voir que le test a pu identifier la version du serveur SSH et la distribution Linux qui l'a packagé ainsi que la version du protocole SSH acceptée. Il a également reconnu la version de Nginx et l'a de nouveau identifiée comme correspondant à un package Ubuntu.

Découverte du système d'exploitation hôte

Nous pouvons essayer de faire en sorte que nmap devine le système d'exploitation hôte en fonction des caractéristiques de son logiciel et de ses réponses. Cela fonctionne à peu près de la même manière que la gestion des versions de service. Encore une fois, nous omettrons l'exécution tcpdump de ce test, mais vous pouvez l'effectuer si vous le souhaitez.

Le drapeau dont nous avons besoin pour effectuer la détection du système d'exploitation est -O (la lettre majuscule "O"). Une commande complète peut ressembler à ceci :

sudo nmap -O -Pn -vv --reason -oN ~/scan_results/versions/os_version.nmap target_ip_addr

Si vous affichez le fichier de sortie, vous verrez peut-être quelque chose qui ressemble à ceci :

less ~/scan_results/versions/os_version.nmap

~/scan_results/versions/os_versions.nmap

# Nmap 6.49BETA4 scan initiated Thu Aug 27 15:53:54 2015 as: nmap -O -Pn -vv --reason -oN /home/user/scan_results/versions/os_version.nmap 198.51.100.15
Increasing send delay for 198.51.100.15 from 0 to 5 due to 65 out of 215 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 5 to 10 due to 11 out of 36 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 10 to 20 due to 11 out of 35 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 20 to 40 due to 11 out of 29 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 40 to 80 due to 11 out of 31 dropped probes since last increase.
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.0012s latency).
Scanned at 2015-08-27 15:53:54 EDT for 30s
Not shown: 998 closed ports
Reason: 998 resets
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63
80/tcp open  http    syn-ack ttl 63
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=6.49BETA4%E=4%D=8/27%OT=22%CT=1%CU=40800%PV=N%DS=2%DC=I%G=Y%TM=55
OS:DF6AF0%P=x86_64-unknown-linux-gnu)SEQ(SP=F5%GCD=1%ISR=106%TI=Z%CI=Z%TS=8
OS:)OPS(O1=M5B4ST11NW8%O2=M5B4ST11NW8%O3=M5B4NNT11NW8%O4=M5B4ST11NW8%O5=M5B
OS:4ST11NW8%O6=M5B4ST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120
OS:)ECN(R=Y%DF=Y%T=40%W=7210%O=M5B4NNSNW8%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+
OS:%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
OS:T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A
OS:=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPC
OS:K=G%RUCK=G%RUD=G)U1(R=N)IE(R=N)

Uptime guess: 1.057 days (since Wed Aug 26 14:32:23 2015)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=245 (Good luck!)
IP ID Sequence Generation: All zeros

Read data files from: /usr/local/bin/../share/nmap
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Aug 27 15:54:24 2015 -- 1 IP address (1 host up) scanned in 30.94 seconds

Nous pouvons voir que dans ce cas, nmap n'a aucune supposition pour le système d'exploitation en fonction de la signature qu'il a vue. S'il avait reçu plus d'informations, il afficherait probablement divers pourcentages indiquant comment la signature de la machine cible correspond aux signatures du système d'exploitation dans ses bases de données. Vous pouvez voir la signature d'empreintes digitales que nmap a reçue de la cible sous la ligne TCP/IP fingerprint:.

L'identification du système d'exploitation peut aider un attaquant à déterminer quels exploits peuvent être utiles sur le système. La configuration de votre pare-feu pour répondre à moins de demandes peut contribuer à entraver la précision de certaines de ces méthodes de détection.

Conclusion

Tester votre pare-feu et prendre conscience de ce à quoi ressemble votre réseau interne pour un attaquant extérieur peut vous aider à minimiser vos risques. Les informations que vous trouvez en sondant votre propre infrastructure peuvent ouvrir une conversation sur la nécessité de revoir l'une de vos décisions politiques afin d'augmenter la sécurité. Cela peut également mettre en lumière les lacunes de votre sécurité qui auraient pu se produire en raison d'un ordre incorrect des règles ou de politiques de test oubliées. Il est recommandé de tester vos politiques avec la régularité des dernières analyses de bases de données afin d'améliorer, ou au moins de maintenir, votre niveau de sécurité actuel.

Pour avoir une idée de certaines améliorations de politique pour votre pare-feu, consultez ce guide.