Now that we know the basics of standard IP access lists from previous posts, let’s learn some more about them.
As our first example, we’ll write an ACL 6 that permits packets sourced by the host with IP address 192.168.100.123, thus:
- Router(config)#access-list 6 permit 192.168.100.123
We could also do this using a wildcard mask:
- Router(config)#access-list 6 permit 192.168.100.123 0.0.0.0
Remember that a zero in a wildcard mask bit position specifies a match in that bit of the address. Thus, a mask of all zeros in dotted-decimal (which represents 32 binary zeros) means match all bits of the address exactly. If you omit the wildcard mask (as in the first example), a WCM of all zeros 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 192.168.100.123
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.
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 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 (virtual terminal) 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 192.168.100.123 only). Note that this ACL only affects Telnet traffic targeted to this router. It has no effect on traffic flowing through the router.
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 10.0.0.0 0.255.255.255
- Router(config)#access-list 7 deny 172.16.0.0 0.0.15.255
- Router(config)#access-list 7 deny 192.168.0.0 0.0.255.255
- 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 172.16.1.1
- Router(config)#access-list 9 permit 10.1.2.3
- 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 172.16.1.1 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 172.16.1.1 accesses our router by Telnet, it can only start Telnet sessions with host 10.1.2.3 while using our router as the “middleman” (again, don’t forget the “implicit deny” at the end).
Note that host 172.16.1.1 (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. Next time, we’ll do more (and there’s still lots more to do) with access-lists.
Author: Al Friebe