Access control lists (ACLs) are powerful tools that are often at the heart of many other processes, including security processes. ACLs can be a good starting point for adding security and traffic management to a network, but they can’t protect the network by themselves. Devices like firewalls and proxy servers, as well as good security practices—password management, physical security, and solid administrative policies—should be used to augment them.
STUDY TIP ? |
\While ACLs aren’t a specific exam objective, they’re fundamental in many security implementations and processes. Newer operating system (OS) versions for devices like PIX firewall boxes and Catalyst switches use Cisco IOS–like features and commands and, therefore, incorporate access list capabilities. Make sure you’re comfortable with how access lists are constructed and how they work. If you need a refresher on ACLs, go to Appendix A. |
This section includes examples of standard IP ACLs with various wildcard Mask options to perform the following security-related tasks.
Traffic filtering
Limiting access to Telnet sessions
Limiting access to HTTP sessions
Filtering routing updates
Limiting the debug ip packet analysis and, therefore, CPU use
Before looking at these examples, let’s look at a technique that can be used in test labs to make a limited pool of devices look more diverse. In some of the next exercises, having more than one LAN interface on the routers would be useful, but this isn’t required. The next section looks at using loopback interfaces as a simple work-around in the lab.
What do you do if your router has only a single Ethernet interface? Or worse, what if one of your lab routers has only a Token Ring LAN interface and you don’t have a Multistation Access Unit (MAU) unit to plug it in to, so the interface won’t come up? Short of getting another device, the only solution is to create loopback interface(s). What are loopback interfaces?
They are logical interfaces, in that they don’t connect to any cables and, therefore, they have no hosts. Loopback interfaces are logical interface only.
They are “up” by default and remain up unless administratively shut down with the shutdown command.
They can be configured as a host, a subnet, a network, or a supernet, like any other interface.
They can be included in the routing updates like any other interface.
They can be used as a ping, a Telnet destination, or a source.
Some routing protocols, such as OSPF and BGP, use loopbacks as router IDs.
Configuring a loopback interface is similar to creating a subinterface. The syntax is
router(config)#interface loopback num router(config-if)#ip address ip-address subnet-mask
The num is any whole number between 0 and 2147483647. It won’t accept module-type notation, like 0/1.
Note, the no shutdown command isn’t required and would only be used with loopback interfaces following a shutdown command.
Here is an example:
router(config)#interface loopback 0 router(config-if)#ip address 192.168.3.1 255.255.255.255
The Layer 3 addresses can be either an IP or an IPX interface configuration (AppleTalk isn’t supported on all router platforms). The example is a 32-bit mask, called a host mask, because it specifies a single host, not a network or a subnetwork. Some routing protocols, such as Open Shortest Path First (OSPF), use loopback interfaces as router IDs and prefer the host mask to avoid problems. With protocols such as RIP, IGRP, and EIGRP, you can use any mask that serves your purpose.
Traffic filtering is a common use for standard access lists used when the plan is to block all packets from a specific source host or group of hosts from reaching a portion of the network. Figure 2-3 shows a simple two-router network that might represent two branch locations of a smaller business.
The following code represents two access lists created on the Rtr1 router. ACL 10 allows only a single host (192.168.2.20) from the Rtr2 LAN and all hosts from the Rtr1 LAN to go out to the Internet. By not adding a permit any statement, all other hosts are denied.
Rtr1(config)#access-list 10 permit host 192.168.1.20.0.0.0.255 Rtr1(config)#access-list 10 permit 192.168.1.20 0.0.0.255 Rtr1(config)#access-list 20 permit host 192.168.2.20 Rtr1(config)#access-list 20 deny 192.168.2.0 0.0.0.31 Rtr1(config)#access-list 20 permit any Rtr1(config)#int s0 Rtr1(config-if)#ip access-group 10 out Rtr1(config-if)#int e1 Rtr1(config-if)#ip access-group 20 out
The first line of ACL 20 permits host (192.168.2.20) from the Rtr2 LAN to access the LAN on Rtr1. The second line blocks the rest of 192.168.2.0 subnet mask 255.255.255.224, or addresses 192.168.2.0 to 192.168.2.31 from the Rtr1 LAN. The final line allows the rest of Rtr2 LAN and anything coming in over the Internet.
Most administrators deduce quickly that if packets can be discarded as early as possible, this will reduce bandwidth requirements on links and router CPU cycles used to process packets that are going to be dumped anyway. Unfortunately, with standard ACLs, the only criterion for making the determination to permit or deny is the source address—the destination is unknown. Standard access lists are generally placed as close to the destination network segment as possible to exercise the most control. For example, in Figure 2-3 in the preceding section, a standard ACL blocking a certain Internet address from entering the Rtr2 LAN would need to be placed on the Rtr2 e0 interface outbound. While s0 on Rtr1 would save more router resources, it would also block access to the Rtr1 LAN. Similarly, applying it to s0 on Rtr2 would work for now, but what if additional interfaces are used later? They would also be blocked.
Looking at Figure 2-3, if ACL 20 had been placed inbound on the Serial 1 interface of Rtr1 or outbound on s0 of Rtr2, this would have saved resources, but this would also have blocked access to the Internet for hosts 192.168.2.1 to 192.168.2.19 and 192.168.2.21 to 192.168.2.30.
Since v11.3 of the IOS, the Log option at the end of an ACL statement results in logging packets that meet the ACL criterion. How and where the logging is stored is controlled with the logging console command. The simplest form of the Log option causes a message to be printed to the console screen the first time the ACL is activated, and then every five minutes while the ACL is still being used. The first report indicates only the first packet, while the subsequent reports summarize the number of occurrences.
The following output lines show the result of adding the Log option to an ACL that blocks the access of host 192.168.1.10 to a LAN.
Rtr1(config)#access-list 50 deny ??192.168.1.10 log Rtr1config)#access-list 50 permit any Rtr1(config)#int e0 Rtr1(config-if)#ip access-group 50 out Rtr1(config-if)#^Z Rtr1 # 11:29:37: %SEC-6-IPACCESSLOGS: list 50 denied 192.168.1.10 1 packet Rtr1 # 11:34:53: %SEC-6-IPACCESSLOGS: list 50 denied 192.168.1.10 27 packets Rtr1#
In the example, the last two lines indicate the workstation attempted to ping a LAN host (192.168.5.1) seven times from the Command window. The first packet was recorded in the first log entry. The other 27 packets, 4 per ping, were reported five minutes later.
The logging console command in Global Configuration mode can be used to modify the Log options, which includes specifying a host address running Syslog server software to forward all log entries for permanent storage. Chapter 5 has a section demonstrating the various logging options.
Using Figure 2-4, assume the company wants to limit Telnet access to Rtr1 to users on the Rtr2 LAN and a single outside address 42.17.17.45, which is the router administrator’s home computer. Just as it’s possible to filter the physical interfaces, such as Ethernet 0 and serial 1, standard access lists can be used to filter the virtual ports, thereby limiting telnet access to the routers.
Five virtual ports, or vty lines, typically are designated as vty 0 4, allowing up to five telnet sessions to be established. Similar to setting Telnet passwords, you can set identical restrictions on all vty lines at one time.
In the following output, inbound access list 15 limits access to the router to users specified by the company. The lack of a permit any statement limits the access to those hosts defined in lines one and two. ACL 16 prevents any user who successfully Telnetted into the router to Telnet to another device. They can only exit out after doing their assigned tasks.
Rtr1(config)#access-list 15 permit 192.168.2.0 0.0.0.255 Rtr1(config)#access-list 15 permit 42.17.17.45 Rtr1(config)access-list 16 deny any Rtr1(config)#line vty 0 4 Rtr1(config-line)#access-class 15 in Rtr1(config-line)#access-class 16 out Rtr1(config-line)#password cisco Rtr1(config-line)#login
The important keyword here is “access-class,” which is used in place of access-group when you’re applying an ACL to a virtual interface.
The following code shows the result when another router, or a host on any other subnet/ network, tries to Telnet into Rtr1. It’s important to realize that this implementation of the access-class applies to the entire router, not only to one direction on an interface.
Rtr2>telnet 192.168.3.1???????????<-could have used 192.168.1.1 Trying 192.168.3.1... % Connection refused by remote host
The following lines show the result of a permitted user (who cleared access-list 15 and supplied the password) trying to telnet onto another router. The output assumes an IP HOST table was set up with both IP addresses associated with the name Rtr2 (Rtr1(config)#ip host rtr2 192.168.3.2 192.168.2.1). Telnet attempts both interfaces, but is denied at each attempt.
Rtr1>telnet Rtr2 Trying Rtr2 (192.168.3.2)... % Connections to that host not permitted from this terminal Trying Rtr2 (192.168.2.1)... % Connections to that host not permitted from this terminal Rtr1>
The show line vty 0 4 command lists the virtual terminals and shows that the access lists are applied. The Acc0 (ACL outbound) and AccI (ACL inbound) display the ACL numbers. Running the command to verify that your access lists are, in fact, applied to all virtual terminals is always a good idea.
Lab-X#show line vty 0 4 Tty Typ ??Tx/Rx ?A Modem ?Roty AccO AccI ??Uses ??Noise ?Overruns ??Int ??2 VTY ?????????- ???- ?????- ??16 ??15 ?????0 ??????0 ????0/0 ??????- ??3 VTY ?????????- ???- ?????- ??16 ??15 ?????0 ??????0 ????0/0 ??????- ??4 VTY ?????????- ???- ?????- ??16 ??15 ?????0 ??????0 ????0/0 ??????- ??5 VTY ?????????- ???- ?????- ??16 ??15 ?????0 ??????0 ????0/0 ??????- ??6 VTY ?????????- ???- ?????- ??16 ??15 ?????0 ??????0 ????0/0 ??????-
Many Cisco devices allow access to the User and Privilege modes via a web browser. Figure 2-5 shows an example of the opening screen for a 2500 model router. While not as extensive or friendly as some manufacturer’s web interfaces, it does enable the user to view the interfaces, view the diagnostic log, ping the device, execute commands, and open a telnet session.
For this feature to work, the ip http server command must be issued in Global Configuration mode because the default is for the service to be off. The command allows the device to act as an HTTP server. Many company security policies require the feature to be turned off by issuing a no ip http server command to reduce the exposure to unauthorized access.
Another alternative is to use a standard ACL to limit which host(s) can access the device from a web interface. The basic steps include the ip http server command, any ACL statement(s) required to define the authorized host, and the ip http access- class {acl-num | acl-name} command. The following lines show an example of the commands:
Rtr1#conf t Rtr1(config)#ip http server Rtr1(config)#access-list 90 permit 192.168.0.10 Rtr1(config)#access-list 90 permit 192.168.5.0 0.0.0.31 Rtr1(config)#access-list 90 permit 192.168.45.0 0.0.0.255 Rtr1(config)#ip http access-class 90 Rtr1(config)#^Z Rtr1#
The lack of a permit any statement limits access to those specifically defined in the permit statement(s). Any time the device is accessed with a web browser, a login screen appears asking for a user name and password. With the previous configuration, the device host name (Rtr1) would be the user name and the enable secret password would be the password.
Controlling the access further is possible with the ip http authentication command, which supports several methods of establishing the user name/password combinations. The syntax would be:
ip http authentication {aaa | enable | local | tacacs}
AAA |
The AAA authentication feature covered in Chapter 4 |
Enable |
Uses the enable password for authentication (the default HTTP) |
Local |
Uses the local user database (user name/password) defined in Global mode |
Tacacs |
The TACACS or XTACACS server authentication covered in Chapter 5 |
The debug ip packet command displays in real-time all IP packet activity passing through a router. This is, unfortunately, extremely hard on CPU resources. In fact, a router running at 50 percent capacity can be buried by the command dominating the CPU use. Many organizations ban all use of the command for this reason. A second problem with the command is the screen is often overwhelmed by output, making it difficult to see the expected information.
Fortunately, the command syntax, debug ip packet [acl-num], allows an ACL to be created to filter the specific traffic of interest. In the following example, the output is limited to any traffic originating in the 192.168.0.0 network. Any valid host address, subnet, or network address can be used.
Rtr1#conf t Rtr1(config)#access-list 20 permit 192.168.0.0 0.0.0.255 Rtr1(config)#^Z Rtr1#debug ip packet ? ???????????????????????<-shows the options ?<1-199> ?????Access list ?<1300-2699> ?Access list (expanded range) ?detail ??????Print more debugging detail ?<cr> Rtr1#debug ip packet 20 IP packet debugging is on for access list 20 Rtr1# 00:05:28: IP: s=192.168.0.1 (local), d=224.0.0.10 (Ethernet0), ???len 60, sending broad/multicast 00:05:28: IP: s=192.168.0.10 (Ethernet0), d=192.168.0.1 (Ethernet0), ???len 56, rcvd 3
The options shown in the debug ip packet ? indicate extended ACLs could be used to filter, based on destination address, protocol, or port numbers.
Extended access lists provide a higher level of traffic control by being able to filter packets based on the protocol, source and/or destination IP address, and source and/or destination port number. For example, an extended access list can block an address (or group of addresses) in a particular network from accessing the FTP services on a specific server, while still allowing other services.
Implicit in using TCP and UDP access list statements is that it becomes possible to support or suppress certain higher level applications. Because port numbers are associated with applications, allowing or denying access to a specific port number determines if that application can be used and which devices can access it. Setting up network segments to carry only one or two types of traffic—say, NNTP news or SMTP mail—becomes possible. Access lists can be established to prevent any other traffic from entering that particular segment. These ACLs not only focus on the source and destination of the packets, but also on the service offered. The following table shows some common port numbers and the related services (applications).
ftp |
File Transfer Protocol |
20, 21 |
Telnet |
Telnet, Remote Terminal |
23 |
smtp |
Electronic Mail (servers) |
25 |
pop3 |
POP Mail (users) |
110 |
nntp |
Network News |
119 |
More examples are included in the sections dealing specifically with TCP and UDP filtering.
The Established option is a TCP-only feature that can use the connection-oriented attributes of the TCP to limit traffic coming into a network or network segment to those sessions that originated from within that network. The established condition is only true if the ACK (acknowledge) or RST (reset) bits are set to one in the TCP header, indicating an already established connection. A packet with no ACK or RST bit set, but a SYN (synchronize) bit set to one, is used to establish a new connection and can then be denied. Figure 2-6 demonstrates the three-step “handshake” that TCP uses to establish a connection.
The following output demonstrates allowing any host to respond to web and Telnet requests that originated within the 192.168.1.0 network, but blocks all other TCP packets.
access-list 101 permit tcp any 192.168.1.0 0.0.0.255 established access-list 101 permit tcp any 192.168.1.0 0.0.0.255 any eq telnet access-list 101 deny ??tcp any any access-list 101 permit ip ?any any
The Established option can help reduce the risk of a common type of hacker attack that buries a host in SYN requests, preventing it from handling normal business. Because a sophisticated hacker can manipulate the TCP header bits, this tool needs support from other tools to protect against that threat.
Look over the following ACL statement using the Established option. This is a common first effort when trying to limit web activity to those sessions originating within the network. So what’s wrong with the statement?
access-list 101 permit tcp any 192.168.1.0 0.0.0.255 eq www established
Remember, www is an “alias” for port 80. A web session originating inside would use port 80 as the destination, but would designate a port above 1024, such as 1065, as the source port. This means the returning packet would have port 80 as the source and port 1065 as the destination. The ACL is looking for port 80 as the destination. The following output might work better:
access-list 101 permit tcp any eq www 192.168.1.0 0.0.0.255 established
When working with the Established feature, it’s important to make sure you understand what the mnemonic and any port numbers stand for, if you use the port numbers. Another approach is represented in the following code lines, which allow any established sessions, but block all other TCP traffic.
access-list 101 permit tcp any 192.168.1.0 0.0.0.255 established access-list 101 deny ??tcp any any
Note? |
Source-port filtering, the process of filtering data on the source port of a packet, isn’t secure because a skilled hacker could easily change a source port on a packet, which could then pass through the filter. |
Since Cisco IOS Release 11.2, it’s possible to use a text name for access lists in many cases. Some new features were added to named ACLs that make them more than just text names. The benefits of using named access lists are described in the following paragraph:
Until recently, an access list was either implemented or not. An administrator would have to change the configuration to include a feature, such as blocking Internet access, and then would have to physically remove either the ACL or the access-group statement to allow access. This wasn’t convenient if the goal was to block employee access during work hours, but to allow access at other times of the day.
Since version 12.0 of the IOS, it’s possible to create access lists that can incorporate date- and time-sensitive features. This allows filtering to occur only during certain hours of the day or on certain days of the week. IP and IPX extended access lists are currently the only functions that can use time ranges. Time ranges enable the network administrator to specify when the permit or deny statements in the access list are in effect. Both named or numbered access lists can use the time range feature.
Two separate tasks are required to implement time ranges:
Define a time range.
Reference the time range.
Three basic commands are used to implement the time-based features in extended ACLs:
time-range
periodic
absolute
The time-range command is used to create (name) a time range, while the absolute and periodic commands are used to define the days and times included in the named range. While multiple periodic entries are allowed per time-range command, only one absolute entry is allowed.
If a time-range command has both absolute and periodic values specified, then the periodic items are evaluated only after the absolute start time is reached, and aren’t evaluated any further after the absolute end time is reached.
The time-range command is used to enable Time-Range Configuration mode and name time ranges for functions, such as extended access lists. The command is issued in Global Configuration mode. The syntax is:
Router(config)#time-range time-range-name
time-range-name |
User-specified name of the time range |
The following output demonstrates defining a time range named NoDayAccess. Remember, the name is case sensitive.
Router(config)#time-range NoDayAccess
The periodic command is used to specify a recurring range of days and times to be included in the time-range created in the previous command. Using this command allows a feature to be implemented on only certain days of the week and within certain hours. The command is issued in the Time-Range Configuration mode, which is activated by the time-range command. The syntax is
Router(config-time-range)#periodic days-of-the-week hh:mm to [days-of-the-week] hh:mm
days-of-the-week |
Used to define the days included in the time-range |
hh:mm |
Defines the beginning or ending time of the time range. hh is the 24-hour time and mm is the minute. |
The first occurrence of the hh:mm argument is the starting hours:minutes that the time range is in effect. The second occurrence is the ending hours:minutes the statement is in effect. Times are expressed using the 24-hour clock; therefore, 8:00 P.M. would be typed as 20:00. The keyword to is required to complete the range, as in start-time to end-time.
Note? |
Remember, all time specifications are interpreted as local time. To ensure the time range entries take effect at the desired times, the software clock should be synchronized using the Network Time Protocol (NTP) or some other authoritative time source. |
The days-of-the-week argument can seem complicated until you become used to it. Used properly, this can be used to represent a single day or combination of days using the following keywords:
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday— day names
daily Monday through Sunday
weekdays Monday through Friday
weekend Saturday and Sunday
The following examples should help you understand the process. The following lines create a time range for a single day named MondayDays, and then define the day and hours (8:00 A.M. to 5:30 P.M.).
Router(config)#time-range MondayDays Router(config-time-range)#periodic monday 8:00 to 17:30
When multiple days can be defined by the keywords daily, weekday, and weekend, the keyword is used. The next lines creates a time range named WeekdayEves, and then define hours (5:00 P.M. to 10:00 P.M.). In this example, the feature is to be implemented Monday through Friday.
Router(config)#time-range WeekdayEves Router(config-time-range)#periodic weekdays 17:00 to 22:00
When multiple days other than those defined by the keywords daily, weekday, and weekend are required, the days are listed separated by spaces. The next lines create a time range named TuThuEves and then defines the days and hours (5:00 P.M. to 10:00 P.M.).
Router(config)#time-range TuThuEves Router(config-time-range)#periodic tuesday thursday 17:00 to 22:00
With a recurring time range on consecutive days, other than those defined by the keywords, the days are also listed separated by spaces. The next lines create a time range named SunMonTue and then define the hours (5:00 P.M. to 10:00 P.M.) included each day.
Router(config)#time-range SunMonTue Router(config-time-range)#periodic sunday monday tuesday thursday 6:00 to 9:00
With a time range that “spans” consecutive days, the optional days-of-the-week after the to is used. The next lines create a time range named MonToWed, and then define the start and ending time as 8:00 A.M. Monday to Wednesday at 5:00 P.M.
Router(config)#time-range MonToWed Router(config-time-range)#periodic Monday 8:00 to Wednesday 17:00
Multiple periodic entries are allowed per time-range command.
Use the absolute time-range command to specify a time range to be in effect each day. The command is issued in the Time-Range Configuration mode, which is activated by the time-range command. The syntax is
Router(config-time-range)#absolute [start time date] [end time date]
The start and end times use the 24-hour clock. The dates are in a text form, such as June 1, 2003.
The following sample defines a time range from 8:00 December 18, 2003, until 8:00 January 3, 2004:
Router(config)#time-range holidays-closed Router(config-time-range)#absolute 8:00 18 december 2003 8:00 3 january 2004
Only one absolute entry is allowed per time-range command. If a time-range command has both absolute and periodic values specified, then the periodic items are evaluated only after the absolute start time is reached, and aren’t evaluated any further after the absolute end time is reached.
An extended access control list can be either a numbered or a named ACL. In each case, the Time-Range option is added to provide an additional qualifier for the permit|deny statement. The basic syntax for a named ACL would be
Router(config)#ip access-list extended name
Router(config-ext-nacl)# {permit | deny} {protocol | protocol-keyword}{source
wildcard | any} [operator source-port] {destination wildcard | any} [operator
destination-port] [precedence precedence] [tos tos] [log | log-input] [options]
[time-range time-range-name]
The basic syntax for a numbered ACL would be
Router(config)#access-list acl# {permit | deny} {protocol | protocol-keyword}{source
wildcard | any} [operator source-port] {destination wildcard | any} [operator
destination-port] [precedence precedence] [tos tos] [log | log-input] [options]
[time-range time-range-name]
The following time range example with a periodic statement denies web traffic to employees on the Ethernet LAN for Monday through Friday during business hours (8:00 A.M. to 6:00 P.M.).
time-range no-web ?periodic weekdays 8:00 to 18:00 ! ip access-list extended block-web ?deny tcp any any eq www time-range no-web ?permit ip any any ! interface ethernet 0 ?ip access-group block-web in !
The following example uses a time-based access list to allow a LAN to begin accessing the network beginning at 8:00 A.M. on January 1, 2003. The access will continue until stopped. The access list and time range together permit traffic on Ethernet interface 0 starting.
time-range new-lan ?absolute start 8:00 1 January 2003 ! ip access-list extended start-service ?permit ip 192.168.15.0 0.0.0.255 any time-range new-lan ! interface ethernet 0 ?ip access-group start-service in
The following example uses a time-based access list to block a LAN from accessing the network beginning at midnight on December 31, 2003.
time-range stop-lan ?absolute end 23:59 31 December 2003 ! ip access-list extended stop-service ?permit ip 192.168.15.0 0.0.0.255 any time-range stop-lan ! interface ethernet 0 ?ip access-group stop-service in
The following example uses a time-based access list to permit weekend employees to browse the Internet for a two month test period from 8:00 A.M. on June 1, 2003, to 6:00 P.M.on July 31, 2003.
time-range web-test absolute start 8:00 1 June 2003 end 18:00 31 July 2003 periodic weekends 00:00 to 23:59 ! ip access-list extended lan-web ?permit tcp 192.168.15.0 0.0.0.255 any eq www time-range web-test ! interface ethernet 0 ?ip access-group lan-web in
The show time-range command can be used to display the current status of the time ranges and list the periodic and absolute attributes.
Rtr1#show time-range time-range entry: WeekdayEves (inactive) ??absolute start 08:00 01 December 2004 end 08:00 03 January 2005 ??periodic weekdays 17:00 to 22:00 time-range entry: weekdayeves (active) ??used in: IP ACL entry time-range entry: worktime (active) ??absolute start 08:00 01 December 2004 end 08:00 03 January 2005 ??periodic weekdays 8:00 to 18:00 ??used in: IP ACL entry Rtr1#conf t
The output shows two defined time ranges WeekdayEves and worktime, but it also shows another undefined time range, weekdayeves. The output shows it was used in an ACL, indicating someone tried to use WeekdayEves and forgot that the names are case sensitive. The result in this case will be that since no times are defined, the ACL statement will be active all of the time.