Native Vlan

[gandrus]

Are there any recommendations on choose a native VLAN? Do you want it to be the VLAN with the most traffic on the switch or the VLAN from which you are going to manage the switch?

[andrew.butterworth]

Neither - You want the Native VLAN to be a non-used VLAN and one that isn't allowed on the trunk i.e.

interface gigabitethernet0/1

switchport mode dynamic desirable

switchport trunk native vlan 999

switchport trunk allowed vlan 10-30

[Kevin Dorrell]

I agree with that. Many NetAdmins avoid using VLAN 1 altogether, then let the trunks stay on VLAN 1. The thing about the trunk native VLAN, is that if there are any access port on that VLAN, they can be used to hack into any other VLAN. The hacker simply generates frames with an 802.1Q tag for the VLAN he wants to hack. The trunk transmits the frames without adding a tag, 'cos they are on the native VLAN. The other end of the trunk sees the tag the hacker inserted, and hey presto, the hacker has jumped VLANs.

Short story, the native VLAN of your trunks should not have any access ports, and should be cleared from the trunk itself.

As for CDP, VTP, etc., don't worry about it. Contrary to what you might suppose, these are always carried on VLAN 1, irrespective of the VLAN you have chosen for the native. That is why you cannot prune VLAN 1 (I think).

Kevin Dorrell

Luxembourg

[gandrus]

Thanks for the information Kevin that really helps.

[milan.kulik]

Hi Kevin,

have you ever tested that simple VLAN hacking you described? (I tried to repeat the test described in http://www.sans.org/resources/idfaq/vlan.php a year ago with no success.)

I've got a feeling that an access port should drop a frame tagged with a different VLAN ID, shouldn't it? (Unless 802.1Q in Q configured.)

If you disable native VLAN or VLAN1 on a trunk, you could get into a Common STP trouble when interconnecting Cisco and non-Cisco switches (see http://www.cisco.com/warp/customer/473/103.html#stp).

There were also some bugs noticed when VLAN1 was disabled on a trunk (3550 stopped sending VTP, e.g.).

So AFAIK, the prefect security (paranoid) aproach should be:

1. Don't use VLAN1 for user data.

2. Create a separate VLANx used as a native VLAN only (no user data again) on all trunks.

3. Create another VLANy and use it as a management VLAN for your switches.

4. Don't put any user ports to VLAN1,VLANx,VLANy. But let these VLANs enabled on trunks. Create an ACL on your routers and switches to specify users allowed to connect the management ports.

Regards,

Milan

[Kevin Dorrell]

Hello Milan,

OK, I confess I have never actually tried it myself. I have only seen it demonstrated with PowerPoint at Networkers, at a session called something like "Hardening Catalyst Security".

I'm not sure about dropping the tagged frame though. I don't see why a tagged frame should be treated any differently from any other frame on an _access_ port. After all, the only difference at layer 2 (as far as an access port is concerned) is that the Ethertype is 0x8100 rather than 0x0800, and a slightly bigger MTU. Unless it is specifically filtered out.

Thanks for the pointers about the side-effects of disabling VLAN 1.

I like your list of paranoid features. I would like to add one more: "Don't configure any subinterfaces on your router for VLANx." Of course, I don't do all of these, but I won't tell which ones I don't do ;-).

Problem is the more paranoid features you build in, the more likely it is that you wont be able to manage the switch in an emergency. I tend to look at security as an educated compromise. Security can be slackened to ease configuration, access, and manageabilty, but the risks should be known and declared. That is the only way to make informed decisions.

Kevin Dorrell

Luxembourg

[milan.kulik]

Hi Kevin,

I think I'm putting this test as #3 to my "when I have time enough" list.

My idea that access port should drop a 802.1q frame tagged for another VLAN comes from my experience with wrong trunk configuration:

When you configure a nonegotiation trunk on one line side and an access port on the other side, there is an error message coming to your syslog saying something like "an unexpected 802.1q tagged frame received on an access port". So I think the frame should be dropped. But I might be wrong.

According to native VLAN subinterfaces:

I'm afraid of IOS bugs and Cisco 802.1q implementation requires native VLAN to be defined.

Maybe the safest way would be to configure a native VLAN subinterface, but not assign an IP address on it and shutdown it. And disable VLANx on the switch side (the only exception when it's reasonable to disable native VLAN on a trunk, I think).

But this looks really paranoid :-)

I'm not fulfilling all these paranoid features, too, of course.

I 100% agree with your conclusions about compromise security. The more secure your network is, the more troubles you have in a case of emergency and troubleshooting.

Best regards,

Milan

[Kevin Dorrell]

Hi Milan,

When you get round to doing the test, could you let me know the results? - I would be interested.

Kevin dot Dorrell at pt dot lu.

Best regards,

Kevin

[milan.kulik]

I will.

But I'm afraid it'll take a long time, this is not a high priority for me and my boss especially :-)

Regards,

Milan

[gandrus]

Thanks - Do most people just use VLAN 1 for the native and put all traffic on other VLAN's?

[Kevin Dorrell]

That's right. But they must make sure that there are no access ports on VLAN1, otherwise they could be hacked from those ports.

Having said that, I don't know about "most people". That is the architecture that was mentioned at Networkers security power session, and the one that is followed by many people. Some other people shift their trunks onto unused unrouted VLAN so they can leave their access ports on the default VLAN 1. Yet others leave the default configuration and take the (small) risk that they might have an internal LAN-savvy hacker.

Kevin Dorrell

Luxembourg