Continuiamo con la nostra serie di articoli che, attraverso esempi pratici e semplificati, dimostrano l’applicazioni di strumenti fondamentali nei rispettivi ambiti. È il turno di affrontare l’argomento Active Reconnaissance con l’aiuto di un breve esempio laboratoriale:
L’active reconnaissance è quella fase del servizio di penetration testing in cui si passa attivamente, con metodi manuali o automatizzati, a fare networking scanning. La ricognizione si dice attiva perché l’utilizzo di pacchetti sonda opportunamente manipolati (crafted packet) rende l’attività “rumorosa” e quindi rilevabile da eventuali sensori perimetrali. Questo a differenza della passive reconnaissance in cui si rastrellano informazioni pubblicamente disponibili in rete (Open Source Intelligence, OSINT) e quindi senza allertare la vittima.
L’active reconnaissance può includere attività quali:
– Host discovery
– Port scanning
– Device enumeration
– Vulnerability scanning
Nmap, o Network Mapper, è fra i tool più utilizzati per questa fase. Ha supporto multi-piattaforma, è incorporato in tantissimi prodotti di testing, sia commerciali che open source, ed offre la possibilità di utilizzare script aggiuntivi nonché opzioni per regolare la velocità e le performance della scansione come tecniche di evasione.
Sebbene ne esistano varianti ad interfaccia grafica, come Zenmap, è più utilizzato nella sua versione a riga di comando. La sintassi per lanciare una scansione non è rigorosa ma ha in genere la seguente struttura:
nmap [Scan Type(s)] [Option(s)]
Fra le tipologie di scansioni possibili vi è il discovery scan, utilizzato per scavare indirizzi IP attivi su una rete e quindi potenziali target. Tradizionalmente un discovery scan viene condotto tramite ping sweep ovvero inviando ICMP Echo Request ad ogni indirizzo IP di un range di indirizzi specificato e quindi raccogliendo le risposte di Echo Reply.
Poiché i moderni host hanno personal firewall che tipicamente bloccano le richieste di ping, Nmap utilizza anche altre tecniche per individuare i live host. Ad esempio, un TCP SYN scan (nmap -sS ) viene condotto senza portare a termine il three-way handshake e quindi il tentativo di connessione ha meno probabilità di essere loggato, ragion per cui questa metodologia di scansione rappresenta lo stealth scan originale.
Vediamo però, più nella pratica, come effettivamente Nmap si comporta lanciando un discovery scan su un indirizzo IP target della rete locale o su un indirizzo IP target remoto. Per analizzare il tipo di pacchetti sonda utilizzati, ci avvarremo di Wireshark.
Dalla nostra Kali Linux all’indirizzo 172.31.10.131/24 proviamo a verificare se esiste un live host all’indirizzo 172.31.10.128/24. L’opzione -sn utilizzata istruisce Nmap ad eseguire solo un discovery scan, senza passare automaticamente al port scan:
root@kali:~# nmap -sn 172.31.10.128
Starting Nmap 7.40 ( https://nmap.org ) at 2020-12-28 05:54 EST
Nmap scan report for 172.31.10.128
Host is up (0.00029s latency).
MAC Address: 00:0C:29:7F:F4:D2 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
root@kali:~#Contemporaneamente, su Wireshark possiamo osservare il seguente scambio di pacchetti:
1 0.000000000 00:0c:29:99:88:e6 ff:ff:ff:ff:ff:ff ARP 42 Who has 172.31.10.128? Tell 172.31.10.131
2 0.000288110 00:0c:29:7f:f4:d2 00:0c:29:99:88:e6 ARP 60 172.31.10.128 is at 00:0c:29:7f:f4:d2In pratica, su una rete locale Ethernet, Nmap preferisce testare la raggiungibilità di un host utilizzando una ARP Request che, essendo un messaggio gestito al livello 2 ovvero al Data Link layer dello stack protocollare, generalmente non viene bloccato dall’eventuale personal firewall del target. Questo equivale anche ad eseguire Nmap con l’opzione: nmap -PR .
Notiamo anche come Nmap, potendo acquisire il MAC address della scheda di rete target ed interpretandone i primi 24 bit, il cosiddetto OUI (Organizationally Unique Identifier), riesce a risalire al vendor della scheda di rete che in questo caso è VMware, trattandosi di un virtual network adapter.
Vediamo adesso come, invece, Nmap si comporta dovendo testare la raggiungibilità di un host remoto. Sempre dalla nostra Kali Linux all’indirizzo 172.31.10.131/24 proviamo a raggiungere l’indirizzo 192.168.1.151:
root@kali:~# nmap -sn 192.168.1.151
Starting Nmap 7.40 ( https://nmap.org ) at 2020-12-28 06:26 EST
Nmap scan report for 192.168.1.151
Host is up (0.00058s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
root@kali:~#Contemporaneamente, su Wireshark possiamo osservare il seguente scambio di pacchetti:
1 0.000000000 172.31.10.131 192.168.1.151 ICMP 42 Echo (ping) request id=0x4100, seq=0/0, ttl=45 (reply in 7)
2 0.000046779 172.31.10.131 192.168.1.151 TCP 58 38803 → 443 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
3 0.000069240 172.31.10.131 192.168.1.151 TCP 54 38803 → 80 [ACK] Seq=1 Ack=1 Win=1024 Len=0
4 0.000089644 172.31.10.131 192.168.1.151 ICMP 54 Timestamp request id=0x11b7, seq=0/0, ttl=55
7 0.000555548 192.168.1.151 172.31.10.131 ICMP 60 Echo (ping) reply id=0x4100, seq=0/0, ttl=128 (request in 1)
8 0.000562179 192.168.1.151 172.31.10.131 TCP 60 443 → 38803 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
9 0.000591890 172.31.10.131 192.168.1.151 TCP 54 38803 → 443 [RST] Seq=1 Win=0 Len=0
10 0.000606359 192.168.1.151 172.31.10.131 TCP 60 80 → 38803 [RST] Seq=1 Win=32767 Len=0In pratica, dovendo testare la raggiungibilità di un host remoto, Nmap utilizza un mix di pacchetti sonda che hanno una qualche possibilità di poter filtrare attraverso dispositivi di protezione perimetrali o personali del target. Nello specifico Nmap utilizza nell’ordine le seguenti 4 sonde:
– ICMP Echo Request
– TCP SYN sulla 443
– TCP ACK sulla 80
– ICMP Timestamp Request
Si ottengono le seguenti risposte elencate in ordine corrispondente alle richieste, le quali confermano la presenza di un live host:
– ICMP Echo Reply
– TCP SYN-ACK dalla 443
– TCP RST dalla 80
– Nessuna risposta
Notiamo anche come, in ulteriore risposta al TCP SYN-ACK dalla 443, Nmap subito interrompa il three-way handshake con un TCP RST verso la 443.
