At 16:44 01.09.99 +0800, bugtraqat_private wrote: [implementation of 802.1q VLANs on Cisco Catalyst 2900 series] >This has been >discussed with Cisco and we believe that it is an issue with the >802.1q specification rather than an implementation issue. I disagree. IMHO, the root of the matter is the following, which is indeed an implementation issue: >The trunk port, along with all the other ports, must be assigned to a >VLAN. The trunk is shared between VLANs. Assigning a trunk port to a specific VLAN leads to confusion between trunk frames (bearing a VLAN tag) and non-trunk frames (not bearing a VLAN tag). > If some non-trunk ports on the switch share the same VLAN as >the trunk port, then it is possible to inject modified 802.1q frames >into these non-trunk ports, and have the frames hop to other VLANs on >another switch. [...] >Recommendations >=============== >Try not to use VLANs as a mechanism for enforcing security policy. >They are great for segmenting networks, reducing broadcasts and >collisions and so forth, but not as a security tool. > >If you MUST use them in a security context, ensure that the trunking >ports have a unique native VLAN number. I think the second recommendation is the correct one. Logically, the trunking ports should *not* be in any VLAN. If Cisco forces you to assign it to one, create a separate "trunk" VLAN and assign the trunk ports to that. This does not completely elliminate the ambiguity, but it prevents exploiting it from a non-trunk port. (And if an attacker has access to your trunk you're hosed anyway.) -- Tilman Schmidt E-Mail: Tilman.Schmidtat_private (office) Sema Group Koeln, Germany tilmanat_private (private) "newfs leaves the filesystem in a well known state (empty)." - Henrik Nordstrom
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:02:17 PDT