Re: VLAN Security

[Tilman.Schmidt () SEMA DE (Tilman Schmidt)]

At 16:44 01.09.99 +0800, bugtraq () SIS ALPHAWEST COM AU 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.Schmidt () sema de (office)
Sema Group Koeln, Germany       tilman () schmidt bn uunet de (private)
"newfs leaves the filesystem in a well known state (empty)."
                                                - Henrik Nordstrom