Rootuseurs

La Plupart d’entre nous seraient familiers avec la simple commande ‘ping’ basée sur ICMP qui nous permet de tester une réponse de base à partir d’un périphérique connecté au réseau. Bien que idéal pour le dépannage de base, il ne nous permet pas de confirmer si l’hôte particulier à l’autre extrémité répond sur les ports TCP ou UDP où la majorité des services sont susceptibles d’être fournis.,

Le Ping n’est pas tout et met fin à tout le dépannage du réseau, si un pare-feu bloque le trafic ICMP entrant, alors un ping ne réussira pas, ce qui peut produire une fausse perception que l’hôte est en panne car il ne répond pas au ping, mais d’autres services pourraient toujours répondre correctement.

alternativement, bien que ping puisse revenir correctement avec une réponse, il n’indique pas si un serveur web répond sur le port 80 pour les requêtes HTTP, le serveur web peut avoir échoué et ne plus répondre.

donc, si ping est basé sur ICMP, pouvons-nous frapper un port TCP ou UDP pour la réponse à la place?, La réponse est oui, jetons un coup d’oeil.

Enter tcping

tcping est un tel outil qui peut être utilisé pour vérifier qu’un port TCP répond, il existe quelques versions disponibles mais j’utilise celle-ci:http://www.elifulkerson.com/projects/tcping.php

le manuel est sur la même page, fondamentalement, vous pouvez exécuter une commande similaire à celle ci-dessous.

ici, nous utilisons tcping pour vérifier le port 443 à google.com. comme on peut le voir, le port s’affiche comme étant ouvert et répondant, si le port n’est pas ouvert, il s’affichera comme aucune réponse après 2000 ms par défaut.,

Vous pouvez également utiliser telnet pour tester la connectivité TCP à un port, mais l’outil tcping fournit d’autres fonctionnalités comme indiqué dans la section Utilisation ici. Certaines de ces fonctionnalités incluent la possibilité d’exécuter continuellement le test, ce qui vous permet de générer du trafic à surveiller dans les captures de paquets en direct ainsi que le temps de réponse.

Qu’en est-il de UDP?

comme UDP est un protocole sans connexion, déterminer s’il répond est un peu différent., Un « ping » TCP fonctionne en effectuant une poignée de main à trois voies, la source enverra un SYN à la destination, la destination répondra avec un SYN-ACK, et la source enverra ensuite un ACK complétant la poignée de main et établissant la connexion. Comme UDP n’établit pas de connexion, nous ne pouvons pas simplement rechercher cela pour déterminer si le port répond, nous devons plutôt envoyer des données spécifiques et voir si nous recevons une réponse.

NMAP est un excellent outil pour cela, vous pouvez le télécharger et l’utiliser pour analyser une adresse de destination pour déterminer quels ports sont ouverts.,

dans cet exemple, nous demandons si 8.8.8.8 répond sur le port UDP 53, car il sert DNS, Nous nous attendons à ce qu’il soit ouvert.

le résultat open / filtered est utilisé lorsque nmap est incapable de déterminer si le port est ouvert ou filtré, le port ouvert peut ne pas avoir donné de réponse. Il montre que le service a été identifié comme « domaine » car il est pour servir DNS. J’ai testé cela sur d’autres serveurs DNS sur Internet et certains s’affichent comme ouverts confirmant seulement qu’ils répondent.

NMAP peut également être utilisé pour vérifier qu’un port TCP est ouvert de la même manière, il suffit de changer-sU en-sT.,

Pourquoi un port ne peut pas répondre

Il y a quelques raisons simples qu’un port ne peut pas répondre à votre test.

• Un pare-feu bloque le trafic: il peut y avoir un pare-feu en cours d’exécution entre la source et la destination filtrant le trafic en fonction des règles en place, même si vous savez que la destination doit répondre sur un port particulier.
• LA destination peut ne pas écouter sur le port: en termes simples, la destination à laquelle vous essayez de vous connecter peut ne pas avoir de services écoutant sur le port spécifié, il n’y aura donc aucune réponse., Cela peut également se produire si un service a été arrêté, par exemple si vous arrêtez Apache, un serveur web ne répondra plus aux demandes du port 80.
• Il y a un autre problème de réseau entre la source et la destination du trafic: il pourrait y avoir n’importe quel nombre de problèmes de connectivité réseau entre la source et la destination, si possible vérifiez le réseau mais si le trafic traverse Internet, vous serez limité dans ce que vous pouvez vérifier.,

Vous pouvez vérifier la connectivité le long du chemin du trafic en exécutant une capture de paquets avec quelque chose comme Wireshark ou tcpdump, cela vous montrera où le trafic arrive et où il est arrêté le long de la route. Vous pouvez l’exécuter sur les serveurs source et de destination, ainsi que sur les périphériques intermédiaires auxquels vous avez accès, tels que les pare-feu ou les routeurs. Suivez le flux de trafic jusqu’à ce que vous déterminiez où se trouve le problème.,

résumé

lors de l’exécution D’un « ping » TCP vers une destination, vous pouvez confirmer s’il répond comme prévu, bien qu’il y ait quelques raisons pour lesquelles le port peut ne pas répondre comme indiqué. UDP peut être vérifié, mais il est un peu plus difficile d’être certain si vous recevez correctement une réponse, donc les tests ne sont pas toujours fiables, ce qui est logique car UDP n’est pas un protocole fiable. Ces tests peuvent être utiles pour tester la sécurité en confirmant si les ports sont ouverts ou fermés.