It is a good security practice to configure a Warning login banner on your Cisco ASA firewall appliance for unauthorized access attempts. The command format is:

ciscoasa(config)# banner {asdm | exec | login | motd text}

As you can see from the command format, there are four access banner types as following:

• asdm: The Firewall displays a banner after you successfully log in to ASDM.
• exec: The Firewall displays a banner before displaying the enable prompt.
• login: The Firewall displays a banner before the password login prompt when accessing the security appliance using Telnet.
• motd: This is the Message of the Day banner. It is displayed when you first connect.

Configuration Example for Login Banner:

ciscoasa(config)# banner login                ** W A R N I N G **
ciscoasa(config)# banner login Unauthorized access prohibited. All access is
ciscoasa(config)# banner login monitored, and trespassers shall be prosecuted
ciscoasa(config)# banner login to the fullest extent of the law.

Following our previous post about AAA Authentication for management access to a Cisco ASA Firewall, in this post we will describe how we can keep track of the authentication requests of admin users to the firewall. This can be helpful to keep a record of the time and date that an administrator user connected to the firewall. This functionality can be achieved by configuring “Accounting” on the ASA Firewall. This will enable the appliance to generate an accounting record that marks the establishment and termination of management access via Telnet, Serial Console, and SSH.

Assume that we have already installed a AAA server and configured the details on the firewall (see previous post). The name of the AAA server that we have given is NY_AAA.

AAA Accounting Configuration:

ASA(config)# aaa accounting serial console NY_AAA
ASA(config)# aaa accounting telnet console NY_AAA
ASA(config)# aaa accounting ssh console NY_AAA

The configuration above will keep a record in the AAA server database for the start-time and end-time of administrator access to the firewall.

Now, if we also need to keep track of all the commands entered by the administrator when he/she was connected to the firewall, we can use the “accounting command” as shown below:

ASA(config)# aaa accounting command NY_AAA

The above works only with TACACS+ protocols.

What is AAA

AAA stands for Authentication, Authorization, and Accounting. AAA is a mechanism that is used to tell the firewall appliance who the user is (Authentication), what actions the user is authorized to perform on the network (Authorization), and what the user did on the network after connecting (Accounting). In this post we will focus on the first element of AAA (that is Authentication).

Types of Authentication supported on ASA appliances

Three types of Authentication are available for Cisco ASA firewalls:

1.      User Authentication for accessing the security appliance itself.

2.      User Authentication for accessing services through the security appliance. This is also called “cut-through proxy” and is used to authenticate users for accessing Telnet, FTP, HTTP, and HTTPs services located in the network through the firewall.

3.      User Authentication for VPN tunnel access (IPsec or SSL VPN).

We will see a configuration example for the first type (authentication for accessing the security appliance for management using Serial Console, SSH, and Telnet access).

Authentication configuration example

In this example we assume that we have already installed and configured a AAA server (e.g Cisco ACS) running the TACACS+ authentication protocol. On the AAA server, we have configured a username/password account that the firewall administrators will use to authenticate. Assume also that the AAA server is located on our internal LAN network with address 10.1.1.1

Referring to the figure above, the firewall administrator (Admin) requests firewall access (serial console, SSH, or Telnet) (Arrow 1) for managing the appliance. The ASA firewall (Arrow 2) will request Authentication permission from the AAA server in order to prompt the admin user for Username/Password credentials. After the Admin successfully enters his credentials, the AAA server will give the permission to the Firewall to allow the user in.

Here is the configuration below:

! Specify a AAA server name (NY_AAA) and which protocol to use (Radius or TACACS+)
ASA(config)#  aaa-server NY_AAA protocol tacacs+

! Designate the Authentication server IP address and the authentication secret key
ASA(config)#  aaa-server NY_AAA (inside) host 10.1.1.1
ASA(config-aaa-server-host)#  key secretauthkey

! Enable Authentication for management access
ASA(config)#  aaa authentication serial console NY_AAA LOCAL
ASA(config)#  aaa authentication telnet console NY_AAA LOCAL
ASA(config)#  aaa authentication ssh console NY_AAA LOCAL

The “LOCAL” keyword at the end designates the use of the local firewall username database for authentication in case the AAA server authentication is not available (e.g AAA server is down).

Of course, to complete the scenario above, you need to properly configure the AAA Server with the internal IP address of the ASA firewall and the same authentication key (e.g secretauthkey) as the one you configured on the ASA above.

DNS in my opinion is the cornerstone of Internet communication. Anything from web browsing, email communication, file transfer, multimedia access etc is based on DNS. After the recent discovery of Dan Kaminsky’s DNS major security issue, protection of DNS service is of critical importance. Fortunately, the Cisco ASA firewall provides several dns security features that can be used to enhance DNS security. These security parameters can be configured under the modular policy framework of the ASA as described below:

class-map inspection_default
     match default-inspection-traffic
    !
    policy-map type inspect dns preset_dns_map
     parameters
      dns-guard
      !– Enable dns-guard to verify that DNS query and
      !– response transaction IDs match and only one DNS
      !– response is allowed through the firewall for
      !– each query.
     !

      message-length maximum 512
      !– Enable a maximum message length to help defeat DNS
      !– amplification attacks. Note: This is the default
      !– configuration and value based on RFC 1035.
      !
    
      id-mismatch count 10 duration 2 action log
        exit
      !– Enable id-mismatch to count DNS transaction ID
      !– mismatches within a specified period of time
      !– and generate a syslog when the defined threshold
      !– has been reached.
      !
       match header-flag RD
        drop
      !– Check for DNS query messages with the recursion
      !– desired (RD) flag set in the DNS header and drop
      !– those packets to avoid being used as a recursive
      !– resolver.
      !

      id-randomization
      !– Enable id-randomization to generate unpredictable
      !– DNS transaction IDs in DNS messages and protect
      !– DNS servers and resolvers with poor randomization
      !– of DNS transaction IDs.

    !
    policy-map global_policy
      class inspection_default
        inspect dns preset_dns_map
      –      CLI Output Truncated       –
    !
    service-policy global_policy global

When you host a public DNS server behind a Cisco ASA 5500 firewall, you might be getting an error log message from the firewall about DNS message length mismatch. This is because by default the DNS inspection engine on the ASA allows a maximum DNS message length of 512 bytes only, as shown below:

policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512

This DNS message length parameter is configurable from 512 to 65535, so you can increase this to an appropriate length according to your traffic needs. However, you should take into consideration that the DNS length value of 512 bytes is configured according to RFC 1035, and its not recommended to change it, so that you can avoid DNS amplification attacks.