FWSM deployement

emmanuel.shoroma · ‎02-09-2010

Hi,

we are planning on ussing the FWSM to protect our server farm and also secure our departments (VLANs) from each other. I just want to know what is the best approach to this comming to security levels. we have 6 departments, 1 development server farm, 1 production server farm, 2 VOIP Vlans and 1 VOIP server farm.

I understand that the security levels in the FWSM is different with the PIX or ASA in terms of explicit permit from high to low security level interfaces.

My plan is to have all the user/department is same security level, say 90 for example, have the server farms on higher security level and obviously the outside on 0. will this be best practice? if not, what is the best approach/ practice.

Regards,

Panos Kampanakis · ‎02-17-2010

Usually the more access you expect from outside to your inside the less the security level.

In other words, it depends on your set up but if the server farm would be accessible inbound from the outside but the inside users did not need to be accessible initiated from the outside I would do

outside 0

server: 50

inside 100

I hope it helps.

PK

swim_or_die · ‎02-17-2010

Greetings,

The security levels are related to the fact that in earlier versions of PIX/FWSM (6.x/2.x and earlier), you were required to translate addresses between interfaces, even if there was no NAT/PAT taking place. With nat-control disabled (default on 7.x/3.x and higher), this is not the case, and security levels are arbitrary, provided you have an access-list applied to each interface, with a deny any statement at the end of the ACL.

In the older versions, with no ACL applied, traffic inbound to a level-0 interface was denied, and traffic inbound to a level 100 interface was allowed. Any traffic from a higher-security (trusted) interface to a lower-security interface (untrusted) was allowed, and vice-versa, denied.

int inside=100

int dmz=50

int outside=0

inside to dmz=allowed

dmz to inside=denied

dmz to outside=allowed

Apologies if this is obvious...

Use the command, "show run nat-control" to verify whether nat-control is enabled.

It is feasible to make your security levels the same, provided you do not need to NAT. Thihs can eliminate the whole ASA/FWSM security level mess, as well as give you the added benefit of normalizing your syslog output, as ASA logs seem to reverse the source and destination ports for traffic initiated from an utrusted interface to a trusted interface. In this case you use your ACL's exclusively to enforce your firewall policy.

You can also NAT even when nat-control is disabled (http://www.wr-mem.com/?p=93). There are caveats (see below.)

http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/configuration/guide/intfce_f.html

Security Level Overview

Each interface must have a security level from 0 (lowest) to 100 (highest). For example, you should assign your most secure network, such as the inside host network, to level 100. While the outside network connected to the Internet can be level 0. Other networks, such as DMZs can be in between. You can assign interfaces to the same security level. See the "Allowing Communication Between Interfaces on the Same Security Level" section for more information.

The level controls the following behavior:

•Inspection engines—Some inspection engines are dependent on the security level. For same security interfaces, inspection engines apply to traffic in either direction.

–NetBIOS inspection engine—Applied only for outbound connections.

–OraServ inspection engine—If a control connection for the OraServ port exists between a pair of hosts, then only an inbound data connection is permitted through the FWSM.

•Filtering—HTTP(S) and FTP filtering applies only for outbound connections. For same security interfaces, you can filter traffic in either direction.

•NAT control—When you enable NAT control, you must configure NAT for hosts on a higher security interface (inside) when they access hosts on a lower security interface (outside).

Without NAT control, or for same security interfaces, you can choose to use NAT between any interface, or you can choose not to use NAT. Keep in mind that configuring NAT for an outside interface might require a special keyword.

•established command—This command allows return connections from a lower security host to a higher security host if there is already an established connection from the higher level host to the lower level host.

If you enable communication between same security interfaces (see the "Allowing Communication Between Interfaces on the Same Security Level" section), you can configure established commands for both directions.