Cisco ASA Firewall Best Practices for Firewall Deployment

Cisco ASA Firewall and Security Appliance Configuration - Best Practices 

Cisco ASA Firewall Best Practices for Firewall Deployment

The document provides a baseline security reference point for those who will install, deploy and maintain Cisco ASA firewalls. It describes the hows and whys of the way things are done. It is a firewall security best practices guideline.

The document highlights best practice for firewall deployment in a secure network. Several areas and commands that affect the overall security architecture of the ASA series firewall are called out. Several of the commands are disabled by default. Several have undesired interactions that are often not noticed. Consistency is the key. There will be many Cisco ASA firewalls deployed to support the network security architecture. The desire is to obtain a consistent, effective security architecture.

Included within is a documented baseline configuration script. These are the commands and settings that will build a base line configuration in a Cisco ASA firewall. These settings also implement the best practices described herein.

The present equipment standard for firewalls is the Cisco ASA line of firewalls - Cisco model comparison chart: http://www.cisco.com/en/US/products/ps6120/prod_models_comparison.html

Throughout this document references to firewall and a set of particular attributes will be relevant to the Cisco ASA series operating firmware code version ASA 7.2(4)

---

Contents

1. Interfaces – Types and Naming
2. Interfaces – Security Level and inter / intra interface
3. Connections to the ASA - L2 and L3
4. Device Access – ACS Configuration
5. Redundant Pair / Failover Setup
6. Routing – Protocols and Static Routes
7. Enable Traffic without NAT -- nat-control versus no nat-control
8. Bypassing Nat when nat-control is enabled
9. Access-List versus Inspection Rules
10. Enabling ICMP to Firewall Interfaces
11. Enabling ICMP through the Firewall
12. Traceroute and Enabling Cisco IOS traceroute
13. Reverse Route Verification
14. IP Audit

 

Interfaces – Types and Naming (top)

When defining names use all lowercase letters, do not use - (dash) but do use _ (under bar). The following interface naming conventions are accepted for use:

• inside – Refers to the side/port of the firewall where the network is considered trusted and protected, most often a locally owned and managed network.
• outside – Refers to the side/port of the firewall that is connected to the Internet or extranet. An extranet firewall will normally be deployed in a two leg design and have not additional DMZ’s defined. An extranet net example allows limited, controlled access to remote users or a remote site, usually in a b2b (business to business) environment.
• dmzXXX_organization_purpose – Refers to the resource where access is being controlled to / from. XXX is replaced with the VLAN number of the L2 network supporting the DMZ. In the case of a non-VLAN interface xxx is replaced with the interface designator i.e. dmzg03_b2b_access. More examples: dmz986_partner1_access, dmzg02_our_applications.
• management – Refers to the management port of the ASA
• failover+stateful – Refers to the interface used in a failover pair of ASA’s.
  The interface’s name is set with the following command:

Interface configuration example trunk on g0/2:

Where ASA’s will be deployed in multiple locations supporting ACTIVE/ACTIVE or DR, the VLAN assignments should be the same at each location if possible. This will simplify the security policy assignments.

Interfaces – Security Level and inter / intra interface(top)

Higher numbers are treated as higher security, better protected, more trust. In the ASA security levels are used to determine how many of firewall functions are applied: NAT, access, inspection engines, filtering. Reference Cisco ASA Command security-level ( 7.2 ). The security policies defined here will override some of the defaults to create a more secure environment. Example: By default, there is an implicit permit from a higher security interface to a lower security interface (outbound). We use access-list rules to supersede this behavior and provide more control.
We want this command: (reference ASDM GUI location below)

Security levels to be applied:

• inside – Security 100 most trusted 
• outside – Security 0 least trusted
• dmzXXX – Security 50  organization-purpose
• dmzXXX – Security 50  organization-purpose   (No default communication between same security)
• We make a design / security choice here:
• dmzXXX – Security 60  organization-purpose
• dmzXXX – Security 70  organization-purpose   (communication possible between security levels)

Note we are using same security levels for DMZ’s. This opens other considerations. Normally, interfaces on the same security level cannot communicate without access-list entries. This command: same-security-traffic permit inter-interface will allow communication between same security level interfaces additionally, without the need for access-lists. Reference Cisco ASA Command same-security-traffic ( 7.2 ) We generally do not want this feature enabled. An example case being in a Vendor-DMZ firewall, 2 banks connected to our network on different DMZs, setting security 50 on both interfaces. If same-security-traffic permit inter-interface is enabled bank A would see bank B without access-lists, interfaces at the same security level are not required to use NAT to communicate. For security, we always want to use access lists.

We want this command: (reference ASDM GUI location below)

Best practice – Apply the keep it simple theory here.

Enabling this feature allows traffic entering an interface to exit the same interface, most useful for VPN and hair-pinning. Unless this is a VPN device, leave the hair-pinning to L3 devices. Best practice – Do not use the firewall for router functions, do not bounce traffic off of the firewall.

When the firewall has a large L2 VLAN attached and hosts are using the firewall interface as a Default route, and further it has routes to networks via the same connected interface, the firewall can allow this traffic under other correct configuration conditions (NAT and ACL). This is much like a router forwarding a packet and sending ICMP redirects.

Best practice – Avoid a difficult configuration and allows firewall log entries to reflect true meaning with reference to intra-interface.

 

 

Connections to the ASA - L2 and L3(top)

In consideration of the core network, the following connection practices are in use.

• HARD CODE Speed and duplex
• G0/0 – outside – L2 or L3 – No 802.1q
• G0/1 – inside - L3 connection on a /28 network – No 802.1q Normally connected to a L3 buffer switch such as a Cisco 4948
• G0/2 – dmz – L2 or L3 – 802.1q for scalability
• G0/3 - failover+stateful – Direct cable, no crossover
• Management Interface 0/0 – Direct to management network only if it exists.
• L2 additional port settings on connecting switches
  • spanning-tree portfast
  • Spanning-tree bpduguard enable

If there is not a dedicated security management network in place, the Management interface is not in use. The 7.2(4) code revision does not support a vrf environement. The static routing required for the management network(s) could interfere with production traffic. Management of further devices past acl ruleset could also be upset. This port can presently support a truly isolated, non routed management network.

G0/3 - failover+stateful, this is direct cabled. You may find Cisco documentation that indicates connecting via L2 switches is preferred / mandatory. This was true in Pix 6.x days but is not required / recommended now. Some of the new ASA 8.03 documentation is wrong.

Device Access – ACS Configuration(top)

Secure access to the ASA is implemented via commands in the default ASA configuration script. We allow connections for SSH and HTTPS for the ASDM web interface. Telnet is not allowed but several commands make reference to it by default. AAA is implemented via the ACS server. ACS and TACACS+ configuration details are described in an external document.

Redundant Pair / Failover Setup(top)

When building a redundant pair the host name will be the same for both units. One unit will be designated PRIMARY or PRI for short, the other SECONDARY or SEC for short. It is best to adjust the device external label or host name tag with the prefix PRI or SEC. Per Standard DNS naming conventions, a host name may be odc-asa5520-b2b. The sticky label applied to the unit would be odc-asa5520-b2b-PRI or odc-asa5520-b2b-SEC

While the pair is in operation, either the primary or secondary may be the active device. In the configuration file use the following statement: prompt priority state hostname. Normally we connect to the active device during normal maintenance and testing. The above prompt setting will result in the prompt displaying primary-secondary / active-standby status / hostname.

We have standardized the failover link on interface G0/3. It requires a network assignment and address. Since the assignment remains local to the device, network 1.1.1.0/30 has been chosen for ASA firewalls.

Stateful failover will be used but not to include http traffic. Http traffic is left out for performance reasons. Typically, http connections are very short lived and are quickly re-established if needed. We are replicating over our failover interface and must consider bandwidth utilization. HTTP replication can generate a lot of traffic.

Routing – Protocols and Static Routes (top)

The Cisco ASA supports the OSPF routing protocol while being used in single context mode.

Best practice in the environment is for a 1 time setup

Supporting improvements in static route maintenance, the ASA’s will join the OSPF routing domain at the inside firewall buffer switches. It will be a receive only neighbor, receiving internal routes. The ASA will not advertise its networks into OSPF directly.

The ASA must receive internal routes via OSPF. If new networks or locations come onto the network and require service from an ASA protected resources, the process for allowing access would simply be access-list modifications.

For added network engineering safety, consistency and security, required ASA originated routes will be static routes at the inside firewall buffer switches. A single point of administration is then defined. These routes will be filtered and redistributed into OSPF as appropriate using a route-map and ip-prefix lists.

Note the NAME tag on this sample route entry at odc-4948-fwbuff-a/b:

• ip route 192.168.90.0 255.255.255.0 10.10.11.14 Name odc-asa5540-dmz995-our_app1
• ip prefix-list allowed-static-to-ospf  permit 192.168.90.0/24

Best practice – Single point of route administration

A single point of administration allows for building the ASA firewall and injecting its required routes one time. If an additional network or service is added to the firewall later, we know how to handle and add the required route to the network and can do so in a controlled manner.

Where a firewall supports Extranet access, careful consideration must be given before injecting those foreign network numbers into route tables.

Best practice – Avoid route table additions and maintenance by the use of source address NAT. Provision and route NAT pool(s) at turn-up time.

Source address routes from Extranets should not be routed through the entire network. The ASA should NAT the source addresses to predetermined pool addresses as policy requires. The pool addresses are routed internally as built during installation or added independently as required. Often we will sacrifice event logging granularity when we NAT many to one. Choose a NAT pool for growth if possible.

We make a design / security choice here:

• NAT many to one and loose event logging granularity
• Use a Network pool and NAT one to one

Enable Traffic without NAT -- nat-control versus no nat-control(top)

A feature in the ASA that can be chosen is No NAT-Control

We want this command: (reference ASDM GUI location below)

By default, NAT control is disabled, so you do not need to perform NAT on any networks unless you choose to perform NAT

Reference:  Cisco ASA Command nat-control ( 7.2 )

NAT control requires that packets traversing from an inside interface to an outside interface match a NAT rule; for any host on the inside network to access a host on the outside network, you must configure NAT to translate the inside host address.

We will default our configurations to enforcing nat-control. In some situations it would appear that no nat-control is handy and is the way to go. There are several configuration interactions that will negate the no nat-control. For example if you are operating with no nat-control and need to add a dynamic nat or pat, the no nat-control is negated and the data flows that used to work will no longer work until you add the appropriate NATs.  

Best practice – Start with nat-control and avoid the potential of breaking existing data flows by entering a NAT command.

 

 

Once you enable any sort of dynamic NAT / PAT, 'no nat-control' rule no longer applies for that zone, now all traffic between this zone and any other zone either requires NAT rules or NAT exemption.

Bypassing Nat when nat-control is enabled (top)

When our inside hosts communicate with our protected DMZ resources we will require a NAT statement because we are enforcing NAT control. In most cases, we will actually NAT to the source IP address with the Static identity NAT command. This effectively looks like a no NAT.   

Reference: Bypassing NAT when nat-control is enabled

Throughout the firewall’s configuration we will employ many of the available types of NAT as appropriate. A good discussion on Cisco’s implementation of NAT in the ASA is found here: Cisco ASA NAT Implementation

Access-List versus Inspection Rules(top)

An access-list is a filter that will permit or deny traffic. The ASA provides application inspection services through its Modular Policy Framework. Many of the inspection engines are not enable by default. Best practice: TURN IT ON. They should be applied as required per system under a controlled environment. The HTTP inspection engine is disabled by default. Two of the basic checks of this engine ensure conformance to RFC 2616 and the use of RFC-defined methods only. Any HTTP flow not adhering to the basic checks is dropped by default. Problem is that many HTTP applications do not conform, even internal applications. We can change the action from dropped to log. We would do this when we are ready to interrogate the contents of the log for purposes of learning about our applications and applying inspection as appropriate. We will enable HTTP inspection according to our needs with policy maps.

Best practice – Enable Inspection for ICMP

If you use Excel to manage lists of IP addresses or network elements, IP Tools for Excel provides for extrodinary productivity increases.  It is our tool, try it and feel free to sugggest feature improvements to support your needs. Page in this website - IP Tools

Two inspection engines that should be enabled during installation are ICMP and ICMP Error inspection. The ICMP inspection engine allows ICMP traffic to be inspected like TCP and UDP traffic. Without the ICMP inspection engine, we recommend that you do not allow ICMP through the security appliance in an ACL. Without stateful inspection, ICMP can be used to attack your network.The ICMP inspection engine ensures that there is only one response for each request, and that the sequence number is correct. Commands to enable ICMP inspection:

Enabling ICMP to Firewall Interfaces(top)

ICMP is often found to be generously enabled. While ICMP is required, its use should be better controlled and inspected per above. With reference to firewall interfaces and not flows through the firewall, on an outside interface, ICMP ping is usually disabled so the firewall is invisible to the casual user. We do need to allow ICMP unreachable messages. They support ICMP Path MTU discovery, which is needed for IPSec and PPTP operation. These settings are not made with access lists entries; in ASDM see Configuration > Properties > Device Administration > ICMP Rules. An acceptable configuration for outside ICMP would be:

ICMP configurations can be allowed as required on Inside and DMZ, but only for the accepted ICMP types

Example:

Enabling ICMP through the Firewall (top)

Allowing ICMP flows through the firewall to protected hosts is often required and implemented via the access lists. We will not allow all ICMP message types. In the ASDM Configuration > Global Objects > Service Groups the allowed ICMP types should be defined as a service object group and where ICMP is allowed in an access-list the service object group should be selected:

Best practice for ICMP is to allow only the minimum required however there is a critical tradeoff with ease of troubleshooting. Eliminating ping is not normally a favorable option, but doing so does increase security. Although not a recommended best practice, we will see permit any any svc_ICMP_types_allowed.  

Traceroute and Enabling Cisco IOS traceroute (top)

By default you do not want most users to see traceroute through the network. We find that it is usually enabled end to end for troubleshooting purposes. At a minimum, Internet users will be denied traceroute to any. It may be desirable to enable it to selected devices.

Cisco devices use a UDP probe in their traceroute routine. Reference: Cisco Ping and Traceroute TechNote. To allow a traceroute originated from a Cisco IOS device beyond a firewall, an access list entry is required. 

Example Rule:

The recommended UDP object group allows for 90 probes, the default 3 x 30 possible hops. Since these are UDP connections, by default they will have a two minute timeout. Each time you begin a traceroute IOS starts at UDP port 33434 by default.

Per this document, the ASA is configured to be invisible in a traceroute and to provide translation for inside hosts along the traceroute via the service-policy inspect icmp-error mechanism.

Reverse Route Verification(top)

IP verify reverse-path guards against IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table. The best practice is to TURN IT ON.  Exceptions will be made where connections are L3 only and it is known that the L3 device is already performing reverse-path verification and has an accurate route table and we are not the default route.

IP Audit (top)

One of the main functions of a firewall is to protect the network from bad things. The ASA will perform basic intrusion protection even when the advanced IPS system is not installed in the system. Basic intrusion and protection must be configured and enabled. The best practice is to TURN IT ON. We create policies that are strict to start with. They will need to be tuned. The alarms will be reported via SYSLOG and can be should be interrogated on an ongoing basis. Note that on the outside interface we do not send a reset on attack. This aids in keeping us invisible.

Be sure to enable the rest of the inspection signatures per the ASA Defaults configuration script. They are disabled by default.The command looks kind of backward but DOES enable the signature identified.