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: Code View: Scroll / Show All

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

[View full size image]

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.)

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.

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.

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:

Code View: Scroll / Show All

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

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.

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.

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:

Code View: Scroll / Show All

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:

Code View: Scroll / Show All

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: Code View: Scroll / Show All

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

Continue reading here: Defining Object Groups

Was this article helpful?

0 0