Basic ACL Configuration

Configuration of ACLs is a two-step process:

Step 1. Create your ACL rules.

Step 2. Activate your ACL rules.

The following sections cover the configuration of ACL rules and their activation. This is an overview process concerning ACLs. Configuring specific types of ACLs, such as extended, reflexive, CBAC, and others, is covered in later chapters.

Creating ACLs

For each protocol that you want to filter, such as IP and IPX, you need to create a separate ACL. Each ACL is basically a grouping of statements that define your filtering rules, where either a number or name is used to group the statements. When using numbers, you cannot just choose any random number to assign to the grouping of your ACL statements. Instead, Cisco has reserved ranges of numbers for different protocols. Table 6-1 lists the numbers that you can use for the various protocols that support ACLs.

The numbers (or names) listed in Table 6-1 are used to group multiple ACL statements in the same group. This enables you to create detailed filtering rules to enforce your security policies.

Generically, the following is the command to create a grouping of ACL statements that use numbers to differentiate between different groups:

Router(config)# access-list ACL_# permit | deny conditions

As you can see from this syntax, the number appears first, followed by the action and, finally, the conditions. Each type of ACL has its own set of valid conditions. These are covered in subsequent chapters on traffic filtering.

Here are some helpful tips when building your ACLs:

• Before creating your ACLs, make sure that you have a picture of the topology of your network in front of you, along with a list of your security policies that you will be enforcing.

• Put your list of security policies in order from most to least restrictive. Then use this list to build your ACL commands.

• With ACL statements that have the same level of restriction, put the statement(s) that are used more often before the ones used less often. This ensures that commonly matched statements are processed first, reducing the burden on your router.

• ACLs support remarks. This enables you to put a brief description before or after any command in your ACL grouping. Use this feature to make your ACL more readable and easier to reference.

• Always create your ACL and then apply it to an interface. By default, empty ACLs permit all traffic. Plus, if you have Telnetted into a router and pasted in an ACL from a text editor, your Telnet connection could break if the empty ACL already was activated on the interface you were using for the Telnet connection.

Activating ACLs

The statements in the ACL grouping will have no impact on the router until you activate them. When you are filtering traffic traveling through the router, you do this by activating the ACL on an interface with the following command:

Router(config)# interface type [slot_#/]port_#

Router(config-if)# protocol_name access-group ACL_#_or_name in | out

For example, if you wanted to activate an IP ACL on your interface, you would use the keyword ip for the protocol_name. Following this, you must specify either the name or number of the ACL that you are activating. Finally, you must specify the direction that the Cisco IOS will use when filtering traffic. If you specify in, the Cisco IOS uses the ACL to filter traffic as packets come into the interface (see Figure 6-2 for the processing of inbound ACLs); if you specify out, the Cisco IOS uses the ACL to filter traffic before it leaves the interface (see Figure 6-3 for the processing of outbound ACLs).

Editing ACLs

You can use two methods to edit groupings of ACL statements:

• Use a text editor for Cisco IOS versions earlier than 12.2(14)S and 12.3(2)T.

• Add, modify, and delete specific ACL entries in Cisco IOS versions 12.2(14)S and 12.3(2)T.

Before Cisco IOS 12.2(14)S and 12.3(2)T, editing ACLs was not a simple process. You could not delete a specific entry (unless the ACL was named), you could not insert an ACL into a specific place in the list (entries always were added to the bottom of the list), and you could not modify an existing entry in the list. Instead, you had to follow these steps to edit your ACL:

Step 1. Either copy the active configuration to a TFTP server (copy running-config tftp or scp?the latter is more secure) and use a text editor, such as Notepad, Wordpad, or any common editor, to extract the ACL statements; or execute the show running-config command, select the ACL statements, and paste them into a text editor.

Step 2. From the text editor, make your ACL changes.

Step 3. Select and copy your changes in your text editor, log back into the router, and access Configuration mode (configure terminal).

Step 4. Go into the interface or interfaces where the ACL was applied, and remove its application (no ip access-group).

Step 5. Delete the access list (no access-list); otherwise, if you pasted in the updated ACL configuration, you would be adding your text editor ACL to the end of the existing ACL on the router. Remember that order is important.

Step 6. Paste your ACL into the router (or use the copy tftp running-config or scp commands to pull in your ACL from your TFTP server).

Step 7. Reactivate the ACL on your router's interface or interfaces (ip access-group).

Step 8. Test your ACL configuration.

Starting with Cisco IOS versions 12.2(14)S and 12.3(2)T, you no longer have to perform these steps when modifying ACLs. Cisco has listened to its customer base and implemented an ACL feature that enables you to modify a specific statement in an ACL, delete one, or insert one at any point in the list. (Since Cisco introduced ACLs in the early 1990s, I have been complaining to any Cisco employee who would listen to me about this annoying approach to editing existing ACLs.) With the new ACL-editing feature, if you need to make only a minor change, such as modify an incorrect line, you can do this with a single command instead of the first seven steps listed earlier. This feature, called sequenced ACLs, is discussed in Chapter 7.