Advanced ACL Features

Cisco ASA provides many advanced packet-filtering features to suit any network environments. These features include:

• Object grouping
• Standard ACLs
• Time-based ACLs
• Downloadable ACLs
• ICMP Filtering

Object Grouping

Object grouping is a way to group similar items together to reduce the number of ACEs. Without object grouping, the configuration on the security appliance may contain thousands of lines of ACEs, which can become hard to manage. The security appliance follows the multiplication factor rule when ACEs are defined. For example, if three outside hosts need to access two internal servers running HTTP and SMTP services, the security appliance will have 12 host-based ACEs, calculated as follows:

Number of ACEs = (2 internal servers) * (3 outside hosts) * (2 services) = 12

By using object grouping, the number of ACEs can be reduced to just a single entry. Object grouping can cluster network objects such as internal servers into one group and outside hosts into another. The security appliance can also conglomerate both TCP services into a service object group. All of these groups can be linked to each other in one ACE.

Note

Although the number of viewable ACEs is reduced when object groups are used, the actual number of ACEs is not. Use the show access-list command to display the expended ACEs in the ACL.

The security appliance supports nesting an object group into another one. This hierarchical grouping can further reduce the number of configured ACEs in Cisco ASA.

The following sections discuss how to configure object groups in a security appliance.

Object Types

The security appliance supports four different types of objects which can group similar items or services:

• Protocol
• Network
• Service
• ICMP type

You can configure object groups by using the object-group command followed by the object type. The complete command syntax is

object-group {{protocol | network | icmp-type} grp_id | service grp_id {tcp | udp | tcp-udp}}

Table 5-5 lists and defines the arguments used in the object-group command.

The different types of object groups are discussed in the following sections.

Protocol

A protocol-based object group specifies a list of IP protocols such as TCP, UDP, and ICMP, just to name a few. To set up a protocol-based object group, use the object-group protocol command followed by the name of the object group, as shown in Example 5-4. An object group called TCP_UDP is set up to group the TCP and UDP protocols by using the protocol-object command. The security appliance allows you to add a description under an object group. In this example, the description Grouping of TCP and UDP protocols identifies this group.

Example 5-4. Configuration of Protocol-Based Object Group

Chicago(config)# object-group protocol TCP_UDP Chicago(config-protocol)# description Grouping of TCP and UDP protocols Chicago(config-protocol)# protocol-object tcp Chicago(config-protocol)# protocol-object udp

As mentioned earlier, an object group can be nested into another object group. This is done by using the group-object command. In Example 5-5, another protocol-based object group called IP_Protocols is set up to include GRE as the IP protocol. This object group also contains the TCP_UDP object group, defined in the preceding example. The description nested object group to include GRE, TCP and UDP is added to this group.

Example 5-5. Nesting of Protocol-Based Object Groups

Chicago(config)# object-group protocol IP_Protocols Chicago(config-protocol)# description nested object group to include GRE, TCP and UDP Chicago(config-protocol)# protocol-object gre Chicago(config-protocol)# group-object TCP_UDP

Caution

When the protocol-based object group is used, all the protocols are expanded into different ACLs. Because of this, it is easy to permit unintended traffic if object groups are applied too liberally.

Network

A network-based object group specifies a list of IP host, subnet, or network addresses. Defining a network-based object group is very similar to defining a protocol-based object group. You use the object-group network command followed by the name of the object group, as shown in Example 5-6. An object group called Local_Net is set up to group together a subnet 209.165.202.128 255.255.255.224 and a host 192.168.10.100 by using the network-object command. The description grouping of 192.168.10.100 and 209.165.202.128/27 is also added to this group.

Example 5-6. Configuration of Network-Based Object Group

Chicago(config)# object-group network Local_Net Chicago(config-network)# description grouping of 192.168.10.100 and 209.165.202.128/27 Chicago(config-network)# network-object host 192.168.10.100 Chicago(config-network)# network-object 209.165.202.128 255.255.255.224

Service

A service-based object group is used to cluster the TCP and/or UDP services together. By using the service-based object group, you can group either TCP, UDP, or TCP and UDP ports into a set by using the object-group service command followed by the name of the object group. If the object group is used to cluster only the TCP ports, then you need to specify the tcp keyword following the object name. For UDP-only services, use the udp keyword. If you are grouping services that are both TCP and UDP, such as DNS or Kerberos, you should use tcp-udp as the keyword. The services can be specified by using the port-object command in two ways:

• By using the eq (equal) option followed by the name of the service or the TCP/UDP port number
• By using the range option to group consecutive Layer 4 ports

In Example 5-7, an object group called TCP_Ports is set up to group the TCP-based services. The SMTP, Web, and HTTPS services are individually configured while FTP and FTP data are clustered using the range option. A description of object group for SMTP, WWW, HTTPS and FTP services is added to this group.

Example 5-7. Configuration of Service-Based Object Group

Chicago(config)# object-group service TCP_Ports tcp Chicago(config-service)# description object group for SMTP, WWW, HTTPS and FTP services Chicago(config-service)# port-object eq smtp Chicago(config-service)# port-object eq www Chicago(config-service)# port-object range ftp-data ftp Chicago(config-service)# port-object eq https

ICMP-Type

The ICMP protocol uses unique types to send control messages, as documented in RFC 792. Using the ICMP-type object group, you can group the necessary types required to meet an organization's security needs. The configuration of an ICMP-type object group uses the object-group icmp-type command followed by the name of the object group, as shown in Example 5-8. An object group called echo is set up to group echo and echo-reply, two ICMP types used when a user issues the ping command. In the object group sub-configuration mode, the ICMP types can be configured by using the icmp-object command. The administrator has entered a description of object group to allow ICMP echo and echo-reply in this object group.

Example 5-8. Configuration of ICMP-Type Object Group

Chicago(config)# object-group icmp-type echo Chicago(config-icmp)# description object group to allow ICMP echo and echo-reply Chicago(config-icmp)# icmp-object echo Chicago(config-icmp)# icmp-object echo-reply

Object Grouping and ACLs

Once object groups have been set up, you can map them in an ACL. In Figure 5-4, the inside network has two servers, both running HTTP and SMTP services. If two hosts on the outside network try to access those servers, then eight ACEs should be configured to allow the hosts to communicate with each other. By using object group parameters in the ACE, you can reduce the viewable number of ACEs to one.

Figure 5-4. Inbound Packet Filtering Using Object Groups

The following is the command syntax to define an ACE using object-group:

access-list id [extended][line line-num] {deny | permit} object-group protocol_obj_grp_id object-group network_obj_grp_id object-group service_obj_grp_id] object-group network_obj_grp_id object-group service_obj_grp_id] [log [[disable | default] | level] [interval secs] [time-range time_range_ID]] [inactive]

Table 5-6 lists and defines the arguments used in an ACE when object groups are specified. Some of these arguments are discussed in Table 5-2.

Example 5-9 shows the corresponding ACE using the object groups. A protocol-based object group called TCP is set up with the TCP protocol. The two network object groups configured are internal_servers and internet_hosts. The internal_server object group specifies the IP addresses of the servers that are on the inside network while internet_hosts is configured with the IP addresses of the hosts that are allowed to access the internal servers. A service based object group called HTTP_SMTP is set up to group the HTTP and SMTP services. An ACL, named outside_in, is used to link all the configured object groups together.

Example 5-9. Configuration of an ACE Using Object Groups

Chicago(config)# object-group protocol TCP Chicago(config-protocol)# protocol-object tcp Chicago(config-protocol)# object-group network internal_servers Chicago(config-network)# network-object host 209.165.202.131 Chicago(config-network)# network-object host 209.165.202.132 Chicago(config-network)# object-group network internet_hosts Chicago(config-network)# network-object host 209.165.201.1 Chicago(config-network)# network-object host 209.165.201.2 Chicago(config-network)# object-group service HTTP_SMTP tcp Chicago(config-service)# port-object eq smtp Chicago(config-service)# port-object eq www Chicago(config-service)# exit Chicago(config)# access-list outside_in extended permit object-group TCP object-group internet_hosts object-group internal_servers object-group HTTP_SMTP

The security appliance allows you to set up an ACE using any mix of object group and nonobject group parameters. You can choose to use TCP as the protocol and an object group for source and destination IP addresses and subnet masks. This is shown in the first deployment scenario "Using ACLs to Filter Inbound and Outbound Traffic" under the outside_in ACL.

After configuring the ACL, you can bind it to an interface for traffic filtering, as shown in Example 5-10. The ACL outside_in is applied to the outside interface in the inbound direction.

Example 5-10. Applying an ACL on the Outside Interface

Chicago# configure terminal Chicago(config)# access-group outside_in in interface outside

Standard ACLs

As mentioned earlier in this chapter, standard ACLs are used when the source network in the traffic is not important. These ACLs are used by processes, such as OSPF route-maps and VPN tunnels, to identify traffic based on the destination IP addresses.

Standard ACLs are defined by using the access-list command and the standard keyword after the ACL name. The command syntax to define a standard ACE is

access-list id standard {deny | permit} {any | host ip_address | ip_address subnet_mask}

In Example 5-11, the security appliance identifies traffic destined for host 192.168.10.100 and network 192.168.20.0/24 and ignores all other traffic.

Example 5-11. Configuration of a Standard ACL

Chicago(config)# access-list dest_net standard permit host 192.168.10.100 Chicago(config)# access-list dest_net standard permit 192.168.20.0 255.255.255.0 Chicago(config)# access-list dest_net standard deny any

In Example 5-12, a route map called ospf is set up to use the standard ACL configured in the previous example. Route maps will be discussed in Chapter 6, "IP Routing."

Example 5-12. Route Map Using a Standard ACL

Chicago(config)# route-map ospf permit 10 Chicago(config-route-map)# match ip address dest_net

Time-Based ACLs

The security appliance can apply the ACLs based on the time interval to allow or deny network access. These rules, commonly referred as time-based ACLs, can prevent users from accessing the network services when the packets arrive outside of the preconfigured time intervals. The ASA relies on the system's clock when time-based ACLs are evaluated. Consequently, it is important to ensure that the system clock is accurate, and thus the use of Network Time Protocol (NTP) is highly recommended.

Note

The time-based restrictions can be used with the extended, IPv6, and WebType ACLs.

The time-based ACLs can be set up by using the time-range command followed by the name of the range. In Example 5-13, a time range called business_hours is set up.

Example 5-13. Time-Range Configuration

Chicago(config)# time-range business_hours Chicago(config-time-range)#

In the time-range configuration mode, you can specify two different types of time restrictions:

• Absolute
• Periodic

Absolute

Using the absolute function, you can specify the values based on a start and/or an end time. This function is useful in cases where a company hires consultants for a period of time and wants to restrict access when they leave. In this case, you can set an absolute time and specify the start and the end time. Once the time period expires, the consultants will not be able to pass traffic through the security appliance.

The start and end times are optional. If there is no start time provided, the security appliance assumes that the ACL needs to be applied right away. If there is no end time configured, the security appliance applies the ACL indefinitely. Additionally, only one instance of the absolute parameter is allowed to be set up in a given time range.

The following is the command syntax to configure an absolute time range:

absolute [start time date] [end time date]

start time date specifies when to begin applying an ACE, and end time date directs the security appliance when to stop applying it. In Example 5-14, the administrator has created a time-range policy called business_hours for a new consultant whose start time/date is 8 a.m. on June 1, 2005 and end time/date is 5 p.m. on December 30, 2005.

Example 5-14. Absolute Time-Range Configuration

Chicago(config)# time-range business_hours Chicago(config-time-range)# absolute start 08:00 01 June 2005 end 17:00 30 December 2005

Note

The start and end times use the same format as the clock set command when configuring time and date values in the absolute function.

Periodic

Using the periodic function, you can specify the values based on the recurring events. The security appliance provides many easy-to-configure parameters to suit an environment. Time-based ACLs using this option is useful when a company wants to allow user access during the normal business hours on the weekdays and wishes to deny access over the weekends. Cisco ASA allows you to configure multiple instances of the periodic parameter. If both absolute and periodic parameters are configured in a time range, the absolute time parameters are evaluated first before evaluating the periodic time value. The following shows the command syntax to configure a periodic time range:

periodic <days-of-the-week> <hh:mm> to <days-of-the-week> <hh:mm>

The days-of-the-week values can be Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday. If you need to configure periodic days-of-the-week from Monday through Friday, you can use a shortcut of weekdays instead. For periodic Saturday and Sunday, you can use weekend as a shortcut. The security appliance can further the restrictions on the users by setting the optional 24-hour format hh:mm time specifications. In Example 5-15, the administrator has created a time-range policy called business_hours for the regular employees who work from 8 a.m. to 5 p.m. on weekdays and from 8 a.m. to 12 p.m. on Saturdays.

Example 5-15. Periodic Time-Range Configuration

Chicago(config)# time-range business_hours Chicago(config-time-range)# periodic weekdays 8:00 to 17:00 Chicago(config-time-range)# periodic Saturday 8:00 to 12:00

Once a time-range entry has been set up, the next step is to map it to the ACL by using the time-range keyword, as illustrated in Example 5-16, in which the administrator allows outside users access to an internal web server, 209.165.202.131, during business hours (8 a.m. to 5 p.m. Monday through Friday and 8 a.m. to 12 p.m. Saturday). If the outside users try to access the servers outside of this time window, the security appliance will drop the packets and generate a syslog message logging this event. The ACL name is inside_server and the time-range name is business_hours. The ACL is applied to the outside interface in the inbound direction.

Example 5-16. Configuration of a Time-Based ACL

Chicago(config)# access-list inside_server extended permit tcp any host 209.165.202.131 eq 80 time-range business_hours Chicago(config)# access-group inside_server in interface outside

Downloadable ACLs

The security appliance can dynamically download the ACLs from an external authentication server such as Cisco Secure ACS (CS-ACS) using RADIUS. This feature is discussed in Chapter 7, "Authentication, Authorization, and Accounting (AAA)." When a user needs to access a service on the outside, the following sequence of events occurs, as illustrated in Figure 5-5:

1. User opens up a browser application and tries to navigate to a web server located at 209.165.201.1. The packets are sent to Cisco ASA for routing.
2. The ASA is set up for user authentication and thus prompts the user for authentication credentials.
3. The user provides username and password.
4. The security appliance forwards the username and password to an authentication server.
5. If authentication is successful, the server returns the ACLs to the security appliance.
6. Cisco ASA applies the downloadable ACLs to the user.

Figure 5-5. Downloadable ACLs

ICMP Filtering

The security appliance does not block ICMP traffic destined for its own interface when ACLs are deployed. Depending on an organization's security policy, an ICMP policy can be defined on the security appliance to block the ICMP traffic that terminates at a security appliance's interface. Use the icmp command to create an ICMP policy for an interface. In Example 5-17, an ICMP policy is enabled on the outside interface to block ICMP echo packets that are used to discover if network devices are alive. The second icmp statement permits all other ICMP that is destined for the security appliance's IP address.

Example 5-17. Creating an ICMP Policy

Chicago(config)# icmp deny any echo outside Chicago(config)# icmp permit any outside

The ICMP commands are processed in sequential order, with an implicit deny at the end of the list. If an ICMP packet is not matched against a specific entry in the ICMP list, the packet is dropped. If there is no ICMP list defined, all ICMP packets are allowed to be terminated on the security appliance.