Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network

Page 1 of 10

Check the Network

by

What's my IP Address?
Your request has come from IP Address: 188.72.40.243

- HOME - ARTICLES - PRODUCTS --- VISIO DRAWINGS --- THOSE BUTTONS --- EXCEL PLUGIN --- DISK CLOCKS - CHECKOUT - CONTACT

Cisco ASA Firewall and Security Appliance Configuration - Best Practices

Network Security Compliance standards like PCI, SOX and HIPPA require accurate network documentation.

New ! IP Tools for Excel

Ping DNS Tracert SSH Telnet

Instant Ping and NsLookup For Excel

Format results your way from the GUI

Hard Disk Drive Desk Clock

High Tech Gift Only Available Here

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network

Page 2 of 10

Cisco ASA Firewall Best Practices for Firewall Deployment General

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)9

The link to the configuration file is here: Link: Cisco ASA Firewall Best Practices Configuration for Firewall Deployment 1 - Check The Network

Contents
Interfaces Types and Naming Interfaces Security Level and inter / intra interface Connections to the ASA - L2 and L3 Device Access ACS Configuration Redundant Pair / Failover Setup Routing Protocols and Static Routes Enable Traffic without NAT -- nat-control versus no nat-control Bypassing Nat when nat-control is enabled Access-List versus Inspection Rules Enabling ICMP to Firewall Interfaces Enabling ICMP through the Firewall Traceroute and Enabling Cisco IOS traceroute Reverse Route Verification

Interfaces Types and Naming

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 DMZs 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 nonVLAN 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 ASAs. The interfaces name is set with the following command: failover lan interface failover+stateful Ethernet0/3

Interface configuration example trunk on g0/2: interface GigabitEthernet0/2 speed 1000 duplex full no shutdown Interface GigabitEthernet0/2.65

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network
vlan 65 no shutdown description our applications production only nameif dmz65_our_applications security-level 55 ip address 10.30.86.33 255.255.255.240 standby 10.30.86.34 Where ASAs 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.

Page 3 of 10

Complete CCIE Training Over 80 hours of R&S CCIE Training Videos for only $299. Download Now. www.INE.com/cisco_training Network Intelligence Understand better yr telco network efficiency & prepare migration plan www.networkmining.com easyCMDB Config, Change & Incident Mgmt - Your ITIL-based ITSM Solution www.easycmdb.com

Interfaces Security Level and inter / intra interface

Higher numbers are treated as higher security, better protected, more trust. In the ASA security levels are use 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)

no

same-security-traffic permit inter-interface Disabled by default

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 DMZs. This opens other considerations. Normally, interfaces on the same security level cannot communicate without access-list entries. This command: same-security-traffic permit interinterface will allow communication between same security level interfaces additionally, without the need for accesslists. 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)

no

same-security-traffic permit intra-interface Disabled by default

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 hairpinning. 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

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.

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network
L2 additional port settings on connecting switches o o spanning-tree portfast Spanning-tree bpduguard enable

Page 4 of 10

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

SecureaccesstotheASAisimplementedviacommandsinthedefaultASAconfigurationscript.WeallowconnectionsforSSHandHTTPSforthe ASDMwebinterface.Telnetisnotallowedbutseveralcommandsmakereferencetoitbydefault.AAAisimplementedviatheACSserver.ACSand TACACS+configurationdetailsaredescribedinanexternaldocument.

Do you have time to have a look at our

Hard Disk Drive Clock?

Redundant Pair / Failover Setup

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 / activestandby 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. ! Primary Unit ! We failover in 10 seconds failover failover lan unit primary failover lan interface failover+stateful Ethernet0/3 failover link failover+stateful Ethernet0/3 failover interface ip failover+stateful 1.1.1.1 255.255.255.252 standby 1.1.1.2 failover key hex 123456789abcdef00fedcba987654321 failover polltime unit 1 holdtime 10 ! the below command specifies hellos sent every 2 seconds hold time ! is 5x polltime failover polltime interface 2 hold time 10 no failover replication http ! prompt redundant pair - primary secondary unit/active or stand/hostname prompt priority state hostname ! Secondary Unit ! We failover in 10 seconds failover failover lan unit secondary failover lan interface failover+stateful Ethernet0/3 failover link failover+stateful Ethernet0/3 failover interface ip failover+stateful 1.1.1.1 255.255.255.252 standby 1.1.1.2 failover key hex 123456789abcdef00fedcba987654321 failover polltime unit 1 holdtime 10 ! the below command specifies hellos sent every 2 seconds hold time ! is 5x polltime failover polltime interface 2 no failover replication http ! prompt redundant pair - primary secondary unit/active or stand/hostname prompt priority state hostname

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network
You can now PING and nsLookup from within Microsoft Excel Also consider IP Tools for Excel Instant Productivity: IP Tools for Excel

Page 5 of 10

Routing Protocols and Static Routes

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 ASAs 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

A feature in the ASA that can be chosen is No NAT-Control We want this command: (reference ASDM GUI location below) nat-control Default no nat-control 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.

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network

Page 6 of 10

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.

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network

Page 7 of 10

Bypassing Nat when nat-control is enabled

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. static (DMZxxx,inside) 1.2.3.0 1.2.3.0 netmask 255.255.255.0 Reference: Bypassing NAT when nat-control is enabled Throughout the firewalls configuration we will employ many of the available types of NAT as appropriate. A good discussion on Ciscos implementation of NAT in the ASA is found here: Cisco ASA NAT Implementation

Access-List versus Inspection Rules

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 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: policy-map global_policy class inspection_default inspect icmp inspect icmp error

WANT TO LEARN A LITTLE BIT MORE YOU MAY NOT HAVE KNOWN? SEE BELOW FOR NEW INFORMATION.

Cisco ASA5540-SSL2500-K9 Cisco 5540 Adaptive Security Appl. W/ 2500 Web SSL VPN Lic. $14,995 www.netechinc.net The DDOS Specialist Identify and block DDOS attacks automatically and in real time. www.riorey.com Computer Training Courses Microsoft, Cisco Networking Database Administration, CompTIA A+ www.newhorizons.com/dubai

Enabling ICMP to Firewall Interfaces

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 permit 0.0.0.0 0.0.0.0 unreachable outside icmp deny 0.0.0.0 0.0.0.0 outside ICMP configurations can be allowed as required on Inside and DMZ, but only for the accepted ICMP types echo-reply unreachable echo time-exceeded 0 3 8 11

Example: !Foreachnamedinterfacename noicmppermit0.0.0.00.0.0.0dmzg02_our_applications icmppermit0.0.0.00.0.0.0echodmzg02_our_applications icmppermit0.0.0.00.0.0.0echoreplydmzg02_our_applications icmppermit0.0.0.00.0.0.0unreachabledmzg02_our_applications

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network
icmppermit0.0.0.00.0.0.0timeexceededdmzg02_our_applications icmpdeny0.0.0.00.0.0.0dmzg02_our_applications

Page 8 of 10

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network

Page 9 of 10

Enabling ICMP through the Firewall

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: object-group icmp-type svc_ICMP_types_allowed description Security - ICMP types allowed in this network icmp-object echo icmp-object echo-reply icmp-object time-exceeded icmp-object unreachable

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

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: access-list dmz432_access_in extended permit udp object-group srvr-svc_ dmz432_network_devices any object -group svc_UDP_cisco_IOS_traceroute 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. object-group service svc_UDP_cisco_IOS_traceroute udp description Cisco IOS uses a udp traceroute starting at 33434 - we will allow 90 probes (3x30)-default udp timeout=2minutes port-object range 33434 33524 Perthisdocument,theASAisconfiguredtobeinvisibleinatracerouteandtoprovidetranslationforinsidehostsalongthetracerouteviatheservice policyinspecticmperrormechanism.

Reverse Route Verification

IPverifyreversepathguardsagainstIPspoofing(apacketusesanincorrectsourceIPaddresstoobscureitstruesource)byensuringthatallpackets haveasourceIPaddressthatmatchesthecorrectsourceinterfaceaccordingtotheroutingtable.ThebestpracticeistoTURNITON.Exceptionswill bemadewhereconnectionsareL3onlyanditisknownthattheL3deviceisalreadyperformingreversepathverificationandhasanaccurateroute tableandwearenotthedefaultroute. ipverifyreversepathinterfaceinside ipverifyreversepathinterfacemanagement ipverifyreversepathinterfaceoutside

IP Audit
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. ip audit name thisnet_audit_outside_attack attack ip audit name thisnet_audit_outside_info ip audit name thisnet_audit_inside_attack ip audit name thisnet_audit_inside_info ip audit name thisnet_audit_dmz_attack ip audit name thisnet_audit_dmz_info info attack info attack info action alarm drop action alarm action alarm drop reset action alarm action alarm drop reset action alarm

ip audit interface outside ip audit interface outside ip audit interface inside ip audit interface inside

thisnet_audit_outside_info thisnet_audit_outside_attack thisnet_audit_inside_info thisnet_audit_inside_attack

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011

Cisco ASA Firewall Best Practices for Firewall Deployment - Check The Network
! Set per configured dmz ip audit interface dmzXXXX ip audit interface dmzXXXX thisnet_audit_dmz_info thisnet_audit_dmz_attack

Page 10 of 10

! The below commands disable a few inspections we are not worried about ip audit signature 1002 disable ! Timestamp considered DOS but needed ! for RFC1323 support ip audit signature 2000 disable ip audit signature 2001 disable ip audit signature 2004 disable ip audit signature 2005 disable ip audit signature 6051 disable ! ICMP echo reply ! ICMP unreachable ! ICMP echo request ! ICMP time exceeded ! DNS zone transfer - we are likely doing ! these and do not want to drop

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. no ip audit signature 2008

(guess it means -- no ip audit signature 2008 disable)

home

products

search

checkout

sitemap

contact

Published by Productive Solutions Inc. Copyright 1996-2011 All rights reserved The Productive Solutions Logo and How well do you communicate? are Trade Marks Other company names and products may be their respective trademarks.

http://www.checkthenetwork.com/networksecurity%20Cisco%20ASA%20Firewall%20Best%20Practi... 8/9/2011