VLANS in a DMZ - good idea?

I like the idea also - looks like it would work well.

I have got the L3 switch setup as per my original plan and it does "look" okay - the routing is only for specific ports to specific interfaces and it is heavily locked down - no WWW interface and telnet is only allowed to be initiated from a single interface, but like I said I don't think it wise to trust a switch to keep the traffice separate.

I haven't heard of any vulns for Layer 2 VLANs in quite some time. I suspect the challenge will be at layer 3 with routing on this switch.

Reading this again, I like your design.

The mulitple DMZ NIC idea on the Firewall maybe the best way to go.

Internet -> FW1 -> NIC1 -> DMZ1 -> NIC2 -> DMZ2 -> NIC3 -> DMZ3 -> NIC4 -> FW2 -> your trusted network.

This way the Firewall controls the routing and ruleset for interDMZ communication. Not a L3/switch/router.

Using VLANS to provide logical and physical seperation in a DMZ(s) is an excellent idea as long as all the configured VLANS are at the same trust level on the switch.

If its a crisco take a look a configuring up private VLANs on each endpoint.

greg

Interesting point there Greg.

I am now thinking that as long as the switch is properly configured and the ports setup correctly there shouldn't be any issue.

I still see 100's of posts about the use of Vlans and what a bad idea it is to use them for security - either I'm missing something or they are.

Have there been any recent vulns relating to VLANs at layer 2?

There was something with Cisco and ISL like ten years ago (when their CAT5000's came out), but I haven't seen anything since.

Me either, yet one of our security analysts always touts this as a BAD idea. Yet when challenged can never site an example of a vuln. It's that kind of thinking that drives me nuts. You have a 48 port switch but can't use it because of some layer 2 VLAN risk! What risk?

There is none, its also a cheaper and far more manageable way to increase port density without resorting to the addition of 4 port nics.

L3 while preferable is not essential as long as the edge device supports dot1q.

A single gig-e trunk will put a lot less load on the firewall than say 12 Fast-Es , letting the switch do the rest.

A few years back I watched as one City bank put in 6 racks of Nokia IP-650s loaded to the gills with 4 port nics for market data feeds, all to achieve port density.

A chronic waste. A pair of 6509s properly configured & trunked into the firewalls would have achieved the same end in a single rack for a lot less money and lot less support hassle.

The most important thing is to not mix trust levels on the same switch. Logical and physical separation of trust levels is non negotiable.

Those who claim its a 'baaad' idea have to square that with the almost universal support for dot1q on name brand firewalls out there.

If Cisco felt it necessary to shoe horn in VLAN support on the Pix, one can be reasonably certain that it wasnt for vanity reasons.

greg

Havent noted anything which wasnt down to ignoring the hardening guidelines.

I've met and had the misfortune to work that type before.

He shouldnt be in a position to dictate policy if he cannot support his arguments.

As long as you dont mix trust levels, the notion of some unamed 'risk' is nonsense.

greg

: >

: >> >Have there been any recent vulns relating to VLANs at layer 2? : >> >

: >>

: >> Havent noted anything which wasnt down to ignoring the hardening : >> guidelines. : >>

: >

: >Me either, yet one of our security analysts always touts this as a BAD idea.

: I've met and had the misfortune to work that type before.

Based on past information and some previous vulnerabilities there is always going to be a theoritical possibility that some vulnerability might be discovered to breach the VLAN separation.

so, in the best of all worlds you should place each security zone on a physical separate switch.

In practical terms this is usually not a cost-effective approach. Using Vlan security and placing multiple vlans on the same switch including different zones is IMHO an acceptable risk.

I still air gap the external zones from all internal and DMZ zones. Because there is that low probability risk that a switch might be compromised I feel it is better to not introduce the possibility that a future vuln might allow external users to totally bypass the perimeter.

: >Yet when challenged can never site an example of a vuln. : >It's that kind of thinking that drives me nuts.

: He shouldnt be in a position to dictate policy if he cannot support his : arguments.

Exactly right..there is a theoritical vuln to this but to act on it in most cases without hard specific arguments of why it becomes an actual risk in the user's environment should not happen.

: >You have a 48 port switch : >but can't use it because of some layer 2 VLAN risk! What risk?

: As long as you dont mix trust levels, the notion of some unamed 'risk' is : nonsense.

Not nonsense but a risk that needs to be mentioned and then documented as to why the risk is not large enough to take action. Because this 'vulnerability' exists in the minds of so many people, especially auditors, you cannot simply hand-wave it away as nonsense. All you need to do is explain why it is a low-probability vuln and no action needs to be taken.

If a security analyst does not mention the risk, they are derelict in their job. Howver, as you have stated, to prohibit without doing an assesment of the actual risk to the organization is dumb. There is a bit too much of this type of FUD being seen and acted upon.

: greg

Richard H. Miller, MCSE, CCSE+ Information Security Manager Information Technology Security and Compliance Information Technology - Baylor College of Medicine

True.

Depends, I personally have audited installations where LAN, DMZ and Internet were plumbed into the same switch.

The design is everything, Layer 3 switches between an inner/outer firewall sandwich are ideal for implementing multiple layer DMZs.

If you're truly paranoid throw an FWSM or the non crisco equivalent into the mix.

not introduce

the perimeter.

Sensibly prudent.

No doubt. Not much point in worrying about a cam table flood via macof or whatever if you've left the environment open to such an extent that its possible to download and build such tools on a penetrated system.

A hard shell is not much use if the centre is soft and creamy. (todays mixed metaphor was brought to you by....)

Of course, but preventing a solution which is good from both a business & technical perspective purely on the basis of a risk they cannot quantify is unacceptable.

I've met a lot of security types who labour under the delusion that the business works for them and not the other way round.

Yes, having had the misfortune to deal with external 'auditors' who's knowledge of IT security extended no further than what colour pen to fill in tick boxes with.

Or have a stand up blazing row and give them a day to produce hard evidence to support their high 'risk' assessment or be told to go forth and multiply.

You'll get no argument here Richard :-).

greg