C'è un modo per vedere cosa sta effettivamente filtrando la comunicazione della porta TCP?

nmap -p 7000-7020 10.1.1.1

Produrrà tutte le porte filtrate

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

C'è un modo in cui posso vedere cosa sta esattamente filtrando quelle porte?

Questo è ciò che dicono i documenti nmap sullo filteredstato

Nmap filtrata non può determinare se la porta è aperta perché il filtro pacchetti impedisce alle sonde di raggiungere la porta. Il filtro potrebbe provenire da un dispositivo firewall dedicato, regole del router o software firewall basato su host ...

L'unico modo per scoprire cosa sta facendo il filtro è sapere quali "macchine" sono tra te e il bersaglio remoto.

Ciò può essere ottenuto utilizzando un'utilità di traccia del percorso, che tenta di determinare host tra l'utente e la destinazione utilizzando pacchetti TCP speciali. Nel tuo caso il comando potrebbe assomigliare a:

traceroute 10.1.1.1

Una volta che conosci le macchine tra te e il bersaglio, indaga sulla configurazione di ciascuna per scoprire se sta filtrando e se sì come.

Nmap offre diversi modi per ottenere maggiori informazioni sulla causa del filtro:

• L' --reasonopzione mostrerà il tipo di risposta che ha causato lo stato della porta "filtrata". Potrebbe essere "nessuna risposta" o "vietato all'amministratore" o qualcos'altro.
• Il TTL dei pacchetti di risposta è riportato nell'output XML come reason_ttlattributo statedell'elemento per la porta. Se il TTL per una porta filtrata è diverso (solitamente maggiore di) dal TTL per le porte aperte, la differenza tra i TTL è la distanza di rete tra la destinazione e il dispositivo di filtraggio. Esistono eccezioni, come target che utilizzano TTL iniziali diversi per i pacchetti ICMP vs TCP o un dispositivo di filtro che falsifica o sovrascrive le informazioni TTL.
• La --traceroutefunzione mostrerà informazioni sui salti lungo il percorso, ognuno dei quali potrebbe filtrare il tuo traffico. In alcuni casi, il nome DNS inverso per uno dei salti sarà persino simile a "firewall1.example.com"
• Lo firewalkscript NSE invierà pacchetti con TTL iniziali che andranno in timeout in diversi hop lungo il percorso nel tentativo di trovare dove vengono bloccati i pacchetti. Questo è qualcosa come una combinazione delle due precedenti tecniche e di solito funziona abbastanza bene.

La versione di sviluppo attualmente inedita di Nmap riporta anche TTL per i pacchetti di risposta nel normale output di testo con le -v --reasonopzioni. Per ora, però, devi usare l'output XML per ottenere queste informazioni.

MODIFICATO PER AGGIUNGERE: Nmap 6.49BETA1 è stata la prima versione a mostrare TTL per i pacchetti di risposta nell'output di testo con -v --reasono -vved è stata rilasciata a giugno 2015.

Risposta breve - No, non è possibile vederlo.

Risposta più lunga:

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

"Nmap filtrata non può determinare se la porta è aperta perché il filtro pacchetti impedisce alle sue sonde di raggiungere la porta. Il filtro potrebbe provenire da un dispositivo firewall dedicato, regole del router o software firewall basato su host. Queste porte frustrano gli attaccanti perché forniscono così poco a volte rispondono con messaggi di errore ICMP come il codice di tipo 3 13 (destinazione non raggiungibile: comunicazione amministrativamente vietata), ma i filtri che semplicemente rilasciano le sonde senza rispondere sono molto più comuni. Ciò costringe Nmap a riprovare più volte nel caso in cui la sonda fosse eliminato a causa della congestione della rete piuttosto che del filtro. Questo rallenta notevolmente la scansione ".

Puoi provare a scoprire la topologia di rete con strumenti come traceroute. Solitamente le porte vengono filtrate sull'host stesso (ovvero tabelle ip), router di bordo della rete di destinazione, router di base della rete di destinazione o switch L3 nella parte superiore del rack.

Se ci si trova nella stessa sottorete dell'host di destinazione quasi sicuramente il firewall si trova sul computer di destinazione.

Prova a confrontare un risultato di tcptrace con una delle porte filtrate con una tcptrace con una porta aperta (o un traceroute standard). Se i tcptraces sono gli stessi, significa che sulla macchina di destinazione c'è qualcosa che filtra le porte.

Aggiornamento: intendevo tcptraceroute, l'ho aliasato.