Re: vlan security ?

[Predrag Zivic <pzivic () yahoo com>]

Here is the info from the guys who have actually done
it. Anyway, feel free to make your own conclusions.
Pez
***********************************************
> -----Original Message-----
> From: bugtraq () SIS ALPHAWEST COM AU 
[SMTP:bugtraq () SIS ALPHAWEST COM AU]
> Sent: Wednesday, September 01, 1999 4:45 AM
> To:   BUGTRAQ () SECURITYFOCUS COM
> Subject:      VLAN Security
>
> To Bugtraq,
>
> We have recently conducted some testing into the
security of the
> implementation of VLANs on a pair of Cisco Catalyst
2900 series
> switches and we feel that the results of this
testing might be of 
some
> value to the readers.  Testing basically involved 
injecting 802.1q
> frames with forged VLAN identifiers into the switch
in an attempt to
> get the frame to jump VLANs.  A brief background is
included below 
for
> those that might not be too familiar with VLANs. 
Others should skip
> to the end for the results.
>
> Background
> ==========
> Virtual LAN (VLAN) technology is used to create
logically separate
> LANs on the same physical switch.  Each port of the
switch is 
assigned
> to a VLAN.  In the case of the Cisco Catalyst,
VLAN'ing is done at
> layer 2 of the OSI network model, which means that a
layer 3 device
> (router) is required to get traffic between VLANs
(possibly a
> filtering device).
>
> In addition to the above, VLANs may be extended
beyond a single 
switch
> through the use of trunking between the switches. 
The trunk allows
> VLANs to exist on multiple switches.  To preserve
VLAN information
> across the trunk, the ethernet frame is 'wrapped' in
a trunking
> protocol.  Cisco have their own proprietary trunking
protocol, but
> they also support the emerging 802.1q standard - we
used 802.1q
> trunking in these tests.
>
> Basically, 802.1q adds a tag to the ethernet frame
that specifies the
> VLAN that the frame belongs to.  Thus, when it is
transported between
> switches over the trunk, it is possible for the
receiving switch to
> send the frame to the correct VLAN.  In Cisco's
implementation of
> 802.1q the tag is
> four bytes long and has the format "0x 80 00 0n nn"
where nnn is the
> VLAN identifier.  The tag is inserted into the
ethernet frame
> immediately after the source MAC address.  So, an
ethernet frame
> entering switch 1 on a port that belongs to VLAN 4
has the tag "80 00
> 00 04" inserted.  The 802.1q frame traverses the
switch trunk and the
> tag is stripped from the frame before the frame
leaves the 
destination
> switch port.
>
> For more information on 802.1q -
> http://grouper.ieee.org/groups/802/1/vlan.html
>
> During our tests we used the packet generation tool
of Network
> Associates' Sniffer Pro v 2 to generate 802.1q
frames with modified
> VLAN identifiers in an attempt to get frames to hops
VLANs without 
the
> intervention of a layer 3 device.
>
> Findings
> ========
> We found that under specific conditions it was
possible to inject
> frames into one VLAN and have them 'hop' to a
different VLAN.  This 
is
> a serious concern if the VLAN mechanism is being
used to maintain a
> security gradient between two network segments. 
This has been
> discussed with Cisco and we believe that it is an
issue with the
> 802.1q specification rather than an implementation
issue.
> The trunk port, along with all the other ports, must
be assigned to a
> VLAN.  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.
>
> eg.
> Switch 1 has ports 1-12 on VLAN 1
> Switch 1 has ports 13-23 on VLAN 2
> Switch 1 has port 24 configured as an 802.1q trunk
(VLAN 1)
> Switch 2 has ports 1-12 on VLAN 1
> Switch 2 has ports 13-23 on VLAN 2
> Switch 2 has port 24 configured as an 802.1q trunk
(VLAN 1)
> Machine 1 is on port 1, switch 1.
> Machine 2 is on port 13, switch 2.
>
> We can send 802.1q frames with the following
details...
>       Source MAC = Machine 1
>       Destination MAC = Machine 2
>       VLAN ID = VLAN 2
> ...from machine 1 and they will arrive at machine 2.
>
> This will only occur if the trunk port belongs to
the same VLAN as
> machine 1.
> * We tried this only for the trunk belonging to VLAN
1.  We expect
> that similar results would be achieve if machine 1
and the trunk port
> shared VLAN 3, 4, ...
>
> Implications
> ============
> This is a problem if the following conditions are
met:
>       1. The attacker has access to a switch port on the
same VLAN as the
>          trunk.
>       2. The target machine is on a different switch.
>       3. The attacker knows the MAC address of the target
machine.
> In a real-life scenario, there may also be a
requirement for some
> layer 3 device to provide a connection from VLAN 2
back to VLAN 1.
> 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.
>
> Final Notes
> ===========
> Thanks to those at Cisco who assisted in the
handling of this issue.
> The two switches used for testing were
WS-C2924M-XL's.  They were 
both
> running 11.2(8)SA5.
> Additional information on test configuration will be
made available 
on
> request.
>
> Regards,
>
> Dave Taylor   (david.taylor () alphawest com au)
> Steve Schupp  (steve.schupp () alphawest com au)
*****************************************************************************
--- John Adams <jna () retina net> wrote:
> On Tue, 8 Aug 2000, Jonathan Feldman wrote:
>
> > Whether or not VLANs are secured, our policy has
> always been to keep
> > dmz / public interfaces on separate physical
> switches when possible.
> > My observation on this is the data link folks are
> not always the folks
> > who are doing network security; it's easy to
> fat-finger a switch and
> > misconfigure it.  It's much easier to keep stuff
> separate when it's on
> > a physically separate device.
>
>
> I've spent alot of time configuring VLANs on
> Catalyst 6xxx series
> switches, and other Cisco products and I have to
> admit, this is one of the
> first times I've seen concerns raised about packets
> jumping from VLAN to
> VLAN. I'd guess that it's entirely possible to make
> this happen, but I'm
> looking for hard evidence that this can happen. 
>
> There's simply no command (aside from putting a port
> up as a span port or
> trunk) to put a port in two VLANs. Would this attack
> involve injecting ISL
> packets into the switch to send data to multiple
> ports? ISL isn't
> authenticated, nor is VTP, so you could have packets
> crossing boundaries
> that way. 
>
> Does anyone have an example (protocol level) of this
> happening? 
>
> -john
>
> --
> J. Adams                                      http://www.retina.net/~jna
> You are supposed to be a consumer, a black hole for
> goods, advertising and
> content. They only want to allocate enough upstream
> bandwidth for
> 10,000,000 buy buttons. Producing or sharing
> information is a subversive
> act and will not be tolerated. -anonymous coward on
> /.
>
>
>
> _______________________________________________
> Firewall-wizards mailing list
> Firewall-wizards () nfr net
> http://www.nfr.net/mailman/listinfo/firewall-wizards


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

_______________________________________________
Firewall-wizards mailing list
Firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards