Chapter 3. Advanced IPv4 Access Control Lists

This chapter covers the following exam topics:

5.0 Security Fundamentals

5.6 Configure and verify access control lists

IPv4 ACLs are either standard or extended ACLs, with standard ACLs matching only the source IP address, and extended matching a variety of packet header fields. At the same time, IP ACLs are either numbered or named. Figure 3-1 shows the categories and the main features of each as introduced in the previous chapter.

An illustration of the features of the four categories of IP ACL.

Figure 3-1 Comparisons of IP ACL Types

This chapter discusses the other three categories of ACLs beyond standard numbered IP ACLs and ends with a few miscellaneous features to secure Cisco routers and switches.

“Do I Know This Already?” Quiz

Take the quiz (either here or use the PTP software) if you want to use the score to help you decide how much time to spend on this chapter. The letter answers are listed at the bottom of the page following the quiz. Appendix C, found both at the end of the book as well as on the companion website, includes both the answers and explanations. You can also find both answers and explanations in the PTP testing software.

Table 3-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section

Questions

Extended IP Access Control Lists

1–3

Named ACLs and ACL Editing

4–6

1. Which of the following fields cannot be compared based on an extended IP ACL? (Choose two answers.)

  1. Protocol

  2. Source IP address

  3. Destination IP address

  4. TOS byte

  5. URL

  6. Filename for FTP transfers

2. Which of the following access-list commands permit packets going from host 10.1.1.1 to all web servers whose IP addresses begin with 172.16.5? (Choose two answers.)

  1. access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www

  2. access-list 1951 permit ip host 10.1.1.1 172.16.5.0 0.0.0.255 eq www

  3. access-list 2523 permit ip host 10.1.1.1 eq www 172.16.5.0 0.0.0.255

  4. access-list 2523 permit tcp host 10.1.1.1 eq www 172.16.5.0 0.0.0.255

  5. access-list 2523 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www

3. Which of the following access-list commands permits packets going to any web client from all web servers whose IP addresses begin with 172.16.5?

  1. access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www

  2. access-list 1951 permit ip host 10.1.1.1 172.16.5.0 0.0.0.255 eq www

  3. access-list 2523 permit tcp any eq www 172.16.5.0 0.0.0.255

  4. access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq www 172.16.5.0 0.0.0.255

  5. access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq www any

4. In a router running a recent IOS version (at least version 15.0), an engineer needs to delete the second line in ACL 101, which currently has four commands configured. Which of the following options could be used? (Choose two answers.)

  1. Delete the entire ACL and reconfigure the three ACL statements that should remain in the ACL.

  2. Delete one line from the ACL using the no access-list… global command.

  3. Delete one line from the ACL by entering ACL configuration mode for the ACL and then deleting only the second line based on its sequence number.

  4. Delete the last three lines from the ACL from global configuration mode, and then add the last two statements back into the ACL.

5. Refer to the following command output, which details an ACL enabled on port G0/0 for the inbound direction. Which answers list a configuration mode and command that would result in the deletion of the line that matches subnet 172.16.1.0/24? (Choose two answers.)

Click here to view code image

    show ip access-lists dikta-list
    Standard IP access list dikta-list
       10 permit 172.16.1.0, wildcard bits 0.0.0.255
       20 permit 172.16.2.0, wildcard bits 0.0.0.255
       30 permit 172.16.3.0, wildcard bits 0.0.0.255
  1. In global config mode: no 10

  2. In interface G0/0 config mode: no 10

  3. In ACL dikta-list config mode: no 10

  4. In ACL dikta-list config mode: no permit 172.16.1.0 0.0.0.255

  5. In global config mode: no permit 172.16.1.0 0.0.0.255

6. An engineer configures an ACL but forgets to save the configuration. At that point, which of the following commands display the configuration of an IPv4 ACL, including line numbers? (Choose two answers.)

  1. show running-config

  2. show startup-config

  3. show ip access-lists

  4. show access-lists

Answers to the “Do I Know This Already?” quiz:

1 E, F

2 A, E

3 E

4 A, C

5 C, D

6 C, D

Foundation Topics

Extended Numbered IP Access Control Lists

Extended IP access lists have many similarities compared to the standard numbered IP ACLs discussed in the previous chapter. Just like standard IP ACLs, you enable extended access lists on interfaces for packets either entering or exiting the interface. IOS searches the list sequentially. Extended ACLs also use first-match logic, because the router stops the search through the list as soon as the first statement is matched, taking the action defined in the first-matched statement. All these features are also true of standard numbered access lists (and named ACLs).

Extended ACLs differ from standard ACLs mostly because of the larger variety of packet header fields that can be used to match a packet. One extended ACE (ACL statement) can examine multiple parts of the packet headers, requiring that all the parameters be matched correctly to match that one ACE. That powerful matching logic makes extended access lists both more useful and more complex than standard IP ACLs.

Matching the Protocol, Source IP, and Destination IP

Like standard numbered IP ACLs, extended numbered IP ACLs also use the access-list global command. The syntax is identical, at least up through the permit or deny keyword. At that point, the command lists matching parameters, and those differ, of course. In particular, the extended ACL access-list command requires three matching parameters: the IP protocol type, the source IP address, and the destination IP address.

The IP header’s Protocol field identifies the header that follows the IP header. Figure 3-2 shows the location of the IP Protocol field, the concept of it pointing to the type of header that follows, along with some details of the IP header for reference.

A figure shows an overview of the IP header and the next header in the extended numbered IP Access Control Lists (ACLs).

Figure 3-2 IP Header, with Focus on Required Fields in Extended IP ACLs

IOS requires that you configure parameters for the three highlighted parts of Figure 3-2. For the protocol type, you simply use a keyword, such as tcp, udp, or icmp, matching IP packets that happen to have a TCP, UDP, or ICMP header, respectively, following the IP header. Or you can use the keyword ip, which means “all IPv4 packets.” You also must configure some values for the source and destination IP address fields that follow; these fields use the same syntax and options for matching the IP addresses as discussed in Chapter 2, “Basic IPv4 Access Control Lists.Figure 3-3 shows the syntax.

Key Topic.
A figure shows the required fields in extended ACL syntax.

Figure 3-3 Extended ACL Syntax, with Required Fields

Note

When matching IP addresses in the source and destination fields, there is one difference with standard ACLs: When matching a specific IP address, the extended ACL requires the use of the host keyword. You cannot simply list the IP address alone.

Table 3-2 lists several sample access-list commands that use only the required matching parameters. Feel free to cover the right side and use the table for an exercise, or just review the explanations to get an idea for the logic in some sample commands.

Table 3-2 Extended access-list Commands and Logic Explanations

access-list Statement

What It Matches

access-list 101 deny tcp any any

Any IP packet that has a TCP header

access-list 101 deny udp any any

Any IP packet that has a UDP header

access-list 101 deny icmp any any

Any IP packet that has an ICMP header

access-list 101 deny ip host 1.1.1.1 host 2.2.2.2

All IP packets from host 1.1.1.1 going to host 2.2.2.2, regardless of the header after the IP header

access-list 101 deny udp 1.1.1.0 0.0.0.255 any

All IP packets that have a UDP header following the IP header, from subnet 1.1.1.0/24, and going to any destination

The last entry in Table 3-2 helps make an important point about how IOS processes extended ACLs:

Key Topic.

In an extended ACL access-list command, all the matching parameters must match the packet for the packet to match the command.

For example, in that last example from Table 3-2, the command checks for UDP, a source IP address from subnet 1.1.1.0/24, and any destination IP address. If a packet with source IP address 1.1.1.1 were examined, it would match the source IP address check, but if it had a TCP header instead of UDP, it would not match this access-list command. All parameters must match.

Matching TCP and UDP Port Numbers

Extended ACLs can also examine parts of the TCP and UDP headers, particularly the source and destination port number fields. The port numbers identify the application that sends or receives the data.

The most useful ports to check are the well-known ports used by servers. For example, web servers use well-known port 80 by default. Figure 3-4 shows the location of the port numbers in the TCP header, following the IP header.

Key Topic.
A figure depicts the IP header and the TCP header in the extended numbered IP Access Control Lists (ACLs).

Figure 3-4 IP Header, Followed by a TCP Header and Port Number Fields

When an extended ACL command includes either the tcp or udp keyword, that command can optionally reference the source and/or destination port. To make these comparisons, the syntax uses keywords for equal, not equal, less than, greater than, and for a range of port numbers. In addition, the command can use either the literal decimal port numbers or more convenient keywords for some well-known application ports. Figure 3-5 shows the positions of the source and destination port fields in the access-list command and these port number keywords.

Key Topic.
A figure depicts the TCP and UDP port numbers enabled in extended ACL syntax.

Figure 3-5 Extended ACL Syntax with TCP and UDP Port Numbers Enabled

For example, consider the simple network shown in Figure 3-6. The FTP server sits on the right, with the client on the left. The figure shows the syntax of an ACL that matches the following:

  • Packets that include a TCP header

  • Packets sent from the client subnet

  • Packets sent to the server subnet

  • Packets with TCP destination port 21 (FTP server control port)

A network diagram shows the process of filtering packets based on the destination port.

Figure 3-6 Filtering Packets Based on Destination Port

To fully appreciate the matching of the destination port with the eq 21 parameters, consider packets moving from left to right, from PC1 to the server. Assuming the server uses well-known port 21 (FTP control port), the packet’s TCP header has a destination port value of 21. The ACL syntax includes the eq 21 parameters after the destination IP address. The position after the destination address parameters is important: that position identifies the fact that the eq 21 parameters should be compared to the packet’s destination port. As a result, the ACL statement shown in Figure 3-6 would match this packet and the destination port of 21 if used in any of the four locations implied by the four dashed arrowed lines in the figure.

Conversely, Figure 3-7 shows the reverse flow, with a packet sent by the server back toward PC1. In this case, the packet’s TCP header has a source port of 21, so the ACL must check the source port value of 21, and the ACL must be located on different interfaces. In this case, the eq 21 parameters follow the source address field but come before the destination address field.

Key Topic.
A network diagram shows the process of filtering packets based on the source port.

Figure 3-7 Filtering Packets Based on Source Port

When examining ACLs that match port numbers, first consider the location and direction in which the ACL will be applied. That direction determines whether the packet is being sent to the server or from the server. At that point, you can decide whether you need to check the source or destination port in the packet. For reference, Table 3-3 lists many of the popular port numbers and their transport layer protocols and applications. Note that the syntax of the access-list commands accepts both the port numbers and a shorthand version of the application name.

Table 3-3 Popular Applications and Their Well-Known Port Numbers

Port Number(s)

Protocol

Application

access-list Command Keyword

20

TCP

FTP data

ftp-data

21

TCP

FTP control

ftp

22

TCP

SSH

23

TCP

Telnet

telnet

25

TCP

SMTP

smtp

53

UDP, TCP

DNS

domain

67

UDP

DHCP Server

bootps

68

UDP

DHCP Client

bootpc

69

UDP

TFTP

tftp

80

TCP

HTTP (WWW)

www

110

TCP

POP3

pop3

161

UDP

SNMP

snmp

443

TCP

SSL

514

UDP

Syslog

16,384–32,767

UDP

RTP (voice, video)

Table 3-4 lists several sample access-list commands that match based on port numbers. Cover the right side of the table, and try to characterize the packets matched by each command. Then check the right side of the table to see if you agree with the assessment.

Table 3-4 Extended access-list Command Examples and Logic Explanations

access-list Statement

What It Matches

access-list 101 deny tcp any gt 49151 host 10.1.1.1 eq 23

Packets with a TCP header, any source IP address, with a source port greater than (gt) 49151, a destination IP address of exactly 10.1.1.1, and a destination port equal to (eq) 23.

access-list 101 deny tcp any host 10.1.1.1 eq 23

The same as the preceding example, but any source port matches, because that parameter is omitted in this case.

access-list 101 deny tcp any host 10.1.1.1 eq telnet

The same as the preceding example. The telnet keyword is used instead of port 23.

access-list 101 deny udp 1.0.0.0 0.255.255.255 lt 1023 any

A packet with a source in network 1.0.0.0/8, using UDP with a source port less than (lt) 1023, with any destination IP address.

Extended IP ACL Configuration

Because extended ACLs can match so many different fields in the various headers in an IP packet, the command syntax cannot be easily summarized in a single generic command. However, the two commands in Table 3-5 summarize the syntax options as covered in this book.

Table 3-5 Extended IP Access List Configuration Commands

Command

Configuration Mode and Description

access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [log | log-input]

Global command for extended numbered access lists. Use a number between 100 and 199 or 2000 and 2699, inclusive.

access-list access-list-number {deny | permit} {tcp | udp} source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established] [log]

A version of the access-list command with parameters specific to TCP and/or UDP.

The configuration process for extended ACLs mostly matches the same process used for standard ACLs. You must choose the location and direction in which to enable the ACL, particularly the direction, so that you can characterize whether certain addresses and ports will be either the source or destination. Configure the ACL using access-list commands, and when complete, then enable the ACL using the same ip access-group command used with standard ACLs. All these steps mirror what you do with standard ACLs; however, when configuring, keep the following differences in mind:

Key Topic.
  • Place extended ACLs as close as possible to the source of the packets that will be filtered. Filtering close to the source of the packets saves some bandwidth.

  • Remember that all fields in one access-list command must match a packet for the packet to be considered to match that access-list statement.

  • Use numbers of 100–199 and 2000–2699 on the access-list commands; no one number is inherently better than another.

Extended IP Access Lists: Example 1

This example focuses on understanding basic syntax. In this case, the ACL denies Bob access to all FTP servers on R1’s Ethernet, and it denies Larry access to Server1’s web server. Figure 3-8 shows the network topology; Example 3-1 shows the configuration on R1.

A network diagram shows example 1 for Extended IP Access Lists.

Figure 3-8 Network Diagram for Extended Access List Example 1

Example 3-1 R1’s Extended Access List: Example 1

interface Serial0
 ip address 172.16.12.1 255.255.255.0
 ip access-group 101 in
!
interface Serial1
 ip address 172.16.13.1 255.255.255.0
 ip access-group 101 in
!
access-list 101 remark Stop Bob to FTP servers, and Larry to Server1 web
access-list 101 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp
access-list 101 deny tcp host 172.16.2.10 host 172.16.1.100 eq www
access-list 101 permit ip any any

The first ACL statement prevents Bob’s access to FTP servers in subnet 172.16.1.0. The second statement prevents Larry’s access to web services on Server1. The final statement permits all other traffic.

If we focus on the syntax for a moment, we can see several new items to review. First, the access-list number for extended access lists falls in the range of 100 to 199 or 2000 to 2699. Following the permit or deny action, the protocol parameter defines whether you want to check for all IP packets or specific headers, such as TCP or UDP headers. When you check for TCP or UDP port numbers, you must specify the TCP or UDP protocol. Both FTP and the web use TCP.

This example uses the eq parameter, meaning “equals,” to check the destination port numbers for FTP control (keyword ftp) and HTTP traffic (keyword www). You can use the numeric values—or, for the more popular options, a more obvious text version is valid. (If you were to type eq 80, the config would show eq www.)

This example enables the ACL in two places on R1: inbound on each serial interface. These locations achieve the goal of the ACL. However, that initial placement was made to make the point that Cisco suggests that you locate them as close as possible to the source of the packet. Therefore, Example 3-2 achieves the same goal as Example 3-1 of stopping Bob’s access to FTP servers at the main site, and it does so with an ACL on R3.

Example 3-2 R3’s Extended Access List Stopping Bob from Reaching FTP Servers Near R1

interface Ethernet0
 ip address 172.16.3.1 255.255.255.0
 ip access-group 103 in

access-list 103 remark deny Bob to FTP servers in subnet 172.16.1.0/24
access-list 103 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp
access-list 103 permit ip any any

The new configuration on R3 meets the goals to filter Bob’s traffic, while also meeting the overarching design goal of keeping the ACL close to the source of the packets. ACL 103 on R3 looks a lot like ACL 101 on R1 from Example 3-1, but this time, the ACL does not bother to check for the criteria to match Larry’s traffic, because Larry’s traffic will never enter R3’s Ethernet 0 interface. ACL 103 filters Bob’s FTP traffic to destinations in subnet 172.16.1.0/24, with all other traffic entering R3’s E0 interface making it into the network.

Extended IP Access Lists: Example 2

Example 3-3, based on the network shown in Figure 3-9, shows another example of how to use extended IP access lists. This example uses the following criteria:

  • Sam is not allowed access to the subnet of Bugs or Daffy.

  • Hosts on the Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet.

  • All other combinations are allowed.

A network diagram shows example 2 for Extended IP Access Lists.

Figure 3-9 Network Diagram for Extended Access List Example 2

Example 3-3 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 the Cisco design guideline of placing extended ACLs as close as possible to the source of the traffic. The ACL filters packets that enter Yosemite’s E0 interface, which is the first router interface that packets sent by Sam enter. If the route between Yosemite and the other subnets changes over time, the ACL still applies. 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.

Practice Building access-list Commands

Table 3-6 supplies a practice exercise to help you get comfortable with the syntax of the extended access-list command, particularly with choosing the correct matching logic. Your job: create a one-line extended ACL that matches the packets. The answers are in the section “Answers to Earlier Practice Problems,” later in this chapter. Note that if the criteria mention a particular application protocol, for example, “web client,” that means to specifically match for that application protocol.

Table 3-6 Building One-Line Extended ACLs: Practice

Problem

Criteria

1

From web client 10.1.1.1, sent to a web server in subnet 10.1.2.0/24.

2

From Telnet client 172.16.4.3/25, sent to a Telnet server in subnet 172.16.3.0/25. Match all hosts in the client’s subnet as well.

3

ICMP messages from the subnet in which 192.168.7.200/26 resides to all hosts in the subnet where 192.168.7.14/29 resides.

4

From web server 10.2.3.4/23’s subnet to clients in the same subnet as host 10.4.5.6/22.

5

From Telnet server 172.20.1.0/24’s subnet, sent to any host in the same subnet as host 172.20.44.1/23.

6

From web client 192.168.99.99/28, sent to a web server in subnet 192.168.176.0/28. Match all hosts in the client’s subnet as well.

7

ICMP messages from the subnet in which 10.55.66.77/25 resides to all hosts in the subnet where 10.66.55.44/26 resides.

8

Any and every IPv4 packet.

Named ACLs and ACL Editing

Now that you have a good understanding of the core concepts in IOS IP ACLs, this section examines a few enhancements to IOS support for ACLs: named ACLs and ACL editing with sequence numbers. Although both features are useful and important, neither adds any function as to what a router can and cannot filter. Instead, named ACLs and ACL sequence numbers make it easier to remember ACL names and edit existing ACLs when an ACL needs to change.

Named IP Access Lists

Named IP ACLs have many similarities with numbered IP ACLs. They can be used for filtering packets, plus for many other purposes. They can match the same fields as well: standard numbered ACLs can match the same fields as a standard named ACL, and extended numbered ACLs can match the same fields as an extended named ACL.

Of course, there are differences between named and numbered ACLs. Named ACLs originally had three big differences compared to numbered ACLs:

Key Topic.
  • Using names instead of numbers to identify the ACL, making it easier to remember the reason for the ACL

  • Using ACL subcommands, not global commands, to define the action and matching parameters

  • Using ACL editing features that allow the CLI user to delete individual lines from the ACL and insert new lines

You can easily learn named ACL configuration by just converting numbered ACLs to use the equivalent named ACL configuration. Figure 3-10 shows just such a conversion, using a simple three-line standard ACL number 1. To create the three permit subcommands for the named ACL, you literally copy parts of the three numbered ACL commands, beginning with the permit keyword.

A figure shows the configurations of named ACL and numbered ACL.

Figure 3-10 Named ACL Versus Numbered ACL Configuration

The only truly new part of the named ACL configuration is the ip access-list global configuration command. This command defines whether an ACL is a standard or extended ACL and defines the name. It also moves the user to ACL configuration mode, as shown in upcoming Example 3-4. Once in ACL configuration mode, you configure permit, deny, and remark commands that mirror the syntax of numbered ACL access-list commands. If you’re configuring a standard named ACL, these commands match the syntax of standard numbered ACLs; if you’re configuring extended named ACLs, they match the syntax of extended numbered ACLs.

Example 3-4 shows the configuration of a named extended ACL. Pay particular attention to the configuration mode prompts, which show ACL configuration mode.

Example 3-4 Named Access List Configuration

Router# configure terminal
Enter configuration commands, one per line. End with CNTL/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
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)# 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:

! lines omitted for brevity

interface serial 1
 ip access-group barney out
!
ip access-list extended barney
 permit tcp host 10.1.1.2 eq www any
 deny   udp host 10.1.1.1 10.1.2.0 0.0.0.255
 deny   ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
 deny   ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255
 permit ip any any

Example 3-4 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, five different permit and deny statements define the matching logic and action to be taken upon a match. The show running-config command output lists the named ACL configuration before the single entry is deleted.

Named ACLs allow the user to delete and add new lines to the ACL from within ACL configuration mode. Example 3-5 shows how, with the no deny ip… command deleting a single entry from the ACL. Notice that the output of the show access-list command at the end of the example still lists the ACL, with four permit and deny commands instead of five.

Example 3-5 Removing One Command from a Named ACL

Router# configure terminal
Enter configuration commands, one per line. End with CNTL/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
    10 permit tcp host 10.1.1.2 eq www any
    20 deny   udp host 10.1.1.1 10.1.2.0 0.0.0.255
    30 deny   ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
    50 permit ip any any

Editing ACLs Using Sequence Numbers

Numbered ACLs have existed in IOS since the early days of Cisco routers and IOS; however, for many years, through many IOS versions, the ability to edit a numbered IP ACL was poor. For example, to simply delete a line from the ACL, the user had to delete the entire ACL and then reconfigure it.

The ACL editing feature uses an ACL sequence number that is added to each ACL permit or deny statement, with the numbers representing the sequence of statements in the ACL. ACL sequence numbers provide the following features for both numbered and named ACLs:

Key Topic.

New configuration style for numbered: Numbered ACLs use a configuration style like named ACLs, as well as the traditional style, for the same ACL; the new style is required to perform advanced ACL editing.

Deleting single lines: An individual ACL permit or deny statement can be deleted with a no sequence-number subcommand.

Inserting new lines: Newly added permit and deny commands can be configured with a sequence number before the deny or permit command, dictating the location of the statement within the ACL.

Automatic sequence numbering: IOS adds sequence numbers to commands as you configure them, even if you do not include the sequence numbers.

To take advantage of the ability to delete and insert lines in an ACL, both numbered and named ACLs must use the same overall configuration style and commands used for named ACLs. The only difference in syntax is whether a name or number is used. Example 3-6 shows the configuration of a standard numbered IP ACL, using this alternative configuration style. The example shows the power of the ACL sequence number for editing. In this example, the following occurs:

Step 1. Numbered ACL 24 is configured using this new-style configuration, with three permit commands.

Step 2. The show ip access-lists command shows the three permit commands with sequence numbers 10, 20, and 30.

Step 3. The engineer deletes only the second permit command using the no 20 ACL subcommand, which simply refers to sequence number 20.

Step 4. The show ip access-lists command confirms that the ACL now has only two lines (sequence numbers 10 and 30).

Step 5. The engineer adds a new deny command to the beginning of the ACL, using the 5 deny 10.1.1.1 ACL subcommand.

Step 6. The show ip access-lists command again confirms the changes, this time listing three commands, sequence numbers 5, 10, and 30.

Note

For this example, note that the user does not leave configuration mode, instead using the do command to tell IOS to issue the show ip access-lists EXEC command from configuration mode.

Example 3-6 Editing ACLs Using Sequence Numbers

! Step 1: The 3-line Standard Numbered IP ACL is configured.
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip access-list standard 24
R1(config-std-nacl)# permit 10.1.1.0 0.0.0.255
R1(config-std-nacl)# permit 10.1.2.0 0.0.0.255
R1(config-std-nacl)# permit 10.1.3.0 0.0.0.255

! Step 2: Displaying the ACL's contents, without leaving configuration mode.
R1(config-std-nacl)# do show ip access-lists 24
Standard IP access list 24
    10 permit 10.1.1.0, wildcard bits 0.0.0.255
    20 permit 10.1.2.0, wildcard bits 0.0.0.255
    30 permit 10.1.3.0, wildcard bits 0.0.0.255

! Step 3: Still in ACL 24 configuration mode, the line with sequence number 20 is deleted.
R1(config-std-nacl)# no 20

! Step 4: Displaying the ACL's contents again, without leaving configuration mode.
! Note that line number 20 is no longer listed.
R1(config-std-nacl)#do show ip access-lists 24
Standard IP access list 24
    10 permit 10.1.1.0, wildcard bits 0.0.0.255
    30 permit 10.1.3.0, wildcard bits 0.0.0.255

! Step 5: Inserting a new first line in the ACL.
R1(config-std-nacl)# 5 deny 10.1.1.1

! Step 6: Displaying the ACL's contents one last time, with the new statement
!(sequence number 5) listed first.
R1(config-std-nacl)# do show ip access-lists 24
Standard IP access list 24
     5 deny 10.1.1.1
    10 permit 10.1.1.0, wildcard bits 0.0.0.255
    30 permit 10.1.3.0, wildcard bits 0.0.0.255

Note that although Example 3-6 uses a numbered ACL, named ACLs use the same process to edit (add and remove) entries.

Numbered ACL Configuration Versus Named ACL Configuration

As a brief aside about numbered ACLs, note that IOS actually allows two ways to configure numbered ACLs in the more recent versions of IOS. First, IOS supports the traditional method, using the access-list global commands shown earlier in Examples 3-1, 3-2, and 3-3. IOS also supports the numbered ACL configuration with commands just like named ACLs, as shown in Example 3-6.

Oddly, IOS always stores numbered ACLs with the original style of configuration, as global access-list commands, no matter which method is used to configure the ACL. Example 3-7 demonstrates these facts, picking up where Example 3-6 ended, with the following additional steps:

Step 7. The engineer lists the configuration (show running-config), which lists the old-style configuration commands—even though the ACL was created with the new-style commands.

Step 8. The engineer adds a new statement to the end of the ACL using the old-style access-list 24 permit 10.1.4.0 0.0.0.255 global configuration command.

Step 9. The show ip access-lists command confirms that the old-style access-list command from the previous step followed the rule of being added only to the end of the ACL.

Step 10. The engineer displays the configuration to confirm that the parts of ACL 24 configured with both new-style commands and old-style commands are all listed in the same old-style ACL (show running-config).

Example 3-7 Adding to and Displaying a Numbered ACL Configuration

! Step 7: A configuration snippet for ACL 24.
R1# show running-config
! The only lines shown are the lines from ACL 24
access-list 24 deny 10.1.1.1
access-list 24 permit 10.1.1.0 0.0.0.255
access-list 24 permit 10.1.3.0 0.0.0.255

! Step 8: Adding a new access-list 24 global command
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# access-list 24 permit 10.1.4.0 0.0.0.255
R1(config)# ^Z

! Step 9: Displaying the ACL's contents again, with sequence numbers. Note that even
! the new statement has been automatically assigned a sequence number.
R1# show ip access-lists 24
Standard IP access list 24
     5 deny 10.1.1.1
    10 permit 10.1.1.0, wildcard bits 0.0.0.255
    30 permit 10.1.3.0, wildcard bits 0.0.0.255
    40 permit 10.1.4.0, wildcard bits 0.0.0.255

! Step 10: The numbered ACL config remains in old-style configuration commands.
R1# show running-config
! The only lines shown are the lines from ACL 24
access-list 24 deny   10.1.1.1
access-list 24 permit 10.1.1.0 0.0.0.255
access-list 24 permit 10.1.3.0 0.0.0.255
access-list 24 permit 10.1.4.0 0.0.0.255

ACL Implementation Considerations

ACLs can be a great tool to enhance the security of a network, but engineers should think about some broader issues before simply configuring an ACL to fix a problem. To help, Cisco makes the following general recommendations in the courses on which the CCNA exam is based:

Key Topic.
  • Place extended ACLs as close as possible to the source of the packet. This strategy allows ACLs to discard the packets early.

  • Place standard ACLs as close as possible to the destination of the packet. This strategy avoids the mistake with standard ACLs (which match the source IPv4 address only) of unintentionally discarding packets that did not need to be discarded.

  • Place more specific statements early in the ACL.

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

The first point deals with the concept of where to locate your ACLs. If you intend 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, the second point seems to contradict the first point, at least for standard ACLs, to locate them close to the destination. Why? 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 example, 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 courses make a blanket recommendation to locate standard ACLs closer to the destination to avoid filtering traffic you do not mean to filter.

For the third item in the list, by placing more specific matching parameters early in each list, you are less likely to make mistakes in the ACL. For example, imagine that the ACL first listed a command that permitted traffic going to 10.1.1.0/24, and the second command denied traffic going to host 10.1.1.1. Packets sent to host 10.1.1.1 would match the first command, and never match the more specific second command. Note that later IOS versions prevent this mistake during configuration in some cases.

Finally, Cisco recommends that you disable the ACLs on the interfaces before you change the statements in the list. By doing so, you avoid issues with the ACL during an interim state. First, if you delete an entire ACL and leave the IP ACL enabled on an interface with the ip access-group command, IOS does not filter any packets (that was not always the case in far earlier IOS versions)! As soon as you add one ACL command to that enabled ACL, however, IOS starts filtering packets based on that ACL. Those interim ACL configurations could cause problems.

For example, suppose you have ACL 101 enabled on S0/0/0 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/0/0 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.

Additional Reading on ACLs

Cisco has long included IP ACLs in the CCNA exam. Preceding the current CCNA 200-301 exam, the CCNA R&S 200-125 exam included IP ACL troubleshooting. If you would like to learn more about ACLs, particularly about troubleshooting ACLs, as well as some unexpected behavior with ACLs and router-generated packets, refer to the section titled “Troubleshooting with IPv4 ACLs,” in Appendix D, “Topics from Previous Editions.

Chapter Review

One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material using either the tools in the book or interactive tools for the same material found on the book’s companion website. Refer to the “Your Study Plan” element for more details. Table 3-7 outlines the key review elements and where you can find them. To better track your study progress, record when you completed these activities in the second column.

Table 3-7 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review key topics

 

Book, website

Review key terms

 

Book, website

Repeat DIKTA questions

 

Book, PTP

Review memory tables

 

Book, website

Review command tables

 

Book

Review All the Key Topics

Table 3-8 Key Topics for Chapter 3

Key Topic.

Key Topic Element

Description

Page Number

Figure 3-3

Syntax and notes about the three required matching fields in the extended ACL access-list command

47

Paragraph

Summary of extended ACL logic that all parameters must match in a single access-list statement for a match to occur

48

Figure 3-4

Drawing of the IP header followed by a TCP header

48

Figure 3-5

Syntax and notes about matching TCP and UDP ports with extended ACL access-list commands

48

Figure 3-7

Logic and syntax to match TCP source ports

49

List

Guidelines for using extended numbered IP ACLs

51

List

Differences between named and numbered ACLs when named ACLs introduced

55

List

Features enabled by ACL sequence numbers

57

List

ACL implementation recommendations

60

Key Terms You Should Know

extended access list

named access list

Command References

Tables 3-9 and 3-10 list configuration and verification commands used in this chapter. As an easy review exercise, cover the left column in a table, read the right column, and try to recall the command without looking. Then repeat the exercise, covering the right column, and try to recall what the command does.

Table 3-9 Chapter 3 ACL Configuration Command Reference

Command

Description

access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [log]

Global command for extended numbered access lists. Use a number between 100 and 199 or 2000 and 2699, inclusive.

access-list access-list-number {deny | permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [log]

A version of the access-list command with TCP-specific parameters.

access-list access-list-number remark text

Command that defines a remark to help you remember what the ACL is supposed to do.

ip access-group {number | name [in | out]}

Interface subcommand to enable access lists.

access-class number | name [in | out]

Line subcommand to enable either standard or extended access lists on vty lines.

ip access-list {standard | extended} name

Global command to configure a named standard or extended ACL and enter ACL configuration mode.

{deny | permit} source [source wildcard] [log]

ACL mode subcommand to configure the matching details and action for a standard named ACL.

{deny | permit} protocol source source-wildcard destination destination-wildcard [log]

ACL mode subcommand to configure the matching details and action for an extended named ACL.

{deny | permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [log]

ACL mode subcommand to configure the matching details and action for a named ACL that matches TCP segments.

remark text

ACL mode subcommand to configure a description of a named ACL.

Table 3-10 Chapter 3 EXEC Command Reference

Command

Description

show ip interface [type number]

Includes a reference to the access lists enabled on the interface

show access-lists [access-list-number | access-list-name]

Shows details of configured access lists for all protocols

show ip access-lists [access-list-number | access-list-name]

Shows IP access lists

Answers to Earlier Practice Problems

Table 3-11 lists the answers to the practice problems listed in Table 3-6. Note that for any question that references a client, you might have chosen to match port numbers greater than 49151, matching all dynamic ports. The answers in this table mostly ignore that option, but just to show one sample, the answer to the first problem lists one with a reference to client ports greater than 49151 and one without. The remaining answers simply omit this part of the logic.

Table 3-11 Building One-Line Extended ACLs: Answers

 

Criteria

1

access-list 101 permit tcp host 10.1.1.1 10.1.2.0 0.0.0.255 eq www

or

access-list 101 permit tcp host 10.1.1.1 gt 49151 10.1.2.0 0.0.0.255 eq www

2

access-list 102 permit tcp 172.16.4.0 0.0.0.127 172.16.3.0 0.0.0.127 eq telnet

3

access-list 103 permit icmp 192.168.7.192 0.0.0.63 192.168.7.8 0.0.0.7

4

access-list 104 permit tcp 10.2.2.0 0.0.1.255 eq www 10.4.4.0 0.0.3.255

5

access-list 105 permit tcp 172.20.1.0 0.0.0.255 eq 23 172.20.44.0 0.0.1.255

6

access-list 106 permit tcp 192.168.99.96 0.0.0.15 192.168.176.0 0.0.0.15 eq www

7

access-list 107 permit icmp 10.55.66.0 0.0.0.127 10.66.55.0 0.0.0.63

8

access-list 108 permit ip any any

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.192.15.251