Nmap - Risultato intenso vs rapido

Question

Nmap - Risultato intenso vs rapido

#1 da (7 voti)

9

Ho ereditato una piccola rete e attualmente sto valutando le sue prestazioni di sicurezza.

Ho avviato la porta di scansione di un host (chiamiamola Weirdo ) in quella piccola rete e dal mio punto di vista, sembra che quell'host specifico abbia una specie di rivelatore di scansione di porte e / o esegui la scansione di risultati offuscati con iptables in corso, perché il risultato che si ottiene dalla scansione intenso è molto diverso da quello del veloce uno.

Quindi ecco il rapido risultato della scansione me@mypc:~# nmap -T4 -F 12.34.56.78 :

Starting Nmap 7.01 ( https://nmap.org ) at 2017-04-18 11:48 CEST
Nmap scan report for 12.34.56.78
Host is up (0.57s latency).
Not shown: 93 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
3306/tcp open  mysql
8080/tcp open  http-proxy
8443/tcp open  https-alt

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

Questo in realtà mostra lo stesso risultato dell'esecuzione della scansione rapida da Weirdo localhost root@Weirdo:~# nmap -T4 -F localhost .

Ma questa è la intensa scansione me@mypc:~# nmap -T4 -A -v 12.34.56.78 :

1/tcp     open  tcpmux?
...(every port is shown as open, except a few)
49155/tcp open  unknown
...
9102/tcp  open  jetdirect?
... 
65389/tcp open  tcpwrapped
...
Completed SYN Stealth Scan at 11:49, 18.22s elapsed (1000 total ports) 
... 
Not shown: 120 closed ports

Nota: ... significa ripetizione della riga precedente con un diverso numero di porta

Quindi in pratica la scansione intensa rileva che molte altre porte sono aperte, ma questo è un paradosso, perché l'intensa scansione su Weirdo localhost root@Weirdo:~# nmap -T4 -A -v localhost fornisce anche la stessa esatta lista di porte aperte del rapido la scansione.

Quando guardo il traceroute , allora vedo quanto segue:

TRACEROUTE (using port 199/tcp)
HOP RTT     ADDRESS
1   1.52 ms 12.99.34.255
2   1.37 ms 12.99.0.3
3   1.09 ms 12.34.56.78

Port Scansione dei due ips con me@mypc:~# nmap -sV -T4 -O -F --version-light 12.99.34.255 12.99.0.3 Vedo che 12.99.34.255 è un Firewall Netgear FVS336Gv2 accessibile con il browser (la porta 80, quindi aperta).

Una scansione rapida consecutiva (1 secondo dopo), dopo la scansione intensa, produce lo stesso risultato della scansione intensa.

Dopo aver atteso un paio di secondi e aver eseguito nuovamente la scansione rapida, si ottiene lo stesso risultato della scansione rapida iniziale.

Probabilmente questo firewall gioca brutti scherzi sulla scansione intensa?

Un'altra piccola aggiunta:

Nell'host Weirdo controllo il firewall iptables e ottieni questo:

root@Weirdo:~# iptables -vL -t filter
Chain INPUT (policy DROP 25288 packets, 1768K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 101K   54M ACCEPT     all  --  lo     any     anywhere             anywhere            
 189K   12M ACCEPT     all  --  eth1   any     anywhere             anywhere            
  285  9686 ACCEPT     icmp --  eth0   any     anywhere             anywhere             icmp echo-request
  297 30354 garbage    all  --  eth0   any     anywhere             anywhere             state INVALID
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/NONE
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN/FIN,SYN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: SYN,RST/SYN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,RST/FIN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,ACK/FIN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: PSH,ACK/PSH
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: ACK,URG/URG
1968K 2742M ACCEPT     all  --  eth0   any     anywhere             anywhere             state RELATED,ESTABLISHED
 9564  391K ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:http
  463 27508 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:domain
   45  2392 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:8443
    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:9422
25288 1768K garbage    all  --  eth0   any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1361K packets, 501M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain garbage (9 references)
 pkts bytes target     prot opt in     out     source               destination

Questi filtri stanno giocando i trucchi sulla scansione intensa?

Che cosa significa avere una regola con target garbage ?

firewalls ports nmap iptables

posta kiltek 18.04.2017 - 14:15

fonte

1 risposta

Leggi altre domande sui tag firewalls ports nmap iptables

Implicazioni di lasciare l'interfaccia utente di amministrazione accessibile agli utenti non amministratori Usa il tracciamento WiFi per identificare i ladri

score 7 · Answer 1

Per prima cosa, correggiamo alcune ipotesi e termini che renderanno la comprensione dei risultati molto più semplice:

L'opzione -F è una scansione "rapida" perché esegue la scansione solo di 100 porte. È l'equivalente di --top-ports 100 . Senza questa opzione, Nmap esegue la scansione di 1000 porte TCP.
L'opzione -A non è "intensa", ma piuttosto "Tutte le funzioni". È l'equivalente di -sV -sC -O --traceroute .

Quindi è stata eseguita una scansione delle porte di 100 porte e la si confronta con una scansione delle porte con rilevamento delle versioni e impronte digitali OS di 1000 porte. È comprensibile che tu avresti più risultati nella seconda scansione. Ma supponiamo che tu intenda letteralmente "ogni porta è aperta" nella seconda scansione. Quale potrebbe essere la causa e come possiamo saperlo con certezza?

In primo luogo, sarebbe interessante sapere se la scansione -F produce risultati diversi se si esegue dopo la scansione -A . Sospetto che lo farebbe. Questo mostrerebbe quindi che qualcosa (probabilmente il firewall) ha cambiato il modo in cui i pacchetti vengono passati tra il sistema di scansione e la destinazione. Ecco gli indizi che vedo nella seconda scansione:

altre porte aperte
Servizi non identificati ( tcpmux? ) e tcpwrapped servizi
apre le porte elencate che non sono in una scansione localhost della destinazione

Iptables non è abbastanza intelligente da solo per adattare un comportamento come questo, e non c'è nulla nelle regole che lo mostri. Quindi l'interferenza probabilmente proviene da un sistema diverso sul percorso di rete tra lo scanner e il target. Se avessi salvato l'output XML ( -oX o -oA ) o avessi usato l'opzione --reason (attivata anche da -vv o -d ), allora saresti in grado di vedere i dettagli su perché Nmap considerava ogni porta aperta o chiusa. La parte più interessante di questo è l'attributo reason_ttl , che registra il valore del campo Time-To-Live IP ricevuto, che viene normalmente decrementato una volta per ogni IP hop sul percorso di rete. Quindi, per un target Linux, le risposte partono da TTL 64 e con 2 hop nel mezzo dovrebbero essere ridotte a 62. Qualunque cosa vedete nella versione più accurata della scansione (ovvero la scansione -F con porte principalmente chiuse) è la vostra linea di base . Se inizi a vedere valori più alti di questo, molto probabilmente significherebbe che qualcosa tra te e il bersaglio sta inviando risposte invece del bersaglio. Esempio (la porta 27 è "falsa-aperta"):

PORT   STATE    SERVICE REASON
25/tcp open     smtp    syn-ack ttl 60
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp open     http    syn-ack ttl 60

Evitare ciò comporterà probabilmente un rallentamento della scansione per evitare di far scattare la soglia di allarme "port scan". L'evasione di misure adattative come questa è complicata . Ma una volta che hai superato la soglia, puoi fare alcune cose interessanti per mappare le regole del firewall.

Se al momento sei stato "bloccato" in questo modo con molte porte aperte, ma puoi ancora accedere ai servizi reali dietro il set originale di porte (ssh, smtp, http, ecc.), puoi provare a impostare un valore TTL molto basso nei pacchetti in uscita. Quando un router decrementa il TTL a 0, invierà un messaggio Time Expired ICMP, causando l'etichettatura della porta filtered . Se possiamo selezionare un TTL che scade dopo il firewall, ma prima del target, possiamo ottenere un elenco di porte "aperte" causate dal firewall e un set di porte "filtrate" che sono probabilmente permesse. Nell'esempio, basato sull'output traceroute, utilizzerei l'opzione --ttl 2 , poiché --ttl 3 avrebbe effettivamente raggiunto la destinazione. Quindi la scansione sarebbe: nmap -sS --ttl 2 -Pn example.com . L'utilizzo di -Pn di solito non è raccomandato, ma in questo caso è necessario, dal momento che le sonde non raggiungeranno mai effettivamente il target. Promemoria: questa scansione produrrà output utili solo se al momento il firewall è bloccato e se il blocco non si trova su ogni porta, ma lascia passare il traffico:

PORT   STATE    SERVICE REASON
25/tcp filtered smtp    time-exceeded from 12.99.34.255 ttl 252
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp filtered http    time-exceeded from 12.99.34.255 ttl 252

In questa uscita, la porta 27 ha ricevuto un syn-ack falsificato per apparire come proveniente dal target, anche se sappiamo dal nostro --ttl 2 che la nostra sonda non avrebbe mai raggiunto il target. Le altre due porte sono consentite, dal momento che riceviamo i messaggi superati nel tempo da quando sono scaduti. Se il firewall non consente i messaggi superati in termini di tempo in uscita, verranno visualizzati come filtered con un motivo no-response .