VLAN security

If a computer is connected to a switch port with access VLAN 10, and the computer spoofs a packet with an 802.1Q header of VLAN 20, as this packet enters the switch port, will the switch drop the packet because the VLAN is mismatched? I'm just trying to get an idea if the switch has basic security built in like this. Thanks!

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

tech-airman

_maurice wrote:

If a computer is connected to a switch port with access VLAN 10, and the computer spoofs a packet with an 802.1Q header of VLAN 20, as this packet enters the switch port, will the switch drop the packet because the VLAN is mismatched? I'm just trying to get an idea if the switch has basic security built in like this. Thanks!

_maurice,

I am having difficulty trying to understand your problem within the basic FRAMEwork (pun intended) of the encapsulation and decapsulation process. Since you mention packet, let's start there. So let's say the computer has a packet at the network layer being encapsulated into a data link layer frame as follows...

[IP Header][Data]
v
[Ethernet Header][IP Header][Data][Ethernet Trailer]

Now the Ethernet frame is further encapsulated from the Data Link Layer to the Physical Layer as follows...

[Ethernet Header][IP Header][Data][Ethernet Trailer]
v
[Winchester encoding][Ethernet Header][IP Header][Data][Ethernet Trailer]

Then the Ethernet cable carries the signals from the computer to the switch. Once the signals reach the switch, the signals are decapsulated from the Physical Layer to Data Link Layer as follows...

[Ethernet Header][IP Header][Data][Ethernet Trailer]
^
[Winchester encoding][Ethernet Header][IP Header][Data][Ethernet Trailer]

So far, the Data Link Layer Frame has no VLAN information yet. I believe that the VLAN tagging occurs with the Data Link Frame AFTER receipt by the switch when the Data Link Frame is being forwarded from the incoming switch port to the outgoing trunk port on the switch. I think it is at that point the Ethernet Frame is VLAN tagged with the 802.1q VLAN header. Then that 802.1q VLAN tagged Frame is forwarded upstream to the next higher switch.

So since VLAN tagging occurs when the Ethernet frame is being forwarded from the incoming access switch port to the trunk port, I don't see how it's even possible for the computer to spoof VLAN tagging when the VLAN tagging occurs within the switch AFTER the Ethernet frame is decapsulated and re-encapsulated with the VLAN tagged 802.1q Ethernet header. Maybe you could reiterate the situation in a different way to show first that it's possible to spoof a VLAN tagged Ethernet header from a computer?

_maurice

tech-airman,

Thank you for the response. You are absolutely correct in what you said, and you understand my question perfectly.

However, my situation/question is in regards to what a hacker might do. There are programs that will send RAW packets with an 802.1Q header in an attempt to hop to another VLAN. Check out http://www.yersinia.net/attacks.htm . (Quite an evil program by the way

)

So in regards to your post, you are right that the 802.1Q header is encapsulated AFTER the packet is sent to the switch port. But what if a custom crafted packet was sent with an 802.1Q header with a different VLAN number than what the switch port is configured for? Would the switch drop it, or forward it? I just want to know if the switch has basic security like this, as I don't have access to a Cisco switch.

Thanks

svo4dot6

Actually where you will run into trouble is with the native vlan on a trunk link.

When a frame enters a switchport with an access vlan set, the tag will be added essentially the frame will be double tagged at this point. When the frame crosses a trunk port the first tag will be removed (the one added by the switch). This will allow the frame to hop to another vlan on the next switch. I have heard that one way to mitigate this is to make the native vlan on trunk links a vlan that is not in use anywhere else.

This is only possible with 802.1q as ISL does not support the native vlan idea.

Hope this helps.

_maurice

svo4dot6,

I understand what you are talking about, you are correct, and the information can be confirmed here: http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39211 .

However, my question is more basic than this native VLAN hopping scenario. In the scenario you describe, the access VLAN and the native VLAN are the same. As you can see, the picture in this scenario on the Cisco website states: "Note: Only Works if Trunk Has the Same Native VLAN as the Attacker."

Lets assume the native VLAN is unique. Will the switch drop a packet if the VLANs mismatch? I think it probably will drop it.

dtlokee

_maurice wrote:

Lets assume the native VLAN is unique. Will the switch drop a packet if the VLANs mismatch? I think it probably will drop it.

On an access link the frame is not inspected to see if there is an existing tag, this will vary slightly when there is a voice VLAN. Keep in mind when a frame is tagged on a trunk link it's ethertype is changed to 0x8100. When a frame is reeived on a trunk it's tag is examined and will be forwarded only if that VLAN exists on the switch and that VLAN is allowed on the trunk port.

_maurice

So lets say a switch has two VLANs, VLAN 10 and 20, and there are no trunk ports.

If a custom crafted frame with an 802.1Q tag for VLAN 20 is received on an access switchport for VLAN 10, what will happen? Will the frame exit the other VLAN 10 interfaces, with the original 802.1Q tag for VLAN 20? Will the switch drop the frame?

My basic question, is VLAN hopping possible when trunks are not involved? What would an access switchport do if it suddenly received vlan tagged frames?

_maurice

After mulling it over for a while, I am going to conclude that if a custom crafted 802.1q frame is received on an access switchport for an isolated switch, the frame will stay on its original vlan, no matter what custom 802.1q headers are added.

If the custom crafted 802.1q frame happens to traverse a trunk port, as long as the originating vlan and the native lan are not the same, and the frame is not double tagged, the frame will stay on its original vlan.

The only way to vlan hop is to negotiate a vlan trunk using DTP, or take advantage of a misconfiguration where the orignal vlan and native vlan for a trunk are the same, and the 802.1q frame is double tagged. The latter, however, will only allow for unidirectional traffic. The target will attempt to respond, but will not be able to reach its destination, as it is not in the same vlan.

_maurice

By the way, the ethertype is not changed to 0x8100. The ethertype remains at 0x0800. It is the Tag Protocol Identifier (TPID) in the 802.1q header that is 0x8100.

dtlokee

_maurice wrote:

By the way, the ethertype is not changed to 0x8100. The ethertype remains at 0x0800. It is the Tag Protocol Identifier (TPID) in the 802.1q header that is 0x8100.

You are correct, my point was that it inserts a new value at the same offset as the ethertype field to identify the frame as tagged vs untagged. The original ethertype is shifted over but is maintained so the L3 protocol can be identified.