Introduction
Avant d'utiliser un analyseur, vous devez distinguer une adresse, un nom, un chemin réseau et un port de service. Ce sont des observations différentes : une réussite à un niveau ne prouve pas une réussite à un autre.
Ce lab fournit un serveur DNS local et un service web dans votre environnement Kali. Vous examinerez le réseau, résoudrez le nom d'entraînement et vérifierez son port TCP en écoute sans analyser de passerelle ni dépendre de cibles publiques.
Examiner les adresses, les routes et la joignabilité de la boucle locale
Dans cette étape, vous examinerez le réseau du conteneur Kali et testerez un chemin de connexion local limité.
Entrez dans le shell préparé et choisissez l'espace de travail :
kali
cd /home/labex/project
Une adresse IP identifie un point de connexion réseau. Une interface est la connexion du système à un réseau ; une route décrit où doit aller le trafic destiné à une adresse. Les conteneurs ont leur propre vue du réseau : examinez donc cet environnement plutôt que de supposer les paramètres de l'hôte.
ip permet d'examiner le réseau Linux. L'option -brief demande une vue compacte des adresses des interfaces :
ip -brief address
Repérez lo, l'interface de boucle locale, et 127.0.0.1. Le trafic de boucle locale reste dans cet environnement réseau. Les autres interfaces et adresses peuvent varier. Un préfixe comme /8 ou /16 décrit la plage réseau de l'adresse ; ce n'est pas un port de service.
Examinez les routes :
ip route
Une entrée default, si elle est présente, est utilisée lorsqu'aucune route plus précise ne correspond. Vous n'avez pas à analyser la passerelle ni à modifier une route.
ping envoie des sondes de joignabilité. -c 3 limite le test à trois sondes pour qu'il se termine automatiquement :
ping -c 3 127.0.0.1
Vous devriez recevoir des réponses et un récapitulatif final des paquets. Les durées exactes varient. Une réponse à ping montre que ces sondes ont reçu des réponses ; elle n'établit pas qu'un service TCP particulier est en écoute.
Enregistrez votre observation des interfaces avec la redirection de sortie que vous connaissez déjà :
ip -brief address > interfaces.txt
cat interfaces.txt
La vue enregistrée doit inclure l'interface de boucle locale et son adresse.
Résoudre un nom avec le serveur DNS d'entraînement
Dans cette étape, vous distinguerez la résolution de nom de la connectivité d'un service à l'aide d'un serveur DNS local.
DNS traduit les noms en enregistrements. Un enregistrement A contient une adresse IPv4. Ce lab fournit un serveur DNS à 127.0.0.1 sur le port 5353 et un nom local training-web.test ; aucun service DNS public n'est nécessaire.
dig interroge DNS. @127.0.0.1 choisit le serveur, -p 5353 choisit son port DNS non standard, l'argument suivant est le nom et A demande un enregistrement d'adresse IPv4 :
dig @127.0.0.1 -p 5353 training-web.test A
La section de réponse doit afficher le nom et l'adresse 127.0.0.1. DNS utilise aussi des ports : le port 5353 appartient ici au serveur DNS d'entraînement, pas au service web nommé par sa réponse.
L'option d'affichage +short affiche uniquement les données de réponse. Enregistrez ce résultat plus court :
dig @127.0.0.1 -p 5353 +short training-web.test A > dns-answer.txt
cat dns-answer.txt
Résultat attendu :
127.0.0.1
La recherche de nom du système peut aussi utiliser des fichiers locaux au lieu d'interroger directement DNS. getent hosts interroge le mécanisme de recherche d'hôtes configuré du système pour un nom :
getent hosts localhost
La sortie associe localhost à une adresse de boucle locale, qui peut être l'adresse IPv6 ::1. Cela diffère d'une interrogation explicite du serveur DNS fourni avec dig. Une résolution de nom réussie donne une adresse ; vous devez encore examiner si le service requis y est disponible.
Examiner un port en écoute et tester son port TCP
Dans cette étape, vous relierez une adresse à un protocole de transport et à un port de service particuliers.
Un port identifie un point de connexion de transport à une adresse. TCP établit des connexions ; UDP envoie des datagrammes sans le même échange préalable de connexion. Le numéro de port d'un service ne prouve pas à lui seul quelle application ou vulnérabilité est présente.
ss affiche des informations sur les sockets. -l sélectionne les sockets en écoute, -t sélectionne TCP et -n conserve les adresses et numéros de port numériques :
ss -ltn
Repérez le point de connexion local 127.0.0.1:8080. Il appartient au service web d'entraînement fourni. L'adresse le limite à la boucle locale dans le conteneur. Examinez les sockets UDP séparément avec -u au lieu de -t :
ss -lun
Le point de connexion DNS d'entraînement utilise le port 5353. TCP et UDP ont des espaces de ports distincts ; le même numéro peut être utilisé par les deux protocoles.
Enregistrez uniquement la ligne TCP en écoute du service d'exercice. Le motif inclut les deux-points avant le port et un espace final pour le distinguer d'un numéro plus long :
ss -ltn | grep ':8080 ' > service-listener.txt
cat service-listener.txt
La ligne doit indiquer LISTEN et 127.0.0.1:8080 ; l'espacement et les valeurs des files peuvent varier.
Ncat peut tester une connexion TCP sans envoyer de données applicatives. -v affiche l'état et -z demande une vérification de connexion plutôt qu'une session de données interactive :
ncat -vz 127.0.0.1 8080
L'état doit signaler une connexion réussie. Cela prouve que le port TCP sélectionné accepte une connexion maintenant ; cela ne valide pas encore une réponse HTTP. Vous examinerez HTTP lui-même dans un lab ultérieur.
Résumé
Vous avez examiné les interfaces et les routes, envoyé un test de joignabilité limité, interrogé le DNS local, examiné les ports TCP et UDP en écoute et testé une connexion TCP. Vous avez distingué une résolution réussie et la joignabilité réseau du comportement au niveau applicatif.
