Cisco ASA Firewall and Security Appliance Configuration -
Best Practices
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
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:
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
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 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
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
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)
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
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
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
o
spanning-tree portfast
o
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
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.
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.
! 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 hello’s 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 hello’s 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
You can now PING
and nsLookup from within Microsoft Excel - Sort IP
Addresses
Also consider
IP Tools for Excel -
Instant Productivity: IP Tools
for Excel 
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 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
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.
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
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 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
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:
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.
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
0
unreachable
3
echo
8
time-exceeded
11
Example:
! For each named interface name -
no icmp permit 0.0.0.0 0.0.0.0
dmzg02_our_applications
icmp permit 0.0.0.0 0.0.0.0 echo
dmzg02_our_applications
icmp permit 0.0.0.0 0.0.0.0 echo-reply
dmzg02_our_applications
icmp permit 0.0.0.0 0.0.0.0 unreachable
dmzg02_our_applications
icmp permit 0.0.0.0 0.0.0.0 time-exceeded
dmzg02_our_applications
icmp deny 0.0.0.0 0.0.0.0
dmzg02_our_applications
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
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.
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 verify reverse-path interface inside
ip verify reverse-path interface management
ip verify reverse-path interface outside
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
action alarm drop
ip
audit name thisnet_audit_outside_info
info
action alarm
ip
audit name thisnet_audit_inside_attack
attack action alarm
drop reset
ip
audit name thisnet_audit_inside_info
info
action alarm
ip
audit name thisnet_audit_dmz_attack
attack action alarm
drop reset
ip
audit name thisnet_audit_dmz_info
info
action alarm
ip
audit interface outside
thisnet_audit_outside_info
ip
audit interface outside
thisnet_audit_outside_attack
ip
audit interface inside
thisnet_audit_inside_info
ip audit interface inside
thisnet_audit_inside_attack
! Set per configured dmz
ip audit interface dmzXXXX
thisnet_audit_dmz_info
ip audit interface dmzXXXX
thisnet_audit_dmz_attack
! 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
! ICMP echo reply
ip
audit signature 2001 disable
! ICMP unreachable
ip
audit signature 2004 disable
! ICMP echo request
ip
audit signature 2005 disable
! ICMP time exceeded
ip audit signature 6051 disable
! 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)
|
