Using Access Control Lists to Secure the Network

Using Loopback Interfaces on Lab Routers

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

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.

Figure 2-3: Two-router network with two ACLs

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.

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#

Limiting Access to Telnet Sessions

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.

Figure 2-4: Two-router network for two branch locations

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>

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 ??????-

Limiting Access to HTTP Sessions

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.

Figure 2-5: Web browser access to a 2500 router

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}

Limiting the debug ip packet Analysis and, Therefore, CPU Use

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.

Restrict Application Traffic

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).

More examples are included in the sections dealing specifically with TCP and UDP filtering.

TCP’s Established Option

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.

Figure 2-6: TCP three-way handshake to establish a session

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.

Define a 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

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

The following output demonstrates defining a time range named NoDayAccess. Remember, the name is case sensitive.

Router(config)#time-range NoDayAccess

The periodic Command

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

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.

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.

The absolute 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.

Reference the Time Range

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

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.