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

Les analyseurs de paquets peuvent être utilisés pour surveiller en détail tout le trafic réseau transitant 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 de leur envoi ou de leur réception, ou d'écrire les informations de paquet dans un fichier et de les traiter ultérieurement. L'analyse des paquets nous permet de voir, à un niveau granulaire, les types de réponses que nos machines cibles renvoient aux hôtes sur le réseau ouvert.

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

Afin de générer le trafic et les réponses que notre analyseur de paquets doit capturer, nous utiliserons un scanner de ports. Les scanners de ports peuvent être utilisés pour créer et envoyer divers types de paquets à des hôtes distants afin de découvrir le type de trafic accepté par le serveur. Les utilisateurs malveillants l'utilisent souvent comme outil de découverte pour tenter de trouver des services vulnérables à exploiter (une des raisons pour lesquelles un pare-feu est utilisé en premier lieu). Nous allons donc l'utiliser pour tenter 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 denmap. Nous pouvons utilisernmap pour envoyer des paquets de différents types afin d'essayer de déterminer quels services sont sur notre machine cible et quelles règles de pare-feu la protègent.

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

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

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

Nous pouvons suspendre le processus en cours en appuyant surCTRL-Z:

Cela mettra en pause le processus en cours:

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

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:

La commande est maintenant exécutée en arrière-plan, surveillant les paquets allant entre nos ordinateurs d'audit et les ordinateurs cibles. Nous pouvons maintenant exécuter notre scan SYN.

Avectcpdump enregistrant notre trafic vers la machine cible, nous sommes prêts à exécuternmap. Nous utiliserons les indicateurs suivants pour obtenirnmap pour effectuer les actions dont nous avons besoin:

Note

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

Ensemble, la commande ressemblera à quelque chose comme ceci:

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

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

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

Arrêtez le processus en maintenant la touche de commande enfoncée et en appuyant sur «c»:

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

Examinons d'abord le fichiernmap.results:

~/scan_results/syn_scan/nmap.results

La zone en surbrillance ci-dessus contient les principaux résultats de l'analyse. Nous pouvons voir que les ports 22 et 80 sont ouverts sur l'hôte analysé afin de permettre le trafic SSH et HTTP. Nous pouvons également constater 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 le long du 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 ordinateurs 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 fichierpackets danstcpdump, comme ceci:

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 traficsent vers la cible, vous pouvez taper:

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

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:

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

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

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

Relancez une capturetcpdump. Cette fois, écrivez le fichier dans le nouveau répertoire~/scan_results/udp_scan:

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

Nous sommes maintenant prêts à exécuter l'analyse UDP. En raison de la nature du protocole UDP, cette analyse prendra généralementsignificantly 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 étant un protocole sans connexion, ne recevoir aucune réponse pourrait signifier que le port de la cible est bloqué, accepté ou que le paquet est 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 utilisés pour le scan SYN. En fait, le seul nouveau drapeau est:

Remettez le processustcpdump au premier plan sur votre machine d'audit en tapant:

Arrêtez la capture du paquet en tenant le contrôle et en appuyant sur «c»:

Maintenant, regardons les fichiers générés.

Le fichiernmap.results résultant devrait ressembler assez à celui que nous avons vu auparavant:

~/scan_results/udp_scan/nmap.results

Une différence clé entre ce résultat et le résultat SYN antérieur sera probablement le nombre de ports marquésopen|filtered. Cela signifie quenmap 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 detcpdump est également beaucoup plus difficile car il n'y a pas d'indicateur de connexion et parce que nous devons faire correspondre les réponses ICMP aux requêtes UDP.

Nous pouvons voir commentnmap a dû envoyer de nombreux paquets aux ports signalés commeopen|filtered en demandant à voir le trafic UDP vers l'un des ports signalés:

Vous verrez probablement quelque chose qui ressemble à ceci:

Comparez cela aux résultats de l'un des ports scannés qui ont été marqués «fermé»:

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

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

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

Cela devrait principalement correspondre à la liste des ports signalés parnmap (il peut contenir des faux positifs de paquets de retour perdus).

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

Untcpdump ne serait pas trop 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.

Le scannmap que nous devons utiliser est déclenché par l'indicateur-sV. Comme nous avons déjà effectué des analyses SYN et UDP, nous pouvons transmettre les ports exacts que nous voulons regarder avec l'indicateur-p. Ici, nous allons regarder 22 et 80 (les ports qui ont été montrés dans notre scan SYN):

Si vous affichez le fichier qui en résulte, vous pouvez obtenir des informations sur le service en cours, en fonction du degré de «bavardage» ou même de l’originalité de la réponse du service:

~/scan_results/versions/service_versions.nmap

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

Nous pouvons essayer de faire deviner ànmap le système d'exploitation hôte en fonction des caractéristiques de son logiciel et des réponses. Cela fonctionne beaucoup de la même manière que la gestion des versions de service. Une fois de plus, nous omettons l’exécution detcpdump de ce test, mais vous pouvez l’effectuer si vous le souhaitez.

L'indicateur 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 à quelque chose comme ceci:

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

~/scan_results/versions/os_versions.nmap

Nous pouvons voir que dans ce cas,nmap n'a aucune estimation pour le système d'exploitation en fonction de la signature qu'il a vue. S'il avait reçu plus d'informations, il indiquerait probablement divers pourcentages indiquant la correspondance entre la signature de l'ordinateur cible et les signatures du système d'exploitation dans ses bases de données. Vous pouvez voir la signature d'empreinte digitale quenmap a reçue de la cible sous la ligneTCP/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 d'informations peut nuire à la précision de certaines de ces méthodes de détection.