Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Firewall Wizards: RE: Cisco Private VLANs

RE: Cisco Private VLANs

From: Barry Dykes <barry_at_onesec.net>
Date: Wed, 20 Dec 2000 14:48:38 -0600

        First a little background. I tried to get Cisco to do this about 4
years back. They kept saying that they couldn't do it. Finally I got
Extreme and Foundry to do it. My intention had nothing to do with
security and this feature still has nothing to do with security! It
is marketing crap that calls it "Private/Public". Extreme calls their
Super/Sub-VLANs (and VMAN in some of their new marketing speak). An
RFC is currently in the draft zone and will be put out as an
information RFC pretty soon. However, let me explain how it really
works and what it was supposed to do. The latter first.
        It's purpose was basically for IP address conservation. Under the
normal VLAN setup you must allocate a block of IP space for each
customer. If you just give them enough to address their single
server, like a /30, then when they add another server you must either
give them another /30 or have them renumber into a /29. Now when you
consider that you are really only using 1 IP address per server and
only really need a default address to point at, you end up with many
IP address just "laying around unused or unusable".
        How it works - What the SuperVLAN (or PublicVLAN) allows you to do is
use one large IP block, with one default IP address and one network
and broadcast address. All of the other address can be given to
hosts/servers below. The SuperVLAN is basically a layer three
decision and does proxy ARP so that each device can also reach other
hosts on the same network. Read the RFC on VLAN aggregation when it
comes out or pull
http://search.ietf.org/internet-drafts/draft-mcpherson-vlan-ipagg-00.t
xt to find out more. As you can see - security must be done at the
server! The "private" (or subVLAN) is nothing more than a regular
bridge group associated with a tag (a VLAN)!

Barry

> -----Original Message-----
> From: firewall-wizards-admin_at_nfr.com
> [mailto:firewall-wizards-admin_at_nfr.com]On Behalf Of
> Zarcone, Christopher
> Sent: Wednesday, December 06, 2000 9:10 AM
> To: firewall-wizards_at_nfr.net
> Subject: [fw-wiz] Cisco Private VLANs
>
>
> Wizards,
>
> I know there have a lot of religious-war threads about the
> use of VLANs as
> security enforcement technologies. (I know firsthand
> because I started a few
> of them :-)
>
> Be that as it may, Cisco has recently introduced "Private
> VLANs" with their
> Catalyst 6000 series of switches. According to the
> whitepapers, Private
> VLANs allow you to "isolate" ports within a VLAN, such that
> they can only
> communicate with other designated ports in the VLAN (like
> the port for your
> router/default gateway). Supposedly an isolated port cannot
> communicate with
> other isolated ports (e.g. one PC can't talk to another PC,
> even though
> they're in the same VLAN). Cisco promotes the use of this
> in provider
> co-location facilities, primarily for IP address
> conservation but also for
> cross-customer security.
>
> It all sounds good in theory, but is anyone aware of any
> security issues or
> known vulnerabilities? For example, I know that with some
> of the other older
> Catalysts, you could cause frames to jump VLANs (and therefore jump
> enforcement boundaries) by creating frames with bogus 802.1q headers
> prepended. I heard Cisco corrected the problem, but it only
> makes you wonder
> what other VLAN gremlins might be lurking out there...
>
> TIA,
>
> Christopher Zarcone, CISSP
> Senior Consultant
> christopher.zarcone_at_netigy.com
>
> Netigy Corporation
> www.netigy.com
>
> My opinions do not necessarily represent the opinions of my
> employer.
>
>
>
>
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards_at_nfr.com
> http://www.nfr.com/mailman/listinfo/firewall-wizards
>
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail: firewall-wizards-unsubscribe_at_onesec.net
> For additional commands, e-mail: firewall-wizards-help_at_onesec.net
>
>

_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_nfr.com
http://www.nfr.com/mailman/listinfo/firewall-wizards
Received on Dec 21 2000

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos