Miscellaneous ACL Topics 443

Example 12-8 Yosemite Configuration for Extended Access List Example 2

interface ethernet 0 ip access-group 110 in

!

access-list 110 deny ip host 10.1.2.1 10.1.1.0 0.0.0.255 access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255 access-list 110 permit ip any any

This configuration solves the problem with few statements while keeping to Cisco’s design guideline of placing extended ACLs as close to the source of the traffic as possible. The ACL filters packets that enter Yosemite’s E0 interface, which is the first router interface the packets sent by Sam touch. The issue of having packets “routed around” access lists on serial interfaces is taken care of with the placement on Yosemite’s only Ethernet interface. Also, the filtering mandated by the second requirement (to disallow Seville’s LAN hosts from accessing Yosemite’s) is met by the second access-list statement. Stopping packet flow from Yosemite’s LAN subnet to Seville’s LAN subnet stops effective communication between the two subnets. Alternatively, the opposite logic could have been configured at Seville.

Miscellaneous ACL Topics

This short section covers a couple of small topics, including named access lists, filtering Telnet traffic, and some general implementation guidelines for ACLs.

Named IP Access Lists

Named ACLs can be used to match the same packets, with the same parameters, you can match with standard and extended IP ACLs. Named IP ACLs do have some differences, however, some of which make them easier to work with. The most obvious difference is that IOS identifies named ACLs using names you make up, as opposed to numbers—and you have a better chance of remembering names. Named ACLs also have another key feature that numbered ACLs do not: You can delete individual lines in a named IP access list.

With numbered ACLs, if you enter no access-list 101 and then enter the rest of the command, you don’t just delete that single line—you delete the whole list! With named ACLs, you can enter a command that removes individual lines in an ACL. Other than that, the only differences are the changes in the configuration syntax.

The configuration syntax is very similar between named and numbered IP access lists. The items that can be matched with a numbered standard IP access list are identical to the items

444 Chapter 12: IP Access Control List Security

that can be matched with a named standard IP access list. Likewise, the items are identical with both numbered and named extended IP access lists.

Two important configuration differences exist between numbered and named access lists. One key difference is that named access lists use a global command that places the user in a named IP access list submode, under which the matching and permit/deny logic is configured. The other key difference is that when a named matching statement is deleted, only that one statement is deleted. With numbered lists, the deletion of any statement in the list deletes all the statements in the list. (This feature is demonstrated in more detail in an upcoming example.)

Example 12-9 shows an example that uses named IP ACLs. It shows the changing command prompt in configuration mode, showing that the user has been placed in ACL configuration mode. It also lists the pertinent parts of the output of a show running-configuration command. It ends with an example of how you can delete individual lines in a named ACL.

Example 12-9 Named Access List Configuration

conf t

Enter configuration commands, one per line. End with Ctrl-Z.

Router(config)#ip access-list extended barney

Router(config-ext-nacl)#permit tcp host 10.1.1.2 eq www any

Router(config-ext-nacl)#deny udp host 10.1.1.1 10.1.2.0 0.0.0.255

Router(config-ext-nacl)#deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255

!The next statement is purposefully wrong so that the process of changing

!the list can be seen.

Router(config-ext-nacl)#deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255

Router(config-ext-nacl)#deny ip host 10.1.1.130 host 10.1.3.2

Router(config-ext-nacl)#deny ip host 10.1.1.28 host 10.1.3.2

Router(config-ext-nacl)#permit ip any any

Router(config-ext-nacl)#interface serial1

Router(config-if)#ip access-group barney out

Router(config-if)#^Z

Router#show running-config

Building configuration...

Current configuration:

.

. (unimportant statements omitted)

.

interface serial 1

ip access-group barney out

!

Miscellaneous ACL Topics 445

Example 12-9 Named Access List Configuration (Continued)

ip access-list extended barney

Router#conf t

Enter configuration commands, one per line. End with Ctrl-Z.

Router(config)#ip access-list extended barney

Router(config-ext-nacl)#no deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255

Router(config-ext-nacl)#^Z

Router#show access-list

Extended IP access list barney

Example 12-9 begins with the creation of an ACL named Barney. The ip access-list extended barney command creates the ACL, naming it barney and placing the user in ACL configuration mode. This command also tells the IOS that barney is an extended ACL. Next, seven different permit and deny statements define the matching logic and action to be taken upon a match. The permit and deny commands use the exact same syntax that the numbered access-list commands use, starting with the deny and permit keywords. In this example, a comment is added just before the command that is deleted later in the example.

The show running-config command output lists the named ACL configuration before the single entry is deleted. Next, the no deny ip... command deletes a single entry from the ACL.

Notice that the output of the show running-config command still lists the ACL, with six permit and deny commands instead of seven.

The ACL, as shown here, does not actually filter any packets. It would need to be enabled on an interface first. For instance, the ip access-group barney out interface subcommand would enable the ACL.

446 Chapter 12: IP Access Control List Security

Controlling Telnet Access with ACLs

Access into and out of the virtual terminal line (vty) ports of the Cisco IOS software can be controlled by IP access lists. IOS uses vtys to represent a user who has Telnetted to a router, as well as for Telnet sessions a user of a router has created to other devices. You can use ACLs to limit the IP hosts that can Telnet into the router, and you can also limit the hosts to which a user of the router can Telnet.

For instance, imagine that only hosts in subnet 10.1.1.0/24 are supposed to be able to Telnet into any of the Cisco routers in a network. In such a case, the configuration shown in Example 12-10 could be used on each router to deny access from IP addresses not in that subnet.

Example 12-10 vty Access Control Using the access-class Command

line vty 0 4 login password cisco

access-class 3 in

!

! Next command is a global command access-list 3 permit 10.1.1.0 0.0.0.255

The access-class command refers to the matching logic in access-list 3. The keyword in refers to Telnet connections into this router—in other words, people Telnetting into this router. As configured, ACL 3 checks the source IP address of packets for incoming Telnet connections.

If the command access-class 3 out had been used, it would have checked for not only outgoing Telnets, but also the packets’ destination IP address. Conceptually, checking the source IP address, which by definition must be one of the interface IP addresses in that router, would not really make any sense for the function desired. For filtering outgoing Telnet sessions, it makes the most sense to filter based on the destination IP address. So, the use of the access-class 3 out command, particularly the out keyword, is one of those rare cases in which a standard IP ACL actually looks at the destination IP address and not the source.

ACL Implementation Considerations

In production IP networks, IP ACL creation, troubleshooting, and updates can consume a large amount of time and effort. I have met people over the years who work in large IP networks whose jobs were nothing but figuring out what to do with IP ACLs in Cisco routers! The ICND exam does not have many questions about things to watch for when you implement IP ACLs in live networks, but it does cover a few small items, which are discussed in this final section of the chapter.

Miscellaneous ACL Topics 447

Cisco makes the following general recommendations, as mentioned in the ICND course, upon which CCNA is partly based:

■Create your ACLs using a text editor outside the router, and copy and paste the configurations into the router.

■Place extended ACLs as close to the source of the packet as possible to discard the packets quickly.

■Place standard ACLs as close to the packet’s destination as possible, because standard ACLs often discard packets that you do not want discarded when they are placed close to the source.

■Place more-specific statements early in the ACL.

■Disable an ACL from its interface (using the no ip access-group command) before making changes to it.

The first suggestion states that you should create the ACLs outside the router using an editor. That way, if you make mistakes when typing, you can fix them in the editor. Why the big deal for ACLs? Well, with numbered ACLs, to delete a single line, you have to delete the whole ACL and reenter all the commands—in order. Also, even if you create the ACL correctly, you might later want to add a line to it—in the middle of the list! If you do, with numbered ACLs, you have to delete the whole list and then reenter all the lines in order. Having the ACLs stored somewhere outside the routers makes your life easier.

The second and third points deal with the concept of where to locate your ACLs. If you are going to filter a packet, filtering closer to the packet’s source means that the packet takes up less bandwidth in the network, which seems to be more efficient—and it is. Therefore, Cisco suggests locating extended ACLs as close to the source as possible.

However, Cisco also suggests, at least in the CCNA-related courses, to locate standard ACLs close to the destination. Why not close to the source of the packets? Well, because standard ACLs look only at the source IP address, they tend to filter more than you want filtered when placed close to the source. For instance, imagine that Fred and Barney are separated by four routers. If you filter Barney’s traffic sent to Fred on the first router, Barney can’t reach any hosts near the other three routers. So the Cisco ICND course makes a blanket recommendation to locate standard ACLs closer to the destination to avoid filtering traffic you don’t mean to filter.

By placing more-specific matching parameters early in each list, you are less likely to make mistakes in the ACL. For instance, imagine that you have a statement that permits all traffic from 10.1.1.1 to 10.2.2.2, destined for port 80 (the web), and another statement that denies all other packets sourced in subnet 10.1.1.0/24. Both statements would match packets sent

448 Chapter 12: IP Access Control List Security

by host 10.1.1.1 to a web server at 10.2.2.2, but you probably meant to match the morespecific statement (permit) first. In general, placing the more-specific statements first tends to ensure that you don’t miss anything.

Finally, Cisco recommends that you disable the ACLs on the interfaces before you change the statements in the list. Thankfully, if you have an IP ACL enabled on an interface with the ip access-group command, and you delete the entire ACL, IOS does not filter any packets. (That was not always the case in earlier IOS versions!) Even so, as soon as you add a command to the ACL, the IOS starts filtering packets. Suppose you have ACL 101 enabled on S0 for output packets. You delete list 101 so that all packets are allowed through. Then you enter a single access-list 101 command. As soon as you press Enter, the list exists, and the router

filters all packets exiting S0 based on the one-line list. If you want to enter a long ACL, you might temporarily filter packets you don’t want to filter! Therefore, the better way is to disable the list from the interface, make the changes to the list, and then reenable it on the interface.