[11775] in bugtraq
Re: VLAN Security
daemon@ATHENA.MIT.EDU (Tilman Schmidt)
Thu Sep 9 08:48:07 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <3.0.5.32.19990903085029.00917920@igate.sema.de>
Date: Fri, 3 Sep 1999 08:50:29 +0200
Reply-To: Tilman Schmidt <Tilman.Schmidt@SEMA.DE>
From: Tilman Schmidt <Tilman.Schmidt@SEMA.DE>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <199909010844.QAA04513@vault.alphawest.com.au>
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
