Existe-t-il un moyen de voir ce qui filtre réellement la communication par port TCP?

nmap -p 7000-7020 10.1.1.1

Sortira tous les ports filtrés

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-04 12:18 EET
Nmap scan report for 10.1.1.1
Host is up (0.00091s latency).
PORT     STATE    SERVICE
7000/tcp filtered afs3-fileserver
7001/tcp filtered afs3-callback
7002/tcp filtered afs3-prserver
7003/tcp filtered afs3-vlserver
7004/tcp filtered afs3-kaserver
7005/tcp filtered afs3-volser
7006/tcp filtered afs3-errors
7007/tcp filtered afs3-bos
7008/tcp filtered afs3-update
7009/tcp filtered afs3-rmtsys
7010/tcp filtered ups-onlinet
7011/tcp filtered unknown
7012/tcp filtered unknown
7013/tcp filtered unknown
7014/tcp filtered unknown
7015/tcp filtered unknown
7016/tcp filtered unknown
7017/tcp filtered unknown
7018/tcp filtered unknown
7019/tcp filtered unknown
7020/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.78 seconds

Existe-t-il un moyen de voir ce qui filtre exactement ces ports?

Voici ce que les documents nmap disent de l' filteredétat

Nmap filtré ne peut pas déterminer si le port est ouvert car le filtrage de paquets empêche ses sondes d'atteindre le port. Le filtrage peut provenir d'un périphérique de pare-feu dédié, de règles de routeur ou d'un logiciel de pare-feu basé sur l'hôte ...

La seule façon de savoir ce que fait le filtrage est de savoir quelles sont les «machines» entre vous et la cible distante.

Ceci peut être réalisé en utilisant un utilitaire de trace d'itinéraire, qui tente de déterminer les hôtes entre vous et la cible à l'aide de paquets TCP spéciaux. Dans votre cas, la commande pourrait ressembler à:

traceroute 10.1.1.1

Une fois que vous connaissez les machines entre vous et la cible, vous étudiez la configuration de chacune pour savoir si elle est en train de filtrer et si oui, comment.

Nmap propose plusieurs façons d'obtenir plus d'informations sur la cause du filtrage:

• L' --reasonoption affichera le type de réponse qui a provoqué l'état du port "filtré". Cela peut être "sans réponse" ou "interdit par l'administrateur" ou autre chose.
• Le TTL des paquets de réponse est signalé dans la sortie XML comme l' reason_ttlattribut de l' stateélément pour le port. Si le TTL pour un port filtré est différent (généralement supérieur à) du TTL pour les ports ouverts, la différence entre les TTL est la distance du réseau entre la cible et le dispositif de filtrage. Il existe des exceptions, telles que des cibles qui utilisent différents TTL initiaux pour les paquets ICMP vs TCP, ou un périphérique de filtrage qui falsifie ou écrase les informations TTL.
• La --traceroutefonction affichera des informations sur les sauts le long de votre itinéraire, qui pourraient filtrer votre trafic. Dans certains cas, le nom DNS inversé pour l'un des tronçons sera même quelque chose comme "firewall1.example.com"
• Le firewalkscript NSE enverra des paquets avec des TTL initiaux qui expireront à différents sauts le long de la route pour tenter de trouver où les paquets sont bloqués. Cela ressemble à une combinaison des deux techniques précédentes et fonctionne généralement assez bien.

La version de développement actuellement inédite de Nmap signale également TTL pour les paquets de réponse dans la sortie de texte normale avec les -v --reasonoptions. Pour l'instant, cependant, vous devez utiliser la sortie XML pour obtenir ces informations.

MODIFIÉ POUR AJOUTER: Nmap 6.49BETA1 a été la première version à afficher TTL pour les paquets de réponse en sortie texte avec -v --reasonou -vv, et a été publié en juin 2015.

Réponse courte - Non, il n'y a aucun moyen de le voir.

Réponse plus longue:

De: https://nmap.org/book/man-port-scanning-basics.html

"Nmap filtré ne peut pas déterminer si le port est ouvert car le filtrage de paquets empêche ses sondes d'atteindre le port. Le filtrage peut provenir d'un périphérique de pare-feu dédié, de règles de routeur ou d'un logiciel de pare-feu basé sur l'hôte. Ces ports frustrent les attaquants car ils fournissent si peu informations. Parfois, ils répondent avec des messages d'erreur ICMP tels que le code 13 de type 3 (destination inaccessible: communication administrativement interdite), mais les filtres qui suppriment simplement les sondes sans répondre sont beaucoup plus courants. Cela force Nmap à réessayer plusieurs fois au cas où la sonde serait a chuté en raison de l'encombrement du réseau plutôt que du filtrage. Cela ralentit considérablement l'analyse. "

Vous pouvez essayer de découvrir la topologie du réseau avec des outils comme traceroute. Habituellement, les ports sont filtrés sur l'hôte lui-même (c'est-à-dire les tables ip), le routeur de périphérie de réseau cible, le routeur principal de réseau cible ou le haut du commutateur L3 du rack.

Si vous êtes dans le même sous-réseau que l'hôte cible, il est presque certain que le pare-feu se trouve sur la machine cible.

Essayez de comparer un résultat de tcptrace à l'un des ports filtrés avec un tcptrace à un port ouvert (ou un traceroute standard). Si les tcptraces sont les mêmes, cela signifie qu'il y a quelque chose sur la machine de destination qui filtre les ports.

Mise à jour: je voulais dire tcptraceroute, je l'ai aliasé.