[fw-wiz] "VLAN jumping" attack?
From: Scott Stursa (stursa_at_mailer.fsu.edu)
Date: 06/06/05
- Previous message: R. DuFresne: "Re: [fw-wiz] Ok, so now we have a firewall, we're safe, right?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: firewall-wizards@honor.icsalabs.com Date: Mon, 6 Jun 2005 16:01:54 -0400 (EDT)
I recently configured a PIX to treat a customer's network as a series of
discrete VLANs, each of which corresponds to functional groupings of hosts
(i.e., DMZ, desktops, internal-use-only servers, etc.) tailoring the ACLS
accordingly. I'd planned to configure the interface as a pure trunk, with
no IP address or VLAN assigned to the physical interface, and all the
VLANs assigned to logical interfaces in turn assigned to the physical
interface. I know this works, because I set up a lab implementation about
a year ago.
However, before I got started, I decided to review the PIX Config Guide,
where I found:
In the attack called "jumping VLANs" an attacker injects packets
onto other VLANs from the native VLAN. To prevent this attack,
never allow access to a native VLAN from any untrusted network.
For maximum security, we recommend avoiding the use of native
VLANs altogether when deploying VLANs in a secure environment.
It is permitted to use native VLANs with the PIX Firewall, but
you should clearly understand the security implications.
To prevent the forwarding of traffic from the PIX Firewall onto
the native VLAN of a switch, use the interface physical command
to assign a VLAN ID (other than VLAN 1) to the physical interface
of the PIX Firewall. Be careful to assign a VLAN ID that is
different from whatever VLAN ID is assigned to the native VLAN on
the switch.
So I set it up like:
interface ethernet1 vlan1702 physical
interface ethernet1 vlan376 logical
interface ethernet1 vlan377 logical
interface ethernet1 vlan1703 logical
interface ethernet1 vlan1704 logical
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif vlan376 desktops security70
nameif vlan377 DMZ security50
nameif vlan1703 lab security40
nameif vlan1704 vpn-and-dialups security20
ip address outside 128.186.x.x 255.255.255.248
ip address inside 128.186.n+1.33 255.255.255.224
ip address desktops 128.186.n.1 255.255.255.0
ip address DMZ 128.186.n+1.1 255.255.255.240
ip address lab 128.186.n+1.65 255.255.255.192
ip address vpn-and-dialups 128.186.n+1.129 255.255.255.192
The "inside" network, VLAN1702, the one assigned to the physical
interface, is the location of internal-use-only servers.
Ethernet1 attaches to a Foundry 2402 switch, wherein the "default VLAN" is
1 (apparently "default VLAN" is Foundryspeak for "native VLAN"). The
Foundry has the port defined as a "tagged" link ("trunk" in Ciscospeak).
This was working fine until about two weeks ago when users started
reporting "drop outs" and broken TCP sessions. A network engineer and I
investigated and found this was happening when one of the servers on the
inside net failed. The Foundry's reaction to this was to declare a
"Topology Change Event" and reset every port on the same VLAN. This had
the effect of killing ALL sessions going over the link to the PIX, even
those not going to the "inside" network.
The "band-aid" solution was to disable Spanning Tree Protocol for the
"inside" net VLAN (this was done on the Foundry). The problem ceased and
the users are happy[1].
The engineer wants to restore STP, and thinks he can configure the Foundry
to match the PIX's config. My reading of Foundry documentation leaves me
wondering how this would be done, and I've been trying to get back with
the guy to discuss this option further. I'm wondering if it's really
possible, and even if it theoretically is, whether the two vendor's
interpretations of the 802.1Q standard might differ enough to create more
problems than are solved.
My inclination is to apply the KISS principle and redefine the PIX to
treat the "inside" network (VLAN1702) as just another logical network,
leaving no VLAN directly assigned to the physical interface.
But this, according to Cisco, opens us up to the "VLAN jumping" attack.
So I'm trying to understand the actual risk here. Google searches turn up
the occasional oblique reference in various ITsec mailing list archives,
but I found no actual reports of these critters.
So my question is: has anyone ever actually seen one of these in the wild?
Thanks,
- SLS
[1] well, they're still complaining about not being able to use AOL or MSN
messenger.
------------------------------------------------------------------------
Scott L. Stursa 850/644-2591
Network Security Analyst stursa@mailer.fsu.edu
OTI Enterprise Security Group Florida State University
- No good deed goes unpunished -
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
- Previous message: R. DuFresne: "Re: [fw-wiz] Ok, so now we have a firewall, we're safe, right?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
