Unauthorized Access

Unauthorized Access

The perimeter router is the first line of defense against external threats. Features like using access lists to perform traffic filtering, covered in Chapter 2 and Appendix A, can help in the battle. In this section, you learn about the Dynamic and Reflexive access lists.

Address Filtering

RFC 2827 filtering involves filtering out any IP addresses from coming into a network segment, which should already be on that segment. If the entire network is attached to a router interface, then no legitimate packets with source addresses in that network should be coming in through the router. This should be applied to perimeter routers for sure, but it can be used on internal routers to prevent spoofing within the network. Similarly, limiting any outbound packets, leaving the network to ones that have source addresses assigned to that network, can prevent a network’s hosts from spoofing other networks. This could be the result of an attacker on the inside or a DoS bot on a local host participating in an attack on an outside host. If the company can get its ISP to perform RFC 2827 filtering on packets coming into the network, it would preserve the bandwidth of the link and kill some hack attempts.

RFC 1918 filtering involves filtering out RFC-defined private addresses from entering or exiting the network segment. Because they have no business on the Internet anyway, they shouldn’t be there. If private addresses are used in the network, RFC 2827 filtering will include them. The following is a standard ACL approach, although an extended or named list would also work.

interface serial 0
ip access-group 10 in
access-list 10 deny
access-list 10 deny
access-list 10 deny
access-list 10 permit any

Dynamic (Lock-and-Key) Access Lists

Assume the network is secured with ACLs regulating traffic in, out, and through the network. Decisions were made to be conservative in allowing traffic to access the resources. So everything that can be blocked is being dealt with. What if you need some flexibility to deal with some necessary exceptions? Dynamic access lists, often called lock-and-key access lists, can literally create temporary openings to your network for specific IP traffic.

Figure 5-3 shows an example of a company network that might have limited TCP access to the internal networks to those sessions that originated from within the LAN. To accomplish this, they might have used the TCP ACL established option. The organization still wants to allow the network administrators access from the outside to reduce the number of evening and weekend callouts, particularly for forgotten passwords, locked accounts, and so forth.

Click To expand
Figure 5-3: Simple example of lock-and-key access

The point of lock-and-key is to grant temporary IP access to specific hosts that would normally be blocked. The process works like this:

  1. A user Telnets to the router configured with the dynamic ACL. The router can be a perimeter router protecting the entire network or an internal router protecting certain segments.

  2. The router challenges the user to authenticate. The authentication method used is whatever security has been applied to Telnet sessions (line vty settings) in the router configuration. Options include using standard passwords, local user name/ password entries, or AAA.

  3. Once successfully authenticated, the Telnet session is terminated and the router creates a temporary ACL that allows traffic between the specific host(s) and resources defined in the ACL statements.

  4. The user(s) can then have temporary access through the router.

  5. When the time limit defined in the ACL is reached, the temporary ACL list is removed and a new authentication is required to continue.

Properly configured, dynamic access lists provide the same benefits as standard and static extended access lists with the additional security benefit of authenticating users, thereby reducing the opportunity for network break-ins by hackers.

Creating a Lock-and-Key System

Creating a dynamic ACL is a two-step process that includes building or modifying an ACL that will be applied to a router interface, and then configuring the virtual terminal access to support the feature.

The Dynamic ACL Statements

The dynamic access list feature is an option for both numbered and named extended access lists for TCP, UDP, ICMP, and IGMP traffic. The [dynamic dynamic-name [timeout minutes]] options precedes the {permit | deny} choice.

The basic syntax for a numbered ACL would be the following:

Router(config)#access-list acl# [dynamic dynamic-name [timeout minutes]] {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]

The basic syntax for a named ACL would be as follows:

Router(config)#ip access-list extended name Router(config-ext-nacl)#[dynamic dynamic-name [timeout minutes]] {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]


Identifies this access list as a dynamic access list, meaning it can create a temporary ACL.


The name of the temporary ACL to be created.

timeout minutes

Specifies the absolute length of time (in minutes) a temporary ACL can exist. Warning: The default is infinite, which allows an entry to remain permanently until an administrator deletes it. Always set a timeout to close this “hole” in your security.

The following simple example creates a named access list with a dynamic access list statement. Line two allows any host to telnet to the router (IP address Line three enables a dynamic list entry called allow-in. The statement allows router access to any IP traffic from the authenticated host or the host network. It also limits the temporary access to 60 minutes, regardless of activity.

Rtr1(config)#ip access-list extended filter-in
Rtr1(config-ext-nacl)#permit tcp any host eq telnet
Rtr1(config-ext-nacl)#dynamic allow-in timeout 60 permit ip any any

Because the dynamic ACL will be applied to an interface and because only be one ACL can exist in each direction per protocol, the dynamic statements are typically going to be added to an existing ACL that’s already regulating traffic through that interface.

The Virtual Terminal Statements

The [dynamic dynamic-name [timeout minutes]] options precede the permit | deny choice.

Router(config-line)#autocommand access-enable [host] [timeout minutes]


Executes the access-enable command when a user authenticates through a Telnet session into the router.


Enables the lock-and-key access feature by enabling the router to create a temporary access list entry in a dynamic access list.


Limits access to the host that originated the Telnet. If not included, the temporary ACL allows access by all hosts on the network defined by the ACL dynamic statement network mask.


Specifies an idle timer (in minutes) for the temporary ACL entry. If the temporary ACL statement isn’t accessed within this time period, the statement is deleted and requires the user to authenticate again. The default is for the entries to remain permanently.

The following example creates a single password—cisco—and then enables the dynamic ACL to create a temporary ACL limited to the host that authenticated. If five minutes pass between exchanges, the temporary entry is deleted.

This example could be one solution to the problem in Figure 5-3 to allow an administrator to access the network from home.

Rtr1(config)#username itadmin password cisco
Rtr1(config)#ip access-list extended filter-in
Rtr1(config-ext-nacl)#permit tcp any host eq telnet
Rtr1(config-ext-nacl)#permit tcp any any established
Rtr1(config-ext-nacl)#permit icmp any any
Rtr1(config-ext-nacl)#dynamic allow-in timeout 60 permit ip any any log
Rtr1(config-ext-nacl)#int s0/0
Rtr1(config-if)#ip address
Rtr1(config-if)#ip access-group filter-in in
Rtr1(config-if)#line vty 0 4
Rtr1(config-line)#login local
Rtr1(config-line)#autocommand access-enable host timeout 5

Line 1 defines an acceptable user name/password combination.

Line 11 stipulates that the local database of user names and passwords will be used to authenticate. If multiple user name/password combinations had been configured, any set would be accepted.

Line 3, permit tcp any host eq telnet, allows anyone to access the lock-and-key router. The “any” could be replaced by a host address, permit tcp host host eq telnet, if the admin has a permanent IP address. This reduces the opportunities for outsiders to access the network. Even if it can’t be reduced to a single IP address, a network address and wildcard mask could limit exposure.

Line 6, dynamic allow-in timeout 60 permit ip any any, specifies the temporary ACL will be called allow-in, limits the temporary ACL statements to 60 minutes, and specifies the temporary ACL statements will allow any host access to any network for IP traffic. If the host option is left off line 12, the temporary ACL will be open to any host in the world. By replacing the first “any” with a network address and a wildcard mask, the exposure could be limited. Replacing the last “any” with a host address or a network address and a wildcard mask, all authenticated access would be limited to the defined address(es). An example of changes to line six could be the following: dynamic allow-in timeout 60 permit ip

Line 12 limits access to only the host address that authenticated and sets the idle timer to five minutes.

Line 10, line vty 0 4, specifies that all five virtual terminal sessions will be configured for lock-and-key. But, what if you have to Telnet into that router for administration purposes? The router is going to authenticate us, and then close the Telnet session just like everyone else. The following lines show an alternative that configures virtual lines 0 through 3 (4 total) to lock-and-key while saving the final session, line vty 4, for separate configuration.

line vty 0 3
 ?login local
 ?autocommand access-enable host timeout 10
line vty 4
 ?password cisco
 ?rotary 1
The rotary Command

Because normal virtual sessions are assigned in round-robin fashion, knowing which session is being accessed is impossible. The rotary 1 command, shown in the example, makes it possible to specify a port number (3001) when setting up the Telnet session, and thereby specify the virtual session. The numbers in the 3000 range are reserved for this purpose, so adding 3000 to a rotary value used will access the correct line. The Telnet 3001 command would access the vty session 4. If the rotary statement had been rotary 17, the Telnet command would have used 3017.

Display Dynamic Access Lists

Displaying a temporary access list is much like any other access list using the show access-list [acl# | acl-name] or show ip access-list [acl# | acl-name] commands from Privilege Exec mode. The trick is this: the temporary access-list lines are only present when they’re in use. After the absolute or idle timeout parameter has activated, the temporary entries are cleared. The number of matches displayed indicates the level of activity for that statement since the last time the counters were cleared.

Rtr1#sho access-lists
Extended IP access list filter-in
 ???permit tcp any host eq telnet (66 matches)
 ???permit tcp any any established (232 matches)
 ???permit udp any any eq rip (44 matches)
 ???Dynamic allow-in permit ip any any log
 ?????permit ip host any log (21 matches) (time left 253)
00:36:10: %SEC-6-IPACCESSLOGP: list filter-in permitted tcp -
>, 2 packets

Line seven identifies the host that authenticated and specifies that 21 packets were permitted. The time left is 253 seconds. Each time another match is made, the idle timer is reset to 300, the five minutes specified in the autocommand access-enable host timeout 5 command.

Reflexive Access Lists

As you learned in Chapter 3, the TCP Established option could be useful in limiting access to the local networks to those sessions that originated from inside the network. Any packets originating from the outside that are trying to establish a connection would be rebuffed. But what about other protocols like UDP and ICMP that aren’t connection oriented? In fact, a similar problem occurs with TCP applications that send on one port and receive on another. Either way, the established feature doesn’t always work in these cases.

A feature of IP-named extended access lists, called reflexive access lists, provides what is referred to as reflective filtering. Any IP packet going out of a filtered port will create a temporary access list statement inbound, which is a mirror image of the outgoing packet source and destination information. This temporary opening remains active until a TCP FIN packet is received or the idle timer expires. The idle timer timeout feature is critical for protocols that don’t have a session-ending message, such as UDP and ICMP.

If host wants to use TCP port 1045 to establish a telnet session with in another network through its TCP 23 (telnet) port, the access list statement to allow this—if one had to be created—would look like the following:

permit tcp host eq 1045 host eq 23

What gets created is a temporary reflected inbound statement, which looks like the following:

permit tcp host eq 23 host eq 1045 

Reflexive access lists can filter network traffic based on IP upper-layer protocol information by using port numbers. They create temporary ACL statements that permit returning IP traffic for sessions originating from within the network, but prevent other IP traffic from outside. They use reflexive filtering that can only be defined in named extended IP access lists.

Reflexive access lists can be an important part of securing your network against spoofing and certain DoS attacks. They can be a major component in a router firewall defense strategy. Reflexive access lists are relatively simple to use and provide greater control over which packets enter your network than do basic access lists.

Selecting the Interface to Use

Reflexive access lists are generally applied to a perimeter router. You can apply reflexive ACLs to either the external or the internal interface. Whenever possible, the reflexive ACL should be configured on the outside interface to block unwanted IP traffic.

Figure 5-4 shows two topologies that might be found on the perimeter of the company network. The topology on the left is a basic perimeter router. In this case, the reflexive ACL can be applied to the external interface (serial) and keep all blocked traffic out of the router.

Click To expand
Figure 5-4: Topology impacts on interface selection

The topology on the right shows a single-device firewall design for supporting shared servers in a DMZ network. In this case, putting the reflexive ACL on the external interface would undoubtedly interfere with legitimate traffic going to the DMZ area. Placing the ACL on the internal interface can protect the local network, while not interfering with traffic to and from the shared resources in the DMZ.

Configure Reflexive Access Lists

Reflexive access lists aren’t applied directly to an interface but, instead, are nested into an extended-named IP access list that’s applied to an interface. Because of the concept of nesting, reflexive access lists don’t have the usual implicit deny-all at the end of the list.

Two primary commands need to be configured in building reflexive access lists: the reflect command and the evaluate command. In addition, the ip reflexive-list timeout command is for setting the idle timer.

The reflect Statement

The keyword reflect in a permit statement is the key to creating the return entries in the temporary access list. The reflect statement in an outbound ACL creates the entries in the inbound ACL when packets matching the condition(s) are recognized.

The ACL that contains the reflect statement can also contain regular permit and deny statements, either before or after the reflect statement. If a match occurs, the packet will be processed but won’t trigger a temporary entry in the reflexive access list.

The basic syntax is

Rtr(config)#ip access-list extended name
Rtr(config-ext-nacl)#permit protocol source destination reflect name [timeout seconds]


Any TCP/IP protocol that can use named extended ACLs

source and destination

Same as any ACL source and destination, including keywords host and any, wildcard masks, and port numbers


Name of temporary reflexive ACL to be created


Optional idle timer for this line only that overrides the absolute timeout set by the ip reflexive-list timeout global configuration command (default is 300 seconds)

Examples follow the discussion of the evaluate statement in the next section.

The evaluate Statement

The evaluate statement is the final configuration entry in another named extended IP access list that partners with the permit/reflect statements previously discussed. The syntax is as follows:

Router(config-ext-nacl)#evaluate name


Name of temporary reflexive ACL specified in the permit/reflect statements

The following is a simple example where outgoing TFTP and HTTP traffic is allowed and generates return openings in a temporary ACL called newlist. The Telnet entries in both ACLs are only an example of normal ACL statements that don’t generate entries in newlist.

Internet serial 0
 ?ip access-group ok-out out
 ?ip access-group ok-in in
ip access-list extended ok-out
 ?permit tcp any any eq telnet
 ?permit udp any any eq tftp reflect newlist
 ?permit tcp any any eq www ?reflect newlist
ip access-lst extended ok-in
 ?permit tcp any any eq telnet
 ?evaluate newlist 

Two named access lists, ok-out and ok-in, are applied to the external serial interface. ok-out contains two reflect permit statements, plus a normal Telnet statement. Outbound TFTP and HTTP packets will create entries in a temporary access list named newlist, which reverses the source and destination designations of the outbound packets.

The ok-in evaluate newlist statement incorporates the newlist statements.

The ip Reflexive-list timeout (Seconds) Command

The global mode command ip reflexive-list timeout seconds specifies the length of time reflexive access list statements remain in the ACL if no packets in that session are detected. Each new matching packet rests the timeout timer. If no timeout statement is specified, the default timeout value is 300 seconds. The next example shows changing the idle timeout to two minutes.

External Interface Example

The following is a simple example of a reflexive ACL applied to an external interface allowing the LAN ( users access to the Internet and the DNS servers.

ip reflexive-list timeout 120
Interface serial 0
 ?ip access-group lan-out out
 ?ip access-group lan-in in
ip access-list extended lan-out
 ?deny icmp any any
 ?permit tcp any any eq dns reflect ok-packets timeout 240
 ?permit tcp any any eq www reflect ok-packets
ip access-list extended lan-in
 ?deny icmp any any
 ?evaluate ok-packets

The first line changes the global timeout value to two minutes for all reflexive access lists entries on this router that don’t specify their own timeout value. Line nine sets a four-minute idle timer for the DNS packets only.

Internal Interface

The following is a simple example of a reflexive ACL applied to an internal interface allowing the LAN ( users access to the Internet and the DNS servers. Typically, this implementation would be used if there’s another network (DMZ) of shared servers. Placing the ACL on the external interface would interfere with the outside access to the servers.

Interface ethernet 1
 ?ip access-group lan-in in
 ?ip access-group lan-out out
ip access-list extended lan-in
 ?deny icmp any any
 ?permit tcp any any eq dns reflect ok-packets timeout 120
 ?permit tcp any any eq www reflect ok-packets timeout 180
ip access-list extended lan-out
 ?deny icmp any any
 ?evaluate ok-packets

The two permit/reflect entries set their own timeout, two and three minutes, respectively. Without these timeout settings, they would be governed by the global default (300 seconds).

Viewing Reflexive Access Lists

Reflexive access lists can be displayed using the show access-list command. No reflexive access list entries will appear if no outbound traffic has triggered the reflexive access list. After a HTTP session is initiated from within the network, the show access-list command could display the following:

Extended IP access list lan-in
 ?permit icmp any echo-response
 ?permit tcp any host eq 80 (7 matches)
 ?permit bgp any any (4 matches)
 ?evaluate ok-packets
Extended IP access list lan-out
 ?permit tcp any eq 80 reflect ok-packets timeout 180
 ?permit tcp any eq 53 reflect ok-packets
Reflexive IP access list ok-packets
 ?permit tcp host eq www host 195.168.52 eq 80 (5 matches)
 ???(time left 140 seconds)
Reflexive Access Lists Caveats

Some applications, like FTP, allow port numbers to be changed during a session, meaning the port numbers of returning packets aren’t the same as the originating packet. Reflexive access lists can’t resolve this and the return packet will be denied—even if it’s part of the same session. Passive FTP is an option that will work with reflexive access lists if the FTP site supports it.

Reflexive access lists can’t examine data in the packet beyond the Layer 4 (OSI model) information, such as TCP and UDP port numbers and the related IP addresses. They can’t follow the application as you just saw with the FTP discussion in the preceding paragraph.

Part III: Virtual Private Networks (VPNs)