Home / Cisco Security

Cisco Firewall Best Practices

Introduction
Prerequisites
Components Used
Conventions
Principles of Secure Operations
Cisco Firewalls as Security Devices
Security Policies and Configuration
Physical Security
Monitor Cisco Security Advisories and Responses
Leverage Authentication, Authorization, and Accounting.
Centralize Log Collection and Monitoring
Use Secure Protocols When Possible
Gain Traffic Visibility with NetFlow
Configuration Management
Securing the Management Plane
General Management Plane Hardening
Securing Management Sessions
Password Management
Login Password Retry Lockout
Disabling Password Recovery
Disable Unused Services
Network Time Protocol
Session Timeout
Using Management Interfaces
Memory Threshold Notifications
CPU Thresholding Notification
ICMP Packet Filtering
Securing Interactive Management Sessions
Encrypting Management Sessions
Console Port
Control Management Sessions
Control Management Sessions for Security Services Modules
Warning Banners
Using Authentication, Authorization, and Accounting.
TACACS+ Authentication
Authentication Fallback
TACACS+ Command Authorization
TACACS+ Command Accounting
Fortifying the Simple Network Management Protocol
SNMP Community Strings
SNMP MIBs
SNMP Version 3
Logging Best Practices
Send Logs to a Central Location
Logging Level
Disable Logging to Monitor Sessions and the Console
Use Buffered Logging
Configure Logging Time Stamps
Software Configuration Management
Securing the Control Plane
General Control Plane Hardening
ICMP Redirects
ICMP Unreachables
Limiting ICMP Responses
Securing Routing Protocols
Routing Protocol Authentication
Securing the Data Plane
General Data Plane Hardening
Filtering Transit Traffic with Transit ACLs
ACL Configuration Best Practices
Security Levels
Content and URL Filtering
Content Filtering
URL Filtering
Modular Policy Framework
Anti-Spoofing Protections
Unicast Reverse Path Forwarding
Antispoofing with Access Lists
Inspection
Enable Inspection for Nondefault Applications
ACLs to Block Private and Bogon Addresses
Denial of Service Protections
Threat Detection
Connection Limiting
TCP Normalizer
Botnet Protection
Limiting the CPU Impact of Data Plane Traffic
Traffic Identification and Traceback
IPv6 Traffic Filtering
High Availability Security
Best Practices Checklist
Management Plane Checks
Control Plane Checks
Data Plane Checks
Conclusion
Acknowledgments
References

Introduction
This document provides administrators and engineers guidance on securing Cisco firewall appliances, which increases the overall security of
an end-to end architecture. The functions of network devices are structured around three planes: management, control, and data. This
document is structured around security operations (best practices) and the three functional planes of a network. In addition, this document
provides an overview of each included feature and references to related documentation. For the purposes of this document, all mentions of
"Cisco firewall" refer explicitly to the Cisco ASA Adaptive Security Appliances, though the concepts may apply to other firewall and security
devices.

The three functional planes of a network each provide different functionality that needs to be protected.

Management plane: The management plane manages traffic that is sent to the Cisco firewall device and is composed of applications
and protocols such as SSH and Simple Network Management Protocol (SNMP).
Control plane: The control plane of a network device processes the traffic that is paramount to maintaining the functionality of the
network infrastructure. The control plane consists of applications and protocols between network devices, which include the interior
gateway protocols (IGPs) such as the Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF).
Data plane: The data plane forwards data through a network device. The data plane does not include traffic that is sent to the local
Cisco firewall device.

In addition to providing configuration details, this document serves primarily as a best practices guide. Therefore, security concepts will be
recommended, although the exact configuration details may not be provided. The feature will be explained in a manner that allows the security
practitioner and decision makers to determine whether the feature is required in a certain environment.

Prerequisites
Engineers and administrators should possess a conceptual understanding of Cisco firewall product software and the basic configuration
options available.

Components Used
This document addresses the capabilities of Cisco ASA versions 8.x and later. Earlier releases of Cisco ASA Software may not include all
features or capabilities outlined. Security practitioners who are using any Cisco firewall devices or ASA versions other than 8.x are advised to
consult the release notes and documentation for the respective release regarding details and supported features.

Note: Some of the features referenced in this document may refer to, or show, examples of options that use strong encryption algorithms. Not
all encryption algorithms may be available in all releases of Cisco firewall device software in all countries because of U.S. government export
regulations.

Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions. Some command line examples in this document are
wrapped to enhance readability.

Principles of Secure Operations

Secure network operations are a substantial topic. Although most of this document is devoted to the secure configuration of a Cisco firewall
device, configurations alone do not completely secure a network. The operational procedures in use on the network contribute as much to
security as the configuration of the underlying devices.

These topics contain operational recommendations that administrators and engineers are advised to implement. These topics highlight specific
critical areas of network operations and are not comprehensive.

Cisco Firewalls as Security Devices

Cisco firewalls provide advanced stateful firewall and VPN concentrator functionality in one device. In addition, some models offer an
integrated intrusion prevention system (IPS) module or an integrated content security and control (CSC) module. Cisco firewall platforms
include many advanced features, such as multiple security contexts (similar to virtualized firewalls), transparent (Layer 2) firewall, or routed
(Layer 3) firewall operation, advanced inspection engines, IP Security (IPsec) VPN, SSL VPN, and clientless SSL VPN support.
Cisco firewalls protect network segments from unauthorized access by users or miscreants while also enforcing security policies and posture.

When discussing the networks connected to a firewall, the outside network is typically defined as being in front of the firewall (an unsecured
area), while the inside network is protected (by default) and resides behind the firewall-a trusted area, and a demilitarized zone (DMZ), while
behind the firewall, allows limited access to outside (external) and inside (internal) users. Because Cisco ASA allows administrators and
engineers to configure many interfaces with varied security policies, these interface terms/names are used only in a general sense.

There are key details that establish a firewall as a firewall and not a Layer 3 forwarding device. The Cisco firewall performs numerous intrinsic
functions to ensure the security of an environment. These functions include, but are not limited to, the following:

Stateful inspection
Layer 2-7 protocol inspection (application protocol visibility)
TCP normalizer functions
Connection limits

These are key functions that differentiate a Cisco firewall from a standard Layer 3 device.

For further details see the Cisco ASA 5500 Series Configuration Guide.

Security Policies and Configuration

Security policies are the top tier of formalized security documents. These high-level documents take into account a risk assessment, and
subsequently offer general statements regarding the organization's assets and resources and the level of protection they should have.
Furthermore, security policies do not provide detailed specifics on how to accomplish the stated goals. Those details are captured in the
subsequent security standards, baselines, and procedure documents.

A security policy determines the standards and rules that an environment/organization must adhere to. This policy also dictates which
architecture solutions should be adopted for a given environment. The policy should be used as a high-level guide when pursuing firewall
configuration details, including which traffic should be permitted to pass through the firewall to access another network and which traffic should
not be permitted to pass. Cisco ASA leverages the construct of "Security Levels" to allow (or deny) the flow of traffic from one interface to
another. Each interface must have a security level assigned 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. By default, Cisco ASA allows traffic to
flow freely from a higher security level interface to a lower security level interface. For more details on Cisco ASA security levels, see
the Security Levels section of this document. Administrators and engineers can apply actions to traffic to customize and/or adjust the firewall to
adhere to stated security policies.

Note: An organization's established security policies, and not product features, should be the key factor when determining configuration
details.
For further details, see the Cisco ASA 5500 Series Configuration Guide in addition to the Resources section of this document.

Physical Security
The security of a device should begin with a progression up the Open Systems Interconnection (OSI) reference model, beginning with the
physical layer. Though obvious, the details surrounding the physical security of a device are often overlooked. Physical security, as it applies to
a firewall, refers to ensuring the device is placed in a physical location that is restricted to authorized personnel. Most often firewalls are
installed in a restricted-access room; however, many levels of personnel have access to the room. Therefore, consider establishing and using
role-based access control (RBAC). In this scenario, in addition to having the firewall placed in a restricted-access room, the firewall may also
be housed in a locking rack/sector in the restricted room.

Furthermore, environmental factors should also be verified because most Cisco firewalls have an operating temperature of 32 to 104 degrees
F (0 to 40 degrees C). For details regarding the environmental factors and statistics, refer to the product data sheets for the respective firewall
on the Cisco website.

Monitor Cisco Security Advisories and Responses

The Cisco Product Security Incident Response Team (PSIRT) creates and maintains publications, commonly referred to as PSIRT advisories,
for security-related issues in Cisco products. The method for communication of less-severe issues is the Cisco Security Response. Security
advisories and responses are available at http://www.cisco.com/go/psirt.

Additional information about these communication vehicles is available in the Cisco Security Vulnerability Policy.

To maintain a secure network, one must be aware of the Cisco advisories and responses that have been released. Moreover, one must have
knowledge of a vulnerability before evaluating the threat it can pose to a network. Refer to Risk Triage for Security Vulnerability
Announcements for assistance with this evaluation process.

Leverage Authentication, Authorization, and Accounting

The authentication, authorization, and accounting (AAA) framework is vital to securing network devices. The AAA framework provides
authentication of management sessions and can also limit users to specific, administrator-defined commands in addition to logging all
commands entered by all users. See the Leverage Authentication, Authorization, and Accounting section of this document for more information
about using AAA. Also, it is highly recommended to implement least privilege, in which every program and every user of the system should
operate using the least set of privileges necessary to complete the job.

Centralize Log Collection and Monitoring

To understand existing, emerging, and historic events related to security incidents, an organization needs a unified strategy for event logging
and correlation. This strategy must employ logging from all network devices and use prepackaged and customizable correlation capabilities.

After centralized logging is implemented, one must develop a structured approach to log analysis and incident tracking. Based on the needs of
the organization, this approach can range from a simple, diligent review of log data to advanced rule-based analysis.

See the Logging Best Practices section of this document for more information about implementing logging on Cisco firewall devices.

Use Secure Protocols When Possible

Many protocols are used to carry sensitive network management data. One must use secure protocols whenever possible. A secure protocol
choice includes using SSH instead of Telnet so that both authentication data and management information are encrypted. In addition, one must
use secure file transfer protocols when copying configuration data. An example is the use of the Secure Copy Protocol (SCP) in place of FTP
or TFTP.

See the Securing Interactive Management Sessions section of this document for more information about the secure management of Cisco
firewall devices.

Gain Traffic Visibility with NetFlow

Cisco firewalls support NetFlow version 9 services. In particular, the Cisco ASA implementation of NetFlow Secure Event Logging (NSEL) is a
stateful, IP flow tracking method that exports only records that indicate significant events in a flow. In stateful flow tracking, tracked flows go
through a series of state changes. NSEL events are used to export data about flow status and are triggered by the event that caused the state
change.

The significant events that are tracked include flow-create, flow-teardown, and flow-denied (excluding flows that are denied by EtherType
access control lists [ACLs]). Each NSEL record has an event ID and an extended event ID field, which describes the flow event.

For details regarding NSEL on Cisco firewalls, refer to the Configuring Network Secure Event Logging (NSEL) section of the Cisco ASA
Configuration Guide.

Configuration Management
Configuration management, also known as change management, is a process by which configuration changes are proposed, reviewed,
approved, and deployed. In the context of a Cisco firewall device configuration, two additional aspects of configuration management are
critical: configuration archiving and security.

One can use configuration archives to roll back changes that are made to network devices. In a security context, configuration archives can
also be used to determine which security changes were made and when these changes occurred. In conjunction with AAA log data, this
information can assist in the security auditing of network devices.

The configuration of a Cisco firewall device contains many sensitive details. Usernames, passwords, and the contents of ACLs are examples of
this type of information. The repository used to archive Cisco firewall device configurations needs to be secured. Insecure access to this
information can undermine the security of the entire network.

Securing the Management Plane

The management plane consists of functions that achieve the management goals of the network. This includes interactive management
sessions using SSH in addition to statistics gathering with SNMP or NetFlow. When considering the security of a network device, it is critical
that the management plane be protected. If a security incident can undermine the functions of the management plane, the administrator may
not be able to "recover" (stabilize) the network.

The Management Plane sections of this document provide the security features and configurations available in Cisco ASA Software that help
fortify the management plane.

General Management Plane Hardening

The purpose of the management plane is to provide the capability to access, configure, and manage a device and to monitor its operations and
the network on which it is deployed. The management plane receives and sends traffic for these functions. One must secure both the
management plane and control plane of a device because operations of the control plane directly affect operations of the management plane.
The following is a list of common protocols and tools used by the management plane:

SNMP
Telnet
SSH
FTP
TFTP
SCP
TACACS+
RADIUS
NetFlow
Network Time Protocol (NTP)
Syslog

Steps must be taken to ensure the survival of the management and control planes during security incidents. If one of these planes is
successfully exploited, all planes can be compromised. Moreover, exploitation can heavily impact the incident handling process, specifically
regarding postmortem and lessons learned.

Securing Management Sessions

Password Management

Passwords control access to resources and devices when they are required for request authentication. When a request for access to a
resource or device is received, the request is challenged for verification of the password and identity. Access can be granted, denied, or limited
based on the result. As a security best practice, passwords must be managed with a TACACS+ or RADIUS authentication server. However,
note that a locally configured password for privileged access will still be needed in the event of TACACS+ or RADIUS services failure. A device
may also have other password information present in its configuration. Examples include an NTP key, SNMP community string, and failover or
routing protocol keys.

The enable password command is used to set the password that grants privileged administrative access to the Cisco firewall system. This
command uses Message Digest 5 (MD5) for password hashing. This algorithm has had considerable public review and is not known to be
reversible. However, the algorithm is subject to dictionary attacks, in which an attacker attempts various dictionary words in addition to other
lists of candidate passwords to search for a match. For resilience against dictionary attacks, a salt value is added to the password before it is
hashed and stored. As a general precaution, configuration files must be securely stored and shared only with trusted individuals.

User passwords are also hashed using the MD5 algorithm after they have been concatenated with a salt value that provides resilience against
dictionary attacks.
Other Cisco firewall passwords (such as OSPF keys and VPN keys) are not encrypted on the firewall device by default, but the configured
passwords will not be shown in the show running-configuration command output. Any Cisco firewall configuration file that contains
passwords must be treated with care.

Beginning with Cisco ASA version 8.3, the firewall can store plaintext passwords in an encrypted format. The encryption algorithm is the
Advanced Encryption Standard (AES). The feature requires the definition of an encryption passphrase that is used to encrypt and decrypt the
keys/passwords. Keys that can be encrypted include keys for routing protocol authentication, VPN, failover, AAA servers, logging, shared
licenses, and more. Refer to Configuring the Master Passphrase section of the Cisco ASA 5500 Series Configuration Guide for further
information on the feature

Login Password Retry Lockout

The ASA allows an administrator to lock out a local user account after a configured number of unsuccessful login attempts. Once a user is
locked out, the account is locked until the administrator unlocks it. An authorized user who is configured with privilege level 15 cannot be
locked out with this feature. The number of users with privilege level 15 must be kept to a minimum.

Note that authorized users can lock themselves out of a device if the number of unsuccessful login attempts is reached. In addition, a malicious
user can create a denial of service (DoS) condition with repeated attempts to authenticate with a valid username.

This example shows how to enable the login password retry lockout feature:

!
aaa authentication telnet console LOCAL
aaa authentication ssh console LOCAL
aaa local authentication attempts max-fail 5
!
username

!
aaa authentication telnet console LOCAL
aaa authentication ssh console LOCAL
aaa local authentication attempts max-fail 5
!
username <name> password UOeJAK2TCgmxctnA encrypted
!

Refer to the Configuring AAA for Network Access section of the Cisco ASA 5500 Series Configuration Guide for more information about this
feature.

Disabling Password Recovery

The no service password-recovery feature prevents anyone with console access from insecurely accessing the device configuration and
clearing the password. It also does not allow users to change the configuration register value and access NVRAM.

!
no service password-recovery
!

Cisco firewalls provide a password recovery procedure that relies on access to ROM monitor (ROMMON) mode using the Break key during
system startup. In ROMMON mode, the device software can be reloaded to prompt a new system configuration that includes a new password.

The current password recovery procedure enables anyone with console access to access the device. The no service password-
recovery feature prevents the completion of the Break key sequence and the entering of ROMMON mode during system startup.

Caution: If no service password-recovery is enabled on a device, it is recommended that an offline copy of the device configuration be
saved and that a configuration archiving solution be implemented. If it is necessary to recover the password after this feature is enabled, the
entire configuration is deleted.

Refer to the Performing Password Recovery section of the Cisco ASA 5500 Series Configuration Guide for more information about this feature.

Disable Unused Services

Being a security device, the Cisco firewall does not run many services (for example, bootp, finger, Cisco Discovery Protocol) by default. As a
security best practice, any unnecessary services must be disabled. These unneeded services, especially those that use UDP, are infrequently
used for legitimate purposes, but can also be used to launch DoS and other attacks that are otherwise prevented by packet filtering.

Network Time Protocol

Network Time Protocol (NTP) is not an especially dangerous service, but any unneeded service can represent an attack vector. If NTP is used,
it is important to explicitly configure a trusted time source and to use proper authentication. Accurate and reliable time is required for syslog
purposes (for example, during forensic investigations of potential attacks) and for successful VPN connectivity when depending on certificates
for Phase 1 authentication.

NTP time zone: When configuring NTP, the time zone must be configured so that time stamps can be accurately correlated. There are
usually two approaches to configuring the time zone for devices in a network with a global presence. One method is to configure all
network devices with the Coordinated Universal Time (UTC) (or Greenwich Mean Time [GMT] if preferred). The other approach is to
configure network devices with the local time zone. More information on this feature is in the Setting the Date and Time section of the
Cisco ASA 5500 Series Configuration Guide.
NTP authentication: Configuring NTP authentication provides assurance that NTP messages are exchanged between trusted NTP
peers. Refer to the Setting the Date and Time Using an NTP Server section of the Cisco ASA 5500 Series Configuration Guide for more
information on configuring NTP authentication.

Session Timeout

To set the interval that the EXEC command interpreter waits for user input before it terminates a session, an administrator can use
the <protocol> timeout global configuration command. The command must be used to log out sessions (Telnet, SSH, console) that are left
idle. By default, sessions are disconnected after 5 minutes of inactivity. See the following example:

!
ssh timeout <minutes>

telnet timeout <minutes>

 console timeout <minutes>

Using Management Interfaces

The management plane of a device is accessed via in-band and out-of-band methods through physical and logical means. Ideally, both in-band
and out-of-band management access exists for each network device so that the management plane can be accessed during network outages.

Cisco firewalls define a specific interface as being the Management interface. This designation is defined by configuring the management-
only command on the specific interface. By default the physically defined Management interface has this command defined. This interface is
used for in-band access to a Cisco firewall. The Management interface can also be used for regular traffic when removing the management-
only interface configuration command. It is recommended to use the Management interface of the ASA device exclusively as a management
interface. This allows administrators and engineers to apply management traffic-based policies throughout the network. After the Management
interface is configured on a Cisco firewall, it can be used by management plane protocols, such as SSH, SNMP, and syslog. Note that the
Management interfaces on a Cisco firewall use the global routing table of the device; they do not use a separate routing table.

Memory Threshold Notifications

The Memory Threshold Notification feature, added in Cisco ASA 8.4, provides administrators and engineers with insight to mitigate low-
memory conditions on a device. This feature enables a device to generate an SNMP notification when the memory pool buffer usage reaches a
new peak.

The following example will generate the memory-threshold trap toward the SNMP server when the system memory reaches 70 percent.
Note: The default memory threshold is 70 percent.

!
snmp-server enable traps memory-threshold

snmp-server host <int-name> <host-address> community <community-string>

CPU Thresholding Notification

Introduced in Cisco ASA 8.4, the CPU threshold notification feature allows administrators and engineers to detect, and be notified, when the
CPU load on a device crosses the set threshold for a configured period of time. When the threshold is crossed, the device generates and
sends an SNMP trap message.

The following example will generate a CPU threshold trap toward the SNMP server when the CPU load is 75 percent or above for 30 minutes.

!
snmp-server enable traps cpu-threshold

snmp cpu threshold rising 75% 30

snmp-server host <int-name> <host-address> community <community-string>

Refer to the Configuring a CPU Usage Threshold section of the Cisco ASA 5500 Series Configuration Guide for more information about this
feature.

ICMP Packet Filtering

ICMP is designed as an IP control protocol. As such, the messages it conveys can have far-reaching ramifications to the TCP and IP protocols
in general. While the network troubleshooting tools ping and traceroute use ICMP, external ICMP connectivity is rarely needed for the proper
operation of a network.

Cisco firewall software provides functionality to filter ICMP messages destined to itself by name or type and code. Cisco firewalls will, by
default, allow pings to the firewalls' interfaces. The following example allows pings to a Cisco firewall interface from trusted management
stations and NMS servers and blocks all other ICMP packets that are destined to the firewall:

icmp permit host <trusted-management-stations-subnet>

<trusted-management-stations-mask> echo <interface-name>
icmp deny any <interface-name>

Securing Interactive Management Sessions

Management sessions destined to devices allow one to view and collect information about a device and its operations. If this information is
disclosed to a malicious user, the device can become the target of an attack, compromised, and used to perform additional attacks. Anyone
with privileged access to a device has the capability for full administrative control of that device. Securing management sessions is imperative
to preventing information disclosure and unauthorized access.
It is not recommended to access the security appliance through an HTTP-based GUI session. The authentication credential information, such
as the password, is sent as clear text. The HTTP server and client communication occurs only in clear text. Cisco recommends the use of
HTTPS for secure GUI-based data communication.

It is not recommended to access the security appliance through a Telnet-based command-line interface (CLI) session. The authentication
credential information, such as the password, is sent as clear text. The Telnet server and client communication occurs only in clear text. Cisco
recommends the use of SSH for secure CLI data communication.

Encrypting Management Sessions

Because information can be disclosed during an interactive management session, this traffic must be encrypted so a malicious user cannot
access the data being transmitted. Encrypting the traffic allows a secure remote access connection to the device. If the traffic for a
management session is sent over the network in clear text, an attacker can obtain sensitive information about the device and the network.

As previously stated, it is not recommended to access the security appliance through an HTTP or Telnet session because the authentication
credential information is sent in clear text. By default, a Cisco firewall will not accept Telnet to its lowest trusted interface, as defined via the
interface-configured security levels. Cisco recommends using SSH for more secure data communication. Reverse Telnet or reverse SSH is not
possible on the Cisco firewall, meaning one cannot execute a reverse Telnet or initiate an SSH connection from the Cisco firewall.

Cisco firewall software supports SSH version 1 (SSHv1), SSH version 2 (SSHv2), and HTTPS. HTTPS leverages SSL and Transport Layer
Security (TLS) for authentication and data encryption of management sessions. Note that SSHv1 and SSHv2 are not compatible.

In addition, IPsec can be used for encrypted and secure remote access connections to a Cisco firewall device, if supported, but IPsec adds
additional CPU overhead to the device. Also, SSH must still be enforced as the transport even when IPsec is used.

Cisco firewall software supports the SCP, which allows an encrypted and secure connection for copying device configurations or software
images. SCP relies on SSH.

The following example configuration enables SSH on a Cisco ASA device:

!
domain-name example.com
!
crypto key generate rsa modulus 2048
!
ssh timeout 60
ssh version 2
!

The following is a configuration example for HTTPS services:

!
crypto key generate rsa modulus 2048
!
http redirect <interface-name>
!

Refer to the Configuring Management Access section of the Cisco ASA 5500 Series Configuration Guide for more information about the Cisco
firewall software SSH feature.

Console Port

On Cisco firewall devices, the console port is an asynchronous line that can be used for local and remote access to a device. One must be
aware that the console port on Cisco firewall devices has special privileges. In particular, these privileges allow an administrator to perform the
password recovery procedure. To perform password recovery, an unauthenticated attacker would need access to the console port in addition to
the ability to interrupt power to the device or cause the device to crash and reload.

Any method used to access the console port of a device must be secured in a manner that is equal to the security that is enforced for
privileged access to a device. Methods used to secure access must include the use of AAA, console timeouts, and modem passwords if a
modem is attached to the console.

As previously mentioned, if password recovery is not required, an administrator can remove the ability to perform the password recovery
procedure using the no service password-recovery global configuration command; however, once the no service password-
recovery command has been enabled, an administrator can no longer perform password recovery on a device without losing the firewall
device configuration. For details regarding password recovery, see the Performing Password Recovery section of the Cisco ASA 5500 Series
Configuration Guide.

Control Management Sessions

Cisco firewall interactive management sessions include console, Telnet, SSH, HTTP, and HTTPS. To ensure that a device can be accessed via
a local or remote management session, proper controls must be enforced for the management protocols. Cisco firewall devices have a limited
number of available management connections; the number of sessions available can be determined by using the show resource
usage EXEC command. When all sessions are in use, new management sessions cannot be established, creating a DoS condition for access
to the device.

The simplest form of access control to a device is through authenticated management sessions. Session access controls can be enforced by
using the <ssh | telnet > <subnet> <mask> <interface name> commands.

Furthermore, authentication can be enforced through the use of AAA, which is the recommended method for authenticated access to a device.
AAA uses the local user database or theenable password in the case of Telnet and console sessions.

The <ssh | telnet | console> timeout command must be used to log out sessions that are left idle.

Refer to the Configuring Management Access section of the ASA 5500 Series Configuration Guide for details regarding management access
configuration.

Control Management Sessions for Security Services Modules

Cisco firewall devices, specifically the ASA 5505, 5510, 5520, and 5540 models, can use two types of Security Services Modules (SSMs),
which provide additional security functionality. The AIP-SSM provides intrusion detection system (IDS)/intrusion protection system (IPS)
features. The CSC-SSM operates as a content scanning and filtering module. The CSC-SSM can scan and filter HTTP, SMTP, POP3, and FTP
traffic. Note that the ASA 5505 is compatible only with the AIP-SSC-5 card. For more information about the modules discussed here, refer to
the Cisco ASA 5500 Series Adaptive Security Appliances Data Sheets.

Much like the Cisco ASA device, securing management sessions for the SSMs is imperative to prevent information disclosure and
unauthorized access. If the traffic for a management session is sent over the network in clear text, an attacker may obtain sensitive information
about the device and the network. Furthermore, an SSM should be configured to accept only encrypted and secure remote-access
management connections to the device. In addition, only authorized subnet ranges should be allowed to access these modules.

To configure management access for the AIP module, the administrator can use Adaptive Security Device Manager (ASDM), IPS Device
Manager (IDM), or the ASA command line via thesession 1 EXEC command. For the CSC-SSM, one can use the ASDM or CLI session
1 EXEC command.

Refer to the Cisco ASA 5500 Series Configuration Guide using ASDM for more information on setting up management access on the AIP-SSM
and CSC-SSM.

Warning Banners

In some legal jurisdictions it may be improbable and/or illegal to monitor and prosecute malicious users unless they have been notified that
they are not permitted to use or access a respective device or resource. One method to provide this notification is the banner message
configuration on the Cisco firewall using the banner login command.

Legal notification requirements are complex, vary by jurisdiction and situation, and should be discussed with legal counsel. Even within
jurisdictions, legal opinions can differ. In cooperation with counsel, a banner can provide the following information:

Notice that the system is to be logged into or used only by specifically authorized personnel
Notice that any unauthorized use of the system is unlawful and can be subject to civil and criminal penalties
Notice that any use of the system can be logged or monitored without further notice and that the resulting logs can be used as evidence
in court
Specific notices required by local laws

From a security point of view, a login banner should not contain any specific information about the device name, model, software, or ownership
because this information can be abused by malicious users.

Refer to the Configuring a Login Banner section of the Cisco ASA 5500 Series Configuration Guide for more information about Cisco firewall
banners.

Using Authentication, Authorization, and Accounting

The Authentication, Authorization, and Accounting (AAA) framework is critical to securing interactive access to network devices. The AAA
framework provides a highly scalable architecture consisting of flexibility and granular configuration that can be tailored to the needs of the
network.

TACACS+ Authentication

TACACS+ is an authentication protocol that Cisco firewall devices can use for authentication of management users against a remote AAA
server. These management users can access the firewall device via SSH, Telnet, HTTP, or HTTPS.

TACACS+ authentication, or more generally AAA authentication, provides the ability to use individual user accounts for each administrator or
engineer, employing the use of access controls. In removing the dependence on a single shared password, the security of the network is
improved and accountability is strengthened.

RADIUS is a protocol similar in purpose to TACACS+. However, it only encrypts the password sent across the network. In contrast, TACACS+
encrypts the entire TCP payload, including both the username and password. For this reason, TACACS+ is the preferred AAA server in Cisco
network environments. Refer to the Cisco TACACS+ and RADIUS Comparison document for a more detailed comparison of these two
protocols.

TACACS+ authentication via Telnet can be enabled on a Cisco ASA device using a configuration similar to the following:

!
aaa authentication telnet console <serv-name>
!
aaa-server <serv-name> protocol tacacs+
aaa-server <serv-name> (<interface-name>) host
<ip-address-of-tacacs-server>
key <key>
!

The previous configuration can be used as a starting point for an organization-specific AAA authentication template. Refer to the Configuring
AAA Rules for Network Access section of the Cisco ASA 5500 Series Configuration Guide for more information about the configuration of AAA.

Authentication Fallback

If the TACACS+ server becomes unavailable, a Cisco ASA device can rely on secondary authentication methods or protocols. Typical
configurations include the use of local authentication if the TACACS+ server is unavailable.

On Cisco ASA software releases that encrypt passwords for locally defined users, fallback to local authentication can be desirable. This allows
a locally defined user to be created for one or more network administrators. If TACACS+ were to become completely unavailable, each
administrator can use a local username and password. Although this approach does enhance the accountability of network administrators
during TACACS+ outages, it significantly increases the administrative burden because local user accounts on all network devices must be
maintained.

The following configuration example builds on the previous TACACS+ authentication example to include fallback authentication to the local
database:

!
aaa authentication telnet console <serv-name> LOCAL
!
aaa-server <serv-name> protocol tacacs+
aaa-server <serv-name> (<interface-name>) host
<ip-address-of-tacacs-server>
key <key>
!

Refer to the Configuring Management Access section of the Cisco ASA 5500 Series Configuration Guide for more information on the use of
fallback authentication with AAA.

TACACS+ Command Authorization

AAA command authorization using TACACS+ provides a mechanism that permits or denies each command that is entered by an administrative
user. When the user enters EXEC commands, the Cisco ASA sends each command to the configured AAA server. The AAA server then uses
its configured policies to permit or deny the command or operation for that particular user.

The following configuration can be added to the previous AAA authentication example to implement command authorization:

!
aaa authorization exec <serv-name> <serv-name>
!
aaa-server <serv-name> protocol tacacs+
aaa-server <serv-name> (<interface-name>) host
<ip-address-of-tacacs-server>
key <key>
!

Refer to the Configuring Command Authorization section of the Cisco ASA 5500 Series Configuration Guide for more information about
command authorization.

TACACS+ Command Accounting

When configured, AAA command accounting sends information about each EXEC command that is entered to the configured TACACS+
servers. The information sent to the TACACS+ server includes the command executed, the date it was executed, and the username of the user
entering the command. Command accounting is not supported using RADIUS.

The following example configuration enables AAA command accounting for EXEC commands entered at privilege levels zero, one, and 15.
This configuration builds on previous examples that include configuration of the TACACS servers.

!
aaa accounting telnet console <serv-name>
 !
aaa-server <serv-name> protocol tacacs+
aaa-server <serv-name> (<interface-name>) host
<ip-address-of-tacacs-server>
key <key>
!

Refer to Configuring Management Access Accounting for more information regarding the configuration of AAA command accounting.

Fortifying the Simple Network Management Protocol

Several methods can be used to secure the deployment of SNMP in Cisco ASA devices. It is critical that SNMP be properly secured to protect
the confidentiality, integrity, and availability of both the network data and the network devices through which this data transits. SNMP provides
one with a wealth of information on the health of network devices. This information should be protected from malicious users that want to use it
to perform attacks against the network.

SNMP Community Strings

Community strings are passwords that are applied to an ASA device to restrict access, both read-only and read-write access, to the SNMP
data on the device. These community strings, as with all passwords, should be carefully chosen to ensure they are not trivial. Community
strings should be changed at regular intervals and in accordance with network security policies. For example, the strings should be changed
when a network administrator changes roles or leaves the company.

These configuration lines configure a community string of COMM for SNMP version 1 (SNMPv1) and Community-based SNMP version 2
(SNMPv2c):

!
snmp-server community COMM
!

Note that the preceding community string examples have been chosen to clearly explain the use of these strings. For production environments,
community strings should be chosen with caution and should consist of a series of alphabetical, numerical, and nonalphanumeric symbols.
Refer to Use a Strong Password for more information on the selection of nontrivial passwords.

Refer to Configuring SNMP Version 1 or 2c for more information about this feature.

SNMP MIBs

MIBs are either standard or enterprise specific. Standard MIBs are created by the IETF and documented in various RFCs. The firewall can
support a variety of MIBs. Cisco ASA version 8.4 recently added more MIBs and traps to the wide range already supported. The administrator
decides which MIB object ID (OID) to poll and which SNMP traps to enable to monitor the uninterrupted operation of the firewall device. A
recommended minimum list of MIBs and traps to monitor that focus on device health, resources, and normal operation follows:

MIB OIDs Related Trap Explanation

CISCO-PROCESS-MIB cpmCPURisingThresholdValue cpmCPURisingThreshold CPU threshold
DISMAN-EVENT-MIB mteHotValue mteTriggerFired Memory threshold
CISCO-ENTITY-SENSOR-EXT-MIB ceSensorExtThresholdValue, ceSensorExtThresholdNotification Power supply failure,
entPhySensorValue, fan failure, CPU
entPhySensorType temperature
CISCO-L4L7MODULE-RESOURCE-LIMIT-MIB crlResourceLimitValueType, clrResourceLimitReached Connection limit
crlResourceLimitMax
IF-MIB ifIndex, ifOperStatus linkup, linkdown Interface up/down

For a list of supported MIBs and traps for the Cisco ASA and ASA Services Module by release, see the following
URL: https://www.cisco.com/c/en/us/td/docs/security/asa/asa99/configuration/general/asa-99-general-config/monitor-snmp.html#ID-2119-
0000005a

SNMP Version 3

SNMP version 3 (SNMPv3) is defined by RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, and RFC 3415 and is an interoperable
standards-based protocol for network management. SNMPv3 provides secure access to devices by authenticating and optionally encrypting
packets over the network. Where supported, SNMPv3 can be used to add another layer of security when deploying SNMP. SNMPv3 consists
of three primary configuration options:

no auth: This mode does not require authentication or encryption of SNMP packets.
auth: This mode requires authentication of the SNMP packet without encryption.
priv: This mode requires both authentication and encryption (privacy) of each SNMP packet.

The SNMPv3 implementation in the Cisco ASA and ASA Services Module differs from the SNMPv3 implementation in Cisco IOS Software. The
local-engine and remote-engine IDs are not configurable. There is no support for SNMP views. Only USM, VACM, FRAMEWORK, and
TARGET MIBs are supported. If needed, SNMP users and groups should also be removed in the correct order.

The following command configures a Cisco ASA device for SNMPv3 with an SNMP server group AUTHGROUP and enables only
authentication for this group by using the auth keyword:

!
snmp-server group AUTHGROUP v3 auth
!

The following command configures a Cisco ASA device for SNMPv3 with an SNMP server group PRIVGROUP and enables both
authentication and encryption for this group by using thepriv keyword:

!
snmp-server group PRIVGROUP v3 priv
!

The following command configures an SNMPv3 user snmpv3user1 with an MD5 authentication password
of authpassword. User snmpv3user2 has an MD5 authentication password ofauthpassword and a Triple Data Encryption Standard (3DES)
encryption password of privpassword:

!
snmp-server user snmpv3user1 AUTHGROUP v3 auth md5 authpassword
snmp-server user snmpv3user2 PRIVGROUP v3 auth md5 authpassword priv 3des privpassword
!

Note that snmp-server user configuration commands are not displayed in the configuration output of the device as required by RFC 3414;
therefore, the user password is not viewable from the configuration. The show snmp user command in the following example allows
administrators to view the configured users:

ASA# show snmp-server user

User name: snmpv3user1

Engine ID: 80000009fe7e9bd7df37970104bb641ffb45ce1eb452604350
storage-type: nonvolatile active
Authentication Protocol: MD5
Privacy Protocol: None
Group-name: AUTHGROUP

User name: snmpv3user2

Engine ID: 80000009fe7e9bd7df37970104bb641ffb45ce1eb452604350
storage-type: nonvolatile active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP

Refer to Configuring SNMP for more information about this feature.

Logging Best Practices

Event logging provides visibility into the operation of a Cisco ASA device and the network where it is deployed. Cisco ASA Software provides
several flexible logging options that can help achieve an organization's network management and visibility goals.

These sections provide some basic logging best practices that can help an administrator use logging successfully while minimizing the impact
of logging on a Cisco ASA device.

Send Logs to a Central Location

Sending logging information to a remote syslog server allows administrators to correlate and audit network and security events across network
devices more effectively. Note that, by default, syslog messages are transmitted unreliably by UDP and in clear text. For this reason, any
protections that a network provides for management traffic (for example, encryption or out-of-band access) should be applied to syslog traffic
as well.

The following configuration example configures a Cisco ASA device to send logging information to a remote syslog server:

!
logging host <ip-address>

Refer to Identifying Incidents Using Firewall and ASA Router Syslog Events for more information about log correlation.

Smart Call Home (SCH) was introduced in Cisco ASA Software version 8.2.2. It offers proactive diagnostics and real-time alerts on the Cisco
ASA and provides higher network availability and increased operational efficiency. SCH can also collect syslogs to the central portal page
hosted on Cisco's servers. Note that SCH does not serve as a syslog collecting service because certain limitations apply. However, it can
collect syslogs at higher levels (warning or error), and under certain conditions it can proactively open service requests and notify the
administrators. Refer to Configuring Smart Call Home and the Smart Call Home User Guide for more information about the SCH feature.
Logging Level

Each log message that is generated by a Cisco ASA device is assigned one of eight severity levels that range from level 0, emergency, through
level 7, debugging. Unless specifically required, it is advisable to avoid logging at level 7. This level produces an elevated CPU load on the
device that can lead to device and network instability.

The global configuration command logging trap level is used to specify which logging messages are sent to remote syslog servers. The
specified level indicates the lowest severity message that is sent. For buffered logging, the logging buffered level command is used.

The following configuration example limits log messages that are sent to remote syslog servers and the local log buffer to levels 0 (emergency)
through 6 (information):

!
logging trap 6
logging buffered 6
!

Refer to Configuring Logging for more information.

Disable Logging to Monitor Sessions and the Console

With Cisco ASA Software, it is possible to send log messages to monitor sessions and to the console. Monitor sessions are interactive
management sessions in which the EXEC commandterminal monitor has been issued. However, doing so can elevate the CPU load of a
Cisco ASA device and therefore is not recommended. Instead, administrators are advised to send logging information to the local log buffer,
which can be viewed using the show logging command.

Use the global configuration commands no logging console and no logging monitor to disable logging to the console sessions and terminal
lines. The following configuration example shows the use of these commands:

!
no logging console
no logging monitor
!

Refer to Configuring Logging for more information about global configuration commands.

Use Buffered Logging

Cisco ASA software supports the use of a local log buffer so that an administrator can view locally generated log messages. The use of
buffered logging is highly recommended versus logging to either the console or monitor sessions.

There are two configuration options that are relevant when configuring buffered logging: the logging buffer size and the message severities that
are stored in the buffer. The size of thelogging buffer is configured with the global configuration command logging buffer-size. The lowest
severity included in the buffer is configured using the logging buffered command. An administrator is able to view the contents of the logging
buffer through the show logging EXEC command.

The following configuration example includes the configuration of a logging buffer of 16,384 bytes and a severity of 6, information, indicating
that messages at levels 0 (emergency) through 6 (information) are stored:

!
logging buffer-size 16384
logging buffered 6
!

Refer to Cisco ASA Command Reference for more information about buffered logging.

Configure Logging Time Stamps

The configuration of logging time stamps helps administrators and engineers correlate events across network devices. It is important to
implement a correct and consistent logging time stamp configuration to enable correlation of logging data. Logging time stamps should be
configured to include the date and time with millisecond precision and to include the time zone in use on the device.

The following example includes the configuration of logging time stamps with millisecond precision:

!
logging timestamp
!

Software Configuration Management

Administrators are encouraged to follow standard configuration management and logging procedures that will enable configuration rollback,
configuration restoration, or misconfiguration tracking.

AAA accounting can be used to track configuration changes on a firewall. If syslogs are collected at a central location, level 5 syslog 111008
(%ASA-5-111008) will also provide a log of the commands executed on a device. In addition, if the firewall is managed through an external
management tool, it should be able to provide configuration management logs. The Cisco Security Manager platform manages firewall devices
and can provide change management and configuration change logging functionality.

Among others, the Smart Call Home feature introduced in Cisco ASA Software version 8.2.2 can provide configuration management by taking
periodic snapshots of the configuration and exporting it to the Smart Call Home portal. The configuration archive can then be used to replace or
roll back the current running configuration.

The following example will configure the Smart Call Home feature to send daily inventory and configuration updates that can later be retrieved
by accessing the Smart Call Home portal at https://tools.cisco.com/sch/. Note: This link requires login because the Smart Call Home feature is
a registered service.

!
service call-home
call-home
contact-email-addr [email protected]
profile CiscoSCH
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination transport-method http
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
!

Refer to Configuring Smart Call Home and the Smart Call Home User Guide for more information about the Smart Call Home feature.

Securing the Control Plane

Control plane functions consist of the protocols and processes that communicate between network devices to move data from source to
destination. These functions include routing protocols such as OSPF in addition to protocols such as ICMP.

It is important that events in the management and data planes do not adversely affect the control plane. If a data plane event such as a DoS
attack impacts the control plane, the entire network can become unstable. The information that follows provides features and configurations
that can help ensure the resilience of the control plane.

General Control Plane Hardening

Protection of the control plane of a network device is critical because the control plane ensures that the management and data planes are
maintained and operational. If the control plane becomes unstable during a security incident, it may not be possible for administrators and
engineers to recover the stability of the network.

ICMP Redirects

Because of the secure nature and operations of Cisco firewall platforms, the platforms do not support ICMP redirects. A Cisco firewall interface
will drop any ICMP redirects it receives.

ICMP Unreachables

Filtering with an interface access list elicits the transmission of ICMP unreachable messages back to the source of the filtered traffic.
Generating these messages can increase CPU utilization on the device. Cisco firewalls can be configured to elicit or suppress ICMP
unreachable messages. ICMP unreachables should be filtered to allow only known sources, for example those from management subnets.

The following example illustrates filtering ICMP unreachable messages to permit only messages to known sources:

!
icmp permit host 10.0.0.1 unreachable mgmt
!

To alleviate CPU utilization, ICMP unreachable messages are limited to one packet every second by default. ICMP unreachable message
generation can be disabled using the global configuration command icmp deny any unreachable <interface>. ICMP unreachable rate limiting
can be changed from the default using the icmp unreachable rate-limit rate burst-sizesize global configuration command.

For details on configuring ICMP unreachables, see icmp unreachable in the Cisco ASA 5500 Series Command Reference.

Limiting ICMP Responses

ICMP responses are often used for troubleshooting and monitoring services. Because of the secure nature and operations of Cisco firewall
platforms, ICMP responses from the firewall should be limited by filtering traffic to permit only what is necessary or expected. ICMP responses
can also be limited by disabling ICMP responses on interfaces, specifically the outside or "untrusted" interface(s) at a minimum. By default
Cisco firewalls permit ICMP traffic destined to an interface.

The following command syntax limits ICMP responses on interfaces:

!
icmp {permit|deny} ip_address net_mask [icmp_type] if_name
!
For details on configuring ICMP filtering, see icmp in the Cisco ASA 5500 Series Command Reference.

Securing Routing Protocols

Routing Protocol Authentication
To enhance security, routing updates may be authenticated using a simple password or keys depending on the routing protocol being used.
Use routing protocol authentication to prevent spoofing and routing attacks on firewalls. EIGRP route authentication provides MD5
authentication of routing updates from the EIGRP routing protocol. The MD5 keyed digest in each EIGRP packet prevents the introduction of
unauthorized or false routing messages from unapproved sources.

To enable authentication of EIGRP packets and specify the authentication key (leveraging MD5), use the authentication mode
eigrp and authentication key eigrp commands as follows:

!
authentication mode eigrp [as-num] md5
!
authentication key eigrp [as-num key] key-id [key-id]
!

To enable authentication of Routing Information Protocol (RIP) version 2 packets and specify the authentication key, use the rip
authentication mode and rip authentication keycommands as follows:

!
rip authentication mode {text | md5}
! Note: By default "text" authentication is used. We recommend the use of "MD5."
rip authentication key [key] key-id [key-id]
!

To enable authentication of OSPF packets and specify the authentication key, use the ospf authentication and ospf authentication-
key commands as follows:

!
ospf authentication [message-digest | null]
! Note: MD5 is the recommended configuration for ospf authentication,
! therefore the "message-digest" configuration option should be leveraged.
ospf authentication-key [key]
!

Securing the Data Plane

The firewall data plane handles most of the traffic that traverses the firewall. Data plane protection can prevent attacks for both the firewall and
devices to which the firewall sends traffic.

General Data Plane Hardening

Securing the control plane and management plane is essential, but all control plane and data plane traffic traverses through the data plane.
Because the data plane is responsible for processing and forwarding traffic, protecting the firewall data plane plays an important part in firewall
hardening and security.

Any activated firewall feature may affect data plane traffic, so it is important to keep the firewall software version updated to the latest stable
code that meets business requirements.
It is also important to back up all firewall rulebase and configuration files regularly on a separate, accessible location. Backups can be used
after a system failure and helps reduce total downtime.

The Adaptive Security Algorithm ensures the secure use of applications and services. Some applications require special handling in the
Adaptive Security Algorithm firewall application inspection function. These applications embed IP addressing information in the user data
packet or open secondary channels on dynamically assigned ports.

Filtering Transit Traffic with Transit ACLs

A host on one firewall interface can create any type of connection to a host on another interface of the same firewall as long as any required
address translation can be made and relevant interface access lists permit it. When address translation methods are required and after they
have been configured between pairs of firewall interfaces, the administrator must configure and apply access lists to the interfaces.

The steps required for placing an ACL on the firewall include configuring the ACL and binding it to a firewall interface. Any source and
destination address specified in the ACL is relative to any address translation that occurs on the interface where the ACL is applied.

Each permit or deny statement in the ACL is referred to as an access control entry (ACE). ACEs can classify packets by inspecting Layer 2
through Layer 4 headers for a number of parameters, including the following:

Layer 2 protocol information such as EtherTypes

Layer 3 protocol information such as ICMP, TCP, or UDP
Layer 3 header information such as source and destination IP addresses
 Layer 4 header information such as source and destination TCP or UDP ports

After an ACL has been properly configured, the administrator can apply it to an interface to filter traffic. The security appliance can filter packets
in both the inbound and outbound direction on an interface. An ACL must be applied to each lower-security interface so that specific inbound
connections are permitted. For information about security levels, refer to the Security Levels section of this document.

Note: In downloadable access lists from a RADIUS server, the per-user-override keyword can be added. This keyword allows any downloaded
ACLs to override the ACL applied to the interface; the per-user downloaded ACLs are evaluated first, before the interface ACL.

After an access list has been applied inbound/outbound on an interface, all traffic entering/exiting that interface is subject to the ACL entries,
and security-level rules defined previously are ignored. Only the first packet in the TCP or UDP flow is matched against the ACL entries. Once
the packet is allowed, the flow is created in the Adaptive Security Algorithm connection table, and all further packets in the flow are permitted
based on the connection entry, bypassing the ACL check. You can use the show conn command to view the connection table.

Note: ACLs are normally evaluated in the order in which they appear in the firewall configuration. As ACLs grow in length, the time needed to
evaluate the ACEs in sequence can also increase.

It is important to configure and use an ACL to limit the types of traffic in a specific direction. When traffic is permitted by an ACL, connections
are allowed to pass; when traffic is denied, all corresponding packets are dropped at the firewall. In addition, when an xlate entry is created for
a new connection and the interface ACLs permit the initial traffic, the return traffic specific to that connection is also permitted because the
firewall has built the proper xlate and conn entries for it.

To configure an ACL, use the following command:

access-list access_list_name [line line_number] [extended] {deny | permit}

protocol source_address mask [operator port] dest_address mask
[operator port | icmp_type] [inactive]

Note: Recompiling an ACL is a silent process, but it can burden an already loaded firewall CPU. Therefore, ACL changes should be made
when traffic through the firewall is low.

ACL Configuration Best Practices

This section lists some best practices to be followed for ACL configuration on firewalls. However, the list is not exhaustive and should serve as
a guideline for firewall hardening.

To control access to an interface, use the access-group command in interface configuration mode. This rule determines whether there any
ACLs are defined that are not applied to an interface.

The permit ip any any command is not recommended. Allowing access to all destinations provides access to all the hosts inside the
perimeter, including the firewall itself, and to all Internet hosts. Traffic should be carefully filtered to meet the organization's requirements.

The permit icmp any any command is also not recommended. It is not secure to permit all ICMP traffic on firewalls, which would allow an
attacker to exploit the network using ICMP attacks such as ping sweeps and ping floods. Traffic should be carefully filtered to meet the
organization's requirements. Also, ICMP generally requires enabling icmp inspection because the ICMP inspection engine allows ICMP traffic
to have a "session" so it can be inspected like TCP and UDP traffic. Without the ICMP inspection engine, we recommend that you do not allow
ICMP through the ASA in an access list. 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.

The best practice is to use ACLs to limit as much traffic as possible. Administrators are advised to create exact matches of host and network
addresses rather than using the generic keyword any in access lists. Specifying the exact port numbers is recommended rather than opening
all ports by not specifying anything in the ports field. Increased granularity increases security and also makes it easier to troubleshoot any
malicious behavior.

It is a best practice to have an explicit deny statement at the end and log all the denied packets. The log keyword at the end of the individual
ACL entries shows the ACL number and whether the packet was permitted or denied in addition to port-specific information. By default, logging
message 106023 (default severity level 4, warning) is generated when a deny access list entry is matched with a traffic flow. One can log
messages when specific ACEs permit or deny a traffic flow because the log keyword is added to the ACE. One can also log the rate at which
traffic flows match specific access list entries. This can be useful to gauge the volume of attacks or exploits that are occurring over time. One
can also set the logging severity level on a per-ACE basis if needed. Otherwise, severity level 6 is the default.

Note: Although all ACLs contain an implicit deny statement, Cisco recommends use of an explicit deny statement, for example, deny ip any
any. On most platforms, such statements maintain a count of the number of denied packets. This count can be displayed using the show
access-list command.

Security Levels

The ability to configure security levels is a necessary firewall feature. A security-level value from 0 through 100 defines the trustworthiness of
networks reachable through an interface. A value of 0 indicates the least trusted, and a value of 100 indicates the most trusted.

Administrators are advised to correctly configure security levels for traffic traversal before ACLs are applied. The following are the key points:
 By default, all outbound traffic from higher-security-level interfaces to lower-security-level interfaces is allowed.
By default, all inbound traffic from lower-security-level interfaces to higher-security-level interfaces is denied; to pass, this traffic needs
to be allowed in an ACL applied inbound on the lower-security-level interface.
Traffic between interfaces with the same security level is denied by default and can be allowed to pass by enabling the same security-
traffic permit inter-interface command globally on the appliance.
Traffic entering the appliance via one interface and exiting it via the same interface, known as a "U-turn," is denied by default and can
be allowed to pass by enabling the same-security-traffic permit intra-interface command globally on the appliance.

The following command configures the security level:

hostname(config)# interface <interface_name>

hostname(config-if)# security-level number

For more details regarding security levels, see the Security Levels section of the Cisco 5500 Series Configuration Guide.

Content and URL Filtering

Traditionally, firewalls filter data packets by analyzing Layer 3 and/or Layer 4 header information. Cisco firewalls can enhance this functionality
by inspecting the content information in many Layer 7 protocols such as HTTP, HTTPS, and FTP. Based on an organization's security policy,
the security appliance can either pass or drop the packets if they contain content not allowed in the network. Cisco firewalls support two types
of application layer filtering: content filtering and URL filtering.

Content Filtering

Cisco firewalls can differentiate friendly applets from untrusted applets. If a trusted website sends Java or ActiveX applets, the security
appliance can forward them to the host requesting the connection. If the applets are sent from untrusted web servers, the security appliance
can modify the content and remove the applets from the packets. This way, end users are not making decisions regarding which applet to
accept or refuse. They can download any applets without taking extra precautions.

The <OBJECT ID> and </OBJECT> HTML tags are used to insert ActiveX code into a web page. The security appliance searches for these
tags for traffic that originated on a preconfigured port. If the security appliance finds these tags, it replaces them with the comment tags <!—
and —>. When the browser receives the HTTP packets with <!— and —>, it ignores the actual content by assuming that the content contains
the author's comments.

A local content filtering server can be set up on the security appliance by using the filter command, followed by the name of the type of content
to be removed. The following shows the complete command syntax:

filter activex|java port[- port] except local_ip local_mask foreign_ip foreign_mask

URL Filtering

Cisco firewalls can delegate packet-filtering responsibilities to an external server. Administrators can define an external filtering server by using
the url-server command. For example, the complete command syntax to specify a Websense server is:

url-server (if_name) vendor websense host local_ip [ timeout

]
[protocol TCP|UDP] [connections num_conns] [version 1 |4]

To define a SmartFilter server, the command syntax is

url-server [ <(if_name) >] vendor {smartfilter | n2h2} host <local_ip>

[port <number>] [ timeout <seconds>] [protocol TCP|UDP] [connections num_conns] ]

Note: Users may experience longer access times if the response from the filtering server is slow or delayed. This may happen if the filtering
server is located at a remote location and the WAN link is slow. In addition, slow response times may also result if the URL server cannot keep
up with the number of requests being sent to it.

The url-server command does not verify whether a Websense or SmartFilter server is reachable from the security appliance. You can specify
up to 16 filtering servers for redundancy. If the security appliance is not able to reach the first server in the list, it tries the second server from
the list, and so on. In addition, Cisco ASA does not allow both SmartFilter and Websense servers to be defined at the same time. One must be
deleted before the other is set up.

Modular Policy Framework

Firewall software offers an adaptable and scalable modular policy framework. For traffic flows traversing the firewall, flow-based policies can be
established for any administratively defined criteria and then applied to a set of security services, such as firewall policies, inspection engine
policies, quality of service (QoS) policies, and VPN policies, with each specified traffic flow providing more granular and flexible inspection
control.
The Modular Policy Framework (MPF) is supported with these features:

TCP and general connection settings

Protocol inspection services
Intrusion prevention services
QoS services
Policing (rate limiting)

The configuration of the MPF consists of four tasks:

Identify the Layer 3 and Layer 4 traffic to which you want to apply actions. Refer to Identifying Traffic Using a Layer 3/4 Class Map for
more information.
(Application inspection only.) Define special actions for application inspection traffic. Refer to Configuring Special Actions for Application
Inspections for more information.
Apply actions to the Layer 3 and Layer 4 traffic. Refer to Defining Actions Using a Layer 3/4 Policy Map for more information.
Activate the actions on an interface. Refer to Applying a Layer 3/4 Policy to an Interface Using a Service Policy for more information.

Anti-Spoofing Protections
IP spoofing occurs when a potential intruder copies or falsifies a trusted source IP address. This is typically employed as an auxiliary technique
for countless types of network-based attacks.

Cisco firewalls contain several features to enhance the ability of the network to defend itself. Antispoofing is one such feature, which helps to
protect an interface of the ASA by verifying that the source of network traffic is valid. This section discusses some antispoofing features.

Unicast Reverse Path Forwarding

Network administrators can use Unicast Reverse Path Forwarding (uRPF) to help limit malicious traffic on a network. This security feature
works by enabling a router to verify the reachability of the source address in packets being forwarded. This capability can limit the appearance
of spoofed addresses on a network. If the source IP address is not valid, the packet is discarded.

uRPF guards against IP spoofing by ensuring that all packets have a source IP address that matches the correct source interface according to
the routing table.

Normally, the security appliance examines only the destination address when determining where to forward the packet. uRPF instructs the
security appliance to look also at the source address. For any traffic to be allowed through the security appliance, the security appliance routing
table must include a route back to the source address. See RFC 2267 for more information.

To enable uRPF, enter this command:

hostname(config)#ip verify reverse-path interface interface_name

uRPF works in two different modes: strict mode and loose mode. When administrators use uRPF in strict mode, the packet must be received
on the interface that the security device would use to forward the return packet. uRPF in strict mode may drop legitimate traffic that is received
on an interface that was not the firewall's choice for sending return traffic. Dropping this legitimate traffic could occur when asymmetric routing
paths exist in the network.

When administrators use uRPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior
using the allow-default option, which allows the use of the default route in the source verification process. In addition, a packet that contains a
source address for which the return route points to the Null 0 interface will be dropped. An access list may also be specified that permits or
denies certain source addresses in uRPF loose mode.

Care must be taken to ensure that the appropriate uRPF mode (loose or strict) is configured during the deployment of this feature because it
can drop legitimate traffic. Although asymmetric traffic flows may be a concern when deploying this feature, uRPF loose mode is a scalable
option for networks that contain asymmetric routing paths.

Antispoofing with Access Lists

RFC 2827 (BCP 38) describes uses of access lists as a current best practice to defeat IP source address spoofing. This RFC is a widespread
resource, particularly for the Internet edge, because in such an environment the boundary between private and public addresses (in the sense
of RFC 1918) is clearly demarcated.

It is usually appropriate for an antispoofing access list to filter out all ICMP redirects regardless of source or destination address. These are just
basic guidelines and can be further fine tuned with other filtering such as anti-bogon, which filters traffic that claims to be sourced from
reserved addresses or from an IPv4 block that has yet to be allocated by the Internet Assigned Numbers Authority (IANA). In general,
antispoofing filters are best deployed as input access lists; that is, packets must be filtered at the arriving interfaces, not at the interfaces
through which they exit. The input access list also protects the firewall itself from spoofing attacks, whereas an output list protects only devices
behind the firewall.

Inspection
Cisco ASA supports application inspection through the Adaptive Security Algorithm function. Through the stateful application inspection used
by the Adaptive Security Algorithm, the Cisco ASA tracks each connection that traverses the firewall and ensures that it is valid. The firewall,
through stateful inspection, also monitors the state of the connection to compile information to place in a state table. With the use of the state
table in addition to administrator-defined rules, filtering decisions are based on context that is established by packets previously passed
through the firewall. The implementation of application inspections consists of these actions:

Identify the traffic

Apply inspections to the traffic
Activate inspections on an interface

By default, the configuration includes a policy that matches all default application inspection traffic and applies certain inspections to the traffic
on all interfaces (a global policy). Not all inspections are enabled by default. Only one global policy can be applied. If it is necessary to alter the
global policy, one must either edit the default policy or disable it and apply a new one. (An interface policy overrides the global policy.)

The default policy configuration includes these commands:

class-map inspection_default

match default-inspection-traffic

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

service-policy global_policy global

To disable global inspection for an application, use the no version of the inspect command.

Enable Inspection for Nondefault Applications

Enhanced HTTP inspection is disabled by default. To enable HTTP application inspection or change the ports on which the security appliance
listens, use the inspect http command in class configuration mode.

Class configuration mode is accessible from policy map configuration mode. To remove the configuration, use the no form of this command.
When used in conjunction with the http-mapargument, the inspect http command protects against specific attacks and other threats that may
be associated with HTTP traffic. Two of the basic checks of this engine ensure conformance to RFC 2616 and the use of RFC-defined methods
only. Any HTTP flow that does not adhere to the basic checks is dropped by default. Many HTTP applications, even internal applications, do
not conform. The action can be changed from dropped to logged, if required.

For more information on using the http-map argument with the inspect http command, refer to the HTTP Inspection section of the Cisco ASA
5500 Configuration Guide.
Note: The error message appears as shown when double encoding is used in some URLs. If access to this type of website is necessary,
administrators can disable strict HTTP inspection.

"%PIX-4-415012:15 HTTP Deobfuscation signature detected - Reset HTTP

 deobfuscation detected IDS evasion technique from x.x.x.x to y.y.y.y

For an FTP and TFTP filtering example,

see http://www.cisco.com/en/US/partner/products/ps6120/products_configuration_example09186a00807ee585.shtml.

To remove global inspection for the FTP application to which the Cisco ASA listens, administrators are advised to use the no inspect
ftp command in class configuration mode.

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 in the same way as TCP and UDP traffic. Without the ICMP inspection engine, it is recommended not to allow
ICMP through the Cisco ASA in an ACL. Without stateful inspection, ICMP can be used to attack a 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
follow:

policy-map global_policy

class inspection_default

inspect icmp

inspect icmp error

For more details regarding ICMP inspection, see the ICMP Inspection section of the Cisco ASA 5500 Series Configuration Guide.

ACLs to Block Private and Bogon Addresses

Unallocated IP addresses, IP addresses for private internets as mentioned in RFC 1918, and special use IP addresses as mentioned in RFC
3330 can be a problem when they are used to route packets on the Internet. These addresses can be used to source attacks that could make it
difficult or impossible to trace back to the source. Filtering these addresses at your network boundary will provide another layer of security. The
official list of unallocated bogon Internet addresses is maintained by Team Cymru. They also maintain a page dedicated to filtering these bogon
addresses at The Bogon Reference.

Denial of Service Protections

Antispoofing will ensure that DoS attacks are not launched from inside the network. Administrators are advised to follow this procedure to
enable antispoofing on the inside interface to ensure DoS attacks are not inadvertently being launched from the inside the security appliance.

Step 1: Identify the traffic to apply connection limits using a class map

ASA(config)# access list CONNS-ACL extended permit ip any 10.1.1.1 255.255.255.255

ASA(config)# class-map CONNS-MAP
ASA(config-cmap)# match access-list CONNS-ACL

Step 2: Add a policy map to set the actions to take on the class map traffic

ASA(config)# policy-map CONNS-POLICY

ASA(config-pmap)# class CONNS-MAP
! The following sets connection number limits
ASA(config-pmap-c)# set connection {[conn-max n] [embryonic-conn-max n]
[per-client-embryonic-max n] [per-client-max n] [random-sequence-number {enable | disable}]}

Threat Detection

Cisco ASA supports the threat detection feature in software versions 8.0 and later. Using basic threat detection, the security appliance monitors
the rate of dropped packets and security events caused by the following:

Denial by access lists.

Bad packet format, such as invalid-ip-header or invalid-tcp-hdr-length).
Connection limits exceeded, both system-wide resource limits and limits set in the configuration.
DoS attack detected, such as an invalid stateful packet inspection or stateful firewall check failure.
Basic firewall checks failed. This option is a combined rate that includes all firewall-related packet drops in this bulleted list. It does not
include non-firewall-related drops such as interface overload, packets failed at application inspection, and scanning attack detected.
Suspicious ICMP packets detected.
Packets failed application inspection.
Interface overload.
Scanning attack detected. This option monitors scanning attacks; for example, the first TCP packet is not a SYN packet or the TCP
connection failed the three-way handshake. Full scanning threat detection takes this scanning attack rate information and acts on it by
classifying hosts as attackers and automatically shunning them, for example. Refer to Configuring Scanning Threat Detection for more
information.
Incomplete session detection, such as TCP SYN attack detected or no-data UDP session attack detected.

The types of commands are as follows:

Embryonic (half-opened) connection: An embryonic connection is a TCP connection request that has not finished the necessary
 handshake between source and destination.
Half-closed connection: A half closed connection is when the connection is closed only in one direction by sending FIN. However, the
TCP session is still maintained by the peer.
per-client-embryonic-max: This command sets the maximum number of simultaneous embryonic connections allowed per client, from
0 through 65535. The default is 0, which allows unlimited connections.
per-client-max: This command sets the maximum number of simultaneous connections allowed per client, from 0 through 65535. The
default is 0, which allows unlimited connections.

The show threat-detection rate command is used to identify potential attacks when the administrator is logged in to the security appliance.

ciscoasa#show threat-detection rate

Average(eps) Current(eps) Trigger Total events

10-min ACL drop: 0 0 0 16

1-hour ACL drop: 0 0 0 112

1-hour SYN attck: 5 0 2 21438

10-min Scanning: 0 0 29 193

1-hour Scanning: 106 0 10 384776

1-hour Bad pkts: 76 0 2 274690

10-min Firewall: 0 0 3 22

1-hour Firewall: 76 0 2 274844

10-min DoS attck: 0 0 0 6

1-hour DoS attck: 0 0 0 42

10-min Interface: 0 0 0 204

1-hour Interface: 88 0 0 318225

Refer to the Configuring Basic Threat Detection section of the Cisco ASA 5500 Series Configuration Guide for more information on the
configuration. When the security appliance detects a threat, it immediately sends a system log message (730100).

Note: Basic threat detection affects performance only when there are drops or potential threats.

Connection Limiting

If the embryonic connection limit is reached, the security appliance responds to every SYN packet sent to the server with a SYN+ACK and
does not pass the SYN packet to the internal server. If the external device responds with an ACK packet, the security appliance knows it is a
valid request (and not part of a potential SYN attack). The security appliance then establishes a connection with the server and joins the
connections together. If the security appliance does not get an ACK back from the server, it aggressively times out that embryonic connection.

Other options are to configure maximum connections, maximum embryonic connections, and TCP sequence randomization in the NAT
configuration. If these settings are configured for the same traffic using both methods, the security appliance uses the lower limit. If TCP
sequence randomization is disabled, the security appliance disables TCP sequence randomization.

To set the maximum connections (both TCP and UDP), maximum embryonic connections, per-client-embryonic-max, or per-client-max, or to
indicate whether to disable TCP sequence randomization, administrators can enter this command:

hostname(config-pmap-c)#set connection {[conn-max number] [embryonic-conn-max number]

[per-client-embryonic-max number] [per-client-max number][random-sequence-number
{enable | disable}}

Recall that the per-client-max and per-client-embryonic-max is an integer from 0 through 65535 and the default is 0, which means no limit
on connections.

Administrators can enter this command all on one line (in any order) or enter each attribute as a separate command. The command is
combined on one line in the running configuration. To set the timeout for connections, embryonic connections (half-opened), and half-closed
connections, administrators can enter this command:

hostname(config-pmap-c)#set connection {[embryonic hh[:mm[:ss]]]

[half-closed hh[:mm[:ss]]] [tcp hh[:mm[:ss]]]}

The embryonic hh[:mm[:ss] is a time from 0:0:5 through 1193:0:0. The default is 0:0:30. Administrators can also set this value to 0, which
means the connection never times out.

The half-closed hh[:mm[:ss] and tcp hh[:mm[:ss] values are a time from 0:5:0 through 1193:0:0. The default for half-closed is 0:10:0 and the
default for tcp is 1:0:0. These values can also be set to 0, which means the connection never times out.

TCP Normalizer

TCP normalization is a Layer 4 feature that consists of a series of checks that the firewall application performs at various stages of a flow, from
initial connection setup to the closing of a connection. Many of the segment checks can be controlled by configuring one or more advanced
TCP connection settings. The firewall application uses these TCP connection settings to decide which checks to perform and whether to
discard a TCP segment based on the results of the checks. The firewall application discards segments that appear to be abnormal or
malformed.

This feature also checks for segments that have invalid or suspect conditions (for example, a SYN sent to the client from the server or a
SYNACK sent to the server from the client) and takes appropriate actions based on the configured parameter settings. The firewall application
uses TCP normalization to block certain types of network attacks (for example, insertionattacks and evasion attacks). Insertion attacks devise a
scheme so that the inspection module accepts a packet that the end system rejects. Evasion attacks devise a scheme such that the inspection
module rejects a packet while the end system accepts it.

For more details regarding the TCP Normalizer feature, see the TCP Normalization section of the Cisco ASA 5500 Series Configuration Guide.
The firewall application always discards segments when the following conditions exist:

Bad segment checksum

Bad TCP header or payload length
Suspect TCP flags (for example, NULL, SYN/FIN, or FIN/URG)

The TCP normalization feature identifies abnormal packets that the Cisco ASA can act on when they are detected; for example, the adaptive
security appliance can allow, drop, or clear the packets. TCP normalization helps protect the Cisco ASA from attacks. TCP normalization is
always enabled, but administrators can customize how some features behave.

The TCP normalizer includes nonconfigurable actions and configurable actions. Typically, nonconfigurable actions that drop or clear
connections apply to packets that are always bad. Configurable actions may need to be customized depending on network needs.

See the following guidelines for TCP normalization:

The normalizer does not protect from SYN floods. Cisco ASA includes SYN flood protection in other ways.
The normalizer always sees the SYN packet as the first packet in a flow unless Cisco ASA is in loose mode because of failover.

This feature uses the Modular Policy Framework so that customizing TCP normalization consists of identifying traffic, specifying the TCP
normalization actions, and activating TCP normalization customization on an interface. See the Configuring a Service Policy Using the Modular
Policy Framework section of the Cisco ASA 5500 Series Configuration Guide. for more information.

Botnet Protection

A Botnet is a collection of autonomous software robots (bots), typically malicious in nature, that operate as a network of compromised
computers. An originator, also known as a "bot herder," typically controls the bots and can launch them at will using command-and-control
communication between the controller and the bots. Botnets have proven to be a malicious adversary to today's network environment and
therefore must be curtailed with proper defense mechanisms.

Cisco ASA 5500 Series Adaptive Security Appliances provide reputation-based control for an IP address or domain name. The Cisco ASA
Botnet Traffic Filter is integrated into all Cisco ASA appliances and inspects traffic traversing the appliance to detect rogue traffic in the network.
When internal clients are infected with malware and attempt to phone home across the network, the Botnet Traffic Filter alerts the system
administrator of these attempts though the regular logging process for manual intervention. This is an effective way to combat botnets and
other malware that shares the same phone-home communications pattern.

The Botnet Traffic Filter feature does not automatically block botnet-related traffic. An administrator must manually configure ACLs to block
malicious traffic.

The Botnet Traffic Filter monitors all ports and performs a real-time lookup in its database of known botnet IP addresses and domain names.
Based on this investigation, the Botnet Traffic Filter will determine whether a connection attempt is benign and should be allowed or whether it
is a risk and should be tagged for mitigation.

When the Botnet Traffic Filter feature is enabled, the Cisco ASA compares DNS A-records and CNAME records against the domain names in
the database. This process is known as DNS snooping and is integrated with the current DNS inspection available on the ASA. When DNS
snooping is enabled, the Cisco ASA builds a DNS reverse cache (DNSRC) for all the DNS replies received on interfaces where DNS snooping
is enabled.

For a comprehensive understanding and more details regarding Botnet mitigation leveraging the Botnet Traffic Filter option of the Cisco ASA,
see Combating Botnets Using the Cisco ASA Botnet Traffic Filter.

Limiting the CPU Impact of Data Plane Traffic

It is key to understand the CPU impacts of the firewall. To achieve this, administrators must keep track of the health and stats of the firewall. It
is important to note that sustained CPU spikes, that is, typically 80 percent or above, while passing "normal" traffic events requires a call to
action and further design and scaling considerations. In addition, special consideration should be given in the occurrence of multiple context
firewalls. In the case of multiple context firewalls, the performance (CPU) impacts of the firewall must be managed holistically (across all
contexts). Use the show cpu usage context all command to view the CPU resources of all configured contexts of the firewall.

To see the entire list of active firewall processes, administrators can use the show processes command. The primary available information
follows:

Process: Displays a descriptive name for the process, such as update_cpu_usage, that computes the values for the show cpu
usage command
Runtime: Lists the actual amount of time the CPU has spent on each process, in milliseconds. The runtime values begin at 0 when the
firewall is first booted and accumulate until it is powered down or reloaded.

As a rule of thumb, the CPU utilization should stay below an average of 80 percent. The utilization may spike or temporarily peak at a greater
value, as often seen in the outputs of the 5-second utilization field of the show cpu usage output. This is normal behavior because the CPU
could be processing a periodic task or a short burst of traffic.

Note that firewall logging and alerts should be enabled only when required because these functions impact the processor cycles and may lead
to a degradation in firewall performance. It is also important to run features on the firewall only when absolutely necessary. Each application
affects CPU cycles and therefore the throughput of the network.

Limit the number of applications that run on the firewall to maximize CPU cycles and network throughput.

Traffic Identification and Traceback

There are many ways to set up the appliance for packet filtering. The most common methods are as follows:

Through traffic filtering using the CLI

Note: This method uses ACL configurations for traffic filtering through the box. For more details, see the About Access Lists and Configuring
Access Rules sections of the Cisco ASA 5500 Series Configuration Guide.

Through traffic filtering using ASDM

Note: This method also uses ACL configurations for traffic filtering through the box. For more details, see the Adding ACLs and ACEs section
of the Cisco ASA 500 Series Configuration Guide using ASDM.

To-the-box traffic filtering

Note: To-the-box traffic filtering most often applies to management plane traffic. For more details, see the Configuring Management Access
section of the Cisco ASA 5500 Series Configuration Guide.

IP version 6 (IPv6) traffic filtering

Due to the unique nature of IPv6 filtering, this method will be discussed at length below.

IPv6 Traffic Filtering

If IPv6 traffic is used in the network, an IPv6 ACL can be configured if desired to control the traffic passing through the security appliance. The
IPv6 ACL can be defined by using the ipv6 access-list command followed by the name of the ACL. Like an extended ACL, the IPv6 ACL uses
similar command options, as shown in the following syntax:

ipv6 access-list id [line line-num] {deny | permit} {protocol |

object-group protocol_obj_grp_id} {source-ipv6-prefix/prefix-length | any |
host source-ipv6address | object-group network_obj_grp_id}
[operator {port [ port] | object-group service_obj_grp_id}]
{destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address |
object-group network_obj_grp_id} [log [ [level] [interval secs] |
disable | default]]

For more details regarding IPv6 traffic filtering, see the Adding an IPv6 Access List section of the Cisco ASA 5500 Series Configuration Guide.

High Availability Security

The firewall offers a failover function that provides a safeguard mechanism in the event of a unit failure. When one unit fails, another
immediately takes its place. The Security Appliance supports the following two types of failover setup. Both failover modes support stateful or
stateless failover.

Active/Standby Failover Mode: In this mode, only one unit (the primary, also called the Active unit) passes traffic, whereas the other
unit is in a standby state. The Active/Standby failover is available in both single and multiple context modes. For more details, see
the Information About High Availability section of the Cisco ASA 5500 Series Configuration Guide.
Active/Active Failover Mode: In this mode, either the primary or secondary may be the active device. The normal procedure is to
connect to the active device during normal maintenance and testing. For more details, see the Information About High Availability
section of the Cisco ASA 5500 Series Configuration Guide.
High availability (HA) solutions should also be secured. As all information between the two firewalls in an HA configuration is sent (in clear text)
over the failover/stateful failover link(s), the key to securing the Cisco firewall HA solution is to secure the communication with a failover key.
Note specifically if the ASA is used to terminate VPN tunnels, unless using a failover key, the following information is sent in the clear: any
usernames, passwords, and preshared keys used for establishing the tunnels. As stated in the Cisco ASA 5500 Configuration Guide,
"Transmitting this sensitive data in clear text could pose a significant security risk. We recommend securing the failover communication with a
failover key if you are using the ASA to terminate VPN tunnels." For more details on High Availability configurations, see the Information About
High Availability section of the Cisco ASA 5500 Series Configuration Guide.

Best Practices Checklist

Management Plane Checks

Disable Console Logging - Firewall

Requirement Severity Comments

Disable Console Low Best practice: Ensure console logging is disabled or set to critical. Although useful for troubleshooting from the
Logging console port, it is possible that excessive log messages on the console could make it impossible to manage the
device, even from the console.
Command:
no logging console
- or -
logging console critical

Enable Logging - Firewall

Requirement Severity Comments

Info
Enable Logging Best practice: Check if state of event logging on the firewall is enabled. Logging a firewall's activities and status
offers several benefits. Using the information in a log, the administrator can tell whether the firewall is working
properly or whether it has been compromised. In some cases, it can show what types of probes or attacks are
being attempted against the firewall or the protected network. If the logging is disabled, the events that happen on
the firewall are not logged anywhere. This may make it harder to troubleshoot any network issues. This may also
cause some of the problems, including attempted attacks, to go unnoticed, as well as prevent collection of
evidence about any unauthorized activity. If logging is enabled, ensure the logging messages are sent to only
trusted hosts on a protected network so the logs cannot be compromised and cannot be viewed by anyone who
is not authorized to view them.
Command:
logging on | logging enable

Low
Enable Logging Best practice: Timestamps should be enabled for log messages, which will facilitate interpretation of the
Timestamp messages for troubleshooting and investigating network attacks. Ensure that the date/time is correctly set (if NTP
is not configured) so that the timestamps provide the proper day/time of the log messages. If the timestamps are
not shown in the log messages, it may not be possible to sense the order of events occurring in the network.
Command:
logging timestamp

Low
Enable Logging to Best practice: Cisco devices can store log messages in memory. The buffered data is available only from an
Buffer exec or enabled exec session, and it is cleared when the device reboots. This form of logging is useful, even
though it does not offer enough long-term protection for the logs. Buffered logging keeps the log messages in
RAM on the device. A logging buffer must be configured on the device, and this buffer is circular, meaning that
when it fills up, the oldest log message is deleted to make room for the new message. If buffer logging is not
enabled, it will not be possible to view the most recent log messages on the device for troubleshooting or
monitoring purposes.
Command:
logging buffered <level>

Info
Log Messages to a Best practice: Cisco devices can be configured to forward log messages to an external Syslog service. It is
Syslog Server highly recommended that networks implement a logging structure based on a Syslog infrastructure. Proactive
monitoring of firewall logs is an integral part of Security Admin duties. The firewall syslogs are useful for
forensics, network troubleshooting, security evaluation, worm and virus attack mitigation, and so on. This is a
scalable solution, which provides long-term storage capabilities and a central location for all device messages
Command:
logging host <interface-name> <ipAddress>
Secure Device Access - Firewall

Requirement Severity Comments

Info
Restrict HTTP Best practice: To specify hosts that can access the HTTP server internal to the FWSM. The addresses allowed
Access to Certain to access the firewall using HTTP can be restricted. Any undefined IP address will not see the prompt at all.
Addresses Command:
http <ip-address> <net-mask> <interface name>

Medium
Restrict SSH Access Best practice: The addresses allowed to access the firewall using SSH can be restricted. Any undefined IP
to Certain Addresses address will not see the prompt at all.
Command:
ssh <ip-address> <net-mask> <interface name>

Medium
Restrict Telnet Best practice: The addresses allowed to access the firewall using Telnet can be restricted. Any undefined IP
Access to Certain address will not see the prompt at all.
Addresses Command:
telnet <ip-address> <net-mask> <interface name>

Info
Set Enable Best practice: Set enable password to secure access to privilege level. Access to the privileged EXEC mode
Password (enable mode) should be protected by requiring a password else user logged in to user mode can access enable
mode.
Command:
enable password <password>

Info
Set Password Best practice: To set the login password, use the passwd command in global configuration mode. You are
prompted for the login password when you access the CLI as the default user using Telnet or SSH. After you
enter the login password, you are in user EXEC mode.
Command:
passwd <password>

Low
Set Suitable Console Best practice: For console connections the idle timeout must be configured to avoid undesirable open and
Timeout unattended console connection to the firewall.
Command:
console timeout <timeout value in minutes>

Low
Set Suitable SSH Best practice: For ssh connections the idle timeout must be configured to avoid undesirable and unattended
Timeout open ssh connections to the firewall.
Command:
ssh timeout <timeout in minutes>

Low
Set Suitable Telnet Best practice: For telnet connections the idle timeout must be configured to avoid undesirable open unattended
Timeout telnet connection to the firewall.
Command:
telnet timeout <timeout in minutes>

Low
Use Warning Banner
Messages Best practice: Use of configurable, personalized login and failed-login banners is recommended. This feature
lets you change the default message for login and failed-login. You can configure message banners that will be
displayed when a user logs in to the system
Command:
banner <banner-message>

Secure Interactive Access Using AAA - Firewall

Requirement Severity Comments

Medium
Define AAA Server Best practice: An Authentication Authorization and Accounting Server (AAA) is recommended to store all the
with Key username / password and privilege levels in one single repository. AAA server should be configured with a key for
authentication and encryption.
Command:
aaa-server TACACS+ <interface> host <ipAddress> <key>

Low
Use AAA Accounting
Best practice: When you configure the aaa accounting command, each command other than show commands
entered by an administrator is recorded and sent to the accounting server or servers.
Command:
aaa accounting command EXAUTH LOCAL

Medium
Use AAA Best practice: Authenticates users who access privileged EXEC mode when they use the enable command. For
Authentication for authentication an external server may be used and also supports fallback to local database if external
Enable Mode authentication server is down.
Command:
aaa authentication enable console RADIUS LOCAL

Medium
Use AAA Best practice: If aaa authentication http console command is not defined, you can gain access to the FWSM (via
Authentication for ASDM) with no username and the FWSM enable password (set with the enable password command).
HTTP Command:
aaa authentication http console RADIUS LOCAL

Info
Use AAA
Authentication for Best practice: Before the firewall can authenticate a Telnet or SSH user, we must first configure access to the
SSH firewall using the telnet or ssh commands. These commands identify the IP addresses that are allowed to
communicate with the firewall.
Command:
aaa authentication ssh console RADIUS LOCAL

Medium
Use AAA Best practice: Before the firewall can authenticate a Telnet or SSH user, we must first configure access to the
Authentication for firewall using the telnet or ssh commands. These commands identify the IP addresses that are allowed to
Telnet communicate with the firewall.
Command:
aaa authentication telnet console RADIUS LOCAL

Low
Use AAA
Authorization Best practice: The aaa authorization command specifies whether command execution at the CLI is subject to
authorization. If you enable TACACS+ command authorization, and a user enters a command at the CLI, the
FWSM sends the command and username to the TACACS+ server to determine if the command is authorized.
When configuring command authorization with a TACACS+ server, do not save your configuration until you are
sure it works the way you want. If you get locked out because of a mistake, you can usually recover access by
restarting the FWSM.
Command:
aaa authorization command TACACS LOCAL

Info
Use Local Login as Best practice: While configuring external authentication it is advisable to keep the local database check as
Backup to AAA fallback option.
Command:
aaa authentication http console RADIUS LOCAL

Secure Management Protocols - Firewall

Requirement Severity Comments

Medium
Authenticate NTP Best practice: Network Time Protocol (NTP) is a UDP based protocol used to synchronize time clocks amongst
Updates network devices. NTP is especially useful to ensure that timestamps on log messages are consistent throughout
the entire network. It is recommended to authenticate NTP updates so that time is synchronized with approved
servers only.
Command:
ntp authentication-key <key-id> md5 <key>

High
Change Default Best practice: The default community string of "public" and "private" are well known. These should always be
Community String changed to more secure strings.
Command:
snmp-server community <non-default-string>

Low
Define SNMP Server Best practice: SNMP is an application-layer communication protocol that allows ONS 15454 network devices to
Host exchange management information among these systems and with other devices outside the network. SNMP is
used in network management systems to monitor network-attached devices for conditions that warrant
administrative attention.
Command:
snmp-server host

Low
Disable SNMP if not
used Best practice: SNMP Protocol should be disabled if not used in the network. If used, access to SNMP service
should be protected using appropriate mechanisms like ACLs.
Command:
no snmp-server

Low
Enable SNMP Trap
Logging Best practice: SNMP traps are used to report an alert or other asynchronous event about a managed firewall.
Command:
snmp server enable traps

Medium
Use NTP to Synch Best practice: Network Time Protocol (NTP) is a UDP based protocol used to synchronize time clocks amongst
Network Clocks network devices. NTP is especially useful to ensure that timestamps on log messages are consistent throughout
the entire network.
Command:
ntp server <ntp server name> source <interface>

Control Plane Checks

Disable Unneeded Services - Firewall

Requirement Severity Comments

Info
Check if Failover is
used Best practice: This rule checks if failover is configured in the firewall devices
Command:
failover

Info
Disable HTTP Best practice: The replication of http session data to the failover firewall should be disabled unless the firewall is
session replication not expected to be under extreme load and the http session data is highly critical. Given the short duration of http
sessions, low probably of firewall failure and the design of most applications, this is not likely to be needed. This
rule checks only firewalls with failover configured.
Command:
no failover replication http

Low
Disable Proxy ARPs
Best practice: Proxy ARP allows a firewall to extend the network at layer 2 across multiple interfaces (i.e. LAN
segments). Hence proxy ARP allows hosts from different segments to function as if they were on the same
subnet, and is only safe when used between trusted LAN segments. Attackers can use the trusting nature of
proxy ARP by spoofing a trusted host and intercepting packets. Because of this inherent security weakness,
proxy ARP should be disabled on interfaces that do not require it, especially those interfaces that connect to
untrusted networks.
Command:
sysopt noproxyarp <interface>

Low
Limit ICMP Best practice: Preferable to disable ICMP on outside interfaces at a minimum. The default (i.e. no ICMP control
responses on list is configured), is for the PIX/ASA/FWSM to accept all ICMP traffic that terminates at any interface (including
interfaces the outside interface). This will depend on the customer policy.
Command:
icmp permit <acl> <interface>
Data Plane Checks

There are numerous techniques of securing the data plane in firewalls, which will be discussed in this section. Packet filtering, stateful
inspection, proxies and application level inspection are one of the basic aspects of data plane security.

It is never recommended to rely on one method of data plane security alone. It is best to use a combination of methods available as covered in
this section.

Data Plane - Firewall

Requirement Severity Comments

Info
Enable uRPF anti- Best practice: Anti-spoofing should be configured on all outside interfaces. This rule checks if uRFP is enabled
spoofing on any one interface.
Command:
ip verify reverse-path interface <interface-name>

Conclusion
The ability to understand device hardening at the core of security architecture design and implementation is essential to success. As the threat
landscape continues to evolve, the reliance on risk analysis and management transcends the evolution and key components of a strong
infrastructure. The firewall is an essential component of this infrastructure. Moreover, it is imperative that administrators and engineers
understand the numerous aspects and barrage of concerns and activity that exist, and must be acknowledged as part of a security policy to
include the implementation of firewalls which are required to prevent such attacks in today's landscape.

Acknowledgments
Authors:

Panos Kampanakis (pkampana[at]cisco[dot]com) is a member of the Applied Security Intelligence team in the Security Intelligence Operations
organization.

Andrae Middleton (amiddlet[at]cisco[dot]com) is a Cisco Technical Marketing Engineer.

References
Kaeo, Merike. Designing Network Security. Cisco Press.

Cisco ASA 5500 Series Configuration Guide

//www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/asa_84_cli_config.html

Cisco ASA 5500 Series Command Reference

//www.cisco.com/en/US/docs/security/asa/asa82/command/reference/cmd_ref.html

Configuring TCP/IP Normalization and IP Reassembly Parameters (PDF)

//www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/security/guide/tcpipnrm.pdf

Security Guide vA5(1.0), Cisco ACE Application Control Engine

//www.cisco.com/c/en/us/td/docs/interfaces_modules/services_modules/ace/vA5_1_0/configuration/security/guide/securgd/preface.html

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability
or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco
reserves the right to change or update this document without notice at any time.

Back to Top

Contacts | Feedback
Terms & Conditions | Privacy | Cookies | Trademarks