Use Guide to Secure ASA Firewall

Introduction

This document describes information to help you secure Cisco ASA devices, which increases the overall security of your network.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

• Cisco Active Security Appliance (ASA) 9.16(1) and later.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

This document is structured in 4 Sections.

1.     Management Plane Hardening - This applies to all ASA related Management/To the box traffic like SNMP, SSH and so on.
2.     Securing config - Commands through which you can stop populating the passwords and so on for the running config and so on.
3.     Logging and Monitoring - This applies to any settings related to logging on ASA.
4.     Through Traffic - This applies to the traffic which goes through the ASA.

The coverage of security features in this document often provides enough detail for you to configure the feature. However, in cases where it does not, the feature is explained in such a way that you can evaluate whether additional attention to the feature is required. Where possible and appropriate, this document contains recommendations that, if implemented, help secure a network.

Related Products

This configuration can also be used with Cisco ASA Software Version 9.1x.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Secure Operations

Secure network operations is a substantial topic. Although most of this document is devoted to the secure configuration of a Cisco ASA 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 you are advised to implement. These topics highlight specific critical areas of network operations and are not comprehensive.

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 used for communication of less severe issues is the Cisco Security Response. Security advisories and responses are available at PSIRT.

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

In order to maintain a secure network, you need to be aware of the Cisco security advisories and responses that have been released. You need to have knowledge of a vulnerability before the threat it can pose to a network can be evaluated. Refer to Risk Triage for Security Vulnerability Announcements for assistance in this evaluation process.

Leverage Authentication, Authorization, and Accounting

The Authentication, Authorization, and Accounting (AAA) framework is vital to secure network devices. The AAA framework provides authentication of management sessions and can also limit users to specific, administrator-defined commands and log all commands entered by all users. See the Authentication, Authorization, and Accounting section of this document for more information about how to leverage AAA.

Centralize Log Collection and Monitoring

In order to gain knowledge about existing, emerging, and historic events related to security incidents, your organization must have a unified strategy for event logging and correlation. This strategy must leverage logging from all network devices and use pre-packaged and customizable correlation capabilities.

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

Use Secure Protocols When Possible

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

Gain Traffic Visibility with NetFlow

NetFlow enables you to monitor traffic flows in the network. Originally intended to export traffic information to network management applications, NetFlow can also be used in order to show flow information on a router. This capability allows you to see what traffic traverses the network in real time. Regardless of whether flow information is exported to a remote collector, you are advised to configure network devices for NetFlow so that it can be used reactively if needed.

Configuration Management

Configuration management is a process by which configuration changes are proposed, reviewed, approved, and deployed. Within the context of a Cisco ASA device configuration, two additional aspects of configuration management are critical: configuration archival and security.

You can use configuration archives to roll back changes that are made to network devices. In a security context, configuration archives can also be used in order 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 ASA device contains many sensitive details. Usernames, passwords, and the contents of access control lists are examples of this type of information. The repository that you use in order to archive Cisco ASA device configurations needs to be secured. Insecure access to this information can undermine the security of the entire network.

Management Plane

The management plane consists of functions that achieve the management goals of the network. This includes interactive management sessions that use SSH, as well as statistics-gathering with SNMP or NetFlow. When you consider the security of a network device, it is critical that the management plane be protected. If a security incident is able to undermine the functions of the management plane, it can be impossible for you to recover or stabilize the network.

Hardening Management Plane

The management plane is used in order to access, configure, and manage a device, as well as monitor its operations and the network on which it is deployed. The management plane is the plane that receives and sends traffic for operations of these functions. This list of protocols is used by the management plane:

• Simple Network Management Protocol
• Secure Shell Protocol
• File Transfer Protocol
• Trivial File Transfer Protocol
• Secure Copy Protocol
• TACACS+
• RADIUS
• NetFlow
• Network Time Protocol
• Syslog
• ICMP
• SMB

Note: Enabling TELNET is not recommended as it is plain text.

Password Management

Passwords control access to resources or devices. This is accomplished through the definition a password or secret that is used in order to authenticate requests. When a request is received for access to a resource or device, the request is challenged for verification of the password and identity, and 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 is still needed in the event of failure of the TACACS+ or RADIUS services. A device can also have other password information present within its configuration, such as an NTP key, SNMP community string, or Routing Protocol key.

ASA 9.7(1) introduced PBKDF2 hashing for local passwords. Local username and enable passwords of all lengths are stored in the configuration using a Password-Based Key Derivation Function 2 (PBKDF2) hash. Previously, passwords 32 characters and shorter used the MD5-based hashing method. Already existing passwords continue to use the MD5-based hash unless you enter a new password. See the Software and Configurations chapter in the General Operations Configuration Guide for downgrading guidelines.

Enable HTTP Service

To use ASDM, you need to enable the HTTPS server, and allow HTTPS connections to the ASA. The security appliance allows a maximum of 5 concurrent ASDM instances per context, if available, with a maximum of 32 ASDM instances between all contexts. To configure ASDM access use:

http server enable <port>

Allow only the IP's which are needed in the ACL list. Allowing a wide access is not a good practice.

http 0.0.0.0 0.0.0.0 <interface> 

Configure ASDM Access Control :

http <remote_ip_address> <remote_subnet_mask> <interface_name>

// Set server version
ASA(config)# ssl server-version tlsv1 tlsv1.1 tlsv.1.2

// Set client version
ASA(config) # ssl client-version tlsv1 tlsv1.1 tlsv.1.2

The ASA has these ciphers enabled in the order as shown by default.

The default ishigh.

• The all keyword specifies using all ciphers: hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-md5 hmac-md5-96

• The custom keyword specifies a custom cipher encryption configuration string, separated by colons.

• The fips keyword specifies only FIPS-compliant ciphers: hmac-sha1 hmac-sha2-256

• The high keyword specifies only high-strength ciphers (the default): hmac-sha2-256

• The low keyword specifies low, medium, and high strength ciphers: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96 hmac-sha2-256

• The medium keyword specifies the medium and high strength ciphers: hmac-sha1 hmac-sha1-96hmac-sha2-256

The ASA by default uses a Temporary Self-Signed certificate which changes on every reboot. If you are looking for a single certificate, you can use this link to generate a Permanent Self-signed certificate.

ASA supports TLS version 1.2  for secure message transmission for ASDM, Clientless SSVPN, and AnyConnect VPN. These commands have been introduced or are modified commands: ssl client-version, ssl server-version, ssl cipher, ssl trust-point, ssl dh-group, show ssl, show ssl cipher, show vpn-sessiondb.

ASA-1/act(config)# ssl server-version ?

configure mode commands/options:
  tlsv1    Enter this keyword to accept SSLv2 ClientHellos and negotiate TLSv1
           (or greater)
  tlsv1.1  Enter this keyword to accept SSLv2 ClientHellos and negotiate
           TLSv1.1 (or greater)
  tlsv1.2  Enter this keyword to accept SSLv2 ClientHellos and negotiate
           TLSv1.2 (or greater)

ASA-1/act(config)# ssl cipher ?

configure mode commands/options:
  default  Specify the set of ciphers for outbound connections
  dtlsv1   Specify the ciphers for DTLSv1 inbound connections
  tlsv1    Specify the ciphers for TLSv1 inbound connections
  tlsv1.1  Specify the ciphers for TLSv1.1 inbound connections
  tlsv1.2  Specify the ciphers for TLSv1.2 inbound connections

Enable SSH

The ASA allows SSH connections to the ASA for management purposes. The ASA allows a maximum of 5 concurrent SSH connections per context, if available, with a maximum of 100 connections divided between all contexts.

hostname <device_hostname>
domain-name <domain-name>
crypto key generate rsa modulus 2048

The default key-pair type is general key. The default modulus size is 1024. The amount of NVRAM space for storing key pairs varies depending on the ASA platform. You can reach a limit if you generate more than 30 key pairs. 

To remove the key pairs of the indicated type (rsa or dsa),

crypto key zeroize { rsa | eddsa | ecdsa } [ label key-pair-label ] [ default ] [ noconfirm ]

Configure SSH for Remote Device Access:

ssh <remote_ip_address> <remote_subnet_mask> <interface_name>

To exchange keys using either the Diffie-Hellman (DH) Group 1, DH Group 14 or Curve25519 key-exchange method, use the ssh key-exchange command in global configuration mode, starting from 9.1(2) ASA supports dh-group14-sha1 for SSH.

ASA(config)#ssh key-exchange group dh-group14-sha256

Configure Timeout for Login Sessions

// Configure Console timeout
ASA(config)#console timeout 10

// Configure Console timeout
ASA(config)#ssh timeout 10

Password Management

Passwords control access to resources or devices. This is accomplished through the definition a password or secret that is used in order to authenticate requests. When a request is received for access to a resource or device, the request is challenged for verification of the password and identity, and 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 is still needed in the event of failure of the TACACS+ or RADIUS services. A device can also have other password information present within its configuration, such as an NTP key, SNMP community string, or Routing Protocol key.

Configure Local User and Encrypted Password

username <local_username> password <local_password> encrypted

Configure Enable Password

enable password <enable_password> encrypted

Configure AAA Authentication for Enable Mode

ASA(config)#aaa authentication enable console LOCAL

Authentication, Authorization, and Accounting

The Authentication, Authorization, and Accounting (AAA) framework is critical in order to secure interactive access to network devices. The AAA framework provides a highly configurable environment that can be tailored based on the needs of the network.

TACACS+ Authentication

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

TACACS+ authentication, or more generally AAA authentication, provides the ability to use individual user accounts for each network administrator. When you do not depend on a single shared password, the security of the network is improved and your 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, which includes both the username and password. For this reason, TACACS+ can be used in preference to RADIUS when TACACS+ is supported by the AAA server. Refer to TACACS+ and RADIUS Comparison for a more detailed comparison of these two protocols.

TACACS+ authentication can be enabled on a Cisco ASA device with a configuration similar to this example:

aaa authentication serial console Tacacs 
aaa authentication ssh console Tacacs
aaa authentication http console Tacacs
aaa authentication telnet console Tacacs

ASA image Signing and Verification

Starting from software version 9.3.1, ASA images are now signed using a digital signature. The digital signature is verified after the ASA is booted.

ASA-1/act(config)# verify flash:/asa941-smp-k8.bin
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!                                                                                        !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Done!
Embedded Hash SHA-512: 0e707a0e45b1c7c5afa9ef4e802a273677a5e46f7e1d186292abe1154                                                                                        c948a63c625463b74119194da029655487659490c2873506974cab78b66d6d9742ed73e
Computed Hash SHA-512: 0e707a0e45b1c7c5afa9ef4e802a273677a5e46f7e1d186292abe1154                                                                                        c948a63c625463b74119194da029655487659490c2873506974cab78b66d6d9742ed73e
CCO Hash      SHA-512: 1b6d41e893868aab9e06e78a9902b925227c82d8e31978ff2c412c18a                                                                                        c99f49f70354715441385e0b96e4bd3e861d18fb30433d52e12b15b501fa790f36d0ea0
Signature Verified


ASA(config)# verify /signature running
Requesting verify signature of the running image...

Starting image verification
Hash Computation:    100% Done!
Computed Hash   SHA2: 2fbb0f62b5fbc61b081acfca76bddbb2
                      26ce7a5fb4b424e5e21636c6c8a7d665
                      1e688834203dfb7ffa6eaefc7fdf9d3d
                      1d0a063a20539baba72c2526ca37771c


Get key records from key storage: PrimaryASA, key_store_type: 6
Embedded Hash   SHA2: 2fbb0f62b5fbc61b081acfca76bddbb2
                      26ce7a5fb4b424e5e21636c6c8a7d665
                      1e688834203dfb7ffa6eaefc7fdf9d3d
                      1d0a063a20539baba72c2526ca37771c

Returned. rc: 0, status: 1
The digital signature of the running image verified successfully

ASA-1/act(config)# show software authenticity running
Image type : Release
 Signer Information
 Common Name : abraxas
 Organization Unit : ASAv
 Organization Name : CiscoSystems
 Certificate Serial Number : 550DBBD5
 Hash Algorithm : SHA2 512
 Signature Algorithm : 2048-bit RSA
 Key Version : A

Configure Clock Time Zone

clock timezone GMT <hours offset>

Configure NTP

The 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, such as during forensic investigations of potential attacks, as well as for successful VPN connectivity when depending on certificates for Phase 1 authentication.

• NTP Time Zone - When you configure NTP, the time zone needs to be configured so that timestamps can be accurately correlated. There are usually two approaches to configure 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) (previously Greenwich Mean Time (GMT)). The other approach is to configure network devices with the local time zone. ntp server ip_address [ key key_id ] [ source interface_name ] [ prefer ]

• NTP Authentication - If you configure NTP authentication, it provides assurance that NTP messages are exchanged between trusted NTP peers. Enable authentication using the ntp authenticate command, sets the trusted key ID for this server. If you enable authentication, the ASA only communicates with an NTP server if it uses the correct trusted key in the packets. To enable authentication with an NTP server, use the ntp authenticate command in global configuration mode.

ASA(config)#ntp authenticate

DHCP Server Service (If not being used)

clear configure dhcpd
no dhcpd enable <interface_name>

Note: ASA does not support CDP.

Control-Plane Access-list

Access control rules for to-the-box management traffic (defined by such commands as http, ssh, or telnet) have higher precedence than an access list applied with the control-plane option. Therefore, such permitted management traffic can be allowed to come in even if explicitly denied by the to-the-box access list.

access-list <name> in interface <Interface_name> control-plane

From ASA

Here are the protocols which can be used to copy/transfer files to ASA.

Clear text:

• FTP
• HTTP
• TFTP
• SMB

Secure:

•  HTTPS
•  Secure Copy Client (SCP) ASA supports SCP client to transfer files to and from a SCP server.

For Through traffic

TCP Sequence Number Randomization

Each TCP connection has two ISNs: one generated by the client and one generated by the server. The ASA randomizes the ISN of the TCP SYN passing in both the inbound and outbound directions.

Randomizing the ISN of the protected host prevents an attacker from predecting the next ISN for a new connection and potentially hijacking the new session.

TCP initial sequence number randomization can be disabled if required. For example:

• If another in-line firewall is also randomizing the initial sequence numbers, there is no need for both firewalls to be performing this action, even though this action does not affect the traffic.
• If you use eBGP multi-hop through the ASA, and the eBGP peers are using MD5. Randomization breaks the MD5 checksum.
• If we use a WAAS device that requires the ASA not to randomize the sequence numbers of connections.

TTL Decrement

By default, does not decrement TTL in the IP header due to which ASA does not show up as a router hop when doing Traceroute.

dnsguard

Enforces one DNS response per query. It can be enabled using the command in global configuration mode.

ASA(config)#dns-guard

Configure Fragment Chain Fragmentation Checks

To provide additional management of packet fragmentation and improve compatibility with NFS, use the fragment command in global configuration mode.

fragment reassembly { full | virtual } { size | chain | timeout limit } [ interface ]

Configure Protocol Inspection

Inspection engines are required for services that embed IP addressing information in the user data packet, or that open secondary channels on dynamically assigned ports. These protocols require the ASA to do a deep packet inspection instead of passing the packet through the fast path. As a result, inspection engines can affect overall throughput. Refer to ASA 9.4 Config Guide for detail information on Application Layer Protocol Inspection.

Inspection on ASA can be enabled using this command. 

policy-map <Policy-map_name>
 class inspection_default
  inspect <Protocol>

service-policy <Policy-map_name> interface <Interface_name> (Per Interface)
service-policy <Policy-map_name> global (Globally)

By default, ASA has global_policy enabled globally.

Configure Unicast Reverse-Path Forwarding

ip verify reverse-path interface <interface_name>

 When traffic gets dropped due to RPF check, this shows asp drop counter on ASA increments.

ASA(config)# show asp drop 

Frame drop:
  Invalid TCP Length (invalid-tcp-hdr-length)                  21
  Reverse-path verify failed (rpf-violated)                    90

// Check Reverse path statistics

ASA(config)# sh ip verify statistics
interface inside: 11 unicast rpf drops
interface outside: 79 unicast rpf drops 

Threat Detection

Threat Detection provides firewall administrators with the necessary tools to identify, understand, and stop attacks before they reach the internal network infrastructure. In order to do so, the feature relies on a number of different triggers and statistics, which is described in further detail in these sections.

Refer to ASA Threat Detection Functionality and Configuration for detailed explanation on Threat Detection on ASA.

Botnet Filter

The BotNet traffic filter monitors Domain Name Server (DNS) requests and responses between internal DNS clients and external DNS servers. When a DNS response is processed, the domain associated with the response is checked against the database of known malicious domains. If there is a match, any further traffic to the IP address present in the DNS response is blocked.

Malware is malicious software that is installed on an unknowing host. Malware that attempts network activity such as sending private data (passwords, credit card numbers, key strokes, or proprietary data) can be detected by the Botnet Traffic Filter when the malware starts a connection to a known bad IP address. The Botnet Traffic Filter checks incoming and outgoing connections against a dynamic database of known bad domain names and IP addresses (the blocked list), and then logs or blocks any suspicious activity.

You can also supplement the Cisco dynamic database with blocked list addresses of your choosing by adding them to a static blocked list. If the dynamic database includes blocked list addresses that you think cannot be block listed, you can manually enter them into a static allowed list. Allowed list addresses still generate syslog messages, but because you are only targeting blocked list syslog messages, they are informational. Refer to Configuring the Botnet Traffic Filter for detailed information.

ARP Cache Additions for Non-Connected Subnets

By default ASA does not respond to ARP for non-directly connected subnet IP addresses. If you have a NAT IP on ASA which does not belong to the same subnet IP of the ASA interface, you can have to enable arp permit-nonconnected on ASA to proxy-ARP for the NATted IP.

arp permit-nonconnected

It is always recommended to have the correct routing on upstream and downstream devices for NAT to work without enabling the previous command.

Logging and Monitoring

Configuring SNMP

This section highlights several methods that can be used in order to secure the deployment of SNMP within ASA devices. It is critical that SNMP be properly secured in order to protect the confidentiality, integrity, and availability of both the network data and the network devices through which this data transits. SNMP provides you with a wealth of information on the health of network devices. This information can be protected from malicious users that want to leverage this data in order 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, can be carefully chosen to ensure they are not trivial. Community strings can be changed at regular intervals and in accordance with network security policies. For example, the strings can be changed when a network administrator changes roles or leaves the company.

Enable SNMP Read Access

snmp-server host <interface_name> <remote_ip_address>

Enable SNMP Traps

snmp-server enable traps all

Configuring Syslog

It is advised to send logging information to a remote syslog server. This makes it possible to correlate and audit network and security events across network devices more effectively.

Note: Syslog messages are transmitted unreliably by UDP and in cleartext.

For this reason, any protections that a network affords to management traffic (for example, encryption or out-of-band access) can be extended in order to include syslog traffic. Logs can be configured to be sent to this destination from ASA:

• ASDM
• Buffer
• Flash
• Email
• FTP server
• SNMP server as traps
• Syslogs server

Configure Console Logging Severity Level

logging console critical

TCP based syslog is also available. All syslogs can be sent to syslog server in plaintext or in encrypted in case of TCP.

Plaintext

logging host interface_name syslog_ip [ tcp/ port

Encrypted

logging host interface_name syslog_ip [ tcp/ port | [ secure ]

If a TCP connection cannot be established with the syslogs server, all new connections can be denied. You can change this default behavior by entering the logging permit-hostdown command.

Configure Timestamps in Log Messages

The configuration of logging timestamps helps you correlate events across network devices. It is important to implement a correct and consistent logging timestamp configuration to ensure that you are able to correlate logging data.

logging timestamp

For Additional Information related to syslog, refer to ASA Syslog Configuration Example.

Configuring Netflow

At times, you can need to quickly identify and traceback network traffic, especially during incident response or poor network performance. NetFlow can provide visibility into all traffic on the network. Additionally, NetFlow can be implemented with collectors that can provide long-term trending and automated analysis.

The Cisco ASA supports NetFlow Version 9 services. The ASA and ASASM implementations of NSEL provide a stateful, IP flow tracking method that exports only those 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.

Refer to Cisco ASA NetFlow Implementation Guide for more information of Netflow on ASA:

Securing config

Passwords in the config

All the passwords and the Keys are either encrypted or obfuscated . The show running-config does not reveal the actual passwords.

Such a backup cannot be used for backup/restore on ASA. The backup which is taken for restore purposes would be performed using the command more system:running-config. The ASA config passwords can be encrypted using a primary pass phrase. Refer to Password Encryption for detailed information.

Service Password Recovery

Disabling this can disable password recovery mechanism and disable access to ROMMON. The only means of recovering from lost or forgotten passwords can be for ROMMON to erase all file systems including configuration files and images. You can make a backup of your configuration and have a mechanism to restore images from the ROMMON command line.

Troubleshoot

There is no troubleshooting information available.