it-swarm-eu.dev

Nmap riporta quasi tutte le porte aperte

Ho notato durante alcune valutazioni quando si fa un TCP port scan, Nmap riporterà quasi tutte le porte come aperte per una macchina.

Usando ad esempio nmap -sS -PN -T4 target -p0-65535, oltre 20.000 porte verranno restituite come aperte. Su ulteriori indagini, la maggior parte di queste porte non sono aperte né filtrate.

Cosa sta causando Nmap per considerare le porte aperte, e c'è un diverso tipo di scansione che può contrastare questo e dare risultati più accurati?

14
Sonny Ordell

Molto probabilmente stai colpendo un dispositivo IDS/IPS ben configurato.

snort può facilmente rilevare la tua scansione della porta in corso con il filtro sfPortscan (il -sS è praticamente una firma "portcan in corso") e oltre a registrare il tuo attacco, può essere configurato per eseguire un risposta attiva . Queste risposte possono essere semplici come l'invio di un RST o ricche come la regola " reagire ". Il comportamento predefinito della risposta "reagisci" è rispondere con un HTTP 403 Forbidden, ma possono anche configurarlo per inviare qualsiasi dato arbitrario desiderato. Il comportamento della reazione non è limitato alle richieste della porta 80. snort invierà la risposta indipendentemente dal numero di porta .

Per testare questa teoria, mentre intraprendi un portcan del target, dalla stessa macchina che sta eseguendo la scansione, prova ad aprire qualsiasi vecchia porta su quel target con un browser o un netcat. Se ricevi la risposta HTTP 403 Proibita da una porta non HTTP, è probabilmente quello che sta succedendo.

Immagino che nmap non interpreti la risposta, segnala solo che è stata stabilita la connessione socket, quindi ti sta segnalando come una porta aperta. Invece di indovinare, tuttavia, è possibile impostare --packet-trace opzione su nmap per vedere cosa stai effettivamente recuperando.

Puoi leggere qui il manuale dello snort .

19
John Deters

Hai alcune opzioni. Il mio primo pensiero sarebbe che potrebbe esserci un sistema intermedio che sta rispondendo con pacchetti SYN/ACK a porte vietate (con firewall). In questo caso, potresti essere in grado di distinguere le porte veramente aperte dal TTL della risposta. Se hai salvato il output XML della tua scansione (-oX o -oA), puoi controllare //port/state/@reason_ttl attributo. Questo è simile alla tecnica del "firewalking". Puoi trovare alcune informazioni correlate qui: Firewalking con nmap .

Un'altra alternativa sarebbe usare un diverso tipo di scansione . Scansione SYN di Nmap (-sS o impostazione predefinita quando si esegue la scansione come root) può essere rilevato da TCP, MSS e dimensioni della finestra, quindi un IDS/IPS potrebbe rispondere a questo. Provare a utilizzare TCP Connetti scansione (-sT) anziché. Altri tipi di scansione (ACK, FIN, Maimon, ecc.) Potrebbero essere utilizzati per filtrare i risultati; non mostreranno le porte aperte da soli, ma potrebbero contrassegnare alcune di queste porte "aperte" come firewall, o almeno mostrare che si comportano diversamente. Prestare attenzione qui, tuttavia, poiché inviano pacchetti "cattivi" molto evidenti e si basano su comportamenti che spesso non sono presenti nei sistemi operativi moderni.

Infine, puoi utilizzare Nmap's rilevamento della versione del servizio (-sV) per identificare i servizi dietro le porte "aperte". È probabile che i falsi positivi scadano semplicemente o inviino un RST per chiudere la connessione subito dopo l'apertura. Questo rallenterà molto la scansione, ma a volte è importante essere precisi. Consiglierei di iniziare con --version-intensity 0, che eseguirà semplicemente uno stendardo del banner e, eventualmente, tutti i probe che sono stati taggati sulla porta specifica in fase di scansione, al contrario del valore predefinito, che fa questo e fino a 8 altri test.

10
bonsaiviking

Esiste una tecnica di offuscamento in cui un server simula quasi tutte le porte da aprire, simulando idealmente la firma del servizio valido sulla maggior parte di queste porte.

Portspoof , ad esempio, implementa questo approccio e gestisce più di 8000 firme di servizio.

5
WhiteWinterWolf

Mi è successa la stessa cosa. Fu Snort a causarlo. Aggiunta di -f e --badsum passa a nmap mi ha permesso di passare l'IDS/IPS. Il comando completo era il seguente:

nmap -sS -p 1-65535 -f --badsum -vv -Pn -oA target_nmap target

3
dprofancik

Ho affrontato lo stesso problema come te. Nel mio caso, l'IDS/IPS avrebbe inviato un SYN, ACK per tutte le porte, il che ha portato nmap a concludere che tutte le porte erano aperte.

Tuttavia, mentre i pacchetti devono essere ritrasmessi quando non sono riconosciuti in base a specifica TCP , l'IDS/IPS NON ha ritrasmesso i pacchetti che non sono stati riconosciuti (come nel caso di un TCP SYN scan),.

Pertanto sono stato in grado di distinguere le porte aperte da quelle inaccessibili guardando i pacchetti ritrasmessi in WireShark. Se un SYN, ACK è stato ritrasmesso, significa che la porta era aperta.

Il filtro WireShark che puoi utilizzare per questo è:

 tcp.analysis.retransmission 
2
Onderbetaald

Potrebbero esserci diverse cose qui.

John ha menzionato che lo snort o un altro tipo di IDS/IPS sono un potenziale trabocchetto che sta catturando la tua scansione syn. Puoi provare a passare da -sS a -sT e specificare un periodo di tempo prima di provare a scansionare un'altra porta: sfportscan è guidato dal tempo, se abilitato. (Fonte: ex dipendente Sourcefire)

Altre possibilità includono firewall di ispezione con stato. Ho visto casi in cui se esiste un firewall/NAT/dispositivo di filtro tra te e la tua destinazione di scansione, il firewall potrebbe restituire un SYN/ACK, mentre in realtà la porta per la tua destinazione effettiva potrebbe non essere accessibile. Ancora una volta, prova una scansione -sT e il tono ha eseguito quante porte stai tentando di scansionare contemporaneamente.

L'avvertenza nell'uso di -sT in contrapposizione a -sS o ad altri tipi di scansione è che, se un servizio è in ascolto su una porta e si ottiene una risposta, ci sono buone probabilità che si finisca per registrarsi. Per un esempio di ciò, lancia una scansione -sT su qualsiasi demone ssh e controlla successivamente/var/log/secure.

1
some_noob

Ho avuto cose strane con nmap in passato quando sto cercando di scansionare troppo velocemente, e -T4 è dopo tutto definito come "aggressivo". Prova a portare la velocità di scansione su 3 e vedi se ottieni gli stessi risultati.

Potresti anche imbatterti in bug OS o nmap o problemi di interoperabilità di qualche tipo. Se hai un altro sistema prova a eseguirlo e vedi se ottieni lo stesso risultato.

Potrebbe esserci una tecnologia firewall che rovina il tuo traffico, vedi se riesci a eliminare qualcosa.

1
GdD