cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2943
Views
6
Helpful
7
Replies

Security design: DMZ ports on internal switch - Bad idea?

m.surtees
Level 1
Level 1

Hi all,

I'm looking for convincing arguments - or being told it does not matter - to why a client of ours should not be creating DMZ vlans on an internal Cat-6509.

So the basic topology is a 6509 in a DC and 2x ASA-5510 in active/standby. They have finally agreed to start utilizing DMZs for various services but since they have no other switch at the DC they are currently happy to have these DMZ's on separate vlans on the 6509.

Is this a security risk? (They are NOT using the 6509 as an 'outside' switch so that is something I suppose)

How can the risk be mitigated?

How could their environments be compromised?

Any suggestions appreciated. Thanks in advance,

Mike

1 Accepted Solution

Accepted Solutions

I dont see a problem with this setup as long as:

1). External / DMZs are LAYER2 ONLY! Use a security device to handle all LAYER3 (Firewall, FWSM, etc...)

2). You disable proxy arp on ALL layer 3 interfaces on the switch.

3). You dont give anyone access to the switch unless they know what they are doing (understand the implications of having mixed traffic on the switch)

4). You configure a bogus vlan, make sure everyone knows what it is (put a name in it and document it), and make that the default vlan for your switchports.

5). You turn off trunk negotiation (all ports should be configured "switchport mode trunk or switchport mode access" and also "switchport nonegotiate". If you use 802.1q (or isl - ugh), explicitly define the vlans that are allowed to pass "switchport trunk allowed vlan x,y"

6). Use VTP transparent and dont trunk external vlans to other switches unless you know what you are doing.

The most important is probably #3. One misplaced layer 3 interface or SVI, and game over, you just bridged the Internet to your internal network. I can't stress enough that while this is possible, and secure if done properly, it is VERY dangerous if you dont know what you are doing. Some would consider this too high of a risk to take, and believe in physical separation to eliminate the risk. I happen to agree, however, I understand that not all of us can afford to buy multiple 6500s.

Another thing to consider, have you thought of using VRF-Lite?

View solution in original post

7 Replies 7

m.sir
Level 7
Level 7

Its not suggested to rely on VLANs as a security boundary , it's possible (although unlikely) to manipulate VLAN and bypass the VLAN boundary.

There is a nice article on it

http://blog.ioshints.info/2008/09/are-vlans-safe-in-dmz-environment.html

Good point in this article is that you are in problems if you lose switch configuration

If you really decide to go for VLAN solution there are few good advices how to improve security Don't allow dot1q on the ports. Allow native vlan only- ignore tags and use private vlans

Also you can check this documet for L2 security

http://www.ciscopress.com/articles/article.asp?p=474239&seqNum=3

M.

Hope that helps rate if it does

Hi m.sir

I still need to read the links you sent but one question: You say "Don't allow dot1q on the ports. Allow native vlan only- ignore tags and use private vlans"

Unless I've got the wrong idea this is a problem ... as the ASA only has 2 physical DMZ interfaces (other 2 = inside and outside) I need to trunk using dot1q.

As far as native vlans go just yesterday I set two trunk ports (one to each FW eth0/2) to native vlan 555; and the only vlan allowed was 555. Other vlans will be added as necessary in the future.

Trouble is the server had no connectivity until I removed the native vlan 555 and left it as vlan 1 (otherwise unused)

This is probably a switch question but I guess thats what I chasing - securing the switch as much as possible if I cannot talk the client into a couple of new switches.

I'll read through your suggsested reading tonight if I get a chance but thanks for your assistance thus far.

- Mike

Jon Marshall
Hall of Fame
Hall of Fame

Mike

I don't see a huge issue with this especially as the client has at least accepted the need for DMZ's.

Milan makes some good points and you may also want to look at this whitepaper by Cisco on vlan security -

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml

it goes into some of the more common attacks and how to mitigate against them.

The key thing IMHO is that you have good technical people and good procedures in place because if you are using vlans a slight misconfiguration can have far more consequences than if you have dedicated switches ie. it's easier to make a balls up :-)

I have worked with the FWSM (Firewall Services Module) in DC's before and this relies on the concept of using vlans within the 6500 chassis to segregate traffic and have no major issues in terms of vlan segregation.

I do agree however that i would be very reluctant if that was not an internal setup. If any part of were meant to be internet facing i would want separation, at the very least on the front-end part of the architecture.

Jon

Hi Jon,

Similar to m.sir I'll have to read through your suggested reading at a later time. I hope not too late to implement changes to what is fast becoming production environment - sort of is already, just not the DMZ infrastructure.

I guess the secret is switch config as opposed to FW, unfortunately I'm more comfortable with the latter.

Thanks again,

Mike

I dont see a problem with this setup as long as:

1). External / DMZs are LAYER2 ONLY! Use a security device to handle all LAYER3 (Firewall, FWSM, etc...)

2). You disable proxy arp on ALL layer 3 interfaces on the switch.

3). You dont give anyone access to the switch unless they know what they are doing (understand the implications of having mixed traffic on the switch)

4). You configure a bogus vlan, make sure everyone knows what it is (put a name in it and document it), and make that the default vlan for your switchports.

5). You turn off trunk negotiation (all ports should be configured "switchport mode trunk or switchport mode access" and also "switchport nonegotiate". If you use 802.1q (or isl - ugh), explicitly define the vlans that are allowed to pass "switchport trunk allowed vlan x,y"

6). Use VTP transparent and dont trunk external vlans to other switches unless you know what you are doing.

The most important is probably #3. One misplaced layer 3 interface or SVI, and game over, you just bridged the Internet to your internal network. I can't stress enough that while this is possible, and secure if done properly, it is VERY dangerous if you dont know what you are doing. Some would consider this too high of a risk to take, and believe in physical separation to eliminate the risk. I happen to agree, however, I understand that not all of us can afford to buy multiple 6500s.

Another thing to consider, have you thought of using VRF-Lite?

Thanks Mike,

I'll still try suggest new switches for the DMZ to the client - they don't need to be 6509s, just a couple of 24-port L2 jobbies.

Reason being #3 as even I am not 100% on all the options the switch provides, plus it is also managed by others and people don't always read the site-docos.

I'll start pestering the Switching forum for further info.

Regards,

Mike

Jon,

I have had a chance to read the white paper you directed me to and I like it - a very good reference. Thanks for your time on this one.

Mike

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: