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.

The Cisco ASA firewall appliance provides both graphical and command line methods for connecting to the device for management. With the graphical method, the administrator can use a web browser (https) for managing the firewall. This method necessitates that the ASDM software (Adaptive Security Device Manager) is installed on the flash memory of the firewall.

The command line methods use either Telnet or SSH to connect to the device. Since the Telnet protocol sends everything in clear text, it is recommended to use SSH where all communication with the firewall is encrypted.

So let’s take a look at the commands needed on the ASA to allow SSH connections:

1) Connect to the ASA via console and get in configuration mode.
2) You have to configure a hostname and domain name
firewall(config)# hostname ASA-FIREWALL
ASA-FIREWALL (config)# domain-name test.com
3) You will need to generate an RSA Key Pair since this is needed by the SSH protocol which uses SSL. This can be achieved with the following command:
ASA-FIREWALL(config)# crypto key generate rsa modulus 2048

After issuing this command and hitting enter, you will see something like the following and you will need to wait:

For >= 2048, key generation could take up to several minutes. Please wait……….

4) Next, you will need to save your newly created Keys to flash by typing the following command:
ASA-FIREWALL # write mem

5) Now, we can tell the ASA exactly which hosts or networks can access the device via SSH. We also need to specify which interface we are allowing access to.

For example, if you have a management PC with internal IP address of 10.0.0.1 and just wanted to allow this PC to access the ASA on the inside interface, you would issue the following command:

ASA-FIREWALL(config) #ssh 10.0.0.1 255.255.255.255 inside

6) Enable authentication for the SSH. You can configure LOCAL authentication by configuring a local username/password on the device:
ASA-FIREWALL(config) # aaa authentication ssh console LOCAL
ASA-FIREWALL(config) # username admin password xxxxxxxx encrypted

7) Download a free SSH client (e.g putty) for connecting to the device.