¿Hay alguna manera de ver lo que realmente está filtrando la comunicación del puerto TCP?

nmap -p 7000-7020 10.1.1.1

Dará salida a todos los puertos filtrados

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

¿Hay alguna manera de que pueda ver qué filtra exactamente esos puertos?

Esto es lo que dicen los documentos nmap sobre el filteredestado

Nmap filtrado no puede determinar si el puerto está abierto porque el filtrado de paquetes impide que sus sondas lleguen al puerto. El filtrado podría ser desde un dispositivo de firewall dedicado, reglas de enrutador o software de firewall basado en host ...

La única forma de averiguar qué está haciendo el filtrado es saber qué 'máquinas' hay entre usted y el objetivo remoto.

Esto se puede lograr utilizando una utilidad de rastreo de ruta, que intenta determinar los hosts entre usted y el destino mediante paquetes TCP especiales. En su caso, el comando podría verse así:

traceroute 10.1.1.1

Una vez que conozca las máquinas entre usted y el objetivo, investigue la configuración de cada una para averiguar si está filtrando y, de ser así, cómo.

Nmap proporciona varias formas de obtener más información sobre lo que está causando el filtrado:

• La --reasonopción mostrará el tipo de respuesta que causó el estado del puerto "filtrado". Esto podría ser "sin respuesta" o "prohibido por el administrador" u otra cosa.
• El TTL de los paquetes de respuesta se informa en la salida XML como el reason_ttlatributo del stateelemento para el puerto. Si el TTL para un puerto filtrado es diferente (generalmente mayor que) del TTL para puertos abiertos, entonces la diferencia entre los TTL es la distancia de red entre el objetivo y el dispositivo de filtrado. Hay excepciones, como los objetivos que utilizan diferentes TTL iniciales para paquetes ICMP vs TCP, o un dispositivo de filtrado que falsifica o sobrescribe la información TTL.
• La --traceroutefunción mostrará información sobre saltos a lo largo de su ruta, cualquiera de los cuales podría estar filtrando su tráfico. En algunos casos, el nombre DNS inverso para uno de los saltos incluso será algo así como "firewall1.example.com"
• El firewalkscript NSE enviará paquetes con TTL iniciales que expirarán en diferentes saltos a lo largo de la ruta en un intento de encontrar dónde se bloquean los paquetes. Esto es algo así como una combinación de las dos técnicas anteriores, y generalmente funciona bastante bien.

La versión de desarrollo actualmente inédita de Nmap también informa TTL para paquetes de respuesta en la salida de texto normal con las -v --reasonopciones. Sin embargo, por ahora, debe usar la salida XML para obtener esta información.

EDITADO PARA AGREGAR: Nmap 6.49BETA1 fue la primera versión en mostrar TTL para paquetes de respuesta en salida de texto con -v --reasono -vv, y se lanzó en junio de 2015.

Respuesta corta: no, no hay forma de que pueda verlo.

Respuesta más larga:

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

"Nmap filtrado no puede determinar si el puerto está abierto porque el filtrado de paquetes impide que sus sondas lleguen al puerto. El filtrado podría ser desde un dispositivo de firewall dedicado, reglas de enrutador o software de firewall basado en host. Estos puertos frustran a los atacantes porque proporcionan muy poco información. A veces responden con mensajes de error ICMP como el código 13 de tipo 3 (destino inalcanzable: comunicación prohibida administrativamente), pero los filtros que simplemente sueltan las sondas sin responder son mucho más comunes. Esto obliga a Nmap a volver a intentarlo varias veces en caso de que la sonda se haya solucionado. cayó debido a la congestión de la red en lugar de al filtrado. Esto ralentiza el escaneo dramáticamente ".

Puede intentar descubrir la topología de red con herramientas como traceroute. Por lo general, los puertos se filtran en el host mismo (es decir, tablas de IP), enrutador de borde de red de destino, enrutador de núcleo de red de destino o en la parte superior del conmutador L3 del bastidor.

Si está en la misma subred que el host de destino, casi con seguridad el firewall está en la máquina de destino.

Intente comparar un resultado de tcptrace con uno de los puertos filtrados con tcptrace con un puerto abierto (o un traceroute estándar). Si las trazas tcp son las mismas, significa que hay algo en la máquina de destino que filtra los puertos.

Actualización: quise decir tcptraceroute, tengo un alias.