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.
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.
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.
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...