Nmap che segnala quasi tutte le porte come aperte

Probabilmente stai colpendo un dispositivo IDS / IPS ben configurato.

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

Per testare questa teoria, mentre esegui un portscan del target, dalla stessa macchina che sta facendo la scansione, prova ad aprire qualsiasi vecchia porta su quel target con un browser o netcat. Se si riceve la risposta HTTP 403 Proibita da una porta non HTTP, è probabile che ciò accada.

Sto indovinando che nmap non interpreta la risposta, segnala solo che la connessione socket è stata stabilita, quindi la sta segnalando come porta aperta. Invece di indovinare, tuttavia, puoi impostare l'opzione --packet-trace su nmap per vedere cosa stai effettivamente recuperando.

Puoi leggere il manuale di snort qui .

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

Un'altra alternativa sarebbe utilizzare un tipo di scansione diverso . La scansione SYN di Nmap ( -sS o predefinita durante la scansione come root) può essere rilevata dalle opzioni TCP, MSS e dalle dimensioni della finestra, quindi un IDS / IPS potrebbe rispondere a questo. Prova invece a utilizzare la scansione TCP Connect ( -sT ). Altri tipi di scansione (ACK, FIN, Maimon, ecc.) Potrebbero essere utilizzati per filtrare i risultati; non mostreranno le porte aperte da sole, ma potrebbero contrassegnare alcune di queste porte "aperte" come firewall, o almeno mostrare che si comportano diversamente. Fai attenzione qui, però, poiché questi inviano pacchetti "cattivi" molto evidenti e fanno affidamento su comportamenti che non sono spesso presenti nei sistemi operativi moderni.

Infine, puoi utilizzare il rilevamento della versione del servizio di Nmap ( -sV ) per identificare i servizi dietro le porte "aperte". È probabile che i falsi positivi eseguano semplicemente un timeout o invii un RST per chiudere la connessione subito dopo averlo aperto. Questo rallenterà molto la tua scansione, ma a volte è importante essere accurati. Ti consiglio di iniziare con --version-intensity 0 , che eseguirà semplicemente un banner e probabilmente eventuali sonde contrassegnate per la porta specifica da analizzare, in contrapposizione a quella predefinita, che esegue questo e altri fino a 8 test.

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

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

Ho avuto la stessa cosa che mi è successa. Era Snort a causarlo. L'aggiunta delle opzioni -f e --badsum a nmap mi ha consentito di passare l'IDS / IPS. Il comando completo era il seguente:

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

Ho avuto cose strane accadute con nmap in passato quando sto provando a scansionare troppo velocemente, e -T4 è in definitiva definito "aggressivo". Prova a trasformare la velocità di scansione a 3 e vedere se ottieni gli stessi risultati.

Potresti anche incappare in bug OS o nmap o problemi di interoperabilità di qualche tipo. Se si dispone di un altro sistema, provare a eseguirlo e vedere se si ottiene lo stesso risultato.

Potrebbe esserci qualche tecnologia firewall che sta facendo casino con il tuo traffico, vedi se riesci a eliminare qualsiasi ostacolo.

Potrebbero esserci molte cose qui.

John ha citato lo snort o un altro tipo di IDS / IPS come una potenziale trappola che sta catturando il tuo syn scan. Puoi provare a passare da -SS a -sT e specificare un periodo di tempo da attendere prima di tentare la scansione di un'altra porta: sfportscan è time-driven, se è abilitato a tutti. (Fonte: ex dipendente di Sourcefire)

Altre possibilità includono firewall di ispezione stateful. Ho visto casi in cui se c'è un firewall / NAT / dispositivo di filtraggio tra te e la tua destinazione di scansione, il firewall potrebbe restituire un SYN / ACK, quando in effetti la porta al tuo obiettivo attuale potrebbe non essere accessibile. Anche in questo caso, prova una scansione -sT e tonifica il numero di porte che tenta di eseguire la scansione in una sola volta.

L'avvertimento sull'uso di -sT rispetto a -sS o altri tipi di scansione è che, se un servizio è in ascolto su una porta, e ottieni una risposta, ci sono buone probabilità che ti ritroverai loggato. Per un esempio, lancia una scansione -sT su qualsiasi demone ssh e controlla / var / log / secure in seguito.

Ho affrontato lo stesso problema di te. Nel mio caso IDS / IPS invierebbe un SYN, ACK per tutte le porte, il che ha indotto nmap a concludere che tutte le porte erano aperte.

Tuttavia, mentre i pacchetti dovrebbero essere ritrasmessi quando non sono riconosciuti in base alla specifica TCP , il IDS / IPS NON ha ritrasmesso alcun pacchetto che non è stato riconosciuto (come nel caso di una scansione SYN TCP).

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

Il filtro wireshark che puoi usare per questo è:

 tcp.analysis.retransmission