TCP et UDP sont des protocoles de transport distincts même si le numéro de port est le même. Le résultat sur l’un n’indique pas automatiquement l’état du service sur l’autre.
Approche de base
Le processus d'établissement de la connexion TCP produit des réponses distinctes. UDP est sans connexion ; Un service ouvert peut rester silencieux si le message d'application approprié n'est pas envoyé. Par conséquent, dans la plupart des cas, aucune réponse dans UDP ne suffit pas à elle seule pour distinguer les possibilités ouvertes, fermées et filtrées.
Étapes de candidature
- Écrire le protocole contrôlé avec le numéro de port ; Ne dites pas simplement que le 53 est ouvert.
- Sélectionnez le mode de transport documenté du service et vérifiez si possible au niveau de l'application.
- Délai d'expiration d'enregistrement en raison d'un échec de connexion ; Ne donnez pas de produit hors étiquette définitif sans preuves suffisantes.
Exemple pratique
Bien que la connexion TCP 53 pour DNS puisse réussir, les requêtes UDP peuvent être filtrées. Dans le cas contraire, les petites requêtes UDP fonctionneront, les transactions nécessitant TCP échoueront. Le même numéro peut masquer deux politiques d’accès différentes.
Interpréter correctement le résultat
Le port ouvert ne garantit pas le type de périphérique ou la version du logiciel. Les services peuvent s'exécuter sur des ports non standard. Le fait de séparer l'observation du port dans l'inventaire de la réponse du service et de l'identité signalée par l'appareil réduit les erreurs de classification.
Source et lecture de suivi
Détails du protocole ou de la commande : RFC768. Les étapes et l'exemple de scénario sont le récit éditorial d'IPScans.