I would echo the points in the email below. VLANS that bridge both sides of a firewall are a disaster waiting to happen. The protocols could be abused to force packets through. Someone could break into the switch and configure it to forward some packets. A network admin may change something and not think through all the ramafications of the change. I always ask for physically seperate hardware for the external (internet side) switch. -----Original Message----- From: Ben Nagy [mailto:[EMAIL PROTECTED]] Sent: Monday, November 27, 2000 6:25 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: multiple VLANs in same physical chassis and firewall integrat ion > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 28 November 2000 4:46 > To: [EMAIL PROTECTED] > Subject: multiple VLANs in same physical chassis and firewall > integration > > > Here's an interesting network/firewall integration issue that > I am seeing > pop up in multiple areas. > > One Cisco switching chassis, a two ported firewall, and two > VLANs. One > VLAN considered untrusted, one considered trusted; X firewall > plugged into > each of these logical VLANs with untrusted interface plugged > into untrusted > VLAN port, etc. In what way is this secure? This should be an FAQ. > I am not fond > of this setup, > but can this be documented secure? Folks hereabouts aren't too fond of it either. The general consensus is that "VLANs were not intended to be a security solution - don't use them as such". > Can anyone claim to have > circumvented > the logical partitioning the VLANs provide (short of having > physical access > and moving cables or gaining administrative access to the switch and > reprogramming). OK - without just relying on rhetoric, the key points where VLANs fail are: - If the switch is overloaded, some leak traffic on all ports - If there are any trunk ports in the VLAN, some tricks are sometimes possible (there is a Bugtraq post about a trunking issue on some Cisco hardware - go look for it) - I've heard rumours that some switches can be fooled by simple manual tag spoofing (but I'd need to see that to believe it). SO. If you have two VLANs with no trunking at all and you've load tested the switch and done tag spoofing, I guess you could consider it. It will still make people itchy though. Having said that, lots of telcos are rolling out these sort of solutions for customers that want private networks - MPLS and virtual routers will make this sort of thing very attractive at the upper end and the paradigm is bound to filter down. Personally, I think it's time for us (security people) to start thinking about the possibilities of using layer-2 devices to separate networks instead of air. Just because it's been bad in the past doesn't mean that it cannot be done securely as an artchitecture. However, I do still advocate extreme caution - this is not a solution which is in line with dogma and so the consequences of a poor or ill-considered setup may be nasty if there's ever an external audit. Also note that most of the attacks against this sort of architecture involves access to layer-2 - not usually possible if you're building firewalls to protect from the Internet (although you must consider the risk of a two-stage attack). > > Looking for fodder to shoot this design spec down and > physically seperate > the security domains or for respected background on the > security of doing so. I'm not sure which of those (if any) I just provided. ;) > > bc Cheers, -- Ben Nagy Marconi Services Network Integration Specialist Mb: +61 414 411 520 PGP Key ID: 0x1A86E304 - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.] ***************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. ***************************************************************************** - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
