Re: Native VLANs (securing 802.1q trunks)

ajenks · ‎01-18-2010

I was reviewing the document :

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39211

Regarding "Double-Encapsulated 802.1Q/Nested VLAN Attack", where the doument makes the recommendation to "clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose."

Looking at a 3750 stack, I have mutiple 802.1q trunks. I cannot see a way to either clear the native VLAN, or the set the "802.1q-all-tagged" mode. I can however, change the native VLAN to one that is not defined (is this the same as "unused" ?).

Switch1(config-if)#switchport trunk native vlan 99
VLAN id 99 not found in current VLAN configuration
VLAN id 99 not found in current VLAN database

Switch1#sh int trun

Port Mode Encapsulation Status Native vlan
Po10 on 802.1q trunking 99

Is this document/concern still valid and is the above a suitable way of dealing with this potential issue ?

Should VLAN 1 actually show any active ports under a "sh vlan" ? I have seen several commentments regarding "Don't use VLAN 1", but does these mean don't use this VLAN or production traffic, or that it should be removed from all ports.

The objective here is to reduce exposure to any type of compromise to VLAN seperation.

Ganesh Hariharan · ‎01-18-2010

Hi,

Genrally these type of attacks are called as vlan hopping and to prevent from these attacks to some extend by turning off the autotrunking feature of all the switches which do not require trunking and by following specific recommendations from switch suppliers on VLAN security.

You should never use the default VLAN either because VLAN hopping is much more easily accomplished from the default VLAN. A good security measure is to assign all your used interfaces to some VLAN and never using any default VLAN, (typically VLAN 1) for anything.

and check out the below link for securing vlans in switches best pratcices.

http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/stake_wp.pdf

Hope that clear out your query!!

If helpful do rate the valueable post.

Regards

Ganesh.H

Jon Marshall · ‎01-18-2010

ajenks wrote:

I was reviewing the document :

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39211

Regarding "Double-Encapsulated 802.1Q/Nested VLAN Attack", where the doument makes the recommendation to "clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose."

Looking at a 3750 stack, I have mutiple 802.1q trunks. I cannot see a way to either clear the native VLAN, or the set the "802.1q-all-tagged" mode. I can however, change the native VLAN to one that is not defined (is this the same as "unused" ?).

Switch1(config-if)#switchport trunk native vlan 99
VLAN id 99 not found in current VLAN configuration
VLAN id 99 not found in current VLAN database

Switch1#sh int trun

Port Mode Encapsulation Status Native vlan
Po10 on 802.1q trunking 99

Is this document/concern still valid and is the above a suitable way of dealing with this potential issue ?

Should VLAN 1 actually show any active ports under a "sh vlan" ? I have seen several commentments regarding "Don't use VLAN 1", but does these mean don't use this VLAN or production traffic, or that it should be removed from all ports.

The objective here is to reduce exposure to any type of compromise to VLAN seperation.

1) Create a new vlan - vlan 998 and allocate any unused ports into that vlan. There should be no ports allocated into vlan 1. Do not create a L3 SVI for vlan 998 because it is simply used as a holding area for unused ports.

2) Create another new vlan - vlan 999. Use this as the native vlan. Do not create a L3 SVI for this vlan because the native vlan never needs to be routed. Set all trunks to use this as the native vlan. Do not allocate any ports into this vlan.

3) Create a 3rd vlan - vlan xx and use this as your management vlan ie. this is the vlan used to manage your switches. It will need a L3 SVI but you do not allocate any ports into it.

A "sh vlan" should show no ports under vlan 1. You should also shutdown any vlan 1 L3 interfaces on the switches. You don't need them up because you have setup a different management vlan.

Jon

Collin Clark · ‎01-18-2010

A common isue I run across is that engineers will put (per Jons VLANs), 998 (unused ports VLAN) and 999 (the native vlan) on the trunk itself. There is no benefit to doing this and it should be removed from the trunks for additional security.

Peter Paluch · ‎01-18-2010

Jon,

A very nice and insightful reply!

Usually when I am asked about the native VLAN, my first words are that "in future, the concept of native VLAN will be regarded as one of the greatest networkers' mistakes..." Anyway, what I recommend is something very similar to what you are proposing - to create a "parking" VLAN to hold all the unused ports, possibly even putting it into locally shutdown/VTP suspended state.

However, I personally do not recommend changing the native VLAN on trunks. I do not see a real value in it - if the VLAN 1 is unused by access ports (which it should be by virtue of placing all access ports into the parking VLAN), the option of VLAN hopping from VLAN 1 to another VLAN is no longer an issue. What is then the benefit of changing the native VLAN on trunks?

I am looking forward to reading your ideas!

Best regards,

Peter

Jon Marshall · ‎01-19-2010

paluchpeter wrote:

Jon,

A very nice and insightful reply!

Usually when I am asked about the native VLAN, my first words are that "in future, the concept of native VLAN will be regarded as one of the greatest networkers' mistakes..." Anyway, what I recommend is something very similar to what you are proposing - to create a "parking" VLAN to hold all the unused ports, possibly even putting it into locally shutdown/VTP suspended state.

However, I personally do not recommend changing the native VLAN on trunks. I do not see a real value in it - if the VLAN 1 is unused by access ports (which it should be by virtue of placing all access ports into the parking VLAN), the option of VLAN hopping from VLAN 1 to another VLAN is no longer an issue. What is then the benefit of changing the native VLAN on trunks?

I am looking forward to reading your ideas!

Best regards,

Peter

In most situations it's actually better to just tag the native vlan as well which is quite possible most of the time since in a modern Cisco network all switches will understand 802.1Q. This would defeat vlan hopping because the switch would not need to remove the native vlan tag by default.

However most people don't do this as far as i know. So the next best thing is to change the native vlan. Now i agree wholeheartedly that if you have changed all the unused ports to a "parking" vlan then there is limited use in doing this but it's just another failsafe. And i always give that advice simply because -

1) mistakes can be made and switches added to the network without reallocating ports into the "parking" vlan. And that's the fundamental problem. All ports by default are in vlan 1 and the native vlan is vlan 1. Vlan 1 is just used too much. I can understand why ie. it does give some element of plug and play but these days it is necessary to secure against vlan 1 on your switches.

2) because vlan 1 is used so much you often find that people have networks where they can change the native vlan but they cannot stop using vlan 1 at least not without a significant redesign/configuration effort. But changing the native vlan does give some additional level of protection.

I guess it boils down to security in layers, trying to minimise the effects of a misconfiguration by using all tools available.

Jon

Peter Paluch · ‎01-19-2010

Hi Jon,

Thank you very much for your response.

Technically, I agree with everything you wrote. I would say that you seem to make your systems more foolproof by layering several measures that perhaps aren't strictly required but which make the impact of a potential issue less serious. I am often very strongly attracted towards minimalistic configurations - configuring only what is necessary and understanding the reasons to do it this or that way, not slapping dozens of commands "just to be sure", as often seen.

Probably the best option would be to tag all VLANs including the native VLAN, effectively eliminating its concept. However, such option is, as far as I know, available only on 3560 and higher/newer. For 2950/2960 access switches, this does not seem to be an option, unfortunately.

I am slightly uneasy about changing the native VLAN on trunks because of intricate and unclear interdependencies between the native VLAN and several service protocols running on a trunk link (STP, CDP, DTP, VTP, LOOP, PAgP, LACP). Some of them are tagged with all VLANs they run in (the STP), some of them are staunchly in VLAN 1 (i.e. they are untagged when the native VLAN 1, and are tagged with VID=1 if the native VLAN has been changed) and other run untagged no matter what native VLAN is configured on a trunk. I was never quite able to remember how are these individual protocols exactly tagged, and also I was never quite sure what will happen if the native VLAN is unallowed on a trunk. I have found these details difficult to grasp and I somehow expected that my students and network engineers out in the field may consider them to be even more difficult. For me, a profound understanding of what is being configured and what are its consequences is of paramount importance. Perhaps this is what is behind my reluctance to go over trunks and change their native VLANs. I admit, that is hardly a technical reason on my part.

Best regards,

Peter

Jon Marshall · ‎01-19-2010

Peter

not slapping dozens of commands "just to be sure", as often seen. - yep, that's me, i just slap on any old command

Seriously though your point is well taken and i guess it depends on the environments you work in. If i could guarantee that all ports were allocated to the "parking" vlan every time then great but unfortunately networks are configured by humans and they make mistakes so an additional layer of security is useful to me.

As for tagging control protocols, i remember doing a lot of reading and testing a while back for this.

Of the major control protocols CDP/STP/PaGP/DTP/VTP the odd one out is DTP if i remember correctly. Obviously STP is a little different because of PVST+ but the other protocols always use vlan 1. If the native vlan is changed then they still use vlan 1 but their packets are tagged.

DTP always uses the native vlan. So if you change the native vlan to 999 then DTP uses vlan 999.

Both vlan 1 and the native vlan can be cleared off trunks and the control protocols listed above will still work.

Obviously that testing was done a while back and it may well be that some switches exhibit different behaviour these days.

Edit - forgot to say. Thank you for information regarding 2950/2960 switches and tagging the native vlan. I was under the impression that you could tag the native vlan on all Cisco switches.

Jon

Peter Paluch · ‎01-19-2010

Hi Jon,

yep, that's me, i just slap on any old command

I hope I did not offend you. I certainly did not mean it. I am truly sorry if I said something inappropriate.

When I attended my BCMSN training I spent one evening sniffing a trunking port to see how are the individual control protocols tagged. I remember the DTP being untagged all the time... and I have the feeling that the LOOP frames are also untagged. Nevertheless, I should spend another evening refreshing and confirming that

Regarding disabling the VLAN1 on trunks - if I am not mistaken it can be done with recent IOSes but again, I have a feeling that older 2950/3550 switches did not allow you to do that. But at least one can see that the possibilities are indeed improving

Best regards,

Peter

Jon Marshall · ‎01-19-2010

paluchpeter wrote:

Hi Jon,

yep, that's me, i just slap on any old command

I hope I did not offend you. I certainly did not mean it. I am truly sorry if I said something inappropriate.

When I attended my BCMSN training I spent one evening sniffing a trunking port to see how are the individual control protocols tagged. I remember the DTP being untagged all the time... and I have the feeling that the LOOP frames are also untagged. Nevertheless, I should spend another evening refreshing and confirming that

Regarding disabling the VLAN1 on trunks - if I am not mistaken it can be done with recent IOSes but again, I have a feeling that older 2950/3550 switches did not allow you to do that. But at least one can see that the possibilities are indeed improving

Best regards,

Peter

No offence taken and absolutely no need to apologise, i was just being a bit flippant

I always try to keep learning and these sort of threads help to clarify things for me as well as, hopefully, other people reading them.

Jon

milan.kulik · ‎01-19-2010

Hi Peter,

I agree totally!

IMHO, the whole native VLAN and dynamic trunking concept brought so many confusions and problems that I wish Cisco never invented it :-((

BR,

Milan

Peter Paluch · ‎01-19-2010

Hi Milan,

Thank you for your kind words!

Best regards,

Peter

milan.kulik · ‎01-19-2010

Hi Peter,

well, my words are not so kind to Cisco :-(

IMHO, they should admit native VLAN, dynamic trunking and VTP are "blind alleys" and remove those artificial features from IOS or make them non-default at least!

BR,

Milan

Peter Paluch · ‎01-19-2010

Hello Milan,

I am not quite sure if the native VLAN concept is a Cisco invention. I have a feeling that it is also considered in the IEEE 802.1Q standard - I am not quite sure about that but I know that the term itself, native VLAN, is not used in the standard. That being said, I do not see a real usability for the native VLAN concept. Backward compatibility with non-802.1Q devices connected to trunks? That's a complete nonsense. Such devices by their very definition do not understand VLANs and are always members of a single VLAN only, and this can be - and should be - dealt with using access ports.

The DTP itself has little practical meaning in my opinion. It is more dangerous than useful, its real usability can be appreciated only when initially setting up a network and the recommended best practice is having it deactivated, with all port modes set statically.

Regarding the VTP, I am not so dismissive. The idea of VTP itself is very good. If I were to maintain a network of 10 or more switches with dozens of VLANs, then manually taking care of consistent VLAN databases on all switches would be a daunting task. Yes, the VTP has been implemented very naively, with all the "wonderful" side effects (that a VTP Client with a higher revision number can overwrite the VLAN database in the entire VTP domain and possibly some others) but the motivation to have and run the VTP is valid. After all, the IEEE works on a similar set of protocols - the GARP and GVRP. Moreover, the VTP version 3 removes some of the deficiences of its predecessors and also has other nice features likes synchronizing the MST VLAN-to-instance mappings which is also a useful thing.

Best regards,

Peter

milan.kulik · ‎01-20-2010

Hi Peter,

AFAIK, no other vendor is using native VLAN. So it was invented by Cisco, I think.

Regarding VTP:

I agree it's a nice idea.

But the VTP1 and 2 implementation was so immature and unsecure!

The "VTP bomb" possibility you mentions is awkward :-(

Let's hope IEEE will bring some useful standard.

BR,

Milan