VLAN on Cisco Catalyst

I am getting conflicting advice from various sources concerning VLAN
security. I have several Catalyst 2950 switches in my network, running
one VLAN with public access (including wireless unrestricted access),
and domain-controlled workstations on another. I classify those as low
and medium security zones, respectively. I will now set up a network
commanding higher security in the same physical space, and due to
construction issues and safety precautions in the buildings, installing
extra cables will be very expensive. I'm thinking of creating a new VLAN
instead.

I get some warnings about the possibility of fixing a packet header to
make traffic cross over between VLANs. Is that possible if all
switchports have the communication explicitly set? (i.e.: ports
connected to other Catalysts are set to Trunk mode, and ports towards
the client side are set to access mode.) With no ports in auto mode, I'd
think that such "trunk spoofing" would fail.

If such attacks are still possible, how serious could they be?
- Can the attacker get a response, or is it only one way?
- If two way communication is available, would it then be possible to do
ARP poisoning, and could MiM attacks succeed?

Are there viable options for hardening the setup?
- Should I set up SSL/VPN channels to secure the network?
- The "high security" VLAN is not needed everywhere. Should I keep the
VLAN undefined on the other switches, or is it better to define it and
not assigning it to any port?

The high security nodes are mostly self sufficient (only occasional need
for network) so DoS is probably not an issue. Eavesdropping and
intrusion could be critical, though.
Any comments on the subject are welcome!

Re: VLAN on Cisco Catalyst

In article <45048148$1@news.broadpark.no>,
Keme wrote:
>I am getting conflicting advice from various sources concerning VLAN
>security. I have several Catalyst 2950 switches in my network

>I will now set up a network
>commanding higher security in the same physical space

>I get some warnings about the possibility of fixing a packet header to
>make traffic cross over between VLANs. Is that possible if all
>switchports have the communication explicitly set? (i.e.: ports
>connected to other Catalysts are set to Trunk mode, and ports towards
>the client side are set to access mode.) With no ports in auto mode, I'd
>think that such "trunk spoofing" would fail.

Historically, there have been attacks (on some devices) in which
a packet that unexpectedly had an 802.1Q header was allowed to hop
to the target VLAN. Most of the obvious vlan hopping attacks were
repaired by (reputable) vendors (on their managed switches) quite
a few years ago. It might, however, still be possible on some switches
by flooding the ARP table: in case of switch overload, some switches
(especially lower-end ones) might flood to *all* ports, not just to
the ports that are part of the same VLAN.

I seem to recall there was an attack demonstrated (and fixed since)
against some of the more advanced layer 2 capabilities such as
packet-in-packet encapsulation, used for "private VLAN" functions
(in which there might be multiple layers of 802.1Q tags.)


>The high security nodes are mostly self sufficient (only occasional need
>for network) so DoS is probably not an issue. Eavesdropping and
>intrusion could be critical, though.

If the work has anything to do with the military, or anything
to do with information that has legally been classified beyond
certain levels, then there are military or legal requirements on the
security mechanisms that must be put in place, and those may
require "air gaps" or other fairly strict interconnection restrictions.

Thus, why you are doing this might make an important difference.
A lot of personnel issues (e.g., not allowing people to see other's
salary) are *not* legally considered to require that level of security,
as is also the case for a lot of standard "keep our competitors
from finding out what we are doing" commercial security. But
EU customer privacy regulations are fairly strict, so ensure that
your choices are consistant with whatever level of customer information
you are holding internally.

Re: VLAN on Cisco Catalyst

Walter Roberson wrote:
> In article <45048148$1@news.broadpark.no>,
> Keme wrote:
>
>>I am getting conflicting advice from various sources concerning VLAN
>>security. I have several Catalyst 2950 switches in my network
>
>
>>I will now set up a network
>>commanding higher security in the same physical space
>
>
>>I get some warnings about the possibility of fixing a packet header to
[...]
>>think that such "trunk spoofing" would fail.
>
>
> Historically, there have been attacks (on some devices) in which
> a packet that unexpectedly had an 802.1Q header was allowed to hop
> to the target VLAN. Most of the obvious vlan hopping attacks were
> repaired by (reputable) vendors (on their managed switches) quite
[...]
> (in which there might be multiple layers of 802.1Q tags.)
>
>
>
>>The high security nodes are mostly self sufficient (only occasional need
>>for network) so DoS is probably not an issue. Eavesdropping and
>>intrusion could be critical, though.
>
>
> If the work has anything to do with the military, or anything
[...]
> your choices are consistant with whatever level of customer information
> you are holding internally.

Thanks! That mostly confirmed what I thought.

There are no legal requirements behind my security assessment. I am the
network administrator in a school, and most of the students have their
own laptop. There have been attacks (with 400+ computer users between 16
an 20 years old, that comes as no surprise...). Obviously, if any
student so inclined finds the path into the system, she or he will find
amusement in playing with the doorlocks. Our insurance company may not
be so amused...

The access control nodes are mostly self sufficient. Network is needed
for any changes to the system (like when a new user is added, or someone
changes their PIN). With each change, the entire user base is uploaded
to all nodes. Considering that VLANs should be secure, and there are
small chances of any hostile user knowing that there is something there
to attack, I guess it's sufficiently secure.

Re: VLAN on Cisco Catalyst

Keme wrote:
> I am getting conflicting advice from various sources concerning VLAN
> security.

Common VLAN implementations hade enough flaws, that it's difficult to
talk about VLAN "security" at all. Better separate physically if you're
implementing networks in different security zones.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: VLAN on Cisco Catalyst

Volker Birk wrote:
> Keme wrote:
>
>>I am getting conflicting advice from various sources concerning VLAN
>>security.
>
>
> Common VLAN implementations hade enough flaws, that it's difficult to
> talk about VLAN "security" at all. Better separate physically if you're
> implementing networks in different security zones.
>
> Yours,
> VB.

Thanks!

That's the most common comment I get, though, different flavors of "VLAN
security is an oxymoron", but without specific info.
Any pointers to reputable sources (web or print) for info on the nature
of the flaws mentioned would be very welcome! (I need to investigate
current activities, too, so knowing where to look for flaws would be
helpful whichever path I choose.)

Re: VLAN on Cisco Catalyst

Keme wrote:
> Any pointers to reputable sources (web or print) for info on the nature
> of the flaws mentioned would be very welcome!

http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-con very-switches.pdf

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: VLAN on Cisco Catalyst

Volker Birk wrote:
> Keme wrote:
>
>>Any pointers to reputable sources (web or print) for info on the nature
>>of the flaws mentioned would be very welcome!
>
>
> http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-con very-switches.pdf
>
> Yours,
> VB.

Black hats... of course. Excellent!

Thanks again.

Re: VLAN on Cisco Catalyst

Volker Birk wrote:
> Keme wrote:
>
>>Any pointers to reputable sources (web or print) for info on the nature
>>of the flaws mentioned would be very welcome!
>
>
> http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-con very-switches.pdf
>
> Yours,
> VB.
Excellent info. Thanks again.

Guess I found a hole. Thought the spurious "network unavailable"
situations were due to something else, but it fits the bill of
intentionally created network loops. I disabled STP, thinking i might
save some overhead...
Will check the logs again when I'm back at the office tomorrow.

I have all the VLAN security precautions already in place, so I am
reassured that it's good enough for my security requirements.