[11811] in bugtraq

home help back first fref pref prev next nref lref last post

Re: VLAN Security

daemon@ATHENA.MIT.EDU (David Taylor)
Fri Sep 10 03:15:55 1999

Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id:  <EA0466720A21D211B6C800104B2B75E2012EFD57@herculis.alphawest.com.au>
Date:         Wed, 8 Sep 1999 14:14:16 +0800
Reply-To: David Taylor <David.Taylor@ALPHAWEST.COM.AU>
From: David Taylor <David.Taylor@ALPHAWEST.COM.AU>
X-To:         Strange <strange@cultural.com>, BUGTRAQ@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Mike and Mike wrote:
> While I think it's immensely useful that your study has debunked
> in hard testing a common myth (that VLANs provide unbeatable
> isolation), the limits of inter-switch VLAN isolation are discussed
> already in Cisco's documentation.  See, e.g.:
>
>
http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/1928v8x/ee
scg8x/aleakyv.htm
>
> Indeed, according to the document, all one needs to jump VLANs
> involving more than one switch is the MAC of the target system.  Is
> that NOT the case?

Thanks for the Cisco hyperlink.  It was an interesting read.  The
content of the document does not seem to apply to our test scenario.
I thoroughly tested the possibility of getting ethernet frames to
cross VLAN boundaries by specifying the MAC addresses, and I was not
able to get this to occur under any circumstances using our test gear
- - two Cisco 2924 switches.

However, in response to our initial post, I did receive feedback from
a couple of people, telling me that they were able to do what the
Cisco document describes.  I attribute this difference in results to
different models of switch.  It seems that the first generation of
Cisco VLAN switches (1900 and 2880) did have this fault, but the more
recent ones don't.  I guess we have to be thankful for small mercies.

I suspect (although I haven't checked yet) that ISL trunking may have
some problems of its own.  We only tested against 802.1q trunking.

We also received a few responses to the initial post saying that the
behaviour we observed conforms to the 802.1q spec, and basically "what
was our problem?".  I haven't had an opportunity to dissect 802.1q in
great detail, and I doubt that I will.  The whole point of our post
was to raise public awareness of the potential security issues when
using VLANs in a security situation, especially when using vendor
default settings.

I guess the moral of the story, from all the feedback, is not to use
VLAN technology to divide security domains unless you really know what
you are doing in terms of switch configuration, and even then to make
sure you test the configuration thoroughly.

Regards,
Dave Taylor (david.taylor@alphawest.com.au)



-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2
Comment: Public key available from ldap://certserver.pgp.com

iQA/AwUBN9WOW7XZ1jV6EllXEQLjHQCcCca8SxmxAW1OulgHU3Ij5jiZBNgAoNvk
mQNehSht5ura47MpB7F2Bdo2
=SPjo
-----END PGP SIGNATURE-----

home help back first fref pref prev next nref lref last post