1. Home
  2. Ethernet LAN
  3. Vlan Hopping Vulnerability

Vlan Hopping Vulnerability

Hello, i have read many doc about this exploit but there are any contradictions.

I hnow that this exploit exist in 3 ways :

1) Basic=> The attacker spoof a switch and gains the trunked states of the switch's port. Rely on auto-negotiate feature turned ON. This ways is simple to understand and to block

2) Complex 1 => This attack is described on

formatting link
and to work need that the attacker and the trunk share same native vlan ( ex. VLAN 10 ). In this doc. the attacker send on the access port ( VLAN 10 ) a tagged frame with a VLAN-ID of target VLAN ( ex. VLAN 20 ) . The switch takes frame and forward it on trunk port without native tag (10). The other switch (connected via-trunk) read VLAN-ID(20) and forward frame on the access vlan 20.

In this scenario my doubts is :

- Why the first SW accepts tagged frame ? Is this behavior an anomaly of work ?

- Why the last switch that receives native frame on trunk port reads the VLAN-ID ? Is this normal or anomaly ? I think that sw does'nt read VLAN-ID because the frame on trunk is native .

2)Complex 2 => In other docs per ex:
formatting link
is an attack called " Double-Encapsulated 802.1Q ". In this exploit the conditions are similar to the precedent but the attacker need to insert two VLAN-ID ( outer,inner ). If this case work then the first switch read VLAN-ID on access port and forward frame on trunk ( strip off first VLAN-ID ) . This behavior is different that precedent case . Why the switch forward this frame according to VLAN-ID

on the access-port ? Is this behavior another anomalies ?

Sorry about lenght of post but i want to understand if this vulnerability were resolved or not .

Thanks

Giuseppe Citerna ccie#10503

Reply to
Jos_Cit
Loading thread data ...

I looked up Cisco's website, and native VLAN appears to be a way of configuring only one of the VLANs to be untagged on a trunk since normally trunks need to have all traffic tagged.

There is no way in the standard to have a port accept only untagged frames. There is a control variable called "Acceptable Frame Types" and that can be set to be:

- Accept all frames

- Accept only tagged frames.

So normally an "access" port will accept tagged frames as well. However, if the switch has ingress filtering enabled (and this is optional in the standard and not default behavior), then the switch would have dropped the incoming frame since it would have had a VLAN tag for a VLAN of which it was not a member.

It looks like this switch is processing the frame as being on VLAN 20 all the way.

This is normal. The VLAN ID (20) is the non-native VLAN of the trunk and so the switch will read it and classify the frame as being on VLAN 20 and forward it accordingly.

The behavior is normal for the given configuration.

This again looks like an anomaly due to the notion of a native VLAN which allows you to send the native VLAN untagged on a trunk. The first switch receives a QinQ frame on a port that expects to see only a single tag. Because it is forwarding it on a trunk, and outer tag based on which it is doing its forwarding, is equal to the native VLAN it untags the frame. In the normal "good case" the receiving switch would have picked up this frame and tagged it using the native VLAN. However, in this case, the frame already has a tag (the inner one) and so the receiving switch classifies and forwards the frame based on that.

Per the white paper this can be avoided by not using the native VLAN.

Anoop

Reply to
anoop

Sorry for multi-posting , i did not know that it was not educated .

I took the conversations to comp.dcom.sys.cisco and all reply would have to be sent to this newsgroup.

Giuseppe Citerna

"Walter Roberson" ha scritto nel messaggio news:dd5908$mor$ snipped-for-privacy@canopus.cc.umanitoba.ca...

Reply to
Jos_Cit

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.