Section 6-3. Controlling Access with Access Lists

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, and a 0 bit ignores), whereas IOS platforms use a wildcard mask (a 0 bit matches, and a 1 bit ignores). Each line of an access list is an ACE.

Cisco firewalls also offer an ACL configuration feature not found in the Cisco IOS software. Access lists can be configured in a modular fashion, using defined object groups as a type of macro.

Object groups can contain lists of IP addresses, ICMP types, IP protocols, or ports. 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 (port) object group could also be called "Engineering" and could contain a set of TCP ports needed in the Engineering department.

Although the firewall might be able to sort 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 to each object group's name to help differentiate their purposes. For example, you could use "Engineering_hosts" and "Engineering_ports." In fact, beginning with PIX 7.0, all object groups are required to have unique names.

Access lists normally are 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. Beginning with FWSM 2.2(1) and PIX 6.2, access lists can be compiled into a more efficient Turbo ACL format. After they are compiled, access lists can be evaluated in a deterministic fashion, without the need to work through each ACE in sequence.

TIP

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 fewer 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 they are edited thereafter. Beginning with PIX 7.0, all access lists are always compiled immediately and automatically.

FWSM 2.x automatically compiles and applies ACLs by default, although you can configure it to use manual compilation instead.

Recompiling an ACL is a silent process, but it can burden an already-loaded firewall CPU. For this reason, you should plan on making ACL changes during a time of low traffic through the firewall.

You can configure an access list to be compiled with the following command:

FWSM 2.x automatic compilation (default)	Firewall(config)# access-list mode auto-commit
FWSM 2.x manual compilation	Firewall(config)# access-list mode manual-commit Firewall(config)# access-list commit
PIX 6.x automatic compilation	Firewall(config)# access-list acl_name compiled
PIX 7.x	(ACLs are always automatically compiled.)

Every access list has an implicit deny all ACE at the end. This entry isn't shown, even though it exists and is active. This is an important thing to keep in mind as you configure an access list. When ACE lines are added to an access list's configuration, they are concatenated to the end of the ACL but before the final implicit deny all.

In releases before PIX 7.0, an ACE is enabled when it is configured as part of an access list. To disable an ACE, you have to remove it from the configuration by reentering it with the no keyword.

Beginning with PIX 7.0, ACEs are still enabled when they are configured. However, you can disable or reenable individual ACEs without removing them from the configuration. To do this, you reenter an ACE with or without the inactive keyword.

PIX 7.0 also introduces the ability to configure individual ACEs so that they are active and evaluated only during a predefined time range.

Access lists are most often used by applying them to firewall interfaces. Before PIX 7.0, access lists could be applied to firewall interfaces only in the inbound direction. To filter traffic leaving an interface, you had to apply an access list to another interface (in the inbound direction) on the "other side" of the firewall. Beginning with PIX 7.0, access lists can be applied to interfaces in the inbound and outbound directions independently.

Defining Object Groups

Object groups can be thought of as a type of macro used within access lists. 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

• ICMP object group Contains one or more ICMP types

• Protocol object group Contains one or more IP protocols

• Service object group Contains one or more UDP or TCP port numbers

The steps needed to configure each type of object group are presented in the following sections. The command syntax is identical on every Cisco firewall platform. After 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 (an arbitrary text string of 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 host name with the host command, the host name 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 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. You must configure this group before including it here. For 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. You could configure the following network object group with the list of addresses before 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 Now suppose that this list of addresses is also part of a larger list containing the hosts of a remote site. A new object group could be configured for the remote site, containing the object groups of 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 ICMP Type Object Groups

You can follow these 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 (an arbitrary text string of 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, one of the decimal numbers or names listed in Table 6-2.

Table 6-2. ICMP Type Names and Numbers

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 this command to define more ICMP types in the group.

4.

(Optional) Reference another 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.

For example, suppose an icmp-type object group named Ping is configured to contain ICMP types echo and echo-reply. Then that object group is included as 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 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 (an arbitrary text string of 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-3. To match any IP protocol, use the value ip.

Table 6-3. IP Protocol Names and Numbers

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 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 object group. You can include another object group by referencing its group name group_id. You must configure this group before referencing it.

For 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 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 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 (an arbitrary text string of 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 The port number can be given as port, a decimal number or name. You can also specify a range of port values ranging 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 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 before referencing it. For example, suppose 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

Configuring an Access List

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

You define access lists 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 in which 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 in which ACEs appear in an access list is important. This is because access lists are evaluated line by line in sequential order.

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 isn't explicitly permitted by an ACE somewhere in the access list is denied by this final implicit ACE.

You can also remove an ACE or insert an ACE at a specific location in an access list. These tasks are covered in the next section.

TIP

PIX access lists are always assumed to use the "extended" format, where both source and destination addresses and ports can be specified. However, FWSM and PIX (beginning with PIX 7.0) firewalls can support both "standard" and "extended" forms, although standard ACLs are reserved for use with routing protocols.

If you have PIX 7.0, you might be wise to begin using the extended keyword when you configure, edit, or delete ACE commands. Even if you don't 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, because it must be given from the command line.

Manipulating Access Lists

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

The ACL line numbers aren't 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:

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

To see the ACL line numbers, use the show access-list command:

 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) 

Finally, if a new ACE is configured at line 2, notice how the previous ACEs at lines 2 and 3 are moved down:

 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) 

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 running PIX 7.0 (notice the extended keyword):

 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 poses a security risk and should be removed. To delete that ACE, you should use the following command:

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

To remove an entire access list from the running configuration, 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:

FWSM 2.x	Firewall(config)# no access-list acl_name or Firewall(config)# clear access-list acl_name
PIX 6.x	Firewall(config)# no access-list acl_name or Firewall(config)# clear access-list acl_name
PIX 7.x	Firewall(config)# clear configure access-list acl_name

Finally, beginning with PIX 7.0, you can make an ACE inactive by entering the complete ACE command followed by the inactive keyword. The ACE is included in the running configuration but is not be evaluated as long as it is inactive.

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 for a person to read 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 that you can supply a line number when you configure them. 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:

FWSM 2.x	Firewall(config)# access-list acl_id remark text
PIX 6.x	Firewall(config)# access-list acl_id [line line-num] remark text
PIX 7.x	Firewall(config)# access-list acl_id [line line-num] remark text

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

NOTE

Remark ACEs are useful as descriptions or reminders of the purpose of the ACE or group of ACEs that follow them. Keep in mind that remark lines aren't tied to actual ACEs; they occupy space only 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

After they are configured, access list entries are active all the time. Beginning with PIX 7.0, you can use two mechanisms to control whether an ACE is actively being evaluated:

• You can add the inactive keyword to an ACE configuration to disable it until the keyword is removed.

• You can add a defined time range to an ACE configuration during which the ACE is actively evaluated. Outside the time range, the ACE is inactive.

To control an ACE with a time range, you must configure the time range itself first. You can use the following steps to configure a time range. After it is configured, the time range must also be applied to specific ACEs, as discussed in the next section.

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 9-1, "Managing the Firewall Clock," in Chapter 9, "Firewall Logging."

1.

Create the time range definition:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config)# time-range name

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

2.

(Optional) Define a recurring time period:

FWSM 2.x
PIX 6.x
PIX 7.x	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

You can define the time period in two ways. The first form of the command defines a continuous time period. 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 through Sunday), weekdays (Monday through Friday), or weekends (Saturday and 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.

For example, suppose a time range is configured to define "after hours." For the weekday (Monday through Friday) period between 5 p.m. and 8 a.m. the following morning, you must use two separate periodic commands. This is because the time between the start and end times can't cross midnight and into the following day. A third periodic range is given for weekends, from midnight Saturday until 11:59 p.m. 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:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-time-range)# absolute [start hh:mm day month year] [end hh:mm day month year]

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 the dates are given as day (1 to 31), month name, and year (1993 to 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 after the start limit occurs.

For example, in the following configuration, a time range named Dec2005 is configured to define the entire month of December 2005. A second time range named End_2005 is configured to start immediately and end at the very end of December 2005:

 Firewall(config)# time-range Dec2005 Firewall(config-time-range)# absolute start 00:00 1 december 2005 end   23:59 30 december 2005 Firewall(config-time-range)# exit Firewall(config)# time-range End_2005 Firewall(config-time-range)# absolute end 23:59 31 december 2005 Firewall(config-time-range)# exit 

Adding an ACE to an Access List

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

FWSM 2.x	[View full width] Firewall(config)# access-list acl_id [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]]
PIX 6.x	[View full width] Firewall(config)# access-list acl_id [line line-num] {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]]
PIX 7.x	[View full width] 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]

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). You can build an access list from many different keywords, parameters, and object groups. You might find Figure 6-11 helpful, because it shows the basic ACE syntax and how each portion can be configured. The figure is based on the PIX 7.x command syntax, although the syntax from all the firewall platforms is very similar.

Figure 6-11. Cisco Firewall ACE Structure and Composition

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.

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.

If you have defined an object group, you can reference the group within the access list. Just replace the appropriate access list parameter with object-group group_id, where group_id is the name of the object group.

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 e-mail servers, for example. You should always define an ACE with the most specific source and destination information possible. The goal is to define the strictest 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 (RFC 2827) or use IP addresses set aside for private network use (RFC 1918). For example, the following ACEs can be used to deny RFC 1918 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 

This could also be configured by referencing a network object group, which would simplify the access list:

 Firewall(config)# object-group network rfc1918 Firewall(config-network)# network-object 10.0.0.0 255.0.0.0 Firewall(config-network)# network-object 172.16.0.0 255.240.0.0 Firewall(config-network)# network-object 192.168.0.0 255.255.0.0 Firewall(config-network)# exit Firewall(config)# access-list anti_spoof deny ip object-group rfc1918 any 

The matched protocol can be ip (any IP protocol), tcp (6), udp (17), ah (51), eigrp (88), esp (50), gre (47), igmp (2), igrp (9), ipinip (4), nos (94), ospf (89), pcp (108), snp (109), or icmp (1). You can also specify the protocol as a decimal number (0 through 255) to identify a protocol that doesn't 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 don't use the "inverted" masks required by routers running the 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 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

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). You can provide port numbers as predefined keywords or as decimal numbers. Appendix A lists the keywords supported by Cisco firewalls.

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

If you have defined object groups to be used in the access list, you can use them in the access-list command by substituting the regular ACE protocol, address, or port operators with object group references, as listed in Table 6-4.

Table 6-4. Substituting Object Group Syntax for Regular ACE Parameters

Regular ACE Parameter	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

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.

You should configure the following rules on the firewall, as shown by the actual configuration commands:

• ICMP traffic from the outside should be limited to 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 fixup protocol ftp (FWSM 2.x or PIX 6.x) or inspect ftp (PIX 7.x) command, you don't 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, you must apply the access list to the outside interface in the inward direction:

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

You can easily configure most of the security policies or rules in this example. 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 are permitted. The more hosts and services you have on each side, the more complicated and lengthy the access list gets.

Now consider the same scenario with the advantage of using object groups. You can group several common things in the policies:

• ICMP packet types

• Inside and/or outside host addresses

• Port numbers

You can configure the same functionality by using the following commands, beginning with object group definition:

 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 you configure the actual access list, 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 to and from object groups. Even if the object group definitions become very lengthy, it doesn't really affect the firewall's performance. The overall access list should be compiled so that it can match traffic in a consistent amount of time, regardless of the ACL length.

In PIX 6.x, you need to add the access-list acl_outside compiled command to the configuration. In FWSM 2.x, all access lists are compiled automatically by default. If manual compilation mode has been configured with the access-list mode manual-commit command, you must manually trigger the compilation with the access-list commit command. Beginning with PIX 7.0, all access lists are automatically and transparently compiled without the need for any extra commands or manual intervention.

TIP

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) into the full access list configuration. If the firewall is configured to compile ACLs, 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 don't 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 the ACEs from the object group allowed-icmp.

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 (the default severity level is 4, warnings). If you want to disable Syslog for an individual ACE, add the log disable keywords. For example, when you add log disable to the following command, the firewall does 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 inappropriate. 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. Adding the log keyword to an access-list command enables Syslog 106100 messages (the default severity is 6, informational) for each connection that the ACE permits or denies. 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; the default is 300).

You can also change the Syslog severity level for message 106100 by adding the level value (0 to 7; the default is 6, informational).

NOTE

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

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, you must configure a limit to the number of cached denied flows to keep the firewall's memory from becoming exhausted.

As soon as 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 command sets the maximum number of flows denied by an ACE to n flows. The maximum limit depends on 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; the default is 300).

Monitoring Access Lists

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

 Firewall# show running-config 

or

 Firewall# write term 

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

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

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 PIX 7.0, you can display an access list configuration with the following 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 you have configured and applied an access list to an interface, you can monitor the use of the access list. Use the following 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.

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 an ACL's hit counters by using the following command:

 Firewall# clear access-list acl_id counters 

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!