Cisco Archives

Which Cisco ASA Models support IPS Module

As we mentioned in previous posts, the Cisco ASA 5500 appliance supports an Intrusion Detection/Intrusion Prevention plug-in module (AIP-SSM). However not all models support this. Specifically only the middle-range models support it. The lowest-end model (5505) and the highest-end models (5550, 5580) does not support the AIP-SSM IPS module.

ASA Models that support IPS Module:

  • Cisco ASA 5510
  • Cisco ASA 5520
  • Cisco ASA 5540

Basically the ASA 5505 can not support the AIP-SSM because of its small size. Also, the 5550 can not support the module because its hardware is occupied with much more integrated network ports compared with other models (it has 8-10/100/1000 and 4 gigabit SFP ports). The highest-end 5580 does not support the module because an IPS inline module in the 5580 would decrease its packet forwarding performance (remember that the 5580 is usually used in high traffic environments).

Antivirus and Antispam protection with CSC SSM

The CSC-SSM module of the Cisco ASA 5500 Firewall offers content security inspection for FTP, HTTP, POP3, and SMTP traffic, thus protecting the network from viruses, spyware, worms, spam and phishing, and controls unwanted mail and Web content. In more detail, the capabilities of the CSC-SSM module include the following:

  • Antivirus and Antispyware protection using the Trend Micro technology.
  • URL filtering
  • content filtering
  • email filtering
  • anti-phishing protection in Web and email.
  • Anti-spam protection in email.

After initial installation and configuration of the CSC-SSM module, you need to configure the ASA Firewall to send specific traffic to the module for inspection. The traffic supported for inspection is FTP, HTTP, POP3 and SMTP as we mentioned above. For SMTP traffic, the inspection works only for inbound traffic from the Internet towards internal SMTP servers protected by the ASA appliance. The flow of scanned traffic with the CSC-SSM module is shown on the figure below (figure courtesy of Cisco.com):

csc ssm traffic flow inspection

To configure the Cisco ASA Firewall to send traffic to the content inspection module we need to use the modular policy framework as following:

Configuring the Cisco ASA to work with CSC-SSM:

Assume we have an internal network range of 192.168.1.0/24. We want to configure the CSC-SSM module to inspect outbound HTTP, FTP, and POP3 traffic from our internal hosts towards the Internet.

! First define what traffic to inspect
ASA(config)# access-list inspect_outbound extended permit tcp 192.168.1.0 255.255.255.0 any eq 80
ASA(config)# access-list inspect_outbound extended permit tcp 192.168.1.0 255.255.255.0 any eq 21
ASA(config)# access-list inspect_outbound extended permit tcp 192.168.1.0 255.255.255.0 any eq 110

! Create a class map to identify the traffic that should be diverted to the CSC SSM
ASA(config)# class-map csc_outbound_class
ASA(config-cmap)# match access-list inspect_outbound

! Create a policy map and attach the class-map
ASA(config)# policy-map csc_out_policy
ASA(config-pmap)# class csc_outbound_class
ASA(config-pmap-c)# csc fail-open

! Apply the policy map globally or to a specific interface (inside in our case)
ASA(config-pmap-c)# service-policy csc_out_policy interface inside

The csc fail-open command under the policy-map controls how the adaptive security appliance handles traffic when the CSC SSM is unavailable. The fail-open keyword specifies that all traffic will be permitted in case the CSC module fails. The other option is fail-close.

IP Phones behind a Cisco ASA 5505 Firewall

The Cisco ASA 5505 firewall is an excellent device for small branch office locations since it can offer several network services in one box. It can provide firewall security, IPSEC VPN lan-to-lan connectivity with a central office, and even power-over-ethernet connectivity for local IP phones (two of its network interfaces are power-over-ethernet ports).

A common network scenario using Cisco ASA firewalls is usually found in Enterprises with small branch offices that implement a Cisco IP Telephony Voice over IP solution. Typically, a Cisco CallManager at the Enterprise central office is used to control Cisco IP Phones at small branch offices. This implementation allows centralized call processing, reduces the equipment required, and eliminates the administration of additional Cisco CallManager and other servers at branch offices.This is illustrated in the diagram below:

ip phones behind a cisco asa 5505 with dhcp option 150

The DHCP feature of the Cisco ASA 5505 firewall can be used to assign IP addresses to the Branch Office IP phones. Via the DHCP, the ASA Firewall can also provide to the phones the IP address of a TFTP Server (this is usually the CallManager server itself). Cisco IP Phones download their configuration from a TFTP server. When a Cisco IP Phone starts, if it does not have both the IP address and TFTP server IP address preconfigured, it sends a request with option 150 to the DHCP server (Cisco ASA 5505 in our case) to obtain this information. In our example above, the Cisco ASA firewall will assign IP addresses in the range 10.0.0.0 and also provide a TFTP server IP address of 192.168.1.10 (CallManager at the central office). After the IP Phones obtain this information, they will be able to communicate with the central CallManager through the IPSEC VPN tunnel.

To configure the DHCP Option 150 on Cisco ASA:

ASA(config)# dhcpd option 150 ip 192.168.1.10
ASA(config)# dhcpd address 10.0.0.10-10.0.0.20 inside
ASA(config)# dhcpd enable inside

The Cisco ASA 5500 security appliance is not just a plain firewall. With an add-on security module (AIP-SSM), you can transform the ASA 5500 into an IDS/IPS sensor as well. The AIP-SSM (Advanced Inspection and Prevention – Security Services Module) is a full-blown IDS/IPS sensor with the same software and functionality like the external standalone IPS-4200 series appliance. Read the rest of this entry

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.

Configuring AAA Accounting on Cisco ASA Firewall

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

Cisco ASA AAA Authentication

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 Security Protection Parameters

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

 Page 9 of 10  « First  ... « 6  7  8  9  10 »