-----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.taylorat_private) -----BEGIN PGP SIGNATURE----- Version: PGP 6.0.2 Comment: Public key available from ldap://certserver.pgp.com iQA/AwUBN9WOW7XZ1jV6EllXEQLjHQCcCca8SxmxAW1OulgHU3Ij5jiZBNgAoNvk mQNehSht5ura47MpB7F2Bdo2 =SPjo -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:02:29 PDT