Mitigare gli attacchi basati su Cisco DTP e gli attacchi di double-tag

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 gli attacchi basati su Cisco DTP e gli attacchi di double-tag.  Riteniamo utile prendere visione del precedente articolo su come Mitigare gli attacchi basati su Cisco CDP. In questo articolo proseguiremo analizzando gli attacchi basati sul Cisco Dynamic Trunking Protocol (DTP) e gli attacchi di double-tag. Ecco di seguito la topologia di riferimento:

 

Di default gli switch Cisco Catalyst eseguono il protocollo Cisco Dynamic Trunking Protocol (DTP) che permette di negoziare dinamicamente la modalità operativa del link partendo da una modalità amministrativa di Dynamic Auto (negoziazione passiva) o Dynamic Desirable (negoziazione attiva). Per una switchport su cui sia collegata una workstation viene tipicamente negoziata la modalità access poiché la workstation, non eseguendo il Cisco DTP, non si propone per la formazione del trunk. Da Yersinia della Kali Linux spostiamoci dal tab CDP (utilizzato per l’attacco del precedente articolo) al tab DTP. È possibile osservare la ricezione dei messaggi DTP e lo stato della switchport ACCESS/AUTO. Eseguiamo l’attacco cliccando su “Launch attack” e selezionando “Enable trunking”. Yersinia comincerà a rispondere alla negoziazione DTP provando a formare il trunk. Dalla console dello switch lab-sw possiamo osservare il risultato e la formazione del trunk sulla switchport Gi0/2 dove è connessa la Kali Linux:

lab-sw(config-if-range)#do show interface status
Port Name Status Vlan Duplex Speed Type
Gi0/0 disabled 1 auto auto unknown
Gi0/1 win-pc connected 11 auto auto unknown
Gi0/2 kali-pc connected trunk auto auto unknown
Gi0/3 kali-srv connected 10 auto auto unknown
Gi1/0 uplink connected trunk auto auto unknown
Gi1/1 connected 1 auto auto unknown
Gi1/2 connected 1 auto auto unknown
Gi1/3 connected 1 auto auto unknown

L’accesso all’infrastruttura switch in modalità trunk permette alla Kali Linux di intercettare il traffico broadcast o unknown unicast in flooding appartenente a tutte le VLAN. Trattasi di un attacco di switch spoofing che rientra nella categoria del VLAN hopping ovvero quegli attacchi che permettono un accesso non autorizzato al traffico di altre VLAN. Per mitigare questo attacco è necessario forzare la modalità access sulla switchport e disattivare il Cisco DTP:

lab-sw(config-if-range)#switchport mode access
lab-sw(config-if-range)#switchport nonegotiate

Ripetendo l’attacco da Yersinia e osservando nuovamente lo stato delle switchport sullo switch lab-sw, possiamo verificare che il trunk non si forma:

lab-sw(config-if)#do show int status
Port Name Status Vlan Duplex Speed Type
Gi0/0 disabled 1 auto auto unknown
Gi0/1 win-pc connected 11 auto auto unknown
Gi0/2 kali-pc connected 11 auto auto unknown
Gi0/3 kali-srv connected 10 auto auto unknown
Gi1/0 uplink connected trunk auto auto unknown
Gi1/1 connected 1 auto auto unknown
Gi1/2 connected 1 auto auto unknown
Gi1/3 connected 1 auto auto unknown
lab-sw(config-if)#do ping 10.10.11.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.11.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms

Ora vediamo come mitigare gli attacchi di DOUBLE-TAG. In talune situazioni un aggressore può iniettare un doppio tag 802.1Q nel frame Ethernet. Questo è possibile quando l’access VLAN della switchport dove si trova l’aggressore coincide con la native VLAN del trunk in uscita dall’access switch. Inserendo come tag esterno quello della native VLAN lo switch rimuoverà tale tag esterno prima di inoltrare il frame sul trunk, lasciando il tag interno intatto. Il risultato di tale attacco è quello di iniettare frame in maniera non autorizzata nella VLAN indicata dal tag interno. Quindi anche l’attacco di double-tag rientra nella categoria degli attacchi di VLAN hopping. L’attacco è unidirezionale ma non da sottovalutare. Esistono sostanzialmente due modi per mitigare questo attacco. Uno è quello di utilizzare come native VLAN su tutti i trunk una VLAN isolata, che cioè non è usata altrove per altri scopi. Il secondo metodo consiste nell’abilitare il tagging della native VLAN, se il modello di switch lo consente chiaramente. Sullo switch lab-sw creiamo una nuova VLAN e chiamiamola “isolated”, quindi impostiamola come native VLAN sul trunk Gi0/1:

lab-sw(config-if)#vlan 999
lab-sw(config-vlan)#name isolated
lab-sw(config-vlan)#int g1/0
lab-sw(config-if)#switchport trunk native vlan 999

Inoltre abilitiamo globalmente il tagging delle native VLAN:

lab-sw(config-if)#exit
lab-sw(config)#vlan dot1q tag native
lab-sw(config)#exit
lab-sw#

Verifichiamo infine lo stato e la configurazione della switchport Gi0/1 per osservare la nuova impostazione:

lab-sw#show int g1/0 switchport
Name: Gi1/0
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 999 (isolated)
Administrative Native VLAN tagging: enabled
<…Outout Omitted…>