From: P729 (p729@cox.net)
Date: Wed Oct 16 2002 - 23:03:54 GMT-3
Yes, basic VLAN hopping requires an exploitable setting on the switch (such
as the default of Auto :) and a client with a VLAN-capable NIC (and possibly
some sort of dynamic trunking protocol signaling as well).
Another exploit requires more knowledge of the underlying network. See:
http://www.sans.org/newlook/resources/IDFAQ/vlan.htm. The tests exposed the
fact that the non-trunk ports in the Catalyst switches in the testbed did
not drop the tagged frames, but merely stripped the tags out. Perhaps this
was/is 802.1q-compliant behavior or perhaps this behavior was modified in
subsequent releases in the code, but this exploit was mentioned specifically
at a Networkers presentation this year. A bullet on one of the slides reads
"Works even if trunk ports are set to off" and goes on to explain that only
the first level of encapsulation is stripped off, leaving the opportunity
for "Q in Q" (double encapsulation) types of attacks as well.
Other discussions over the years repeatedly mention that 802.1q was not
specifically engineered with high-grade security in mind, but simply as a
means to carve up broadcast domains, etc. Bottom line: Implement an air-gap
if it's that sensitive.
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "Larson, Chris" <CLarson@usaid.gov>
To: "'seadon'" <seadon@attbi.com>; "Ccielab (E-mail)"
<ccielab@groupstudy.com>
Sent: Wednesday, October 16, 2002 7:45 AM
Subject: RE: 802.1q native vlan( further question on VLAN hopping -securi t
y issue)
In response to earlier posting in this thread about spoofing and vlan tag.
Can you do that? If a port on a switch receives a packet with a vlan header
what does it do? Unless it is a trunk, I would think that it would drop the
packet wouldn't it? Vlan headers are applied to packet as they are received
on the interface, and removed when they are forwarded out an interface.
Unless it is a trunk they are not forwarded or received on any interface,
only applied and removed there.
Is this correct?
I have heard notions of vlan spoofing, but I have never seen anything real
or applied that would actually do this and work. I do not think it can be
done (vlan spoofing) because of how the switch operates.
If you had a machine off of one of the ports to spoof with, the switch
recieving the vlan header would drop it because it is not a trunk port and
does not expect vlan headers. If it were a trunk port, your nic would have
to be dot1q capable, the switch would have to have that port configured as
trunk and allow the vlan you want to get to, which is not really spoofing at
all, but normal operation.
> -----Original Message-----
> From: seadon [SMTP:seadon@attbi.com]
> Sent: Tuesday, October 15, 2002 6:59 PM
> To: Ccielab (E-mail)
> Subject: Re: 802.1q native vlan( further question on VLAN hopping
> -securit y issue)
>
> > Don't really know the answer to that one. From what I've seen, most
> Cisco
> > switches will hold 8000 or more MACs. I'd imagine the correct behavior
> for
> > a switch with a rapidly fill CAM table would be to delete the least
> recently
> > added addresses.
>
> Actually, the correct behavior upon filling the table is almost
> universally
> to delete all addresses and start over. At least for every switch I've
> ever
> researched. Probably because the CPU time it would take to selectively
> erase entries would prohibit the switch from keeping up with the changes.
> Don
>
> > I guess if it happens too often, it could cause the switch
> > to maybe reboot if the CPU couldn't keep up. But I don't think it would
> > ever go into a 'dumb hub' mode. The ASICs aren't designed for that.
> But
> I
> > don't want you to base your network security on my speculation. Ask
> Cisco
> > for a definitive answer.
> >
> > Chuck Church
> > CCIE #8776, MCNE, MCSE
> > Sr. Network Engineer
> > Magnacom Technologies
> > 140 N. Rt. 303
> > Valley Cottage, NY 10989
> > 845-267-4000
> >
> >
> >
> > -----Original Message-----
> > From: Rick [mailto:ccie_2003@hotmail.com]
> > Sent: Tuesday, October 15, 2002 3:44 PM
> > To: Ccielab (E-mail); Chuck Church
> > Subject: Re: 802.1q native vlan( further question on VLAN hopping
> > -securit y issue)
> >
> >
> > Thanks Chuck,
> >
> > I believe that is the one of the answers we were looking for in regards
> to
> > the frame size of DOT1Q or ISL modified frames because there would be an
> > issue with size coming from an access port. I would have thought there
> would
> > have been a security document somewhere in regards to VLAN separation.
> Let
> > me ask you this question... Remember back with the early switches how
> they
> > had very small bridging tables that would only hold a few MAC address,
> and
> > if they overflowed they would sometimes reboot? What would happen if
> someone
> > was generating frames at a high feed rate into a switch port with a
> > different source MAC address on every frame, would the switch melt down
> and
> > turn into a dumb hub allowing interVLAN contamination? I figured there
> has
> > to be one hardcore lab rat who has tested this...
> >
> > Thanks,
> > Rick
> > ----- Original Message -----
> > From: "Chuck Church" <cchurch@MAGNACOM.com>
> > To: "'Rick'" <ccie_2003@hotmail.com>; "'Ccielab (E-mail)'"
> > <ccielab@groupstudy.com>
> > Sent: Monday, October 14, 2002 2:17 PM
> > Subject: RE: 802.1q native vlan( further question on VLAN hopping
> -securit
> y
> > issue)
> >
> >
> > > Rick,
> > >
> > > There's a few things that can be done to make it secure. Since they
> > > want a separate switch for their own traffic, it sounds like they
> don't
> > need
> > > any trunks. Without any trunks, I'd imagine a switch would be immune
> to
> a
> > > spoofed vlan tag, as the non-trunk ports would not look at the tag,
> and
> > drop
> > > it if it exceeded the 1514/1518 limit. Someone correct me on that
> part
> if
> > > I'm wrong. I certainly wouldn't ever trunk to a switch you didn't
> have
> > > absolute control over. And you certainly need to make sure that
> access
> to
> > > the switch's management interface (telnet, http, snmp, whatever) are
> > secure.
> > > But Mas is right, nothing's more secure than air. (Unless you're
> using
> > > wireless. Then wired is more secure :)
> > >
> > > Chuck Church
> > > CCIE #8776, MCNE, MCSE
> > > Sr. Network Engineer
> > > Magnacom Technologies
> > > 140 N. Rt. 303
> > > Valley Cottage, NY 10989
> > > 845-267-4000
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > > P729
> > > Sent: Sunday, October 13, 2002 3:23 AM
> > > To: Rick; Ccielab (E-mail)
> > > Subject: Re: 802.1q native vlan( further question on VLAN hopping
> > > -security issue)
> > >
> > >
> > > Nothing, short of no network connectivity at all, is going to be as
> secure
> > > as an air-gap. Administrative fat-fingering aside, if someone had the
> > > wherewithal to forge a valid tagged frame, that person could
> theoretically
> > > implement a one-way DoS attack from a non-local VLAN.
> > >
> > > Regards,
> > >
> > > Mas Kato
> > > https://ecardfile.com/id/mkato
> > > ----- Original Message -----
> > > From: "Rick" <ccie_2003@hotmail.com>
> > > To: "Ccielab (E-mail)" <ccielab@groupstudy.com>; "Brian McGahan"
> > > <brian@cyscoexpert.com>
> > > Sent: Wednesday, October 09, 2002 5:36 AM
> > > Subject: Re: 802.1q native vlan( further question on VLAN
> > hopping -security
> > > issue)
> > >
> > >
> > > Brian,
> > >
> > > There has been a big discussion lately about VLANs and security in
> regards
> > > to keeping different flows of traffic separate and protected. Do you
> see
> > > anyway someone could manipulate dot1q tags to compromise data
> integrity
> > > between organizations? There is a 3rd party telling me that his
> traffic
> > > should be on a separate switch that VLAN separation was not enough.
> How
> > can
> > > I support that it is enough separation?
> > >
> > > Thanks,
> > > Rick
> > > ----- Original Message -----
> > > From: "Brian McGahan" <brian@cyscoexpert.com>
> > > To: "'Chris'" <clarson52@comcast.net>; "'P729'" <p729@cox.net>;
> > "'chenyan'"
> > > <chenyan@deeptht.com.cn>; "'ccielab'" <ccielab@groupstudy.com>
> > > Sent: Sunday, October 06, 2002 3:50 PM
> > > Subject: RE: 802.1q native vlan
> > >
> > >
> > > > Chris,
> > > >
> > > > You're overcomplicating the issue. Let's assume that your
> > > > native vlan is vlan 10. This means that all traffic received on a
> .1q
> > > > trunk link that does not have a tag, belongs to vlan 10. Remember
> that
> > > > tagging only happens on the trunk line, the tag values are not
> carried
> > > > over access links (non trunk links).
> > > >
> > > > If traffic is generated by a host in vlan 10, and this traffic
> > > > must traverse the .1q trunk, the packet will not be tagged. When
> the
> > > > switch on the other end of the trunk receives the frame, it knows
> that
> > > > this frame belongs to vlan 10, since the packet is untagged, and the
> > > > native vlan is 10. Your native vlan must match between all switches,
> > > > otherwise you will have traffic leaking between vlans. That case is
> as
> > > > follows.
> > > >
> > > > Take the same situation, a host in vlan 10 generates a packet
> > > > that traverses a .1q trunk. The switch which this host is attached
> has
> > > > vlan 10 designated as the native vlan, however the switch on the
> other
> > > > side has vlan 20 designated as the native vlan. When the switch on
> the
> > > > remote side receives this packet, it assumes that the packet belongs
> to
> > > > vlan 20, and forwards it appropriately. This results in incorrect
> > > > forwarding, since the packet should actually be destined for vlan
> 10.
> > > >
> > > > HTH
> > > >
> > > > Brian McGahan, CCIE #8593
> > > > Director of Design and Implementation
> > > > brian@cyscoexpert.com
> > > >
> > > > CyscoExpert Corporation
> > > > Internetwork Consulting & Training
> > > > http://www.cyscoexpert.com
> > > > Voice: 847.674.3392
> > > > Fax: 847.674.2625
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf
> > > > Of
> > > > > Chris
> > > > > Sent: Sunday, October 06, 2002 2:13 PM
> > > > > To: P729; chenyan; ccielab
> > > > > Subject: Re: 802.1q native vlan
> > > > >
> > > > > I have been looking through the Docs and indeed it does say that
> > > > native
> > > > > vlan traffic is not tagged. I guess I have missed that when
> reading
> > > > the
> > > > > switching docs previously, and was always taught that all traffic
> is
> > > > > tagged.
> > > > >
> > > > > Thanks for the clarification.
> > > > >
> > > > > This would also mean that it is restricted to the native vlan then
> > > > right?
> > > > > Without a tag it could not be forwarded to any other vlan.
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "P729" <p729@cox.net>
> > > > > To: "Chris" <clarson52@comcast.net>; "chenyan"
> > > > <chenyan@deeptht.com.cn>;
> > > > > "ccielab" <ccielab@groupstudy.com>
> > > > > Sent: Sunday, October 06, 2002 2:05 PM
> > > > > Subject: Re: 802.1q native vlan
> > > > >
> > > > >
> > > > > > "Any untagged frames will get tagged..."
> > > > > >
> > > > > > Mmmm...sounds kinda contradictory doesn't it? Actually, frames
> > > > assigned
> > > > > to
> > > > > > the native VLAN of the trunk are sent untagged across the trunk,
> > > > period.
> > > > > But
> > > > > > one might ask, "how would the switches on each end know when
> there's
> > > > a
> > > > > > native VLAN mismatch?" The answer for Cisco switches is through
> CDP.
> > > > If
> > > > > CDP
> > > > > > is disabled or not available, then they wouldn't know and you
> can
> > > > pretty
> > > > > > much bridge the two VLANs together and maybe not know it...
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Mas Kato
> > > > > > https://ecardfile.com/id/mkato
> > > > > > ----- Original Message -----
> > > > > > From: "Chris" <clarson52@comcast.net>
> > > > > > To: "chenyan" <chenyan@deeptht.com.cn>; "ccielab"
> > > > > <ccielab@groupstudy.com>
> > > > > > Sent: Sunday, October 06, 2002 9:48 AM
> > > > > > Subject: Re: 802.1q native vlan
> > > > > >
> > > > > >
> > > > > > Any untagged frames will get tagged to the native vlan and
> travel
> > > > the
> > > > > native
> > > > > > vlan.
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "chenyan" <chenyan@deeptht.com.cn>
> > > > > > To: "ccielab" <ccielab@groupstudy.com>
> > > > > > Sent: Sunday, October 06, 2002 11:13 AM
> > > > > > Subject: 802.1q native vlan
> > > > > >
> > > > > >
> > > > > > > hi,guys
> > > > > > >
> > > > > > > I want to know why there is native vlan for 802.1q and what is
> > > > that
> > > > > for?
> > > > > > >
> > > > > > > Thanks
This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:49 GMT-3