Expert Reference Series of White Papers. Access Control Lists (ACLs)

Transcription

1 Expert Reference Series of White Papers Access Control Lists (ACLs) COURSES

2 Access Control Lists (ACLs) Al Friebe, Global Knowledge Instructor Introduction In this white paper, we ll take a look at access control lists, often referred to as access lists or ACLs (sometimes pronounced ackels ). In Cisco IOS, ACLs are used for many things, including but not limited to: Filtering data packets (firewalling) Controlling Telnet or SSH access to a router or switch Filtering routing protocols Specifying Quality of Service (QoS) Controlling encryption Controlling NAT (Network Address Translation) Controlling Dial-on-Demand The idea of an access list is straightforward: it permits some things, and denies others. What exactly is being permitted or denied varies according to the application of the ACL. Although access lists for other protocols (such as IPX, AppleTalk, MAC addresses, etc.) exist, we ll be focusing on IP access lists. In general, only routers and multi-layer switches understand IP access lists (but some Layer-2 switches are ACL-aware to some extent). IP Access Lists For example, let s say that traffic originating from a host with IP address should be permitted to leave the FastEthernet0/0 interface. An ACL that would accomplish this would be: Router#configure terminal Router(config)#access-list 1 permit The ACL resides in the running config, and can be seen with the command show access-lists. There are various options for this command, including show ip access-lists, show access-lists X where X is the ACL identifier, etc. The ACL created above is now resident in memory, but will not take effect until it is placed into service in some manner. To place it outbound on the FastEthernet0/0 interface, the commands would be: Router(config)#interface fastethernet0/0 Router(config-if)#ip access-group 1 out Copyright 2009 Global Knowledge Training LLC. All rights reserved. 2

3 To see the access lists that are outgoing or inbound on an interface, use the command show ip interface. Note that the ip is required (if you don t specify the protocol, it won t show you the ACL information). This command also has options, such as the particular interface you re interested in, such as sh ip int f0/0. As usual, commands can be abbreviated, so to create and apply the ACL, you could simply do: Router#conf t Router(config)#access-l 1 per Router(config)#int f0/0 Router(config-if)#ip access-g 1 o Find some shortcuts that work for you, and then use them! In the ACL we created above, we have explicitly permitted traffic originating from the host with IP address , but what about other traffic? The default behavior of an access list is to deny all traffic that is not referenced by the list. In other words, it s as if there is a deny everything else at the bottom of the list. This is much better than having to deny every other IP address, of which there are over four billion possibilities! It s commonly desired to permit and/or deny multiple hosts in a single list. What if we want to permit more hosts? Simply add more lines to the list. This can be accomplished by going back into global config mode and adding the lines. Building on the single line list from above, let s add lines to ACL 1 to also permit packets from the hosts with addresses and Router#conf t Router(config)#access-list 1 permit Router(config)#access-list 1 permit If we examine ACL 1 with show access-list, we ll see that it now contains three lines, for , 2, and 3. It s important to realize that because the same ACL number was used for each line, all lines belong to that access list (ACL 1, in this case). Note that if the list is in effect on the interface while we are editing it, the changes take effect immediately (this can be dangerous, as we ll discuss in the future). Let s create another ACL, this one denying traffic from the hosts with addresses , , and , and permitting all other addresses. Since this is a separate ACL, we ll use access list number 2: Router#conf t Router(config)#access-list 2 deny Router(config)#access-list 2 deny Router(config)#access-list 2 deny The list we ve just created will deny traffic from the specified hosts, but what about traffic from other hosts? Remember that ACLs deny all traffic that they don t explicitly permit, as if there was a deny everything else at Copyright 2009 Global Knowledge Training LLC. All rights reserved. 3

4 the bottom. In other words, this list denies all traffic! Obviously, we need to permit traffic from the other hosts, but it would be unreasonable to list the billions of them individually. Instead, we can use the any keyword, thus: Router(config)#access-list 2 permit any HINT: An ACL that contains only deny statements is either incomplete, or wrong! Our ACL 2 will now deny traffic from the , 2 and 3 hosts, but permit traffic sourced from any other host. Again, as with ACL 1, the list doesn t actually take effect until it is placed in effect. Let s place it inbound on Serial 2/1. Router(config)#int s2/1 Router(config-if)#ip access-group 2 in As before, we can see the list with sh access-l 2, and see its application on the interface with sh ip int s2/1. To summarize the basics of access lists, ACLs Are created in global config mode End with an implicit deny any (which can be overridden) Must be placed into service somewhere to have any effect Thus, the commands Router#conf t Router(config)#access-list 3 deny Router(config)#access-list 3 deny Router(config)#access-list 3 deny Router(config)#access-list 3 permit any Router(config)#interface g1/2 Router(config-if)#ip access-group 3 out will create an ACL 3 (denying traffic from hosts , 2 and 3, while permitting all other traffic), and place it in service on the GigEthernet1/2 interface in the outbound direction. Wildcard Mask (WCM) An ACL placed inbound on a router interface will control the traffic that s allowed to enter the router via that interface. You would think, therefore, that an ACL placed outbound on a router interface (such as ACL 3 above) would likewise control the traffic that s allowed to leave the router via that interface. This is also true, except for traffic that was generated by the router itself. In other words, an outbound ACL will affect only traffic attempting to transit the router, not traffic originated by the router. Copyright 2009 Global Knowledge Training LLC. All rights reserved. 4

5 Let s look at another example. In this case, we d like to use ACL 4 inbound on the Serial 1/1 interface to permit traffic from all hosts on the network, and deny all other traffic. We could start as before: Router#conf t Router(config)#access-list 4 permit Router(config)#access-list 4 permit But wait, the Class C network covers 254 hosts ( through ), which would require 254 lines in the ACL. Obviously listing each host address one by one is a non-scalable solution (and imagine what would happen with a Class B or a Class A network). What we need is a system to shorten the list. Such a system exists, and it makes use of a wildcard mask. The rules for IPv4 wildcard masks are simple. Wildcard masks are 32 bits long (just like IPv4 addresses). A 0 bit in a WCM means match the corresponding address bit. A 1 bit in a WCM means ignore the corresponding address bit. WCMs are represented in dotted-decimal (just like IPv4 addresses). WCMs follow addresses. Okay, let s use a WCM to solve our example. What we want is to match the first three octets (the part), and ignore the fourth octet. Thus, we could match the entire network like this: Router(config)#access-list 4 permit How does it work? In ACL 4, you see that there is an address ( ), followed by a wildcard mask ( ). The first octet of the dotted-decimal WCM is a 0, which represents eight binary 0s. Since a 0 in a WCM means match, these eight 0s in the WCM mean match the first octet of the address (the 192 part). Likewise, the second and third octets of the WCM are also 0s, meaning that the second and third octets of the address (168 and 1, respectively) must be matched exactly. Finally, the fourth octet of the WCM is a 255, which is all 1s in binary. Since a 1 means ignore, the ACL ignores the entire last octet of the address, meaning that it could have any value (0 through 255). Since this covers the range of legal host addresses on network , it meets the requirements stated above. The only thing left to do is to place the ACL in service on the interface. Router(config)#int serial 1/1 Router(config-if)#ip access-group 4 in Those of us who are particularly geeky, might have noticed that the permit statement above not only permits the range of legal hosts, it also permits the reserved addresses of and (the network and broadcast addresses). Since those addresses will never be assigned to hosts, this isn t an operational problem. And one more thing, you ll recall that the default subnet mask for a Class C network is If we simply flip the bits of the subnet mask (0s become 1s, 1s become 0s), we d have , which is the wildcard mask we want. More on this later! Copyright 2009 Global Knowledge Training LLC. All rights reserved. 5

6 Note that we can also represent the permit any at the end of ACL 3 as: Router(config)#access-list 3 permit While this is syntactically correct, if you type it into a router, IOS will display it as permit any (which is easier to read), so that s the way you might as well enter it. Now that we have a neat method of representing large blocks of addresses, let s write and apply an ACL that will deny packets sent from hosts with private addresses, and permit packets from hosts with public addresses. The first question, then, is what are the private and public addresses? Per RFC 1918, the private address ranges are: Class A /8 Class B /12 Class C /16 Everything else in the Class A, B, and C ranges is public. Thus, we need an ACL that denies the above-listed address ranges, and permits everything else. Let s use ACL 5, and place it on Serial 0/0.123 (a Frame Relay subinterface) outbound. We ll take it one line at a time. First, let s handle network , a Class A network. Since we re interested in matching the network portion (the first octet), and ignoring the host portion (the last 3 octets), the wildcard mask should be Thus, the first line in ACL 5 is: Router(config)#access-list 5 deny Next, we ll look at the second line, which involves the Class B address space /12. Note that the mask here is a /12, not the default Class B mask of /16. As you may recall from route summarization, moving 4 bits to the left (from 16 to 12) results in a block of 16 (2 4 ) networks. Therefore, this address space encompasses the through networks. We could list these 16 networks individually, thus: Router(config)#access-list 5 deny Router(config)#access-list 5 deny (12 more lines for 18 through 29 go here) Router(config)#access-list 5 deny Router(config)#access-list 5 deny Note that the wildcard mask on each line is because we care about the first two octets (the network portion) but not about the last two (the host portion). There is, however, a more elegant way. In fact, we can cover the Class B private networks in one line. Since the mask on the Class B address space is a /12, it means that we only care about the first 12 bits of the address space, and can ignore the last 20 (remember, there are a total of 32 bits in an address). Since a 0 in a WCM means match the corresponding address bit, and a 1 means ignore, the WCM in binary would be twelve 0s, followed by twenty 1s, thus: Copyright 2009 Global Knowledge Training LLC. All rights reserved. 6

7 This can be represented in dotted-decimal as , which is the format we want for a wildcard mask. Another method for determining the WCM is to note that a /12 (the mask specified with the address space) is , and if we simply flip the bits, we get , which is exactly the WCM we need. An easy way to flip the bits is to just subtract each octet of a mask ( ) from 255: First octet: = 0 Second octet: = 15 Third octet: = 255 Fourth octet: = 255 Since the address space begins with , and the WCM is , the second line of the ACL should be: Router(config)#access-list 5 deny Next, we need to take care of the Class C address space. Notice that the mask specified is a /16. Since the default mask for a Class C is /24, and /16 is 8 bits to the left of that, this represents a block of 256 (2 8 ) Class C networks (those starting with ). Similar to what we did with the Class B block, we can just flip the bits of the summary mask (/16, or ) to get , which is the wildcard mask we need (match the first 2 octets of , and ignore the last 2). Since the address space starts with , the third line of ACL 5 should be: Router(config)#access-list 5 deny What we have at this point is an ACL that denies the private address space, but what about the public addresses? Remember that ACLs act as if they have a deny any at the bottom. We want to permit everything that wasn t denied, so we need to finish the ACL with a permit any line: Router(config)#access-list 5 permit any Altogether then, the list is: Router(config)#access-list 5 deny Router(config)#access-list 5 deny Router(config)#access-list 5 deny Router(config)#access-list 5 permit any Now, of course, we have to invoke it on the interface: Router(config)#interface s0/0.123 Router(config-subif)#ip access-group 5 out Copyright 2009 Global Knowledge Training LLC. All rights reserved. 7

8 Keyword Host ACL As our first example, we ll write an ACL 6 that permits packets sourced by the host with IP address , thus: Router(config)#access-list 6 permit We could also do this using a wildcard mask (WCM). Router(config)#access-list 6 permit Remember that a 0 in a wildcard mask bit position specifies a match in that bit of the address. Thus, a mask of all 0s in dotted-decimal (which represents 32 binary 0s) means match all bits of the address exactly. If you omit the wildcard mask (as in the first example), a WCM of all 0s is assumed, thus the two versions of ACL 6 are functionally equivalent. Interestingly enough, we can also write this ACL line a third way, by using the keyword host: Router(config)#access-list 6 permit host Note that when using this method, the keyword host is placed before the address, and that no wildcard mask is used. Thus there are three functionally equivalent methods for specifying a single host address in an ACL, and the router doesn t care which one you use. Specify the address, without a WCM Specify the address, followed by a WCM of all zeros Precede the address by the keyword host, with no WCM used In a standard ACL (the type we ve examined so far), I generally use the first option, because it s brief, concise, and specific (in other words, easy to type and read). The second option gains us nothing, so I never use it. The third option is also commonly used. ACL for vty Lines Now, let s put our ACL to work. This time, though, instead of using it to control user data flowing through a router s interfaces, we ll use it to enforce security on a router (or an IOS-based switch). To do this, instead of placing the ACL in service by using the ip access-group command on an interface, we ll use the access-class command on the vty (virtual terminal) lines, like this: Router(config)#line vty 0 4 Router(config-line)#access-class 6 in Remember that inbound Telnet sessions are via the vty lines. What the above commands do is place ACL 6 in use inbound on the vty lines, which has the effect of constraining inbound Telnet traffic to hosts permitted by ACL 6 (in this case, the host with address only). Note that this ACL only affects Telnet traffic targeted to this router. It has no effect on traffic flowing through the router. Copyright 2009 Global Knowledge Training LLC. All rights reserved. 8

9 Of course, you can also build more sophisticated ACLs using wildcard masks, and use them to control vty access. An example would be: Router(config)#access-list 7 deny Router(config)#access-list 7 deny Router(config)#access-list 7 deny Router(config)#access-list 7 permit any Router(config)#line vty 0 4 Router(config-line)#access-class 7 in ACL 7 would permit any public address to Telnet to this router, but block attempts at Telnet from any private address. Note that we are placing the ACL inbound on the vty lines, which controls Telnet access to the router. If you place the ACL in service outbound on the vty lines, it will affect the router s being used as the middleman in a string of Telnet sessions. For example, let s say that R1 wants to Telnet to R2. The ability of R1 to do this is controlled by R2 s inbound vty ACL. If there is no inbound vty ACL on R2, then any host can freely Telnet into R2 (assuming that R2 s vty password is known, of course). Now, assuming that R1 has used Telnet to access R2, the ability of R1 to then Telnet onward from R2 to another host would be controlled by R2 s outbound vty ACL. If there is no outbound vty ACL on R2, then R1 could freely Telnet to any other host via R2 (assuming that the target host s Telnet password is known). Note that when the ACL is used inbound on the vty lines, the ACL specifies source addresses (from which hosts are inbound Telnet into our router allowed). When the ACL is used outbound on the vty lines, the ACL specifies destination addresses (to which hosts are outbound Telnet sessions allowed). The latter is an unusual usage of a standard IP ACL, which normally specifies source addresses only. Okay, now it s Quiz Time: Let s suppose that the following commands are placed on our router. What effect do they have? Router(config)#access-list 8 permit Router(config)#access-list 9 permit Router(config)#line vty 0 4 Router(config-line)#access-class 8 in Router(config-line)#access-class 9 out Since ACL 8 is placed inbound on the vty lines, it controls which hosts can Telnet into our router. In this case, only the host with address will succeed (don t forget about the implicit deny any at the bottom of the ACL). Now, assuming that it has established a Telnet session with our router, to where could it Telnet from our router? That s controlled by ACL 9, which is in effect outbound on the vty lines. Because of ACL 9, if host accesses our router by Telnet, it can only start Telnet sessions with host while using our router as the middleman (again, don t forget the implicit deny at the end). Copyright 2009 Global Knowledge Training LLC. All rights reserved. 9

10 Note that host (or any other host) can still Telnet through our router to anywhere. The ACLs placed on our router s vty lines are only controlling Telnet sessions for which our router is an endpoint. In other words, the access-class statements on the vty lines have absolutely no effect on data passing through our router, but only on Telnet sessions terminating at (or starting from) our router (or switch). In addition to controlling Telnet access (TCP port 23), access-class statements on vty lines also affect SSH sessions (SSH is the encrypted version of Telnet, and it uses TCP port 22). Finally, remember that ACLs can be used to control Telnet or SSH access to and from IOS-based switches, as well. So why use access-class on the vty lines? It allows you to easily control Telnet and/or SSH sessions to a router or switch. It covers all of the data interfaces (and a large switch could have hundreds of data interfaces). It affects only Telnet and SSH traffic targeting our router or switch, not traffic traversing our router or switch. It uses standard ACLs, which are easier to write than extended ACLs. That makes the vty access-class statement a slick solution. Let s move on; there s still a lot more to do with access-lists. Additional Tips and Tricks for Standard IP ACLs This time we ll look at additional tips and tricks when using standard IP ACLs. Let s suppose that we re given ACL 10 (the lines have been labeled A through E to facilitate the upcoming discussion): A. access-list 10 permit B. access-list 10 deny C. access-list 10 permit D. access-list 10 deny E. access-list 10 permit any Based on ACL 10, what will happen to packets that are sourced from the following addresses? 1) ) ) ) ) Here are the results: Packet #1: Denied by line B Packet #2: Permitted by line E Copyright 2009 Global Knowledge Training LLC. All rights reserved. 10

11 Packet #3: Permitted by line C Packet #4: Permitted by line A Packet #5: Denied by line D Why is packet #1 denied, although it matches some permits in ACL 10? Remember, access lists are top-down, first-match. Since line B is the top-most match for packet #1, the packet is denied. Because of this, the order of the lines in an ACL can be critical. For example, let s say that we swap lines B and C in ACL 10, to obtain ACL 11: (A) access-list 11 permit (B) access-list 11 permit (C) access-list 11 deny (D) access-list 11 deny (E) access-list 11 permit any Now what happens to packet #1? Unlike ACL 10, with ACL 11 packet #1 is permitted (by line B). In fact, any /16 address will be permitted by line B, and will never make it to line C. For that reason, ACL 11, although syntactically correct, is logically inconsistent. The old programmer s rule of Garbage in, garbage out applies to ACLs as well. ACL Editing The ACL editing capabilities depend on the IOS version. Under older IOS (early 12 and before), all you could do with a numbered ACL was: Add lines to the bottom (append) Delete the entire ACL What you couldn t do was add lines anywhere other than at the bottom, or delete individual lines. If you wanted to do more extensive editing, you had to delete the list, and then recreate it. With current IOS (12.4), you can add lines wherever you like or to the bottom, and delete individual lines as well as the entire ACL. You access the enhanced editing capabilities via sequence numbers that IOS automatically adds to the lines. You can see the sequence numbers with show access-list. For example, given ACL 11 above, we would see: Router#show access-list Standard IP access list permit permit , wildcard bits deny , wildcard bits deny , wildcard bits permit any Copyright 2009 Global Knowledge Training LLC. All rights reserved. 11

12 Using the per-line sequence numbers, you can make the changes you desire. Named ACLs Another enhanced capability, named ACLs, was introduced with IOS 12. Let s take a look at creating a named standard ACL. Router#conf t Router(config)# ip access-list standard Block_RFC1918 Router(config-std-nacl)# Note that the prompt now reads config-std-nacl, meaning that we re configuring a standard named ACL (with the case-sensitive name Block_RFC1918 ). Now let s add some lines to the list: Router(config-std-nacl)#deny Router(config-std-nacl)#deny Router(config-std-nacl)#deny Router(config-std-nacl)#permit any You might recognize this as a list that denies the RFC 1918 private addresses, and permits the public addresses. Like numbered ACLs, a named ACL must be placed in service to have any effect, and that s done exactly as it is for a numbered list. For example, to control the data flowing outbound through FastEthernet0/0: Router(config)#interface fa0/0 Router(config-if)#ip access-group Block_RFC1918 out You can also use a named standard ACL to control Telnet and/or SSH access: Router(config)#line vty 0 4 Router(config-line)#ip access-group Block_RFC1918 As with the numbered ACLs, named ACLs are assigned per-line sequence numbers that facilitate editing. You can also use the named ACL editor to create and edit numbered ACLs. Just use the number of the ACL as the name: Router(config)# ip access-list standard 12 Router(config-std-nacl)# One more thing - with both named and numbered ACLs, you can add remarks. You add a remark to a numbered ACL like this: Router(config)#access-list 13 remark This is my workstation Router(config)#access-list 13 permit Copyright 2009 Global Knowledge Training LLC. All rights reserved. 12

13 Similarly, to add a remark to a named ACL, you would do: Router(config)# ip access-list standard Permit_Me Router(config-std-nacl)#remark This is my workstation Router(config-std-nacl)#permit You can have multiple remarks within a numbered or named ACL. Note that while the remarks don t appear with show access-list, they do appear with show run and show start. Differences between Standard and Extended ACLs Having discussed general ACL rules and syntax, let s now turn to the differences between standard and extended ACLs. As you might recall, numbered ACLs fall into several ranges. 1 99: Standard IP : Extended IP : Standard IP (expanded range) : Extended IP (expanded range) Other ranges for other protocols Originally, the ranges for standard and extended IP ACLs were 1-99 and , respectively, but now that ACLs are used for so many things, a hundred or so of each might not be enough. For this reason, the expanded ranges were introduced. There are now a total of 699 standard, and 700 extended numbered IP ACLs available. So, aside from the different numerical ranges involved, what are the differences between a standard and an extended ACL? In addition to filtering by source address (which is all that a standard IP ACL can do), an extended IP ACL allows us to filter based on: Destination address Transport layer protocols Port numbers Other options To see what this means, let s look at an example of an extended IP ACL. access-list 101 permit tcp host host eq telnet ACL 101 permits only Telnet traffic (TCP port 23) originating from source and targeting host , and denies all other traffic (the implicit deny any also applies to extended ACLs). Note that the source address is given first (along with either the keyword host or a wildcard mask), followed by the destination address (also with either the keyword host or a WCM). You could also write ACL 101 using wildcard masks, like this: Copyright 2009 Global Knowledge Training LLC. All rights reserved. 13

14 access-list 101 permit tcp eq telnet The two choices are functionally equivalent, but for most humans the WCM format is harder to read than that using keyword host, so I personally avoid the WCM. Note that, unlike a standard ACL, when specifying an address in an extended ACL, either the keyword host or a wildcard mask must be used. Attempting to write ACL 101 like this would result in a syntax error: access-list 101 permit tcp eq telnet Here s another example of a syntactically correct extended IP ACL. access-list 102 deny udp eq tftp access-list 102 permit ip any any ACL 102 denies TFTP traffic (and only TFTP traffic) from any host on the network going to any host on the network, and permits everything else. Note that a permit any in an extended ACL must specify the protocol (ip, meaning anything in the IP suite), and both the source and destination addresses (any any). Using Port Numbers By the way, in our extended ACLs we ve been using keywords for the common port numbers (Telnet = 23, TFTP = 69, etc), but you can also use the port numbers, which means that ACL 102 could also be written like this: access-list 102 deny udp eq 69 access-list 102 permit ip any any To get a list of the keywords for commonly used ports, you can use the question mark, like this (note the space in between the WCM and the? ): access-list 102 deny udp eq? Also, in addition to eq (equal-to), you can also specify gt (greater-than), lt (less-than), and other options. You can also use the question mark to view these. Let s say that we want to permit traffic only to hosts on network , while denying everything else. Here s a possible solution. access-list 103 permit ip any Copyright 2009 Global Knowledge Training LLC. All rights reserved. 14

15 ACL 103 applies to any protocol in the IP suite (due to the ip keyword), from any source (keyword any), going to any destination on the network (note the WCM). Since no port or other option information was specified, the ACL applies to all ports and options. Options Speaking of options, let s look at a few of those. ICMP has many different options, one of them being echo used by the ping application. Here s an ACL that will specifically deny pings, while permitting all other traffic: access-list 104 remark This ACL stops pings access-list 104 deny icmp any any echo access-list 104 permit ip any any If you really wanted to nail things down, you could deny not only pings (ICMP echoes), but also their replies (ICMP echo replies), like this: access-list 105 remark This ACL stops pings and replies access-list 105 deny icmp any any echo access-list 105 deny icmp any any echo-reply access-list 105 permit ip any any As with standard IP ACLs, you can create named extended IP ACLs. For example, you could create a named ACL equivalent to ACL 105 like this: Router#conf t Router(config)#ip access-list ext stop_ping Router(config-ext-nacl)#This ACL stops pings and replies Router(config-ext-nacl)#deny icmp any any echo Router(config-ext-nacl)#deny icmp any any echo-reply Router(config-ext-nacl)#permit ip any any Finally, you put an extended IP ACL in service the same way you do a standard IP ACL. For example, to put ACL 105 in effect outbound on the GigEthernet2/1 interface, you would do: Router#conf t Router(config)#int g2/1 Router(config-if)#ip access-group 105 out Likewise, to place ACL stop_ping in force inbound on the Serial 1/2 interface: Router#conf t Router(config)#int s1/2 Router(config-if)#ip access-group stop_ping in Copyright 2009 Global Knowledge Training LLC. All rights reserved. 15

16 Remember, ACL names are case-sensitive, and the underscore is not the same as the dash (hyphen). You need to place an ACL in service using exactly the same name as that used to create it. Packet Filtering We can use extended IP ACLs to filter packets based on source address, destination address, transport layer protocols, and other options, as follows: access-list 106 permit tcp host host eq telnet For a packet to be permitted by ACL 106, the following must be true: The transport layer protocol is TCP The source address is The destination address is The destination port is Telnet (port 23) Why is it the destination port, and not the source port? It s because the port specification (eq telnet) follows the destination address ( ). In ACL 106, since the source port is unspecified, it could be anything. What if instead we had written the ACL like this: access-list 107 permit tcp host eq telnet host For a packet to be permitted by ACL 107, the following must be true: The transport layer protocol is TCP. The source address is The source port is Telnet (port 23). The destination address is Thus, using an extended IP ACL gives us directional control that we don t have with a standard IP ACL. Let s look at an example: access-list 108 deny tcp host host eq telnet access-list 108 permit ip any any Assuming that ACL 108 is placed in service correctly, it will prevent host from opening a Telnet session to host This is because when host (the Telnet client) sends the TCP syn to host (the Telnet server), the addresses match the deny line, as does the destination port of 23 (Telnet) and the transport layer protocol (TCP). Thus, the syn packet is denied, and the TCP session is never established. Copyright 2009 Global Knowledge Training LLC. All rights reserved. 16

17 Will ACL 108 also prevent host from opening a Telnet session to host ? Remember that for most applications, client ports are chosen randomly in the range of 1024 and above. Let s say that when host s Telnet client process starts, the IP stack in assigns that process a port number of Now, when sends a TCP syn to host (the Telnet server), even though the destination port of 23 (the server) matches that specified by the deny line of ACL 108, as does the transport protocol (TCP), the source and destination addresses do not match (the addresses are reversed). Since the packet does not match the deny line, it s permitted by the permit line. Thus receives the syn packet, and the first phase of the TCP three-way handshake is successful. Next, the Telnet server ( ) will reply to the client ( ) with a syn ack (the second phase of the TCP three-way handshake). For this packet, the addresses do match those specified by the deny line of ACL 108, as does the transport protocol (TCP), but the destination port doesn t. Remember, the server ( ), using port 23 (which would be the source port), is replying to the client ( ), at port 2000 (the destination port). Since 2000 is not the destination port specified by the deny line of ACL 108, the packet does not match the deny line, and is permitted by the permit line. Thus, the syn ack makes it to When then sends an ack (to complete the three-way handshake), this packet is permitted as well, and the Telnet session has been successfully established. Thus, an extended IP ACL gives us directional control, which is both good and bad. It s good, because it gives us more flexibility, but it s bad because to deny traffic in both directions, we have to explicitly deny the traffic in both directions. In other words, to block Telnet bi-directionally between and , but permit everything else, we could do this: access-list 109 deny tcp host host eq telnet access-list 109 deny tcp host eq telnet host access-list 109 permit ip any any When blocking particular protocols, be careful to permit everything you intend to permit. What does ACL 110 permit? access-list 110 deny tcp host host eq telnet access-list 110 deny tcp host eq telnet host access-list 110 permit tcp any any ACL 110 permits any TCP traffic that isn t Telnet, but it doesn t permit TFTP or VoIP (which use UDP) or ping (which uses ICMP). If you mean to permit ip (the entire protocol suite), then that s what you have to say. And remember that in addition to specifying an exact port (eq), you can also use lt, gt, or a range (less-than, greater-than, or a range or ports numbers, respectively). Similarly, what if we want to block pings (ICMP echoes) from host to the network? We could do: access-list 111 deny icmp host echo access-list 111 permit ip any any Copyright 2009 Global Knowledge Training LLC. All rights reserved. 17

18 Note that although ACL 111 will prevent host from successfully pinging hosts on the network, it will permit network hosts to ping host To block pings in both directions, you could also deny ICMP echo replies, like this: access-list 112 deny icmp host echo access-list 112 deny icmp host echo-reply access-list 112 permit ip any any What other options are available with extended IP ACLs? As you might recall, both standard and extended IP ACLs now count the number of matches on each line, and this can be viewed with show access-lists. This allows you to monitor who is doing what, or, in the case of a deny, who is attempting to do what. With extended IP ACLs, you can go one step further, and have the ACL display console messages when matches occur. This is accomplished by appending the keyword log to lines of the ACL, like this: access-list 113 deny tcp host host eq telnet log access-list 113 deny tcp host eq telnet host log access-list 113 permit ip any any Note that in ACL 113, we didn t add the log option to the permit, because we aren t interested in the non-telnet traffic, and don t want to see messages regarding that. There are many other things that can be done with extended IP ACLs. Consult the Cisco docs for examples, and don t forget to use the? to check for available keywords and options with your particular version of IOS. Learn More Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out the following Global Knowledge courses: ICND1 Interconnecting Cisco Network Devices 1 ICND2 Interconnecting Cisco Network Devices 2 CCNA Boot Camp For more information or to register, visit or call COURSES to speak with a sales representative. Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use. Our expert instructors draw upon their experiences to help you understand key concepts and how to apply them to Copyright 2009 Global Knowledge Training LLC. All rights reserved. 18

19 your specific work situation. Choose from our more than 700 courses, delivered through Classrooms, e-learning, and On-site sessions, to meet your IT and management training needs. About the Author Al Friebe is a Cisco Certified Systems Instructor (CCSI) who has been teaching networking classes since In the past, he has served as Global Knowledge s Course Director for BGP and BSCI, and he is the author of Global Knowledge s current ICND2 labs. His previous experience includes instructor duty in the U.S. Navy s Nuclear Power School, radiochemistry, software engineering, and network management. His certifications include CCDA, CCDP, CCNA, CCNP, A+ and others. Copyright 2009 Global Knowledge Training LLC. All rights reserved. 19