it-swarm.dev

Perché una scansione nmap -sT mostra le porte filtrate ma -sS mostra le porte chiuse

Quali sono le possibili ragioni per cui un nmap -sT scan mostrerebbe "port filtered" ma un identico nmap -sS scan mostra "porte chiuse"? Lo capisco -sT è un full TCP Connect, che è più facile da rilevare (e filtrare) rispetto al -sS scansione a metà aperta. Ma perché?

Entrambi i tipi di scansioni inviano un pacchetto SYN; entrambi i tipi di scansioni dovrebbero aspettarsi un SYN | ACK o un RST. L'unica differenza che vedo è che la scansione semiaperta invierà un RST invece di terminare l'handshake di connessione.

Inoltre, ho eseguito il comando nmap -sT -P0 che dice a nmap di non inviare prima un ping (penso che in genere esegua sia un TCP ping che un ping ICMP). L'esecuzione di quel comando gli fa rispondere con "porte chiuse" che è identico a -sS scan scan. È perché -sT viene normalmente bloccato a causa del ping prima?

Questa è la mia ipotesi, ma voglio alcune opinioni più esperte su ciò che sto vedendo e su quali tipi di scansioni posso fare per indagare ulteriormente. A proposito, ovviamente mi è permesso di fare queste scansioni (lavoro di classe).

9
KyleM

Se hai salvato l'output XML di Nmap, esiste un attributo di <state> tag chiamato reason, che ti darà il motivo Nmap ha scelto di etichettare una porta chiusa, aperta o filtrata. Di solito è qualcosa come "reset", "conn -refused "," syn-ack "o" port-unreach ", a seconda del tipo di scansione e dello stato della porta. Queste informazioni possono anche essere visualizzate nell'output" normale "usando --reason flag o setting -d per il debug.

Un malinteso comune è che la scansione SYN (-sS) è "più invisibile" rispetto a TCP Connect scan (-sT). Un tempo, e da un punto di vista, questo era vero: cioè dal punto di vista dell'applicazione in esecuzione sull'host. In passato, prima degli IDS e dei firewall con stato, la migliore indicazione di una scansione delle porte erano i registri delle applicazioni che mostravano le connessioni aperte e immediatamente chiuse. La scansione SYN, poiché abbatte la connessione prima di lasciare il kernel, non attraversa mai l'applicazione, quindi questi log non vengono scritti. Dal punto di vista della rete, tuttavia, il comportamento di una scansione SYN semiaperta (SYN, SYN-ACK, RST) è abbastanza insolito e può essere un indicatore significativo di una scansione delle porte, anche se solo una, aperta la porta viene scansionata. In questo caso (la scansione di un numero limitato di porte che potrebbero essere aperte, protette da IDS), la TCP la scansione Connect potrebbe in realtà essere "invisibile".

-Pn (formalmente conosciuto come -P0 e -PN) indica Nmap per saltare la fase di rilevamento dell'host e suppone invece che tutti gli host siano attivi. I dettagli del rilevamento dell'host sono ben documentati, ma è è possibile che questo comportamento stia attivando un firewall adattivo sull'host. I firewall adattivi possono essere complicati, poiché si ottiene una varietà di risposte a seconda del comportamento e della velocità della scansione. Raccomanderei di rallentare la scansione con uno dei opzioni di temporizzazione e riducendo il numero di porte scansionate a una manciata, fino ad ottenere risultati coerenti.

11
bonsaiviking

Se vuoi approfondire ulteriormente, abilita --packet-trace bandiera. Ciò consentirà di tracciare i pacchetti nmap inviati e ricevuti al fine di determinare lo stato esatto della porta.

Ci possono essere una varietà di fattori che portano alla differenza nei risultati. È difficile determinare la causa esatta senza ulteriori informazioni.

4
user10211

Ciò è quasi certamente dovuto alla perdita di pacchetti. I tempi funzionano in modo leggermente diverso tra connessione e scansione SYN. Prova a scansionare un numero minore di porte con tempi meno intensi. Inoltre, se non ti trovi sull'ultima nmap, prova ad aggiornare, poiché modificano continuamente gli algoritmi di temporizzazione.

1
paj28