Chapter 8: Controlling Access through the ASA.

......update soon ......

----------------------------------------------------------------------------------------------------------------------

6-3: Controlling Access with Access Lists

On a Cisco firewall, you can use access lists to filter traffic coming into or out of a firewall interface. Access lists that are applied to interfaces become an integral part of the traffic inspection mechanism.

Access lists can be defined using the familiar Cisco IOS Software ACL format. However, one important difference exists between the firewall and IOS ACL formats: Firewalls use real subnet masks (a 1-bit matches, a 0-bit ignores), while IOS platforms use a wildcard mask (a 0-bit matches, a 1-bit ignores). For example, the subnet 192.168.199.0/24 would be configured as 192.168.199.0 255.255.255.0 on an ASA or FWSM, and as 192.168.199.0 0.0.0.255 on an IOS platform.

Access lists are configured one line at a time; every line that makes up a single access list must have an identical ACL name. Each line of an access list is called an Access Control Entry (ACE).

Cisco firewalls also offer an ACL configuration feature not found in the IOS Software. Access lists can be configured in a modular fashion, using defined object groups as a type of macro. Object groups are discussed in detail in the “Defining Object Groups” section.

Compiling Access Lists

Access lists are normally evaluated in sequential order, as they appear in the firewall configuration. As access lists grow in length, the amount of time needed to evaluate the ACEs in sequence can also grow. Fortunately, the ASA and FWSM platforms compile access lists into a more efficient Turbo ACL format. On a PIX platform, you can compile ACLs beginning with release 6.2. Once compiled, access lists can be evaluated in a deterministic fashion, without the need to work through each ACE in sequence. In other words, the time required to find and evaluate any specific ACE within the entire access list is more or less constant.

In PIX releases 6.2 and 6.3, access lists must have at least 19 ACEs before they can be compiled into the Turbo ACL format. If they have less than 19 entries, it becomes more efficient for the firewall to evaluate them sequentially. As well, compiled ACLs are stored in Flash memory so that they can be retrieved in their native compiled format even after a reboot.

On a PIX platform, TurboACLs can be compiled when they are first configured, and at most every time when they are edited thereafter. ASAs running 7.0 or later automatically compile access lists immediately after they are edited or configured—usually after every ACE is entered. This is important because any configuration changes you make to ACLs take effect right away. This process is completely hidden, so that you are never aware that an ACL is compiled or not. It simply exists in human-readable form in the firewall configuration.

A FWSM automatically compiles and applies ACLs in real-time by default too. However, you can configure it to use manual compilation instead.

Recompiling an ACL is a silent process, but can burden an already loaded firewall CPU. For this reason, you might choose to manually compile and apply ACL changes so that the only occur at predetermined times. For example, you might plan on making changes to large ACLs during a time of low traffic through the firewall or during a scheduled maintenance window.

On a FWSM, you can use the following command to see whether ACLs are compiled automatically or manually:

Firewall# show access-list mode

You can use the following command to configure whether access lists will be compiled automatically (the default) or manually:

Firewall(config)# access-list mode {auto-commit | manual-commit}

In the manual-commit mode, you have to manually compile and commit ACLs to FWSM memory after they are edited, in order for them to be updated and used. If you forget to commit the ACL changes, the FWSM keeps using the previously compiled ACL contents it already has in memory. The following configuration command can be used to commit all access lists configured on the FWSM:

Firewall(config)# access-list commit

Configuring an Access List

You can use the steps presented in this section to configure a firewall access list. The access list exists in the firewall configuration, but does not actively do anything until you apply it to a firewall interface or to some other firewall function.

Access lists are defined simply by entering ACE commands in global configuration mode. There is no need to define the access list name first; just the action of entering an ACE with an ACL ID acl_id (an arbitrary text name) is enough to make it a part of that access list. However, as soon as an access list is defined with at least one ACE, the order the ACEs are entered becomes important.

When you enter a new ACE into the configuration, it is always appended to the end or bottom of the access list. Therefore, the order that ACEs appear in an access list is important. This is because access lists are evaluated line-by-line, in sequential order. To designate an ACE’s exact position within a whole access list, you can specify a line number as part of the ACE configuration.

In addition, every access list ends with an implicit, hidden deny ip any any ACE. Even though a newly configured ACE is appended to the bottom of the access list, the implicit deny ACE always comes after that. In effect, anything that is not explicitly permitted by an ACE somewhere in the access list will be denied by this final implicit ACE.

Adding an ACE to an Access List

You can define an access list entry with the following configuration command:

Firewall(config)# access-list acl_id [line line-num] [extended] {permit | deny} protocol
source_addr source_mask [operator sport] destination_addr destination_mask [operator
dport] [log [[disable | default] | [level]]] [interval secs]] [time-range name] [inactive]

Although the command syntax looks complex, the concept is simple: Either permit or deny traffic from a source (using an optional source port) to a destination (using an optional destination port). An access list can be built from many different keywords and parameters. You might find Figure 6-11 helpful, as it shows the basic ACE syntax and how each portion can be configured.

Figure 6-11: Cisco Firewall ACE Structure and Composition

To simplify complex traffic definitions, you can also define groups of parameters as object groups; the object groups are then referenced in the ACE configurations. (Object groups are covered in the “Defining Object Groups” section in this chapter.)

Tip

You can use a similar ACE command syntax to create an access list for IPv6 traffic. Use the following guidelines when you adapt the syntax for IPv6:

• Use the ipv6 access-list command keywords instead of access-list.

• Whenever an IP subnet is given with source_addr source_mask or destination_addr destination_mask, substitute the IPv6 address prefix as source_ipv6_prefix/prefix_length or destination_ipv6_prefix/prefix_length.

• Whenever specific host addresses are needed, substitute host ip_address with host ipv6_address.

First, begin by identifying the protocol of interest. The matched protocol can be ip (any IP protocol), icmp (1), tcp (6), udp (17), ah (51), eigrp (88), esp or ipsec(50), gre or pptp(47), igmp (2), igrp (9), ipinip (4), nos (94), ospf (89), pim (103), pcp (108), or snp (109). You can also specify the protocol as a decimal number (0-255) to identify a protocol that does not have a predefined keyword.

Source and destination addresses can be explicit IP addresses or subnets, and the masks are regular subnet masks.

Tip

Cisco firewalls do not use the “inverted” masks required by routers running Cisco IOS Software. Instead, think of a firewall mask as a normal IP subnet mask, where a 1 bit matches a bit value and a 0 bit ignores it.

If you need to identify a specific host in an access list, you can give its IP address and a host mask (255.255.255.255). You can also specify the same thing by using the host keyword followed by the IP address.

To specify a wildcard or “any” IP address, you can use IP address 0.0.0.0 and mask 0.0.0.0 (0 bits in the mask ignore the value). You can also do the same thing by using the any keyword in place of an address and mask.

Tip

For inbound firewall rules, ACEs are usually concerned with the destination address and destination port values. This would be useful to allow outside hosts to connect to inside web or email servers, for example. You should always define an ACE with as specific source and destination information as possible. The goal is to define the most strict security policy while allowing users to connect to necessary resources. As well, you should always include access list rules that filter out attempts to spoof legitimate IP addresses (RFC2827) or use IP addresses set aside for private network use (RFC1918). For example, the following ACEs can be used to deny RFC1918 source addresses: Firewall(config)# access-list anti_spoof deny ip 10.0.0.0 255.0.0.0 any Firewall(config)# access-list anti_spoof deny ip 172.16.0.0 255.240.0.0 any Firewall(config)# access-list anti_spoof deny ip 192.168.0.0 255.255.0.0 any

If you need to match against a source or destination port number, you can add one of the following keywords as an optional operator:

Less Than	lt port
Greater Than	gt port
Equal To	eq port
Not Equal To	neq port
Range	range lower upper

Open table as spreadsheet

The operator compares the port number to the value given by port (a single decimal number; for a range, give two numbers for lower and upper limits). Port numbers can be given as predefined keywords or as decimal numbers. The keywords supported by Cisco firewalls are listed in Appendix A: “Well-Known Protocol and Port Numbers.”

In the case of an ICMP (protocol icmp) ACE, no operator keyword is used. Instead, the ICMP message type is given alone, in place of the port number.

By default, each ACE is enabled and actively used when it is configured. However, individual ACEs can be disabled without removing them from the configuration. This might be handy if you need to troubleshoot or temporarily deactivate a firewall rule. To do this, reenter the ACE configuration command along with the inactive keyword. To reenable an ACE, reenter it without the inactive keyword.

You can also configure individual ACEs so that they are active and evaluated only during a predefined time range. Time-based ACEs can be useful if you have security policies that change, based on the time of day, day of the week, and so on. After an access list is configured, you can always remove an ACE or insert an ACE at a specific location within the access list. These tasks are covered in the next section.

Tip

ASA and FWSM access lists are always assumed to use the “extended” format, where both source and destination addresses and ports can be specified. This is very similar to extended IP access lists on IOS router and switch platforms. However, the ASA and FWSM firewalls can support both “standard” and “extended” forms, although standard ACLs are reserved for use with routing protocols. You might be wise to get into the habit of using the extended keyword when you configure, edit, or delete ACE commands. Even if you do not specify the keyword when an ACE is entered, it is automatically inserted into the configuration. The extended keyword becomes important when you need to remove an ACE, as it must be given from the command line.

Remember that even though an access list is properly configured, it will not be used until it is applied to a firewall function. Access lists are most often used by applying them to firewall interfaces. Access lists can be applied to interfaces in the inbound and outbound directions independently.

Manipulating Access Lists

Every access list contains statements that are internally numbered. If you type in a new ACE without using a line number, it is simply added to the end of the list (just prior to the implicit deny ip any any ACE). If you do include a line number, the new ACE is inserted into the list just prior to the current ACE at that position. The current ACE is not replaced; rather, it and all ACEs below it are moved down one line to make room for the new ACE.

Tip

Prior to FWSM 2.3, line numbers were not used at all. In that case, you would have to edit an ACL simply by adding new ACEs or deleting existing ones.

Typically, a firewall numbers ACEs in an ACL with incremental values: the first ACE is line 1, the second ACE is line 2, and so on. However, the ACL line numbers are not shown in the configuration. To see them, you can use the show access-list [acl_id] command. For example, suppose the following ACL has been configured in a firewall:

Firewall(config)# access-list test permit tcp any host 192.168.10.1 eq www
Firewall(config)# access-list test permit udp any host 192.168.10.2 eq domain
Firewall(config)# access-list test permit tcp any host 192.168.10.3 eq smtp

When the running-configuration is displayed, the access list is shown just as it was entered. Notice that the final implicit deny any any is not shown, although it is actually present.

Firewall# show running-config
[output omitted]
access-list test extended permit tcp any host 192.168.10.1 eq www
access-list test extended permit udp any host 192.168.10.2 eq domain
access-list test extended permit tcp any host 192.168.10.3 eq smtp

No line numbers are shown, though the extended keyword has been added even though the ACE lines were not manually entered that way. To see the ACL line numbers, use the show access-list command, as follows:

Firewall# show access-list test
access-list test line 1 extended permit tcp any host 192.168.10.1 eq www (hitcnt=1784)
access-list test line 2 extended permit udp any host 192.168.10.2 eq domain (hitcnt=37465)
access-list test line 3 extended permit tcp any host 192.168.10.3 eq smtp (hitcnt=43544)

If a new ACE is entered without specifying a line number, it simply goes to the end of the ACL:

Firewall(config)# access-list test permit udp any host 192.168.10.4 eq tftp
Firewall(config)# exit
Firewall# show access-list test
access-list test line 1 extended permit tcp any host 192.168.10.1 eq www
(hitcnt=1784)
access-list test line 2 extended permit udp any host 192.168.10.2 eq domain
(hitcnt=37465)
access-list test line 3 extended permit tcp any host 192.168.10.3 eq smtp (hitcnt=43544)
access-list test line 4 extended permit udp any host 192.168.10.4 eq tftp (hitcnt=0)

Finally, suppose another new ACE is configured so that it appears at ACL line 2. Notice how the ACEs that were previously at lines 2 and 3 are moved down in the following output, to make room for the new ACE at line 2:

Firewall(config)# access-list test line 2 deny udp 192.168.200.0 255.255.255.0 host
192.168.10.2 eq domain
Firewall(config)# exit
Firewall# show access-list test
access-list test line 1 extended permit tcp any host 192.168.10.1 eq www (hitcnt=1784)
access-list test line 2 extended deny udp 192.168.200.0 255.255.255.0 host 192.168.10.2
eq domain (hitcnt=0)
access-list test line 3 extended permit udp any host 192.168.10.2 eq domain (hitcnt=37465)
access-list test line 4 extended permit tcp any host 192.168.10.3 eq smtp (hitcnt=43544)
access-list test line 5 extended permit udp any host 192.168.10.4 eq tftp (hitcnt=0)

Beginning with ASA 7.0 and FWSM 2.2, you can make an existing ACE inactive without removing it from the ACL configuration. To do this, enter the complete ACE command again, followed by the inactive keyword. The ACE will still be included in the running configuration, but will not be evaluated in the ACL as long as it is inactive. To make the ACE active again, reenter the whole ACE command without the inactive keyword.

To remove an existing ACE, use the no keyword followed by the complete ACE command line. For example, suppose the following access list has been configured on a firewall (notice the extended keyword present in the output):

Firewall# show run access-list acl_outside
access-list acl_outside extended permit ip any any
access-list acl_outside extended permit tcp any host 10.3.3.3 eq www
access-list acl_outside extended permit tcp any host 10.3.3.4 eq smtp

Obviously, the first ACE could pose a security risk because it might allow all types of traffic to pass. Therefore, you could delete that ACE by using the following command:

Firewall# configure terminal
Firewall(config)# no access-list acl_outside extended permit ip any any

Remember to include the extended keyword, so that the entire ACE syntax is matched. No ACL line numbers can be specified when you delete an ACE.

You can also remove an entire access list, including each of its ACE lines, from the running configuration. However, it is a good idea to first make sure the access list is no longer referenced in any other firewall feature or applied to any firewall interface. This prevents a feature from trying to reference an access list that no longer exists.

Then you can use the following command syntax to remove the access list:

ASA, FWSM 2.3+	Firewall(config)# clear configure access-list acl_name
FWSM 2.2-, PIX 6.3	Firewall(config)# no access-list acl_name or Firewall(config)# clear access-list acl_name

Open table as spreadsheet

Notice how the clear configure access-list command is quite different from the no access-list acl_name that you might have expected—the difference in syntax might just prevent you from accidentally deleting a very large or important access list someday!

Suppose you configure an ACL with a name, and you decide that you need to change its name at a later date. Normally, this would be a cumbersome process. You would have to create a new ACL by reentering each of the ACE lines along with the new ACL name and then delete the old ACL.

Beginning with ASA 8.0, you can easily rename an ACL with just one configuration command. Use the following command syntax to change the ACL name from old_acl_name to new_acl_name:

asa(config)# access-list old_acl_name rename new_acl_name

Adding Descriptions to an Access List

Access lists can become very large, especially if your network has many security policies, many hosts, and many types of traffic to protect with a firewall. Large access lists can be difficult to read (for a human) because it might not be clear what a particular ACE is doing or what its original purpose was.

You can add access list entries that contain text descriptions or remarks to provide some readable clues. Remark ACEs can be added anywhere within an access list, provided you can supply a line number when you configure them. As well, you can configure as many remark ACEs as necessary in an access list.

To add a remark ACE to an access list, use the following command:

Firewall(config)# access-list acl_id [line line-num] remark text

A new ACE is added to the access list named acl_id and contains only the word remark followed by the description text (arbitrary text string, 1 to 100 characters). If the line keyword is used, the remark is added just prior to the current ACE at line line-num.

Tip

Remark ACEs are useful as descriptions or reminders of the purpose for the ACE or group of ACEs that follow them. Keep in mind that the remark lines are not tied to actual ACEs; they only occupy space in the ACL. If you remove or relocate an ACE, a remark line might be left behind in its original position. In other words, unless you remove or relocate remark lines and their associated ACEs, the remarks might become confusing or meaningless.

Defining a Time Range to Activate an ACE

Once configured, access list entries are active all the time. Beginning with ASA 7.0 and FWSM 3.1(1), you can use two mechanisms to control whether an ACE is actively being evaluated or not:

• Adding the inactive keyword to an ACE configuration disables it until the keyword is removed.

• Adding a defined time range to an ACE configuration, during which the ACE will be actively used. Outside the time range, the ACE will be inactive.

To control an ACE with a time range, you must configure the time range itself first. You can use the steps that follow to configure a time range. Once configured, the time range must also be applied to specific ACEs, as discussed in the section, “Adding an ACE to an Access List.”

Tip

Because a time range controls the state of access list entries, you should make sure the firewall’s internal clock is set to the correct date and time. Otherwise, the firewall might not provide the proper security policies at the expected times. To learn more about setting the firewall clock and synchronizing it with an accurate, external source, refer to Section “10-1: Managing the Firewall Clock,” in Chapter 10, “Firewall Logging.”

1. Create the time range definition:

   ASA, FWSM	Firewall(config)# time-range name
   PIX 6.3	N/A

   Open table as spreadsheet

   The time range is referenced by its name (arbitrary text string, up to 64 characters).

2. (Optional) Define a recurring time period:

   ASA, FWSM	Firewall(config-time-range)# periodic start-day hh:mm to end-day hh:mm or Firewall(config-time-range)# periodic days-of-the-week hh:mm to hh:mm
   PIX 6.3	N/A

   Open table as spreadsheet

   You can define the time period in two ways. In the first form of the command, a continuous time period is defined. This begins on start-day at time hh:mm (24-hour format) and ends on end-day at time hh:mm (24-hour format). The day parameters can be one of the following: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday. These are not case sensitive and can be abbreviated, as long as they are not ambiguous.

   In the second form, the period lasts from hh:mm to hh:mm (24-hour format, both within the same day), only on the days listed in days-of-the-week. This is one of the following keywords: daily (Monday-Sunday), weekdays(Monday-Friday), or weekends (Saturday-Sunday). You can also use a list of one or more of the following day keywords separated by spaces: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday.

   You can repeat either of these commands in the same time range definition to add more time periods.

   As an example, a time range is configured to define “after hours”. For the weekday (Monday through Friday) period between 5:00pm until 8:00am the following morning, two separate periodic commands must be used. This is because the time between the start and end times cannot cross midnight and into the following day. A third periodic range is given for weekends, from midnight Saturday until 11:59pm Sunday using the following commands:

   Firewall(config)# time-range after_hours
   Firewall(config-time-range)# periodic weekdays 17:00 to 23:59
   Firewall(config-time-range)# periodic weekdays 00:00 to 08:00
   Firewall(config-time-range)# periodic saturday 00:00 to sunday 23:59
   Firewall(config-time-range)# exit
   

3. (Optional) Define an absolute time period:

   ASA, FWSM	Firewall(config-time-range)# absolute [start hh:mm day month year] [end hh:mm day month year]
   PIX 6.3	N/A

   Open table as spreadsheet

   The time period has an absolute starting time and date and an ending time and date. The times are given as hh:mm (24-hour format), and dates as day (1-31), month name, and year (1993-2035).

   If you omit the start limit, the time range begins immediately and runs until the end limit. If you provide a start limit, but omit the end limit, the time range runs indefinitely as soon as the start limit occurs.

   As an example, in the configuration that follows, one time range named Dec2010 is configured to define the entire month of December, 2010. A second time range named End_2010 is configured to start immediately and end at the very end of December, 2010.

   Firewall(config)# time-range Dec2010
   Firewall(config-time-range)# absolute start 00:00 1 december 2010 end 23:59 30
   december 2010
   Firewall(config-time-range)# exit
   Firewall(config)# time-range End_2010
   Firewall(config-time-range)# absolute end 23:59 31 december 2010
   Firewall(config-time-range)# exit
   

4. Reference the time range in an ACE.

   In the ACE configuration, add the time-range name keyword and argument to the access-list ACE command.

Access List Examples

A firewall connects an inside network (192.168.17.0/24) to an outside network. Inside hosts include a DNS server, a mail server, and two other servers that support extranet services. Assume that the inside hosts have a NAT exemption to the outside, such that they maintain their same IP addresses. The outside hosts include two extranet servers on the 172.22.10.0/24 network.

The following rules should be configured on the firewall, as shown by the actual configuration commands:

• ICMP traffic from the outside should be limited to only ICMP echo (ping) requests, ICMP time-exceeded replies (needed for traceroute support), and ICMP unreachables (needed for path MTU discovery).

  Firewall(config)# access-list acl_outside permit icmp any 192.168.17.0 255.255.255.0
  echo
  Firewall(config)# access-list acl_outside permit icmp any 192.168.17.0 255.255.255.0
  time-exceeded
  Firewall(config)# access-list acl_outside permit icmp any 192.168.17.0 255.255.255.0
  unreachable
  

• Only DNS traffic from the outside is permitted to inside host 192.168.17.21.

  Firewall(config)# access-list acl_outside permit udp any host 192.168.17.21 eq domain
  

• Only SMTP, POP3, and NNTP traffic from the outside is permitted to inside host 192.168.17.22.

  Firewall(config)# access-list acl_outside permit tcp any host 192.168.17.22 eq smtp
  Firewall(config)# access-list acl_outside permit tcp any host 192.168.17.22 eq pop3
  Firewall(config)# access-list acl_outside permit tcp any host 192.168.17.22 eq nntp
  

• Outside hosts 172.22.10.41 and 172.22.10.53 are allowed to send SQLnet and FTP packets toward the two inside hosts 192.168.17.100 and 192.168.17.114.

  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.41 host
  192.168.17.100 eq sqlnet
  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.41 host
  192.168.17.100 eq ftp
  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.53 host
  192.168.17.100 eq sqlnet
  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.53 host
  192.168.17.100 eq ftp
  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.41 host
  192.168.17.114 eq sqlnet
  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.41 host
  192.168.17.114 eq ftp
  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.53 host
  192.168.17.114 eq sqlnet
  Firewall(config)# access-list acl_outside permit tcp host 172.22.10.53 host
  192.168.17.114 eq ftp
  

Tip

Notice that only the FTP control port (TCP 21) is specified in the access list, even though a separate FTP data connection is opened on a different port. As long as FTP inspection is enabled with the inspect ftp command, you do not have to explicitly configure the data port in the access list. Instead, the firewall automatically permits the additional inbound FTP data connection when it is negotiated dynamically.

Finally, the access list must be applied to the outside interface, in the inward direction:

Firewall(config)# access-group acl_outside in interface outside

Most of the security policies or rules in this example can be easily configured. The final rule, however, requires a bit more work defining a one-to-one relationship between outside and inside hosts, along with a combination of TCP ports that will be permitted. The more hosts and services you have on each side, the more complicated and lengthy the access list gets. ACL complexity can be greatly reduced by using object groups, as discussed in the following section.

Defining Object Groups

Object groups can be thought of as a type of macro used within access lists. Object groups can contain lists of IP addresses, ICMP types, IP protocols, or ports. You can define several different types of object groups, each containing a list of similar values, as follows:

• Network object group— Contains one or more IP addresses.

• Protocol object group— Contains one or more IP protocols.

• ICMP object group— Contains one or more ICMP types.

• Basic service object group— Contains one or more UDP or TCP port numbers.

• Enhanced service object group— Beginning with ASA 8.0, service object groups can contain any mix of protocols, ICMP types, UDP ports, and TCP ports. Enhanced service object groups can be used for either source or destination services, or both, in the access list configuration.

Object groups can also be nested; that is, one object group can contain members that are themselves object groups of the same type.

Tip

When object groups are configured, it is possible to use the same name for object groups of different types. For example, a network object group might be called “Engineering” and contain IP addresses of hosts in the engineering department. A service (application port) object group could also be called “Engineering”, and contain a set of TCP ports needed in the engineering department. While the firewall might be able to sort out the object groups into the correct types, name duplication can be confusing for human users. It is usually a good idea to add a little tag into each object group’s name to help differentiate their purposes. For example, you could use “Engineering_hosts” and “Engineering_ports”. In fact, beginning with ASA 7.0, all object groups are required to have unique names.

The steps needed to configure each type of object group are presented in the sections that follow. The command syntax is identical on the ASA and FWSM firewall platforms. As soon as an object group is defined or configured, it can be referenced within one or more access lists.

Defining Network Object Groups

You can use the following steps to configure a network object group containing a list of IP addresses.

1. Name the object group:

   Firewall(config)# object-group network group_id
   

   The group is named group_id (arbitrary text string, 1 to 64 characters).

2. (Optional) Add a description:

   Firewall(config-network)# description text
   

   You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.

3. Add an IP address to the list:

   Firewall(config-network)# network-object host ip_addr
   

   or

   Firewall(config-network)# network-object ip_addr mask
   

   The IP address can be given as the host keyword with a single address ip_addr. If you have preconfigured a hostname with the host command, the hostname can be used here. You can also define an IP subnet with a subnet mask, if needed.

   You can repeat this command to define more IP addresses in the object group.

4. (Optional) Reference another network object group:

   Firewall(config-network)# group-object group_id
   

   Sometimes you might define a network object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. This group must be configured before including it here.

   As an example, suppose you need to configure the same access list statement for a list of three IP addresses (192.168.1.10, 192.168.1.20, and 192.168.1.30) and one IP subnet (192.168.2.0/24), all assigned to hosts in the Accounting department. The following network object group could be configured with the list of addresses, prior to applying it within an access list.

   Firewall(config)# object-group network Accounting_addrs
   Firewall(config-network)# description List of Accounting Dept IP addresses
   Firewall(config-network)# network-object host 192.168.1.10
   Firewall(config-network)# network-object host 192.168.1.20
   Firewall(config-network)# network-object host 192.168.1.30
   Firewall(config-network)# network-object 192.168.2.0 255.255.255.0
   Firewall(config-network)# exit
   

   Now suppose that list of addresses is also a part of a larger list containing the hosts of a remote site. A new object group could be configured for the remote site, containing other object groups defined for various departments. You could use the following commands:

   Firewall(config)# object-group network RemoteSite_addrs
   Firewall(config-network)# description List of IP addresses used in the Remote Site
   Firewall(config-network)# group-object Accounting_addrs
   

Defining Protocol Object Groups

You can use the following steps to configure a protocol object group, containing a list of IP protocols.

1. Name the object group:

   Firewall(config)# object group protocol group_id
   

   The group is named group_id (arbitrary text string, 1 to 64 characters).

2. (Optional) Add a description:

   
   Firewall(config-protocol)# description text
   

   You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.

3. Add an IP protocol to the list:

   Firewall(config-protocol)# protocol-object protocol
   

   The IP protocol can be given as protocol, a decimal number (1 to 255), or one of the names listed in Table 6-2. To match any IP protocol, use the value ip.

   Table 6-2: IP Protocol Names/Numbers
   Open table as spreadsheet

   Protocol Name	Protocol Number
   icmp	1
   igmp	2
   ipinip	4
   tcp	6
   igrp	9
   udp	17
   gre or pptp	47
   esp or ipsec	50
   ah	51
   icmp6	58
   eigrp	88
   ospf	89
   nos	94
   pim	103
   pcp	108
   snp	109

   You can repeat this command to define more IP protocols in the group.

4. (Optional) Reference another protocol object group:

   Firewall(config-protocol)# group-object group_id
   

   Sometimes you might define a protocol object group for one purpose and need to include it in a larger protocol object group. You can include another object group by referencing its group name group_id. You must configure this group prior to referencing it.

   As an example, a protocol object group named Tunnels_proto is configured to contain a list of tunneling protocols (GRE, IP-in-IP, ESP, and AH). A second group named Routing_proto contains a list of routing protocols (IGRP, EIGRP, and OSPF). These object groups can then become a part of a larger list called Group1_proto, using the following commands:

   Firewall(config)# object-group protocol Tunnels_proto
   Firewall(config-protocol)# description Tunneling Protocols
   Firewall(config-protocol)# protocol-object gre
   Firewall(config-protocol)# protocol-object ipinip
   Firewall(config-protocol)# protocol-object esp
   Firewall(config-protocol)# protocol-object ah
   Firewall(config-protocol)# exit
   !
   Firewall(config)# object-group protocol Routing_proto
   Firewall(config-protocol)# description Routing Protocols
   Firewall(config-protocol)# protocol-object igrp
   Firewall(config-protocol)# protocol-object eigrp
   Firewall(config-protocol)# protocol-object ospf
   Firewall(config-protocol)# exit
   !
   Firewall(config)# object-group protocol Group1_proto
   Firewall(config-protocol)# description Group1 list of protocols
   Firewall(config-protocol)# group-object Tunnels_proto
   Firewall(config-protocol)# group-object Routing_proto
   

Defining ICMP Type Object Groups

You can use the following steps to configure an ICMP type object group, containing a list of ICMP type values.

1. Name the object group:

   Firewall(config)# object-group icmp-type group_id
   

   The group is named group_id (arbitrary text string, 1 to 64 characters).

2. (Optional) Add a description:

   Firewall(config-icmp-type)# description text
   

   You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.

3. Add an ICMP type to the list:

   Firewall(config-icmp-type)# icmp-object icmp_type
   

   The ICMP type can be given as icmp_type, a number from 0 to 255, or one of the decimal numbers or names listed in Table 6-3.

   Table 6-3: ICMP Type Names/Numbers
   Open table as spreadsheet

   ICMP Type Name	Number
   echo-reply	0
   unreachable	3
   source-quench	4
   redirect	5
   alternate-address	6
   echo	8
   router-advertisement	9
   router-solicitation	10
   time-exceeded	11
   parameter-problem	12
   timestamp-request	13
   timestamp-reply	14
   information-request	15
   information-reply	16
   mask-request	17
   mask-reply	18
   traceroute	30
   conversion-error	31
   mobile-redirect	32

   You can repeat the icmp-object icmp_type command to define more ICMP types in the group.

4. (Optional) Reference another ICMP object group:

   Firewall(config-icmp-type)# group-object group_id
   

   Sometimes you might define an icmp-type object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. You must configure this group before referencing it with the preceding command.

   As an example, an icmp-type object group named “Ping” is configured to contain ICMP types echo and echo-reply. Then that object group is included as a part of a more encompassing icmp-type object group that also contains the unreachable, redirect, and time-exceeded types. You can use the following commands to accomplish this:

   Firewall(config)# object-group icmp-type Ping_icmp
   Firewall(config-icmp)# icmp-object echo
   Firewall(config-icmp)# icmp-object echo-reply
   Firewall(config-icmp)# exit
   !
   Firewall(config)# object-group icmp-type BiggerList_icmp
   Firewall(config-icmp)# group-object Ping_icmp
   Firewall(config-icmp)# icmp-object unreachable
   Firewall(config-icmp)# icmp-object redirect
   Firewall(config-icmp)# icmp-object time-exceeded
   

Defining Basic Service Object Groups

You can use the following steps to configure a service object group, containing a list of port numbers.

1. Name the object group:

   Firewall(config)# object-group service group_id {tcp | udp | tcp-udp}

   The group is named group_id (arbitrary text string, 1 to 64 characters). Ports defined in the group can be used in access list statements that match TCP ports (tcp), UDP ports (udp), or either TCP or UDP port numbers (tcp-udp).

   Tip

   Object groups configured for tcp can be used only in access list statements that match TCP port numbers. Likewise, udp object groups can match only UDP port numbers. If you need to match an application that uses the same port number over both TCP and UDP, you can use the tcp-udp object group. You still need to have separate TCP and UDP access list statements, but they can both reference the same object group.

2. (Optional) Add a description:

   Firewall(config-service)# description text
   

   You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.

3. Add a port number to the list:

   Firewall(config-service)# port-object eq port
   

   or

   Firewall(config-service)# port-object range begin_port end_port
   

   A specific port number can be given with the eq keyword as port, a decimal number or name. With the range keyword, you can also specify a range of port values from begin_port to end_port. Refer to Appendix A for a complete list of well-known protocol and port number keywords supported by Cisco firewalls.

   You can repeat this command to define more IP addresses in the group.

4. (Optional) Reference another basic service object group:

   Firewall(config-service)# group-object group_id
   

   Sometimes you might define a service object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. You must configure this group prior to referencing it.

   As an example, one object group is defined to contain the HTTP and HTTPS TCP ports for web services. A second group is defined to contain the SMTP, POP3, and IMAP4 TCP ports for e-mail services. A third object group is defined to contain both of the other groups, in addition to the TCP port range 2000 through 2002. You can use the following commands to accomplish this:

   Firewall(config)# object-group service Web_ports tcp
   Firewall(config-service)# description TCP ports used by web browsers
   Firewall(config-service)# port-object eq www
   Firewall(config-service)# port-object eq https
   Firewall(config-service)# exit
   !
   Firewall(config)# object-group service Mail_ports tcp
   Firewall(config-service)# description TCP ports used for email
   Firewall(config-service)# port-object eq smtp
   Firewall(config-service)# port-object eq pop3
   Firewall(config-service)# port-object eq imap4
   Firewall(config-service)# exit
   !
   Firewall(config)# object-group service Example_ports tcp
   Firewall(config-service)# description A bunch of TCP ports
   Firewall(config-service)# group-object Web_ports
   Firewall(config-service)# group-object Mail_ports
   Firewall(config-service)# port-object range 2000 2002
   

Defining an Enhanced Service Object Group

Beginning with ASA 8.0, you can define a single enhanced service object group that can contain any combination of protocols, ICMP types, UDP ports, and TCP ports. This is important because it greatly simplifies object group configuration and use.

Use the following steps to configure an enhanced service object group:

1. Name the object group:

   Firewall(config)# object-group service group_id
   

   The group is named group_id (an arbitrary string of 1 to 64 characters). Notice that no other keywords are used to identify the group as a specific type.

2. (Optional) Add a description:

   Firewall(config-service)# description text
   

   You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.

3. Add a service object to the list:

   Firewall(config-service)# service-object protocol [source [src_op] src_port]
   [dest_op] dest_port
   

   In one service object definition, you can identify the protocol, source port, and destination port. The source port information is optional; if you do not provide the source keyword, only the destination port is assumed. If you do provide the source keyword, you need to also supply the source and destination parameters.

   You can use the keywords listed in Table 6-4 when you configure the protocol and port parameters:

   Table 6-4: protocol/port/type Parameter Keywords for Enhanced Service Objects
   Open table as spreadsheet

   protocol Keyword	port or type Keyword
   ah
   eigrp
   esp (same as ipsec)
   gre
   icmp type	0–255 alternate-address, conversion-error, echo, echo-reply, information-reply, information-request, mask-reply, mask-request, mobile-redirect, parameter-problem, redirect, router-advertisement, router-solicitation, source-quench, time-exceeded, timestamp-reply, timestamp-request, traceroute, unreachable
   icmp6 type	0–255 echo, echo-reply, membership-query, membership-reduction, membership-report, neighbor-advertisement, neighbor-redirect, neighbor-solicitation, packet-too-big, parameter-problem, router-advertisement, router-renumbering, router-solicitation, time-exceeded, unreachable
   igmp
   igrp
   ip
   ipinip
   ipsec (same as esp)
   nos
   ospf
   pcp
   pim
   pptp
   snp
   udp port	0–65535 biff, bootpc, bootps, cifs, discard, dnsix, domain, echo, http, isakmp, kerberos, mobile-ip, nameserver, netbios-dgm, netbios-ns, nfs, ntp, pcanywhere-status, pim-auto-rp, radius, radius-acct, rip, secureid-udp, sip, snmp, snmptrap, sunrpc, syslog, tacacs, talk, tftp, time, who, www, xdmcp
   tcp port	0–65535 aol, bgp, chargen, cifs, citrix-ica, cmd, ctiqbe, daytime, discard, domain, echo, exec, finger, ftp, ftp-data, gopher, h323, hostname, http, https, ident, imap4, irc, kerberos, klogin, kshell, ldap, ldaps, login, lotusnotes, lpd, netbios-ssn, nfs, nntp, pcanywhere-data, pim-auto-rp, pop2, pop3, pptp, rsh, rtsp, sip, smtp, sqlnet, ssh, sunrpc, tacacs, talk, telnet, uucp, whois, www
   tcp-udp port	0–65535 cifs, discard, domain, echo,http,kerberos, nfs,pim-auto-rp,sip,sunrpc,tacacs, talk,www

   The source and destination operators, src_op and dest_op, can be given as one of the following keywords:

   • Less Than: lt port

   • Greater Than: gt port

   • Equal To: eq port

   • Not Equal To: neq port

   • Range: range lower upper

4. (Optional) Reference another service object group:

   Firewall(config-service)# group-object group_id
   

   Sometimes you might define a service object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. You must configure this group prior to referencing it.

As an example of an enhanced service object group, suppose you would like to identify packets containing ICMP echo and echo-reply, IPsec ESP (IP protocol 50), ISAKMP (UDP port 500), UDP port 10000, and HTTP. With object groups on a FWSM or an ASA prior to ASA 8.0, you would have to configure individual object groups for each type of traffic, as shown in the following example:

Firewall(config)# object-group icmp test-icmp
Firewall(config-icmp)# description ICMP types to identify
Firewall(config-icmp)# icmp-object echo
Firewall(config-icmp)# icmp-object echo-reply
Firewall(config-icmp)# exit
Firewall(config)# object-group protocol test-protocol
Firewall(config-protocol)# description Protocols to identify
Firewall(config-protocol)# protocol-object esp
Firewall(config-protocol)# exit
Firewall(config)# object-group service test-service1 udp
Firewall(config-service)# description UDP ISAKMP
Firewall(config-service)# port-object eq isakmp
Firewall(config-service)# exit
Firewall(config)# object-group service test-service2 udp
Firewall(config-service)# description UDP 10000
Firewall(config-service)# port-object eq 10000
Firewall(config-service)# exit
Firewall(config)# object-group service test-service3 tcp
Firewall(config-service)# description TCP 80
Firewall(config-service)# port-object eq www
Firewall(config-service)# exit

In contrast, with ASA 8.0, all of the traffic types can be identified using a single enhanced service object group as demonstrated in the configuration that follows. Notice how the configuration is smaller and that only a single object group needs to be referenced.

Firewall(config)# object-group service test
Firewall(config-service)# description Enhanced Service Obj Group
Firewall(config-service)# service-object icmp echo
Firewall(config-service)# service-object icmp echo-reply
Firewall(config-service)# service-object esp
Firewall(config-service)# service-object udp eq isakmp
Firewall(config-service)# service-object udp source 10000
Firewall(config-service)# service-object tcp eq www
Firewall(config-service)# exit

Using Object Groups in an Access List

After you have defined an object group, it must be referenced in an access list before it can be used. You can substitute the object group in place of the appropriate protocol, address, or port parameters within the access-list command syntax. In the complete command syntax that follows, notice the location of each of the regular object group keywords:

Firewall(config)# access-list acl_id [line line-num] [extended] {permit | deny}
  {protocol | object-group protocol_obj_group}
  {source_addr source_mask | object-group network_obj_group} 
  [operator sport | object-group service_obj_group]  
  {destination_addr destination_mask | object-group network_obj_group} 
  [operator dport | object-group service_obj_group] 
  [log [[disable | default] | [level]]] [interval secs]]
  [time-range name] [inactive]

You can substitute the following regular ACE parameters with the object group syntax shown:

Open table as spreadsheet

Regular ACE parameters	Substitute this object group syntax
protocol	object-group protocol_grp_id
icmp icmp-type	object-group icmp_grp_id
address mask	object-group network_grp_id
operator port	object-group service_grp_id

As you begin to use object groups, think of the common things in security policies that can be grouped together: ICMP packet types, inside and/or outside host addresses, protocols, and port numbers. Consider the following example, which is identical to the scenario presented in the “Access List Examples” section.

Firewall(config)# object-group icmp-type allowed-icmp
Firewall(config-icmp)# description ICMP traffic allowed inside
Firewall(config-icmp)# icmp-object echo
Firewall(config-icmp)# icmp-object time-exceeded
Firewall(config-icmp)# icmp-object unreachable
Firewall(config-icmp)# exit
Firewall(config)# object-group service mail-services tcp
Firewall(config-service)# description Email and News services to 192.168.17.22
Firewall(config-service)# port-object eq smtp
Firewall(config-service)# port-object eq pop3
Firewall(config-service)# port-object eq nntp
Firewall(config-service)# exit
Firewall(config)# object-group network extranet-hosts
Firewall(config-network)# description Extranet hosts allowed in for backend services
Firewall(config-network)# network-object host 172.22.10.41
Firewall(config-network)# network-object host 172.22.10.53
Firewall(config-network)# exit
Firewall(config)# object-group network extranet-targets
Firewall(config-network)# description Inside servers supporting extranet servers
Firewall(config-network)# network-object host 192.168.17.110
Firewall(config-network)# network-object host 192.168.17.114
Firewall(config-network)# exit
Firewall(config)# object-group service extranet-services tcp
Firewall(config-service)# description Extranet backend services allowed
Firewall(config-service)# port-object eq sqlnet
Firewall(config-service)# port-object eq ftp
Firewall(config-service)# exit

Now the actual access list is configured, including any references to the object groups that have been configured:

Firewall(config)# access-list acl_outside permit icmp any 192.168.17.0 255.255.255.0
object-group allowed-icmp
Firewall(config)# access-list acl_outside permit udp any host 192.168.17.21 eq domain
Firewall(config)# access-list acl_outside permit tcp any host 192.168.17.22 object-group
mail-services
Firewall(config)# access-list acl_outside permit tcp object-group extranet-hosts object-
group extranet-targets object-group extranet-services

This time, the number of object group commands seems to be lengthy but the access list is rather short. The idea is to make the ACL as short as possible to become more abstract and readable. If you have defined your object groups with meaningful names, you begin to see the access list defined with abstract functions or quantities.

You can always make adjustments to the security policies by adding or deleting lines from object groups. Even if the object group definitions become very lengthy, it does not really impact the firewall’s performance—the overall access list is compiled so that it can match traffic in a consistent amount of time, regardless of the actual ACL length.

Although the access list is much shorter in the running-configuration when it includes object group references, this is primarily for a firewall administrator’s benefit.

Internally, the firewall expands the object groups (even nested ones) out into the full access list configuration. If the firewall is configured to compile ACLs, then the expanded result is compiled and used. You can display the full access list with the show access-list command, as in the following example:

Firewall# show access-list acl_outside
access-list acl_outside; 15 elements

access-list acl_outside line 1 extended permit icmp any 192.168.17.0 255.255.255.0 object-
group allowed-icmp

access-list acl_outside line 1 extended permit icmp any 192.168.17.0 255.255.255.0 echo
(hitcnt=0)

access-list acl_outside line 1 extended permit icmp any 192.168.17.0 255.255.255.0 time-
exceeded (hitcnt=0)

access-list acl_outside line 1 extended permit icmp any 192.168.17.0 255.255.255.0
unreachable (hitcnt=0)

access-list acl_outside line 2 extended permit udp any host 192.168.17.21 eq domain
(hitcnt=0)
access-list acl_outside line 3 extended permit tcp any host 192.168.17.22 object-group
mail-services
access-list acl_outside line 3 extended permit tcp any host 192.168.17.22 eq smtp
(hitcnt=0)
access-list acl_outside line 3 extended permit tcp any host 192.168.17.22 eq pop3
(hitcnt=0)
access-list acl_outside line 3 extended permit tcp any host 192.168.17.22 eq nntp
(hitcnt=0)
access-list acl_outside line 4 extended permit tcp object-group extranet-hosts object-
group extranet-targets object-group extranet-services
access-list acl_outside line 4 extended permit tcp host 172.22.10.41 host 192.168.17.110
eq sqlnet (hitcnt=0)
access-list acl_outside line 4 extended permit tcp host 172.22.10.41 host 192.168.17.110
eq ftp (hitcnt=0)
access-list acl_outside line 4 extended permit tcp host 172.22.10.41 host 192.168.17.114
eq sqlnet (hitcnt=0)
access-list acl_outside line 4 extended permit tcp host 172.22.10.41 host 192.168.17.114
eq ftp (hitcnt=0)
access-list acl_outside line 4 extended permit tcp host 172.22.10.53 host 192.168.17.110
eq sqlnet (hitcnt=0)
access-list acl_outside line 4 extended permit tcp host 172.22.10.53 host 192.168.17.110
eq ftp (hitcnt=0)
access-list acl_outside line 4 extended permit tcp host 172.22.10.53 host 192.168.17.114
eq sqlnet (hitcnt=0)
access-list acl_outside line 4 extended permit tcp host 172.22.10.53 host 192.168.17.114
eq ftp (hitcnt=0)
Firewall#

Even though this access list was reported to have 15 elements (ACEs), notice what has happened with the line numbers. The line numbers follow the ACL in the running configuration, where the object groups have not been expanded. However, in this output, the line numbers do not increment as long as the ACEs are part of the same object-group expansion. This is shown by the shaded text, where “line 1” represents all of the ACEs from the object-group allowed-icmp.

The real beauty of object groups can be seen when you need to make changes to existing firewall rules. For example, suppose you have a host on the DMZ (10.1.1.1) that needs to communicate with another host on the inside (192.168.10.30). With an access list, you might configure these ACEs:

Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq https
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq www
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq sqlnet
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq 5003

That seems straightforward enough, until you need to add a second DMZ host at a later date. You could replicate the four ACE command lines to permit traffic from the new DMZ server, as follows:

Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq https
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq www
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq sqlnet
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.1 host
192.168.10.30 eq 5003
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.2 host
192.168.10.30 eq https
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.2 host
192.168.10.30 eq www
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.2 host
192.168.10.30 eq sqlnet
Firewall(config)# access-list acl_dmz extended permit tcp host 10.1.1.2 host
192.168.10.30 eq 5003

Replicating ACEs might become cumbersome if you continue to add even more DMZ hosts that need the same rules. Even worse, what if you begin adding hosts on the inside that need to receive the same types of traffic from the DMZ hosts?

Instead, you can use object groups to work smarter. Define one network object group for the DMZ hosts and another for the inside hosts:

Firewall(config)# object-group network dmz_hosts
Firewall(config-network)# network-object host 10.1.1.1
Firewall(config-network)# network-object host 10.1.1.2
Firewall(config-network)# exit
Firewall(config)# object-group network inside_hosts
Firewall(config-network)# network-object host 192.168.10.30
Firewall(config-network)# exit
Firewall(config)# access-list acl_dmz extended permit tcp object-group dmz_hosts object-
group inside_hosts eq https
Firewall(config)# access-list acl_dmz extended permit tcp object-group dmz_hosts object-
group inside_hosts eq www
Firewall(config)# access-list acl_dmz extended permit tcp object-group dmz_hosts object-
group inside_hosts eq sqlnet
Firewall(config)# access-list acl_dmz extended permit tcp object-
group dmz_hosts object-group inside_hosts eq 5003

Now when you need to add a new DMZ host, you simply make one addition to the dmz_hosts object group:

Firewall(config)# object-group network dmz_hosts
Firewall(config-network)# network-object host 10.1.1.3
Firewall(config-network)# exit

The firewall automatically expands the object group within the ACL, and the necessary rules are replicated with the new DMZ host address! You can easily add new addresses to the list of inside hosts as well.

You could also carry this idea one step further by creating a service object group that contains all of the TCP ports that are common to the groups of hosts. To do this, you could enter the following configuration commands:

Firewall(config)# object-group service dmz_inside tcp
Firewall(config-service)# port-object eq https
Firewall(config-service)# port-object eq www
Firewall(config-service)# port-object eq sqlnet
Firewall(config-service)# port-object eq 5003
Firewall(config-network)# exit
Firewall(config)# access-list acl_dmz extended permit tcp object-
group dmz_hosts object-group inside_hosts object-group dmz_inside

The basic service object group must be referenced in the place of source or destination ports in the ACE.

Beginning with ASA 8.0, you have the advantage of defining an enhanced service object group that can contain any combination of protocol, source port, and destination port parameters. After you configure an enhanced service object group, you need reference it only once in the access-list command. The firewall takes care of expanding the object group into all of the appropriate parameter locations in the ACE.

This makes the access-list command syntax a little simpler:

Firewall(config)# access-list acl_id [line line-num] [extended] {permit | deny}
  object-group enh_service_obj_group 
  {source_addr source_mask | object-group network_obj_group}
  {destination_addr destination_mask | object-group network_obj_group}
  [log [[disable | default] | [level]]] [interval secs]]
  [time-range name] [inactive]

Notice that the enhanced service object group completely takes the place of the protocol, source port, and destination port parameters.

The following example shows the configuration of an enhanced service object group to identify the ESP protocol; ISAKMP (UDP destination port 500); UDP destination ports 10000 through 10001; TCP destination port 10000; ICMP echo, echo-reply, and time-exceeded types; and connections from TCP source port 5000 to destination port 6970. Then the object group is applied to access list acl_outside from any source address to destination host 10.10.10.10.

Firewall(config)# object-group service group1
Firewall(config-service)# service-object esp
Firewall(config-service)# service-object udp eq isakmp
Firewall(config-service)# service-object udp range 10000 10001
Firewall(config-service)# service-object tcp eq 10000
Firewall(config-service)# service-object icmp echo
Firewall(config-service)# service-object icmp echo-reply
Firewall(config-service)# service-object icmp time-exceeded
Firewall(config-service)# service-object tcp source 5000 6970
Firewall(config-service)# exit
Firewall(config)# access-list acl_outside extended permit object-group group1 any host
10.10.10.10

Because an enhanced service object group is referenced only once in an ACE, it might be confusing how it actually expands within the access list. You can see the final results with the show access-list command:

asa-a/admin# show access-list acl_outside
access-list acl_outside; 8 elements
access-list acl_outside line 1 extended permit object-group group1 any host 10.10.10.10
0x1a469c46
access-list acl_outside line 1 extended permit esp any host 10.10.10.10 (hitcnt=0)
0x6b6ae91e
access-list acl_outside line 1 extended permit udp any host 10.10.10.10 eq isakmp
(hitcnt=0) 0x2b45ae69
access-list acl_outside line 1 extended permit udp any host 10.10.10.10 range 10000 10001
(hitcnt=0) 0x25eb4d7a
access-list acl_outside line 1 extended permit tcp any host 10.10.10.10 eq 10000
(hitcnt=0) 0x1dda7d99
access-list acl_outside line 1 extended permit icmp any host 10.10.10.10 echo (hitcnt=0)
0xa2294c03
access-list acl_outside line 1 extended permit icmp any host 10.10.10.10 echo-reply
(hitcnt=0) 0xb1c482a3
access-list acl_outside line 1 extended permit icmp any host 10.10.10.10 time-exceeded
(hitcnt=0) 0xd8647b13
access-list acl_outside line 1 extended permit tcp any eq 5000 host 10.10.10.10 eq 6970
(hitcnt=0) 0xcc3269c
asa-a/admin#

Logging ACE Activity

By default, no syslog messages are generated for permit ACEs, but each traffic flow that matches a deny ACE triggers a syslog 106023 message (default severity level 4, warnings). If you want to disable syslog completely for an individual ACE, add the log disable keywords. For example, by adding log disable to the following command, the firewall will not generate a syslog message:

Firewall(config)# access-list acl_outside deny icmp any any log disable

Tip

You can also change the severity level of the 106023 message, if the default level 4 is not appropriate. Use the following command: Firewall(config)# logging message 106023 level level The new level is one of the following keywords or numbers: emergencies (0), alerts (1), critical (2), errors (3), warnings (4), notifications (5), informational (6), or debugging (7).

You can also enable syslog activity for both permit and deny conditions. When the log keyword is added to an access-list command, it will enable syslog 106100 messages (default severity 6, informational) for each connection that is permitted or denied by the ACE. Subsequent flows or connections cause the ACE hit count to be incremented.

After a time interval, another syslog 106100 message is generated for the connection, showing the updated hit count. You can use the interval keyword to alter this syslog hold interval to secs (1 to 600 seconds, default 300).

You can also change the syslog severity level for message 106100 by adding the level value (0 to 7, default 6 or “informational”).

Tip

Syslog usage on a Cisco firewall is covered in more detail in Chapter 10.

If the ACE with the log keyword is denying packets, the firewall caches the denied flow so that it can be tracked. Because of this, there must be a limit to the number of cached denied flows to keep the firewall’s memory from becoming exhausted.

After the limit is reached, syslog message 106101 is generated. You can limit the number of cached denied flows with the following command:

Firewall(config)# access-list deny-flow-max n

This sets the maximum number of flows denied by an ACE to n flows. The maximum limit is dependent upon the amount of firewall RAM: 4096 flows (more than 64 MB RAM), 1024 flows (16 MB to 64 MB RAM), or 256 flows (less than 16 MB RAM). On a firewall running PIX 7.0 or later, you can use the access-list deny-flow-max ? command to display the maximum limit value for that platform.

You can also set the cache limit syslog interval with the following command:

Firewall(config)# access-list alert-interval secs

Syslog message 106101 is generated each time the cache limit is reached, but only at an interval of secs (1 to 3600 seconds, default 300).

Monitoring Access Lists

You can review an access list definition by displaying the firewall configuration with this EXEC command:

Firewall# show running-config

or

Firewall# write term

To jump right to the access-list in the configuration, you can use this variation:

Firewall# show running-config | begin access-list [acl_id]

Or to display only the lines of the access-list configuration and nothing else, you can use a further variation:

Firewall# show running-config | include access-list [acl_id]

Beginning with ASA 7.0, you can display an access-list configuration with this command:

Firewall# show running-config access-list [acl_id]

Object groups and access list contents are shown exactly as they were configured. In fact, only the object group references are shown in the ACL configuration; the actual object group definitions are shown in a different point in the configuration. This makes it difficult to review a large access list because you have to refer back and forth between the ACL and any object groups.

After an access list has been configured and applied to an interface, you can monitor its use. Use this EXEC command to see a breakdown of ACL contents and activity counters:

Firewall# show access-list [acl_id]

Each line of the ACL is shown, along with a hit counter indicating how many connections or flows (or packets for ICMP) have been matched by that line. This is shown as “(hitcnt=n)” at the end of each ACE. For example, an access list configured to permit inbound HTTP connections to several web servers is shown to have the following contents and hit counters:

Firewall# show access-list acl_outside
access-list acl_outside line 1 permit tcp any host 192.168.3.16 eq www (hitcnt=97)
access-list acl_outside line 2 permit tcp any host 192.168.3.19 eq www (hitcnt=69513)
access-list acl_outside line 3 permit tcp any host 192.168.3.23 eq www (hitcnt=12)
access-list acl_outside line 4 permit tcp any host 192.168.3.231 eq www (hitcnt=82)
access-list acl_outside line 5 permit tcp any host 192.168.3.242 eq www (hitcnt=27)

From this information, it is clear that host 192.168.3.19 (line 2) is receiving the greatest volume of inbound HTTP connections.

Tip

Beginning with ASA 7.3(1) and FWSM 3.1, each line of the show access-list command output ends with a unique string of hex numbers. For example, see how the following line ends with 0xa2294c03: access-list acl_outside line 5 extended permit tcp any host 192.168.3.242 eq www (hitcnt=27) 0xa2294c03 The hex string listed is the same string that is generated in syslog messages 106023 (deny packet by ACL, default warnings level) and 106100 (deny/permit packet by ACL, default informational level). This does not mean much for human readers, but it gives Adaptive Security Device Manager (ASDM) an easy way to reference syslog messages it collects with the actual ACL lines that generated the messages.

Now suppose that an object group has been configured to list the web servers with the following commands:

Firewall(config)# object-group network web-servers
Firewall(config-network)# network-object host 192.168.3.16
Firewall(config-network)# network-object host 192.168.3.19
Firewall(config-network)# network-object host 192.168.3.23
Firewall(config-network)# network-object host 192.168.3.231
Firewall(config-network)# network-object host 192.168.3.242
Firewall(config-network)# exit
Firewall(config)# access-list acl_outside permit tcp any object-group web-servers eq www

Using the show access-list command also expands any object groups that are referenced in an ACL. This allows you to see the actual ACEs that the firewall is evaluating. In this example, the ACL would be expanded as follows:

Firewall# show access-list acl_outside
access-list acl_outside line 1 permit tcp any object-group web-servers eq www
access-list acl_outside line 1 permit tcp any host 192.168.3.16 eq www (hitcnt=97)
access-list acl_outside line 1 permit tcp any host 192.168.3.19 eq www (hitcnt=69513)
access-list acl_outside line 1 permit tcp any host 192.168.3.23 eq www (hitcnt=12)
access-list acl_outside line 1 permit tcp any host 192.168.3.231 eq www (hitcnt=82)
access-list acl_outside line 1 permit tcp any host 192.168.3.242 eq www (hitcnt=27)

Notice that each line of the output is shown as line 1 of the ACL. Although the object group is expanded and evaluated as sequential ACEs, it appears as the one ACE that referenced it.

Tip

You can reset the hit counters of an ACL by using this command: Firewall# clear access-list acl_id counters In releases prior to ASA 7.0, be careful when you use this command—if you omit the counters keyword, the entire ACL named acl_id is removed from the firewall configuration! ASA 7.0 and later, as well as all releases of FWSM, do not allow this command to be executed unless the counters keyword is included, so you are in no danger of deleting any configuration.