Access Control via Cisco IOS Access Control Lists

Cisco IOS software provides traffic-filtering capabilities for Access Control Lists (ACLs) with the capability to prevent traffic from entering or exiting the network. ACLs provide filtering in Cisco IOS software because they can be used to control traffic by allowing or denying network access. The IINS exam objectives that will be covered in this chapter are as follows:

• Explain the functionality of standard, extended, and named IP ACLs used by routers to filter packets
• Configure and verify IP ACLs to mitigate given threats (filter IP traffic destined for Telnet, SNMP, and DoS attacks) in a network using CLI
• Configure IP ACLs to prevent IP address spoofing using CLI
• Discuss the caveats to be considered when building ACLs

This chapter is broken up into the following sections:

• Access Control List Overview
• Access Control List Types
• ACL Processing and Packet Flow Rules
• Implementing ACLs
• Using ACLs to Mitigate Network Layer Attacks
• Using ACLs to Secure Telnet Access
• Using ACLs to Secure SNMP Access

We cover access lists in detail in our Cisco CCNA video and lab course.

Back to book index.

Access Control List Overview

An Access Control List (ACL) is a list of permit and deny statements that controls network access to enforce a security policy. Each filter in an ACL, referred to as an Access Control Entry (ACE), permits or denies a packet, or packets, across an interface based on the information contained inside the packets. There are two broad categories for data received by a router:

1. It is traffic that passes through the router via the forwarding path; or
2. It is traffic destined for the router for route processor handling.

In normal operations, the vast majority of traffic simply flows through a router en route to its ultimate destination. Therefore, if ACLs are not configured and implemented, all packets passing through the router can also be allowed onto all parts of the network – which is very undesirable in terms of network security. Administrators can use ACLs to prevent such behavior and restrict traffic between networks so as to comply with security policy. In addition to this, administrators can also use ACLs in numerous other ways, such as to:

• Filter routing information received from or sent to adjacent neighbors;
• Control access to networks by permitting or denying particular types of traffic;
• Control interactive access to the router itself, e.g. Telnet, HTTPS, and SSH;
• Define interesting traffic that can be used to initiate ISDN connections;
• Define interesting traffic for IPSec Virtual Private Network (VPN) encryption;
• Define queuing and Quality of Service (QoS) features, allowing traffic to be prioritized;
• Use in security techniques such as TCP Intercept and the Cisco IOS Firewall;
• Define traffic for Network Address Translation (NAT); and
• Mitigate IP spoofing, smurf attacks, and other similar network attacks.

While this list provides some of the most common applications and uses of ACLs, it is important to know that it does not encompass all possible uses of ACLs. However, the list is a good starting point for understanding the flexibility afforded by ACLs.

Access Control List Types

There are many types of ACLs that can be configured in Cisco IOS software. While knowledge of the majority of these ACLs is beyond the scope of the IINS course requirements, as a future network security administrator, you should be familiar with the different ACL configuration options available in Cisco IOS software. Therefore, the following section provides a brief description of the different types of IP ACLs available in Cisco IOS software. The different types of ACLs that are covered in this section are as follows:

• IP Standard ACLs
• IP Extended ACLs
• IP Named ACLs
• Dynamic ACLs
• Reflexive ACLs
• Time-based ACLs
• Turbo ACLs
• Receive ACLs
• Infrastructure Protection ACLs
• Transit ACLs
• Classification ACLs

IP Standard ACLs

IP standard ACLs are one of the most basic types of ACLs that can be configured for matching IP packets. These ACLs inspect traffic based on the source address of the IP packets.

IP standard ACLs filter only the source address. This allows administrators to restrict or allow access to the network for a subnet, group of subnets, or specific hosts based on where they are coming from. Because they filter only the source address, IP standard ACLs should be placed as close as possible to the destination network. This concept is illustrated in the following diagram:

Figure 4.1. Access List Placement

In the diagram illustrated above, Host 1 sends an IP packet to Host 2. However, based on network security policy, Host 1 should not be allowed to communicate with Host 2. When using IP standard ACLs, an inbound IP ACL should be configured on the FastEthernet0/0 interface of R3.

One of the most common mistakes when using IP standard ACLs is to implement them in the wrong place. For example, if the standard ACL to prevent Host 1 from communicating with Host 2 was placed on the FastEthernet0/0 interface of R1, Host 1 not only would be unable to communicate with Host 2, it also would be unable to communicate with any other host that did not reside on the 10.1.1.0/24 subnet, as illustrated in the following diagram:

Figure 4.2. Access List Placement Error

In the diagram above, an IP standard ACL is incorrectly configured on the FastEthernet0/0 interface of R1, in the inbound direction, with the intention of preventing this host from communicating with Host 2. However, because IP standard ACLs match only on source addresses, and not destination addresses, this incorrect placement effectively means that R1 will deny any and all packets from Host 1. This results in Host 1 not only being unable to communicate with Host 2 but also being unable to communicate with Hosts 3, 4, and 5.

IP standard ACL’s numbers can be anywhere from 1 to 99 or 1300 to 1999, as illustrated by the bold text in the following output:

R1(config)#access-list ? <1-99>            IP standard access list <100-199>         IP extended access list <1100-1199>       Extended 48-bit MAC address access list   <1300-1999>       IP standard access list (expanded range) <200-299>         Protocol type-code access list <2000-2699>       IP extended access list (expanded range) <700-799>         48-bit MAC address access list dynamic-extended  Extend the dynamic ACL absolute timer rate-limit        Simple rate-limit specific access list

The syntax used to configure IP standard ACLs is:

access-list access-list-number {deny | permit} source [source-wildcard] [log [word]]

For example, to configure an IP standard ACL to permit traffic from the 172.16.0.0/12 subnet, while denying traffic from host 192.168.1.254, the following configuration would be implemented on the router:

R1(config)#access-list 5 permit 172.16.0.0 0.15.255.255 R1(config)#access-list 5 deny host 192.168.1.254

The following example illustrates how to configure an IP standard ACL to permit traffic from host 10.1.1.254, deny traffic from all other hosts on the 10.1.1.0/24 subnet, block traffic from host 172.16.1.1, and allow traffic from the 172.16.1.0/24 subnet:

R1(config)#access-list 10 permit host 10.1.1.254 R1(config)#access-list 10 deny 10.1.1.0 0.0.0.255 R1(config)#access-list 10 deny host 172.16.1.1 R1(config)#access-list 10 permit 172.16.1.0 0.0.0.255

NOTE: When configuring ACLs, the host keyword can be replaced with the 0.0.0.0 address. For example,  access-list 10 permit host 10.1.1.254 can be configured as access-list 10 permit 10.1.1.254 0.0.0.0. These two configuration commands produce the same result.

One of the most common mistakes made with ACL configuration is applying the incorrect wildcard mask. A wildcard mask is simply the inverse of a subnet mask and is used to match subnets when configuring ACLs. For example, a network may have the subnet mask 255.255.255.0. In order to configure an ACL to match all hosts on this network, a wildcard mask of 0.0.0.255 must be used. As a second example, if a network has the subnet mask 255.255.255.128, a wildcard mask of 0.0.0.127 must be used to match all hosts on the subnet.

The simplest method to calculate the wildcard masks is to subtract the subnet mask from 255.255.255.255. This concept is illustrated below for the subnet mask 255.255.255.0:

Table 4.1. Wildcards masks 1

All-1s Subnet Mask	255	255	255	255
Minus Subnet Mask	255	255	255	0
Wildcard Mask	0	0	0	255

As a second example, to determine the wildcard mask for the 255.255.255.128 subnet, the same basic calculation would be performed. This is illustrated in the following table:

Table 4.2. Wildcards masks 2

All-1s Subnet Mask	255	255	255	255
Minus Subnet Mask	255	255	255	128
Wildcard Mask	0	0	0	127

Using this as a reference, an ACL to permit the 172.16.1.0/25 and 172.16.1.128/25 subnets would be configured as follows:

R1(config)#access-list 50 permit 172.16.1.0 0.0.0.127 R1(config)#access-list 50 permit 172.16.1.128 0.0.0.127

Using the same concept, we would calculate the wildcard mask for the 70.7.7.64/26 subnet, as illustrated in the following table:

Table 4.1. Wildcards masks 1

All-1s Subnet Mask	255	255	255	255
Minus Subnet Mask	255	255	255	192
Wildcard Mask	0	0	0	63

The ACL to deny this subnet, for example, would therefore be configured as follows:

R1(config)#access-list 25 deny 70.7.7.64 0.0.0.63

IP Extended ACLs

IP extended ACLs allow for greater filtering capabilities than IP standard ACLs. IP extended ACLs can be used to filter based on source address, destination address, specific protocols, ports, and flags. IP extended ACLs are configured using a range of 100 to 199 or 2000 to 2699. The syntax used to configure an IP extended ACL is:

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [time-range time-range-name] [fragments] [log [word] | log-input [word]]

The syntax used to configure an IP extended ACL for ICMP is:

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} icmp source source-wildcard destination destination-wildcard [icmp-type [icmp-code] | icmp-message] [precedence precedence] [tos tos] [time-range time-range-name] [fragments] [log [word] | log-input [word]]

The syntax used to configure an IP extended ACL for TCP is:

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established] [precedence precedence] [tos tos] [time-range time-range-name] [fragments] [log [word] | log-input [word]]

And, finally, the syntax used to configure an IP extended ACL for UDP is:

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} udp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [precedence precedence] [tos tos] [time-range time-range-name] [fragments] [log [word] | log-input [word]]

As can be seen, IP extended ACLs provide far greater filtering capabilities than those provided by IP standard ACLs. These are the most commonly used ACLs when enforcing network security policy. It is therefore important that you thoroughly understand the options available with IP extended ACLs.

Unlike IP standard ACLs, extended ACLs should be placed closest to the source as possible. This is because IP extended ACLs have the capability to match based on source and destination addresses. This concept is illustrated in the following diagram:

Figure 4.3. Placing Extended Access Lists

As illustrated in the diagram above, extended IP ACLs should be applied as close to the ingress point (source) as possible because they can filter based on source and destination pairs. Therefore, applying an IP extended ACL inbound on the FastEthernet0/0 interface of R1 would effectively prevent Host 1 from being able to communicate with Host 2, while still allowing the same host to communicate with Hosts 3, 4, and 5.

Although applying the same ACL inbound on the FastEthernet0/0 interface of R3 would produce the same result, it demonstrates a lack of knowledge on extended ACL application. This is because the packet is allowed to traverse R1 and R3 before being blocked, when it actually should be blocked on R1, thus preventing the unnecessary consumption of resources (e.g. memory, route lookups, etc.) on R1 and R2.

The following example illustrates how an IP extended ACL can be configured to permit OSPF traffic, deny all UDP packets that are destined to host 10.1.1.254, deny ICMP ping packets, and, finally, permit WWW traffic from the 192.168.1.0/24 subnet to any subnet:

R1(config)#access-list 150 permit ospf any any R1(config)#access-list 150 deny udp any host 10.1.1.254 R1(config)#access-list 150 deny icmp any any echo R1(config)#access-list 150 deny icmp any any echo-reply R1(config)#access-list 150 permit tcp 192.168.1.0 0.0.0.255 any eq www

When using IP extended ACLs for security purposes, one of the most important functions or services provided by these ACLs is the ability to provide detailed logging information. While both IP standard and IP extended ACLs provide the administrator the capability to log against matches via the log keyword, only IP extended ACLs provide detailed logging capabilities provided by the log-input keyword.

Logging, which is described in detail in the next chapter, is globally enabled via the logging on global configuration command. Cisco IOS routers have the capability to store logs locally (i.e. on the router itself) and administrators can use the logging buffered [level] global configuration command to enable this functionality. Administrators can check local logs on the router by issuing the show logging command.

Additionally, administrators can also send logs to a remote Syslog server via the logging host [ip address] global configuration command to specify the IP address of the Syslog server, and then the logging trap [level] global configuration command to specify the level of messages to send to the Syslog server. Syslog, and other logging types, are also described in detail in the next chapter.

The log keyword used in IP standard and extended ACLs causes an informational logging message about the packet that matches the entry to be sent to the Console, buffer, or a remote Syslog server, depending on the router configuration.

For IP standard ACLs, the log message includes the ACL number, whether the packet was permitted or denied, the source address, the number of packets, and, if appropriate, the user-defined cookie or router-generated hash value, which is beyond the scope of the IINS course requirements. The message is generated for the first packet that matches and then at 5-minute intervals, including the number of packets permitted or denied in the prior 5-minute interval.

However, for IP extended ACLs, the log message includes the ACL number, whether the packet was permitted or denied, the protocol, whether it was TCP, UDP, ICMP, or a number, and, if appropriate, the source and destination addresses and port numbers, and the user-defined cookie or router-generated hash value. As is the case with IP standard ACLs, the message is generated for the first packet that matches and then at 5-minute intervals, including the number of packets permitted or denied in the prior 5-minute interval.

The log-input keyword includes the input interface and source MAC address or virtual circuit in the logging output. This can provide valuable information during an attack. For example, the following ACL is configured to provide detailed logging for all TCP and UDP packets sourced from the 172.16.1.0/24 subnet:

R1(config)#access-list 180 permit tcp 172.16.1.0 0.0.0.255 any log-input R1(config)#access-list 180 permit udp 172.16.1.0 0.0.0.255 any log-input

In the following output, the show ip access-lists command shows some matches against this ACL, based on TCP and UDP packets from the 172.16.1.0/24 subnet:

R1#show ip access-lists 180 Extended IP access list 180 10 permit tcp 172.16.1.0 0.0.0.255 any log-input (20 matches) 20 permit udp 172.16.1.0 0.0.0.255 any log-input (39 matches)

Assuming that extended ACL 180 is applied inbound on an Ethernet interface, because of the log-input keyword, the MAC address of the IP address matching against this ACL, as well as the input interface, will be provided in the log, as follows:

R1#show logging Syslog logging: enabled (1 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)   No Active Message Discriminator.       No Inactive Message Discriminator.     Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging:  level informational, 4 messages logged, xml disabled, filtering disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled Trap logging: level informational, 22 message lines logged   Log Buffer (4096 bytes):   *Mar  1 01:45:30.074: %SEC-6-IPACCESSLOGP: list 180 permitted udp 172.16.1.254(0) (FastEthernet0/0 001d.09d4.0238) -> 172.16.1.255(0), 1 packet *Mar  1 01:45:58.405: %SEC-6-IPACCESSLOGP: list 180 permitted tcp 172.16.1.254(0) (FastEthernet0/0 001d.09d4.0238) -> 172.16.1.1(0), 1 packet

The subsequent example illustrates how an IP extended ACL can be used to perform the following:

• Disallow Web traffic from network 172.16.1.0/24 to network 192.168.1.0/29
• Allow traffic from network 172.16.1.0/24 to access only FTP on 192.168.1.0/29
• Allow TACACS+ traffic from host 10.1.1.254 to host 192.168.254.1
• Disallow SNMP traffic from any network to server 192.168.254.1

r1(config)#access-list 100 remark ‘Disallow WWW Traffic from 172.16.1.0/24 to 192.168.1.0/29' r1(config)#access-list 100 deny tcp 172.16.1.0 0.0.0.255 eq www 192.168.1.0 0.0.0.7 r1(config)#access-list 100 remark ‘Allow 172.16.1.0/24 to access FTP on 192.168.1.0/29' r1(config)#access-list 100 permit tcp 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.7 eq 21 r1(config)#access-list 100 remark ‘Allow TACACS+ from host 10.1.1.254 to host 192.168.254.1' r1(config)#access-list 100 permit tcp host 10.1.1.254 eq tacacs host 192.168.254.1 r1(config)#access-list 100 remark ‘Deny SNMP traffic from any to server 192.168.254.1' r1(config)#access-list 100 deny udp any eq snmp host 10.1.1.254

The following example illustrates how an IP extended ACL can be used to perform the following:

• Allow all OSPF routing protocol traffic
• Disallow all EIGRP routing protocol traffic
• Allow all RIP routing traffic
• Allow all other traffic from any source network to any destination and log it

r1(config)#access-list 150 remark ‘Allow OSPF' r1(config)#access-list 150 permit ospf any any r1(config)#access-list 150 remark ‘Deny EIGRP' r1(config)#access-list 150 deny eigrp any any r1(config)#access-list 150 remark ‘Allow RIP' r1(config)#access-list 150 permit udp any eq rip any r1(config)#access-list 150 remark ‘Allow all IP traffic and log it' r1(config)#access-list 150 permit ip any any log

IP Named ACLs

IP named ACLs are simply IP standard and IP extended ACLs that are configured using administrator-defined names, instead of the reserved ranges used in Cisco IOS. Their functionality is exactly the same as that of numbered ACLs, and they are applied to both interfaces and terminal lines in the same manner. The main difference, however, is in the configuration. The syntax used to configure standard or extended IP named ACLs is:

ip access-list {standard | extended} {access-list-name | access-list-number}

If you opt to use a number for the configuration of an IP named ACL, you must adhere to the ranges reserved for both IP standard and extended ACLs. In other words, the Cisco IOS software will not allow you to configure a standard IP named ACL using the number 100, for example, as that is used by numbered IP extended ACLs. If you so attempt, you will receive an error message similar to the following:

R1(config)#ip access-list standard 100 % % Invalid access list name.

The same is applicable when configuring IP named extended ACLs; you cannot use a number that is reserved for IP extended ACLs. To avoid such situations, it is simply recommended that if you prefer to use names for ACL configuration, configure IP named ACLs using unique names, instead of numbers; however, if you prefer to use numbers for ACL configuration, then use the IP standard and extended ACLs in your configuration instead.

The following example illustrates how to configure an IP named extended ACL named EXT-ACL and an IP named standard ACL named STA-ACL on a router:

R1(config)#ip access-list extended EXT-ACL R1(config-ext-nacl)#permit tcp any any R1(config-ext-nacl)#permit udp any any R1(config-ext-nacl)#exit R1(config)#ip access-list standard STA-ACL R1(config-std-nacl)#permit host 10.1.1.1 R1(config-std-nacl)#permit host 10.1.1.2

Dynamic ACLs

Dynamic ACLs are also referred to as Lock-and-Key ACLs.  These ACLs allow administrators to set up a dynamic access that will allow per-user access control to a particular source or destination using an authentication mechanism. The lock-and-key feature depends on the following items: Telnet, an authentication process, and an IP extended ACL.

Because dynamic ACL configuration is beyond the scope of the IINS course requirements, the configuration commands required to enable this functionality will not be discussed. However, the following example illustrates the output of the show ip access-lists command on a router if a dynamic IP ACL was configured and applied to an interface:

R1#show ip access-lists Extended IP access list DYNAMIC-ACL-EXAMPLE 10 permit tcp host 172.16.1.254 host 172.16.1.1 eq telnet (60 matches)     20 Dynamic DACL permit ip any any        permit ip host 172.16.1.254 any (90 matches) (time left 599)

Reflexive ACLs

Reflexive ACLs allow IP packets to be filtered based on upper-layer session information. These ACLs are generally used to allow outbound traffic, while limiting inbound traffic to traffic from sessions originated from the internal network(s), as illustrated in the following diagram:

Figure 4.4. Reflexive Access Lists

In the diagram illustrated above, when reflexive ACLs are configured and implemented, the router will only permit inbound traffic from external networks, or hosts, if it was originated by internal hosts, as illustrated in step 1. If external hosts attempt to connect to internal hosts, the packets will be denied, unless explicitly permitted on the inbound ACL on the router, as illustrated in step 2.

Reflexive ACLs can only be used with IP extended ACLs. You cannot configure IP named or standard ACLs as reflexive ACLs; however, reflexive ACLs can be used in conjunction with IP named or numbered ACLs. In other words, reflexive ACLs can be applied on the same interface as other ACLs; however, they can only be defined using IP standard ACLs.

As is the case with dynamic ACLs, the configuration of reflexive ACLs is beyond the scope of the IINS course requirements. However, the following output illustrates how a configured reflexive ACL would look in the output of the show ip access-lists command in Cisco IOS routers:

R1#show ip access-lists Extended IP access list INBOUND 10 permit tcp any any reflect MY-REFLECT (93 matches) 20 permit icmp any any reflect MY-REFLECT (24 matches) Reflexive IP access list MY-REFLECT      permit icmp host 1.1.1.1 host 172.16.1.254  (10 matches) (time left 297)      permit icmp host 150.1.1.1 host 172.16.1.254  (10 matches) (time left 289) Extended IP access list OUTBOUND 10 evaluate MY-REFLECT

Time-based ACLs

Time-based ACLs are similar to IP extended ACLs; however, they provide an additional capability that controls access based on the time. The time specified in the configuration of time-based ACLs is dependent on the router’s system clock. However, the majority of time-based ACL implementations are deployed on routers that have their system clock synchronized to a Network Time Protocol (NTP) server.

NTP is a protocol for synchronizing the clocks of computer systems over IP to network time servers, which may be private or public (i.e. on the Internet). Time-based ACL configuration is beyond the scope of the IINS course requirements; however, the following output illustrates how entries in a time-based ACL would appear on a router configured with a time-based ACL:

R1#show ip access-lists Extended IP access list 100     10 permit tcp any any time-range MY-TIME (active) (67 matches)     20 permit icmp any any time-range MY-TIME (active) (12 matches)

Turbo ACLs

The turbo ACL feature is designed to process ACLs more efficiently and improve router performance. This feature is available only on high-end Cisco IOS routers, such as the Cisco 7200 and 7500 series routers, which are beyond the requirements of the IINS course.

Traditional ACLs are searched sequentially, in a top-down manner, until a match is found. However, as ACLs grow larger, a significant amount of time and resources, such as memory, will be consumed as the router processes packets. This can add to a delay in the forwarding of packets and result in poor router performance.

The turbo ACL feature compiles ACLs into a group of lookup tables while maintaining the first match requirements. This leads to reduced latency because the time it takes to match packets is fixed and consistent. Turbo ACLs are enabled by using the show access-list compiled global configuration command. The following output illustrates a router with turbo ACLs configured on it:

R1#show access-list compiled Compiled ACL statistics: 12 ACLs loaded, 12 compiled tables ACL         State      Tables  Entries  Config  Fragment  Redundant  Memory 1           Operational    1        2        1         0          0      1Kb 2           Operational    1        3        2         0          0      1Kb 3           Operational    1        4        3         0          0      1Kb 4           Operational    1        3        2         0          0      1Kb 5           Operational    1        5        4         0          0      1Kb 9           Operational    1        3        2         0          0      1Kb 20          Operational    1        9        8         0          0      1Kb 21          Operational    1        5        4         0          0      1Kb 101         Operational    1       15        9         7          2      1Kb 102         Operational    1       13        6         6          0      1Kb 120         Operational    1        2        1         0          0      1Kb 199         Operational    1        4        3         0          0      1Kb First level lookup tables: Block      Use               Rows     Columns   Memory used 0   TOS/Protocol            6/16     12/16      66048 1   IP Source (MS)         10/16     12/16      66048 2   IP Source (LS)         27/32     12/16      132096 3   IP Dest (MS)            3/16     12/16      66048 4   IP Dest (LS)            9/16     12/16      66048 5   TCP/UDP Src Port        1/16     12/16      66048 6   TCP/UDP Dest Port       3/16     12/16      66048 7   TCP Flags/Fragment      3/16     12/16      66048

Receive ACLs

Receive ACLs are used to increase security on Cisco 12000 routers by protecting the gigabit route processor (GRP) of the router from unnecessary and potentially nefarious traffic. Cisco 12000 series routers are typically found in Service Provider networks and are beyond the requirements of the IINS course.

Receive ACLs can be configured using the ip receive-access-list {100-199|1300-2699} global configuration command. You are not expected to demonstrate knowledge on the Cisco 12000 series platform or receive ACLs as part of the IINS course requirements.

Infrastructure Protection ACLs

Infrastructure Protection ACLs (iACLs) are a conceptual view and require no special configuration. These ACLs are mainly used to reduce the risk of network infrastructure attacks by explicitly permitting only authorized traffic to the network infrastructure devices, such as routers, switches, and firewalls.

When configuring iACLs, it is important to ensure that when you explicitly deny traffic to infrastructure devices, you allow authorized (legitimate) transit traffic to pass through the router, to ensure uninterrupted traffic flow. Depending on the router platform, network infrastructure protection can be achieved through a variety of techniques, as follows:

• Receive ACLs (rACLs)

These are supported on Cisco 12000 and 7500 platforms support. These ACLs are designed to filter all traffic destined to the Route Processor (RP) and do not affect transit traffic. Authorized traffic must be explicitly permitted and the rACL must be deployed on every router. The RP performs route processing services on the router.

• Hop-by-hop router ACLs

Routers can also be protected by defining ACLs that permit only authorized traffic to the interfaces of the router, denying all others except for transit traffic, which must be explicitly permitted. This ACL is logically similar to a receive ACL but does affect transit traffic, and therefore can have a negative performance impact on the forwarding rate of a router, if it grows too large – although this can be mitigated by using turbo ACLs, if supported.

• Edge filtering via infrastructure ACLs

ACLs can be applied to the edge (i.e. the very beginning) of the network. This ACL explicitly filters traffic destined for infrastructure address space. Deployment of edge infrastructure ACLs requires that you clearly define your infrastructure space and the required and authorized protocols that access this space. The ACL is applied at ingress to your network on all externally facing connections, such as peering connections, customer connections, and so forth.

To clarify further this concept, we will use the following diagram as an example:

Figure 4.5. Infrastructure Protection Access Lists

In the diagram illustrated above, Company X owns the 150.1.0.0/16 public IP address space. This company has a large network, with many internal devices (i.e. routers, switches, etc.). Company X has therefore decided to dedicate the 150.1.0.0/24 and 150.1.1.0/24 to infrastructure devices; the remainder of the IP address space will be used for network hosts, which will include PCs, laptops, printers, servers, etc.

Company X is also peering to an Internet Service Provider. This peering is via the R1 and R2 routers belonging to Customer X and the ISP-1 and ISP-2 routers belonging to the ISP. The ISP routers are in turn connected to the Internet. Company X and the ISP are using BGP to advertise and exchange routing information.

Following best practices, Company X implements iACLs on its edge routers (R1 and R2). These iACLs will be used to deny external networks access to internal devices, which are all located on the 150.1.0.0/24 and 150.1.1.0/24 subnets.

The following output illustrates the configuration and application of an iACL to protect the infrastructure devices in the Company X network. Although this example depicts configuration on R1, the same concept would be applicable to R2:

R1(config)#ip access-list extended iACL-Inbound R1(config-ext-nacl)#remark ‘Deny Access To Internal Infrastructure Devices' R1(config-ext-nacl)#deny ip any 150.1.0.0 0.0.1.255 R1(config-ext-nacl)#remark ‘Permit All Other Traffic' R1(config-ext-nacl)#permit ip any any R1(config-ext-nacl)#exit R1(config)#interface serial 0/0 R1(config-if)#ip access-group iACL-Inbound in

Keep in mind, however, that there is no defined standard for configuring and creating iACLs. This is generally left to the discretion of network administrators, who can utilize best practices defined in RFCs, such as RFC 2827, which is described in the following section. However, it is important to ensure that the IP address range assigned to infrastructure devices is included; otherwise, the ACL cannot be considered a true iACL.

Transit ACLs

Transit ACLs are similar to infrastructure ACLs (iACLs) in two ways:

• Transit ACLs give administrators only a conceptual view; and
• Transit ACLs do not require any special configuration.

Transit ACLs are used to enhance network security by permitting only legitimate traffic into the network. In most cases, the filtering should be performed at the network edge, allowing for the control of inbound traffic into the network and blocking any unauthorized attempts at the edge of the network. Transit ACLs can be developed using the following guidelines:

• Use of anti-spoofing protection based on the following RFCs:

1. RFC 1918 – This RFC defines private IP address space that is not routable on the Internet.
2. RFC 2827 – This RFC provides anti-spoofing guidelines for network ingress filtering.
3. RFC 3330 – This RFC provides special addresses that might require filtering, e.g. 127.0.0.0/8.

• Explicitly permit return traffic from all connections originating from the internal network.
• Explicitly permit externally sourced traffic that is originating from the external network.
• Explicitly use a deny statement at the end of the ACL.

The following output illustrates how one might configure a transit ACL:

R1(config)#ip access-list extended TRANSIT-ACL R1(config-ext-nacl)#remark ‘Permit BGP Peer Session' R1(config-ext-nacl)#permit tcp host 200.1.1.2 host 200.1.1.1 eq bgp R1(config-ext-nacl)#permit tcp host 200.1.1.2 eq bgp host 200.1.1.1 R1(config-ext-nacl)#remark ‘Permit Return Traffic' R1(config-ext-nacl)#permit icmp any any echo-reply R1(config-ext-nacl)#permit icmp any any unreachable R1(config-ext-nacl)#permit icmp any any time-exceeded R1(config-ext-nacl)#remark ‘Permit Traffic to Our Web Server' R1(config-ext-nacl)#permit tcp any host 150.1.100.254 eq 80 R1(config-ext-nacl)#remark ‘Deny All Other Traffic' R1(config-ext-nacl)#deny ip any any log

As with the iACL example, keep in mind that this is simply an example because there is no single defined standard for configuring transit ACLs. Ensure that you are familiar with the three RFCs mentioned in this section. While going into their specific details is beyond the scope of the IINS course requirements, you should be able to identify RFCs based on their names and usage.

Classification ACLs

Classification ACLs are also referred to as characterization ACLs and are initially composed with all permit statements for various protocols, ports, and other characteristics that the administrator would like to identify. These ACLs are used to classify and categorize denial-of-service (DoS) attacks by identifying the type of traffic and its source.

When configuring classification ACLs, it is good practice to enable logging for the traffic you are trying to classify. In addition to this, it is also important to remember to enable the permit ip any any statement at the end of all classification ACLs so that all other traffic will not be blocked. The following example illustrates the configuration of a classification ACL:

R1(config)#show ip access-list extended CLASSIFICATION-ACL R1(config-ext-nacl)#permit icmp any any echo log-input R1(config-ext-nacl)#permit tcp any any syn log-input R1(config-ext-nacl)#permit tcp any any fragment log-input R1(config-ext-nacl)#permit udp any any fragment log-input R1(config-ext-nacl)#permit ip any any fragment log-input R1(config-ext-nacl)#permit ip any any

The administrator can then use the show ip access-lists command repeatedly to view the ACL counters and to determine the type of attack that is occurring. The administrator could then view the router logs, via the show logging command, to identify the source(s) of the attack and then create an applicable filter to block the source(s), while allowing legitimate traffic.

For example, an increasing amount of TCP SYN packets may be an indication of a SYN flood attack, while an increasing number of ICMP echo packets may indicate a smurf attack: 

R1#show ip access-lists CLASSIFICATION-ACL Extended IP access list CLASSIFICATION-ACL 10 permit icmp any any echo log-input (12 matches) 20 permit tcp any any syn log-input (11 matches) 30 permit tcp any any log-input fragments 40 permit udp any any log-input fragments 50 permit ip any any log-input fragments 60 permit ip any any (401 matches)

Using this information, the administrator can then configure restrictive ACLs to block the source host or subnet. This ACL would include both permit and deny statements and should never end with the permit ip any any statement used in classification ACLs. 

ACL Processing and Packet Flow Rules

When a packet enters a router, the destination address of the packet is checked against the entries in the routing table to identify the egress interface. The packet is also checked against any configured ACLs assigned to the interface and will either be permitted or denied accordingly. ACLs can be applied to inbound or outbound directions on router interfaces. The following diagram illustrates the inbound and outbound directions as they apply to LAN and WAN interfaces:

Figure 4.6. Access List Directions

Inbound ACL Processing

When an inbound ACL is applied to an interface, the router checks the received packets against the statements in the ACL, looking for a match. If a match is found, and the ACL action is to permit, then the router continues to process the packet. However, if a match is found, and the action is to deny, the router discards the packet and typically (unless otherwise configured) sends an ICMP Destination Unreachable message, typically using the Administratively Prohibited code, back to the source address. This is illustrated in the following screenshot for a simple ping generated from a Windows-based client to a subnet blocked by an Access Control List:

Figure 4.7. ICMP Unreachable

In the screenshot provided above, the Windows-based client is receiving an ICMP Destination Unreachable message from 172.16.1.1. This IP address is the address of the device (router) that has been configured with an ACL preventing traffic from being sent to the 192.168.1.1 host. The configuration of the router is as follows:

R1#show running-config interface fastethernet 0/0 Building configuration…   Current configuration : 119 bytes ! interface FastEthernet0/0 ip address 172.16.1.1 255.255.255.0 ip access-group 100 in duplex auto speed auto end   R1#show ip access-lists 100 Extended IP access list 100 10 deny ip any host 192.168.1.1 (12 matches) 20 permit ip any any (186 matches)

In the event that a match is not found, the router applies the default deny all statement at the end of ACLs and discards the packet(s), sending the source an ICMP Destination Unreachable message. ICMP is a core component of Cisco CCNA certification, and ICMP messages are covered in detail in the CCNA study guide.

Inbound ACL Packet Flow Processing in Cisco IOS routers

The following diagram illustrates the processing of an inbound packet:

Figure 4.8. Inbound Packet Processing 

Outbound ACL Processing

When an outbound ACL is applied to an interface, the router first performs a route lookup for the destination address in the routing table to determine the egress interface via which the packet should be forwarded. If a valid path is found in the routing table and a match is found for the ACL, and the action of the ACL is to permit, then the router continues to process the packet. But if the ACL action is to deny the packet, then the packet is discarded by the router and the router sends an ICMP Destination Unreachable message back to the source host(s).

However, if a match is not found, the implied deny all statement at the end of the ACL is applied and the router discards the packet, sending the source an ICMP Destination Unreachable message. Finally, if a valid path to the intended destination is not found in the routing table, then the router simply discards the packet.

Outbound ACL Packet Flow Processing in Cisco IOS routers

The following diagram illustrates the processing of an outbound packet:

Figure 4.9. Outbound Packet Processing

Implementing ACLs

There are two basic steps required in the implementation of ACLs:

1. Create the ACL
2. Apply the ACL

Create the ACL

To create an ACL in Cisco IOS software, specify the protocol to be filtered by assigning a unique number or name to the ACL and by defining the matching criteria. Each individual rule that is part of an ACL is referred to as an access control entry (ACE). A single ACL can have multiple ACEs, and a group of ACEs forms an ACL.

Each ACL must be uniquely identified by using either a name or a number. Because it is possible to configure multiple ACLs per device, the names or numbers assigned to ACLs allows the device to distinguish one ACL from another. In addition to this, assigning each ACL a unique name or number allows for the ACEs to be bound together. The following table illustrates the ACL numbers that you should be familiar with:

Table 4.4. Access List Ranges

Protocol	ACL Number Range
IP standard	1 – 99 and 1300 – 1999
IP extended	100 – 199 and 200 – 2699
Protocol type-code	200 – 299
MAC ACL	700 – 799
Extended MAC ACL	1100 – 1199

Apply the ACL

While ACLs can be defined without being applied to interfaces or terminal lines, they will have no effect on the router until they are applied to an interface, terminal line, or are used in conjunction with other techniques, such as routing protocol update filtering. Although ACLs can be applied to various interfaces, etc., there are some functional aspects that must be taken into consideration before applying ACLs.

This concept is illustrated using the following diagram:

Figure 4.10. Access List Application

Standard ACLs should always be applied as close to the destination as possible. This is because these ACLs have the capability to filter based only on the source address. Using the diagram illustrated above as a reference, a standard ACL to block traffic from Host 2 destined to Host 4 would be applied on R4, because this is the closest router to the destination. Applying the standard ACL on R1 or R2, for example, would block Host 2 entirely. In other words, Host 2 not only would be unable to communicate with Host 4, but also it would be unable to communicate with Host 1, which is undesirable in this case.

Extended ACLs, on the other hand, should be applied as close to the source (ingress point) as possible. Extended ACLs filter based on source and destination IP address and ports and provide more granular filtering than that provided by standard ACLs. Referencing the diagram illustrated above, to block traffic (in this case, ICMP echo packets) from Host 1 to Host 3, the extended ACL would be applied on R1. Although the extended ACL could be implemented on R3, and still provide the same result, it causes unnecessary resource consumption on other routers in the path (i.e. R4), which would still have to process the packet(s). 

General Guidelines for Implementing ACLs

The following section provides some general guidelines for implementing ACLs in Cisco IOS routers. Keep in mind that these are not standards but, rather, general guidelines that you should be familiar with as a network security administrator. These guidelines are as follows:

• ACLs can be assigned to multiple interfaces on a device. This refers to either different ACLs or even the same ACL.

• Only one ACL is allowed per protocol per interface per direction; you can have one inbound and one outbound ACL applied using this rule.

• ACLs are processed from the top down; therefore, take care when planning ACEs in ACLs. Entries that are more specific should appear first.

• When creating an ACL, the router appends each ACE to the end of the ACL; however, in newer versions of IOS, beginning with 12.2, administrators have the ability to insert ACEs between current entries in the ACL.

• There is an implicit deny for all traffic that is not explicitly permitted. You will never see any matches or log entries against this implicit deny in an ACL. If an ACL does not have at least one permit statement, all traffic will be blocked.

• Always create an ACL before applying it to an interface. Additionally, when editing an ACL, always remove it from the interface, make the desired modifications, and then reapply it to the interface; otherwise, you may block legitimate traffic or even yourself from the router. This is a very important point to remember.

• Outbound ACLs applied to router interfaces only check for traffic traversing the router; they do not and will not filter traffic that is originated by the router itself.

Understanding the concepts described in this section will greatly assist you in understanding the fundamentals of ACL implementation as well as identifying caveats pertaining to ACLs.

 Using ACLs to Mitigate Network Layer Attacks

In this section, we are going to be learning about how to use and apply ACLs to mitigate against Layer 3 (Network Layer) attacks. This section will be broken up into the following sections:

• Established ACLs
• ACLs and Fragmented Packets
• Using ACLs to Characterize Smurf Attacks
• Using ACLs to Characterize SYN Attacks
• Using ACLs to Prevent IP Address Spoofing Attacks
• Unicast Reverse Path Forwarding with ACLs

Established ACLs

The established keyword, used in extended TCP ACLs, is used to validate that a packet belongs to an existing connection from an ongoing TCP session initiated earlier and checks whether the TCP packet has either the ACK or RST bit set. The use of the established keyword in an extended TCP ACL is to allow only internal hosts to initiate a TCP session to an external (outbound) location, while preventing any TCP sessions originated from external networks into the internal network.

In a TCP segment, there are six flag bits, two of which are the ACK (acknowledgement) and the RST (reset). If any one of these two bits is set, a match will be made on an ACL that contains the established keyword. To clarify this concept, the following diagram illustrates the three-way TCP handshake between a client and a server:

Figure 4.11. Three-Way Handshake

As illustrated in the diagram, during the three-way TCP handshake, the client requests a new connection by sending a SYN packet to a server. The server sends a SYN/ACK packet back to the client and places the connection request in a queue. Finally, the client acknowledges the packet received from the server with an ACK packet.

Now let’s look at the same connection being made through a router with an ACL containing the established keyword:

Figure 4.12. Three-Way Handshake Established

In the diagram illustrated above, the client and the server are connected to the FastEthernet0/0 and FastEthernet0/1 interfaces of R1, respectively. The FastEthernet0/1 interface of R1 has been configured with an inbound ACL, which is ACL 101. This ACL has a single statement that reads: access-list 101 permit tcp 20.1.1.0 0.0.0.255 10.1.1.0 0.0.0.255 established.

The client initiates a TCP connection to the server at address 20.1.1.1/24 by sending a SYN packet. The server receives the SYN packet from the client and responds with a SYN/ACK packet. R1 receives this packet from the server on its FastEthernet0/1 interface and looks at the ACL configured and applied on this interface. Because the established keyword is used in the ACL, R1 checks to ensure only packets with either the TCP ACK or RST bit set are allowed.

Given that the packet from the server is a SYN/ACK packet, the condition is satisfied and the packet is permitted. The client then responds to the server’s SYN/ACK packet by sending out its own ACK packet, and the TCP session between the client and the server is established. The following diagram illustrates the same basic condition, except for the fact that this time it is the server initiating the TCP connection to the client:

Figure 4.13. Packet Without ACK or RSK Bit Denied

Referencing the diagram illustrated above, the FastEthernet0/1 interface of R1 is still configured with the ACL statement access-list 101 permit tcp 20.1.1.0 0.0.0.255 10.1.1.0 0.0.0.255 established. Therefore, when the server attempts to establish a connection to the client, it starts off by sending a TCP SYN packet. The router receives this packet and notices that the established keyword is used in the ACL configuration. The router then checks the packet for either the ACK or RST bit and does not see it enabled. The packet is then simply denied.

ACLs and Fragmented Packets

Before we delve into the specifics of how ACLs can be used to filter fragmented packets, it is important to understand what fragmentation means as far as Internet Protocol is concerned. IP implements datagram (packet) fragmentation so that packets may be formed that can pass through a link with a smaller Maximum Transmission Unit (MTU) than the original datagram size. The MTU of a layer of a communications protocol is the size (in bytes) of the largest protocol data unit that it can pass onwards. For example, consider the following scenario:

Figure 4.14. Packet Fragmentation

In the diagram illustrated above, Host 1 is connected to R1, which is connected to the Internet. Host 1 attempts to send a packet to 200.10.1.1 and the packet has a size of 1800 bytes. The MTU configured on the FastEthernet0/0 interface of R1 is 1436 bytes. This means that R1 is only capable of sending and receiving packets with a byte size less than or equal to 1436 bytes.

Because the packet received from Host 1 is 1500 bytes in size, the R1 is unable to accept the entire packet due to an MTU limitation on its FastEthernet0/0 interface. Therefore, when the packet reaches R1, it will discard the packet and send Host 1 an ICMP message stating the packet must be fragmented, i.e. broken up into smaller pieces that will be within the MTU range, in order for R1 to receive and forward the packet to its intended destination. When Host 1 receives this ICMP message from R1, it fragments the packet and sends it again. R1 then accepts the fragmented packets and forwards them to their intended destination, as illustrated in the following diagram:

Figure 4.15. Fragmented Packet Forwarded

Once Host 1 is aware of the MTU restrictions on R1, it will not send packets that exceed the MTU value of 1500 bytes (i.e. further fragments), which are commonly referred to as non-initial fragments. While fragmentation has its advantages, attackers can also take advantage of this feature to breach networks.

RFC 1858 covers security considerations for IP fragment filtering and highlights two attacks on hosts that involve IP fragments of TCP packets. These two attacks are:

• The Tiny Fragment Attack; and
• The Overlapping Fragment Attack.

The Tiny Fragment Attack

A Tiny Fragment Attack is a class of attack that takes advantage of the fact that it is possible to impose an unusually small fragment size on outgoing packets. If the fragment size is made small enough to force some of a TCP packet’s TCP header fields into the second fragment, filter rules that specify patterns for those fields will not match. If the filtering implementation does not enforce a minimum fragment size, a disallowed packet might be passed because it didn’t hit a match in the filter. In essence, every Internet device must be able to forward a datagram of 68 octets without further fragmentation.  This is because an Internet header may be up to 60 octets, and the minimum fragment is 8 octets.

RFC 1858 provides two techniques that can be used to prevent the Tiny Fragment Attack: the direct method and the indirect method. In the direct method, initial fragments that are smaller than a minimum length are discarded. The indirect method involves discarding the second fragment of a fragment set, if it starts 8 bytes into the original IP datagram or packet.

The Overlapping Fragment Attack

An Overlapping Fragment Attack is also called IP Fragmentation Attack. In an Overlapping Fragment Attack, the re-assembled packet starts in the middle of another packet. As the OS receives these invalid packets, it allocates memory to hold them. This eventually uses all the memory resources and causes the machine to reboot or hang.

There is no standard that can be used to prevent these attacks. However, vendors can safeguard against such attacks by updating the router’s filtering capabilities. In Cisco IOS software, the fragments keyword can be used in conjunction with extended ACLs to prevent such attacks.

Non-initial fragments, which are IP packets that have been fragmented after the initial fragments (as explained earlier) that match the Layer 3 statements, irrespective of the Layer 4 information in an ACL, are affected by the permit or deny statement of the matched entry that includes the fragments keyword. In addition to this, the use of the fragments keyword can force ACLs to either deny or permit non-initial fragments with greater flexibility. Filtering fragments adds an additional layer of protection against a DoS attack, such as the Tiny Fragment Attack, which uses only non-initial fragments.

Going into greater detail on ACL processing of fragments is beyond the scope of the IINS course requirements. In fact, this is a topic that you will most likely run into at the Professional level (e.g. CCNP) and most definitely at the Expert level (e.g. CCIE Security) in Cisco certification programs. However, the following example illustrates how the fragments keyword can be used in an IP extended ACL to deny any non-initial fragment access to the network, while non-fragmented packets or initial fragments pass to the next lines of the ACL unaffected by the deny fragment statements used in the ACL:

R1(config)#int s0/0 R1(config-if)#description ‘Connected to ISP' R1(config-if)#ip address 150.1.1.1 255.255.255.252 R1(config-if)#no shutdown R1(config-if)#exit R1(config)#int f0/0 R1(config-if)#description ‘Connected to LAN with Web Server' R1(config-if)#ip address 200.1.1.1 255.255.255.0 R1(config-if)#exit R1(config)#access-list 100 deny ip any host 200.1.1.254 fragments R1(config)#access-list 100 permit tcp any host 200.1.1.254 eq 80 R1(config)#access-list 100 deny ip any 200.1.1.0 0.0.0.255 fragments R1(config)#access-list 100 permit ip any 200.1.1.0 0.0.0.255 R1(config)#int s0/0 R1(config-if)#ip access-group 100 in

In the example above, non-initial fragments to the web server with the IP address 200.1.1.254 are denied; however, HTTP connections to this server are permitted. In addition to this, non-initial fragments to the 200.1.1.0/24 subnet are denied, while all other IP packets are permitted.

It is important to keep in mind that allowing the non-initial fragments of an IP datagram through is acceptable because the host receiving the fragments is not able to reassemble the original IP datagram without the initial fragment.

Using ACLs to Characterize Smurf Attacks

IP extended ACLs can be used to characterize smurf (ICMP flood) attacks. Smurf attacks, which were described in detail in Chapter 1, have two victims: the target and the reflector, or amplifier. Because ICMP echo and echo-reply packets are typically used as a troubleshooting tool, denying them could hinder network troubleshooting efforts. Therefore, network administrators can use classification ACLs to identify the sources of smurf attacks before creating and applying ACLs to restrict these sources. A typical classification ACL used to identify the source of smurf attacks would be configured as follows:

R1(config)#show ip access-list extended CLASSIFY-SMURF R1(config-ext-nacl)#permit icmp any any echo log-input R1(config-ext-nacl)#permit icmp any any echo-reply log-input R1(config-ext-nacl)#permit ip any any

By using the show ip access-lists and the show logging commands, administrators can quickly identify the source IP address, and MAC address if the packets are received from a LAN interface, of large numbers of ICMP echo and echo-reply packets. There are several ways an administrator can differentiate between a simple ping flood and a smurf attack.

First, smurf packets are sent to a directed broadcast address, such as 172.16.1.255 for the 172.16.1.0/24 subnet, rather than to a Unicast address, such as 172.16.1.2 for the 172.16.1.0/24 subnet, whereas ordinary ping floods are always sent to a Unicast address.

When the log-input keyword is used in a classification ACL, an administrator can use the captured log information (show logging) to determine the type of attack, as illustrated in the following output:

R1#show logging Syslog logging: enabled (1 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)   No Active Message Discriminator.       No Inactive Message Discriminator.     Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging:  level informational, 5 messages logged, xml disabled, filtering disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled Trap logging: level informational, 32 message lines logged   Log Buffer (4096 bytes):   *Mar  1 21:10:10.700: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up *Mar  1 21:10:16.702: %SYS-5-CONFIG_I: Configured from console by console *Mar  1 21:10:26.999: %SEC-6-IPACCESSLOGDP: list CLASSIFY-SMURF permitted icmp 172.16.1.254 (FastEthernet0/0 001d.09d4.0238) -> 200.1.1.1 (8/0), 1 packet *Mar  1 21:10:31.827: %SEC-6-IPACCESSLOGDP: list CLASSIFY-SMURF permitted icmp 172.16.1.254 (FastEthernet0/0 001d.09d4.0238) -> 200.1.1.255 (8/0), 1 packet

In the output illustrated above, the router log shows that two ICMP packets matched the CLASSIFY-SMURF ACL. These packets were sourced from a host with the IP address 172.16.1.254, and the MAC address 001d.09d4.0238. Additionally, this packet was received by the router on the FastEthernet0/0 interface.

Secondly, when experiencing a smurf reflector attack, there are typically a larger number of broadcast packets shown in the output of the show interfaces command. Because simple ping floods target Unicast addresses, the counter would not increase, as no broadcast packets would be sent. A sample output of the show interfaces command is illustrated below. The fields you should be concerned with are provided in bold font:

R1#show interfaces fastethernet 0/0 FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is 0013.1986.0a20 (bia 0013.1986.0a20) Description: ‘Connected to LAN' Internet address is 172.16.1.1/24 MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:02:42, output 00:00:00, output hang never Last clearing of “show interface” counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 318 packets input, 46258 bytes Received 185 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog 0 input packets with dribble condition detected 8687 packets output, 879144 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

In addition, the show ip traffic command can also be used to view IP packet statistics. A sample output of the information printed by this command is provided below. The field that you should be looking at to verify whether this is a smurf attack is in bold font:

R1#show ip traffic IP statistics: Rcvd:  316 total, 150 local destination 0 format errors, 0 checksum errors, 0 bad hop count 0 unknown protocol, 12 not a gateway 0 security failures, 0 bad options, 0 with options Opts:  0 end, 0 nop, 0 basic security, 0 loose source route 0 timestamp, 0 extended security, 0 record route 0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump 0 other Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble 0 fragmented, 0 fragments, 0 couldn't fragment Bcast: 151 received, 24 sent Mcast: 0 received, 0 sent Sent:  75 generated, 0 forwarded Drop:  0 encapsulation failed, 0 unresolved, 0 no adjacency 107 no route, 0 unicast RPF, 0 forced drop 0 options denied Drop:  0 packets with source IP address zero Drop:  0 packets with internal loop back IP address 36 physical broadcast —–[Truncated Output]—–

Once administrators have identified the source(s) of smurf attacks, they can configure an ACL to deny ICMP echo packets from the source(s). In addition to this, administrators can also use the no ip directed-broadcast command on Cisco router interfaces to prevent Cisco routers from being reflectors in such attacks.

The following output provides a sample configuration that would be applied on a router to prevent ICMP echo packets from the 200.1.1.0/24 subnet, while allowing all IP packets from any other subnet. In addition, the example illustrates how to prevent the router from being used as a reflector in a smurf attack:

R1(config)#ip access-list extended NO-ICMP-ECHO-FROM-NET-200 R1(config-ext-nacl)#deny icmp 200.1.1.0 0.0.0.255 any echo R1(config-ext-nacl)#permit ip any any R1(config-ext-nacl)#exit R1(config)#int s0/0 R1(config-if)#ip access-group NO-ICMP-ECHO-FROM-NET-200 R1(config-if)#no ip directed-broadcast

Using ACLs to Characterize SYN Attacks

TCP SYN flood attacks occur during the three-way handshake that is used to establish a TCP connection. During a TCP SYN flood, the attacker sends an abundance of TCP SYN packets to the victim, obliging it both to open many TCP connections and to respond to them. However, the attacker does not execute the third step of the three-way handshake that follows, rendering the victim unable to accept any new incoming connections, because its queue is full of half-open TCP connections, as illustrated in the following diagram:

Figure 4.16. TCP SYN Flood

In order for a SYN flood attack to be successful, the attacker must fill and overflow the TCP server’s memory so that the oldest received SYN entries are flushed, as well as fill the TCP queue faster than the typical time it takes to send SYN + ACK packets to and receive the corresponding ACK packet from legitimate hosts. In a manner similar to smurf attacks, classification ACLs can be used to characterize a TCP SYN attack, and the administrator can then use the captured information to create and apply a restrictive ACL for the source(s) of these attacks.

The following example illustrates a classification ACL for TCP SYN floods:

R1(config)#ip access-list extended TCP-CLASSIFY R1(config-ext-nacl)#permit tcp any any syn log-input R1(config-ext-nacl)#permit ip any any

Once the source(s) of high TCP SYN packets has been identified by looking at matches against the ACL (by issuing the show ip access-lists command repeatedly), as well as the output contained in the router log (by issuing the show logging command), administrators can configure a restrictive ACL to filter out TCP packets from the source(s), while allowing all other traffic through. For example, to prevent TCP SYN attacks from the 172.16.1.0/24 subnet, while allowing all other TCP traffic from that subnet, as well as all other IP subnets, the following ACL would be configured:

R1(config)#ip access-list extended NO-SYN-FROM-172-16-1-0-SUBNET R1(config-ext-nacl)#permit tcp 172.16.1.0 0.0.0.255 any established R1(config-ext-nacl)#permit tcp any any R1(config-ext-nacl)#exit R1(config)#int s0/0 R1(config-if)#ip access-group NO-SYN-FROM-172-16-1-0-SUBNET in

NOTE: Remember, the use of the established keyword permits TCP packets only if the ACK or RST bit is set, which effectively means that it allows internal-to-external TCP session initiation but not external-to-internal TCP session initiation.

In addition to using ACLs to classify and then protect against SYN flood attacks, administrators can also use the TCP Intercept feature available in Cisco IOS routers. Although advanced configuration pertaining to the TCP Intercept feature is beyond the scope of the IINS course requirements, you should be aware of how this feature works and should be familiar with the basic commands required to configure TCP Intercept in Cisco IOS routers.

The TCP Intercept feature works by intercepting and validating all incoming TCP connection requests flowing between a TCP client and a server. TCP Intercept operates in two modes, which are watch mode and intercept mode.

In watch mode, the router allows all connection requests to pass through it while passively watching the connection(s) being established. If a connection fails to establish within a configurable threshold, Cisco IOS software intervenes and terminates the connection attempt.

In intercept mode, Cisco IOS software actively intercepts all incoming connection SYN requests and responds on behalf of the server with a SYN/ACK, while waiting for an ACK from the server. When an ACK is received from the server, the original SYN packet is sent to the server and the software performs a three-way handshake with the server. When this is complete, the two half-sessions are joined and the actual client and server have an established TCP session. This concept is illustrated in the following diagram:

Figure 4.17. Intercept Mode

In the diagram illustrated above, the TCP Intercept feature is enabled for intercept mode on the router. In step 1, the TCP client initiates a connection to the TCP server. The TCP Intercept feature intercepts this connection and the router sends a proxy SYN/ACK to the TCP client, as illustrated in step 2.

In the meantime, the router sends a SYN packet to the TCP server, as illustrated in step 3, and the TCP server responds to the router with a SYN/ACK packet, accepting the connection, as illustrated in step 4.

If the client returns a valid ACK to complete the three-way TCP handshake, as illustrated in step 5, the TCP Intercept feature passes this to the TCP server and joins the two half-open connections, effectively allowing the establishment of a session between the client and server.

To enable basic TCP intercept, three simple steps must be taken. The first step is defining an IP extended ACL that matches the TCP traffic you want the Cisco IOS software to intercept. The second step is to configure TCP Intercept to watch the traffic specified in the ACL via the ip tcp intercept list [acl] global configuration command. And, finally, the third step is to specify the mode in which you want TCP Intercept to work. This last step is performed by using the ip tcp intercept mode [intercept|watch] global configuration command.

The following example illustrates how to enable TCP Intercept to intercept all incoming TCP connection requests from any IP subnet to a web server with the IP address 150.1.1.254:

R1(config)#access-list 100 permit tcp any host 150.1.1.254 R1(config)#ip tcp intercept list 100 R1(config)#ip tcp intercept mode intercept

 Using ACLs to Prevent IP Address Spoofing Attacks

IP address spoofing attacks are those where the attacker fakes the source IP address of packets to gain access to a network and access resources in the same manner as legitimate network hosts and users. Anti-spoofing measures should be implemented at every point in the network where practical but are usually easiest to implement at the network edge.

Anti-spoofing techniques are described in detail in RFC 2827 – Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing. This RFC states that no packet should be sent out to the Internet with a source address other than the valid addresses that have been allocated to your network. In summary, anti-spoofing is used to:

1. Deny incoming packets if the source address is allocated to your network; and
2. Deny outgoing packets if the source address is not allocated to your network.

To clarify further this point, we will use the following diagram as an example:

Figure 4.18. Anti-Spoofing

In the diagram illustrated above, Company X owns the 150.1.0.0/16 public IP address space. Company X is also peering to an Internet Service Provider. This peering is via the R1 and R2 routers belonging to Customer X and the ISP-1 and ISP-2 routers belonging to the ISP. The ISP routers are in turn connected to the Internet. Company X and the ISP are using BGP as the protocol of choice to advertise and exchange routing information.

To adhere to the best practices recommended in RFC 2827, Company X must configure two ACLs, one inbound and the other outbound, which will then be applied to the Serial0/0 interfaces of R1 and R2. The inbound ACL will be configured to prevent any and all packets within the 150.1.0.0/16 subnet from coming into the network. This is because this range has been allocated to Company X. Therefore, there is no reason that packets outside of their network should have an IP address within this range. The inbound ACL will then permit other traffic.

The outbound ACL that will be applied to the Serial0/0 interfaces of R1 and R2 will permit only traffic with an IP address in the 150.1.0.0/16 subnet. This is because there is no valid reason a host or device that resides in the Company X network should use an IP address that is not within this range. As an example, the configuration on the edge routers would be as follows:

R1(config)#ip access-list extended ANTI-SPOOF-IN R1(config-ext-nacl)#remark “Deny Our Own Address Space”                 R1(config-ext-nacl)#deny ip any any log-input R1(config-ext-nacl)#exit R1(config)#interface serial0/0 R1(config-if)#ip access-group ANTI-SPOOF-IN in R1(config-if)#ip access-group ANTI-SPOOF-OUT out

While the configuration illustrated above is applied to R1, the same would be applicable to R2. It is important to remember that there is no defined standard for Network Ingress Filtering, in the same way that there are no defined standards for iACLs or transit ACLs. In the real world, it is common practice to include all three techniques within the same ACL, as illustrated in the following example:

R1(config)#ip access-list extended PERIMETER-ACL-IN R1(config-ext-nacl)#remark ‘Deny RFC 1918 Addresses' R1(config-ext-nacl)#deny ip 10.0.0.0 0.255.255.255 any R1(config-ext-nacl)#deny ip 172.16.0.0 0.15.255.255 any R1(config-ext-nacl)#deny ip 192.168.0.0 0.0.255.255 any R1(config-ext-nacl)#remark ‘Deny RFC 3330 Special Use Addresses' R1(config-ext-nacl)#deny ip 127.0.0.0 0.255.255.255 any R1(config-ext-nacl)#deny ip 192.0.2.0 0.0.0.255 any R1(config-ext-nacl)#deny ip 224.0.0.0 31.255.255.255 any R1(config-ext-nacl)#deny ip host 255.255.255.255 any R1(config-ext-nacl)#deny ip host 0.0.0.0 any R1(config-ext-nacl)#remark ‘Allow BGP Peering Session' R1(config-ext-nacl)#permit tcp host 200.1.1.2 host 200.1.1.1 eq bgp R1(config-ext-nacl)#permit tcp host 200.1.1.2 eq bgp host 200.1.1.1 R1(config-ext-nacl)#remark ‘Deny Our Own Address Space' R1(config-ext-nacl)#deny ip 150.1.0.0 0.0.255.255 any R1(config-ext-nacl)#remark ‘Permit Only TCP Sessions Initiated Internally' R1(config-ext-nacl)#permit tcp any any established R1(config-ext-nacl)#remark ‘Prevent Fragment Attacks' R1(config-ext-nacl)#deny ip any any fragments R1(config-ext-nacl)#remark ‘Explicitly Allow Return Traffic' R1(config-ext-nacl)#permit icmp any any echo-reply R1(config-ext-nacl)#permit icmp any any unreachable R1(config-ext-nacl)#permit icmp any any time-exceeded R1(config-ext-nacl)#remark ‘Explicitly Deny All Other Traffic' R1(config-ext-nacl)#deny ip any any log-input

As illustrated, these ACLs can become very long indeed. It is therefore important to consider the capabilities of the router prior to creating such long ACLs. For example, while the ACL illustrated above may have minimal impact on a high-end router, such as a Cisco 7200 series router, it would definitely have an impact on a lower-end router, such as a Cisco 1700 or 1800 series router. Do not be tempted to create hundreds of permit and deny statements because those are the recommendations in RFC 3330, etc. 

Unicast Reverse Path Forwarding with ACLs

Unicast Reverse Path Forwarding (uRPF) is a tool that helps mitigate IP source address spoofing attacks by discarding IP packets that lack a verifiable source address in the routing table. As is the case with Network Ingress Filtering, uRPF should be deployed at the network edge. However, unlike Network Ingress Filtering, it is mandatory that Cisco Express Forwarding (CEF) be enabled in order to implement uRPF.

CEF  is used to increase packet switching speed, reducing the overhead and delays introduced by other routing techniques, and to increase overall router performance. While going into detail on CEF is beyond the scope of the IINS course requirements, it is important to enable CEF for uRPF by issuing the ip cef command.

There are two ways in which uRPF can be implemented:

1. Strict Mode – This mode complies with RFC 2827: Network Ingress Filtering; and
2. Loose Mode – This mode is commonly used by ISPs and is beyond the scope of the IINS course requirements.

The following diagram provides a conceptual view of how the uRPF feature works:

Figure 4.19. uRPF Feature

In the diagram illustrated above, the uRPF feature is enabled on a Cisco IOS router. This router then receives an IP packet from 200.1.1.254 with a destination IP address of 172.1.1.254, as illustrated in step 1.

When the router receives this packet, it first checks to see if the reverse path, i.e. the path back to the source address, matches the input interface that it has in both its IP routing table and its IP CEF table. If the uRPF check fails, meaning that the packet from 200.1.1.254 arrived on an interface other than Serial0/0, the router will discard the packet, as illustrated in step 2.

However, if the RPF check succeeds, meaning that the packet was in fact received on the Serial0/0 interface of the router, the router would forward the packet on to the destination IP address, which is 172.1.1.254 in this example. This is illustrated in step 3.

The uRPF feature is also typically used with ACLs in what is commonly referred to as pass-through mode. In this mode, all uRPF violations are logged using the log-input keyword that is appended to the referenced ACL. If a packet fails a uRPF check, the ACL is checked to determine what should happen to the packet, i.e. if the packet should be permitted or denied. The ACL logging and match counter statistics are then incremented in such an event and can be referenced by administrators to reflect statistics for packets with spoofed IP addresses. This concept is illustrated in the following diagram:

Figure 4.20. uRPF With Access List

Referencing the diagram illustrated above, a router with uRPF enabled on its Serial0/0 interface receives a packet sourced from 192.168.1.1, with a destination IP address of 172.1.1.254, as illustrated in step 1.

When the router receives this packet, it first checks to see if the reverse path, i.e. the path back to the source address, matches the input interface that it has in both its IP routing table and its IP CEF table. As illustrated in step 2, there is no matching entry for this packet. The router then proceeds and references ACL 100, which has been configured in conjunction with uRPF. This ACL, however, has been configured to deny and log all packets from the 192.168.0.0/16 subnet, which includes 192.168.1.1. This is illustrated in step 3.

In step 4, the router drops the packet due to the deny statement in the ACL. In addition to this, the ACL counter is incremented (i.e. the number of matches against the ACL increments) and a log message is generated due to the use of the log-input keyword appended to the ACL. The following configuration example illustrates the use of uRPF in conjunction with ACLs:

R1(config)#ip cef          R1(config)#access-list 150 deny ip 10.0.0.0 0.255.255.255 any log-input R1(config)#access-list 150 permit ip 172.16.0.0 0.15.255.255 any log-input R1(config)#access-list 150 deny ip 192.168.0.0 0.0.255.255 any log-input R1(config)#int se0/0 R1(config-if)#ip verify unicast reverse-path 150

In the configuration above, if the router receives a packet from the 10.0.0.0/8 or 192.168.0.0/16 subnets and the packet fails the uRPF check, the router will deny the packet because of the deny statement in the ACL and increment the ACL counters, plus generate a log message.

However, if the same router receives a packet from the 172.16.0.0/12 subnet, even if that packet fails the uRPF check, the packet will be permitted because of the permit statement in the ACL. In addition to this, the router will increment the ACL counter and generate a log message. 

Using ACLs to Secure Telnet Access

Telnet Basics

Telnet, which stands for teletype network, is one of the most common network management applications used to access network devices. Telnet is a user command and an underlying TCP/IP protocol for accessing remote computers.

Typically, Telnet provides access to a command-line interface on a remote host via a virtual terminal connection, which consists of an 8-bit byte-oriented data connection over the TCP using port 23 as the destination port. When using Telnet, user data is combined and sent in-band with Telnet control information. In-band signaling is simply the process of sending control information in the same channel as used for data.

As popular as Telnet is, it is important to understand that the protocol itself has very little security and Secure Shell (SSH) should be used for remote login and management of devices, from a security perspective. Secure Shell provides greater security than Telnet and will be described in detail later in this guide. The shortcomings of Telnet, from a security point of view, are listed and described in the following section:

• By default, Telnet does not encrypt any data sent over the connection, which includes password information. This makes it very easy for attackers to steal username and password information from Telnet sessions using readily-available tools such as Wireshark and Ethereal sniffers. However, some comfort can be derived from the fact that security protocols (e.g. Kerberos) have the ability to encrypt Telnet sessions.

• Most implementations of Telnet have no authentication that would ensure communication is carried out between the two desired hosts and not intercepted in the middle. To address this issue, SSH should be used instead of Telnet.

• Commonly used Telnet daemons have several vulnerabilities discovered over the years. The vulnerable systems include Sun Solaris, Linux, and FreeBSD, to name a few.

Although extensions to the Telnet protocol provide Transport Layer Security (TLS) security and Simple Authentication and Security Layer (SASL) authentication that address the above issues, most Telnet implementations do not support these extensions, and there has been relatively little interest in implementing these, as SSH is adequate for most purposes. The main advantage of TLS-Telnet would be the ability to use certificate-authority signed server certificates to authenticate a server host to a client that does not yet have the server key stored. TLS is described in detail later in this guide; SASL is beyond the scope of the IINS course requirements. 

Securing Telnet Access to Cisco IOS Routers

By default, Cisco IOS routers will accept incoming Telnet connections without any special configuration. However, even though the routers will accept incoming Telnet connections, if a password is not configured for the Virtual Terminal (VTY) line(s), users will receive the Password required, but none set message before being disconnected by the router.

Prior to implementing ACLs, VTY lines must be configured in order to allow users to log in to the device. This is performed by configuring a password, via the password command, in line configuration mode, and then issuing the login command to allow users to log in to the device. The basic configuration statements to enable Telnet access to Cisco IOS devices are illustrated in the following output:

R1(config)#line vty 0 4 R1(config-line)#password c!sc0 R1(config-line)#login R1(config-line)#exit R1(config)#exit R1#

From a network security standpoint, it is recommended that Telnet access to routers be restricted to authorized hosts, subnets, or both. Telnet access to Cisco IOS devices can be restricted by configuring an IP standard or extended named or numbered ACL, defining which host(s) or subnet(s) will be permitted or denied and then applying it to the router using the access-class line configuration command. For example, to restrict Telnet access to R1 to any host residing on the 172.16.0.0/12 subnet, the following configuration would be applied:

R1(config)#access-list 5 permit 172.16.0.0 0.15.255.255 R1(config)#line vty 0 4 R1(config-line)#access-class 5 in R1(config-line)#exit R1(config)#exit R1#

The following example illustrates how to allow Telnet access to a specific IP address configured on the device from a specific host, as well as an authorized subnet:

R1(config)#interface loopback0 R1(config-if)#description ‘Telnet Management Interface' R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config-if)#exit R1(config)#ip access-list extended TELNET-TO-MANAGEMENT R1(config-ext-nacl)#permit tcp host 192.168.1.254 host 1.1.1.1 eq telnet R1(config-ext-nacl)#permit tcp 10.1.1.0 0.0.0.255 host 1.1.1.1 eq telnet R1(config-ext-nacl)#exit R1(config)#line vty 0 4 R1(config-line)#access-class TELNET-TO-MANAGEMENT in R1(config-line)#exit R1(config)#exit R1#

 Using ACLs to Secure SNMP Access

Although going into detail on SNMP is beyond the scope of the IINS course requirements, it is imperative that you have a solid grasp of the basics pertaining to SNMP. This section provides an overview of SNMP and then concludes with securing SNMP access to Cisco IOS devices via the use of IP Access Control Lists.

SNMP Basics

The Simple Network Management Protocol (SNMP) is a widely used management protocol and defined set of standards for communications with devices connected to an IP network. SNMP provide a means to monitor and control network devices. In addition to this, SNMP is also used to manage device configurations, collect statistics, and monitor device performance such as CPU, memory, and interface utilization, for example.

SNMP is an Application Layer (Layer 7) protocol that facilitates the exchange of management information between network devices using UDP ports 161 and 162. In general terms, an SNMP-managed network consists of a management system, agents, and managed devices.

A management system executes monitoring applications and controls managed devices. The management systems execute most of the management processes and provide the bulk of memory resources used for network management. A network might be managed by one or more management systems. Examples of SNMP management systems include HP OpenView, SolarWinds, and NetCool.

An SNMP agent resides on each managed device and translates local management information data, such as performance information or event and error information caught in software traps, into a readable form for the management system. SNMP agents use get-requests that transport data to the network management software. SNMP agents capture data from Management Information Bases (MIBs), which are device parameter and network data repositories, or from error or change traps.

A managed element, such as a router, computer host, or firewall, is accessed through the SNMP agent. Managed devices collect and store management information, making it available through SNMP to other management systems having the same protocol compatibility. The following diagram illustrates the primary components of an SNMP-managed network:

Figure 4.21. An SNMP Managed Network

In the diagram illustrated above, R1 is the SNMP-managed device. Residing on this device (logically) is the SNMP agent. The SNMP agent translates local management information data, stored in the management database of the managed device, into a readable form for the management system, which is also referred to as the Network Management System (NMS).

The main feature of SNMP is the ability to generate notifications from SNMP agents. SNMP notifications can be generated as traps or inform requests. SNMP traps are simply SNMP messages that alert the SNMP manager of a condition on the network. Examples of SNMP traps could include an interface transitioning from an up state to a down state. SNMP informs are SNMP traps that include a confirmation of receipt from the SNMP manager. These messages can be used to indicate failed authentication attempt, or the loss of a connection to a neighbor router, for example. The following diagram illustrates the communication between the SNMP manager and the SNMP agent:

Figure 4.22. SNMP Manager and Agent

The most significant difference between SNMP traps and SNMP informs is that traps require no acknowledgement. Therefore, the SNMP agent never knows if the trap was received by the NMS. However, all inform requests must be acknowledged. The SNMP agent will not stop sending inform requests until an acknowledgement is received.

Currently, there are three versions of SNMP, which are versions 1, 2, and 3. The following section provides a brief overview of these three versions:

NOTE: You are NOT required to demonstrate advanced knowledge of SNMP as a part of the IINS course requirements. However, you are expected to have a basic understanding of SNMP theory, and, most importantly, knowledge of basic SNMP configuration via the CLI.

SNMPv1 is the initial implementation of the SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), and the OSI Connectionless Network Service (CLNS). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.

SNMPv2 revises SNMPv1 and includes improvements in the areas of performance, security, confidentiality, and manager-to-manager communications. SNMPv2 also defines two new operations: GetBulk and Inform. The GetBulk operation is used to efficiently retrieve large blocks of data. The Inform operation allows one NMS to send trap information to another NMS and then to receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results.

SNMPv3 provides three additional security services that are not available in previous versions of SNMP. The additional security features provided in SNMPv3 are message integrity, authentication, and encryption. SNMPv3 uses message integrity to ensure that a packet has not been tampered with in-transit. SNMPv3 also uses authentication, which is used to determine if the message is from a valid source. And, finally, SNMPv3 provides encryption, which is used to scramble the contents of a packet to prevent it from being seen by unauthorized sources. When using SNMP, managed devices are monitored and controlled using three common SNMP commands. These three commands are the read, write, and trap commands.

The read command is used by an NMS to monitor managed devices. This is performed by the NMS examining different variables that are maintained by managed devices. The write command is used by an NMS to control managed devices. Using this command, the NMS can change the values of variables stored within managed devices. Finally, the trap command is used by managed devices to report events to the NMS. Cisco IOS routers can be configured to send SNMP traps or informs to an NMS. The traps and informs that are sent are dependent on the version of Cisco IOS software running on the device, as well as the platform, e.g. Cisco 2600, Cisco 3800, Cisco 7200, etc.

Securing SNMP Access to Cisco IOS Routers

Both SNMPv1 and SNMPv2 use a community-based form of security. This community string is used to allow access to the SNMP agent and can also be defined by an IP ACL and password. To configure a community string to permit access to SNMP on Cisco IOS routers, the snmp-server community [string] [view [view-name]] [ro|rw] [acl] global configuration command must be used. The keywords that are used in conjunction with this command are listed and described in the following table:

Table 4.5. SNMP Server Keywords

Keyword	Description
[string]	This keyword is used to specify the case-sensitive community string that acts as a password and permits access to the SNMP protocol.
[view [view-name]]	This keyword is used to specify the name of a previously configured view, and is used in SNMPv3 implementations – which are beyond the scope of the IINS course requirements and will not be described in this chapter. The view is used to define the objects available to the community.
ro	This keyword specifies read-only access. Authorized management stations are only able to retrieve MIB objects.
rw	This keyword specifies read-write access. Authorized management stations are able to retrieve and modify MIB objects.
[acl]	This keyword is used to specify an IP standard numbered ACL (i.e. 1- 99) that includes the IP addresses or subnets that are allowed to use the community string to gain access to the SNMP agent.

To reinforce these concepts, we will go over a couple of configuration examples. The first configuration example illustrates how to enable SNMP on a Cisco IOS device, specify an SNMP community string, and authorize read access from an NMS with the IP address 10.1.1.254:

R3(config)#access-list 5 permit host 10.1.1.254 R3(config)#snmp-server community !in5c0urs3 ro 5 R3(config)#exit R3#

In the configuration output above, the access-list 5 permit host 10.1.1.254 command is used to create a standard IP that permits only the IP address of the NMS (10.1.1.254). The snmp-server community !in5c0urs3 ro command enables SNMP on a Cisco IOS router. The SNMP community string, which is in5c0urs3, serves as a password protection mechanism for SNMP. This community string will be sent in every SNMP packet, so an incorrect community string results in no access to the SNMP agent running on the router. The ro keyword means that only read access will be permitted via SNMP, for the host specified by ACL 5.

The second configuration example illustrates how to enable SNMP on a Cisco IOS device, specify a community string that will be used for read/write access, and allow read/write access to any host residing on the 192.168.1.0/24 subnet:

R3(config)#snmp-server community !in5wr!t3 rw 10 R3(config)#access-list 10 permit 192.168.1.0 0.0.0.255 R3(config)#exit R3#

 

Breaking down the configuration commands used in the output above, the snmp-server community !in5wr!t3 rw command enables SNMP on a Cisco IOS router, using the SNMP community string in5c0urs3, which provides read/write access to the SNMP agent, as indicated by the rw keyword. In addition to this, ACL 10 is used to restrict read/write access to the 192.168.1.0/24. No other SNMP managers have access to any objects.

Now that we have an understanding of the configuration commands required to enable SNMP on a Cisco IOS device, to specify community strings, and to restrict SNMP access via ACLs, it is important to also understand how to configure SNMP to send notifications to an NMS. The snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]} [community-string [udp-port port] [notification-type]] command is used in Cisco IOS software to configure a router to send SNMP traps and informs to an NMS.

While most of the options provided by this command are beyond the scope of the IINS course requirements, the following table lists and describes the options you should be familiar with:

Table 4.6. SNMP Server Host Keywords

Keyword	Description
hostname | ip-address	This keyword is used to specify the hostname (e.g. snmp1.howtonetwork.net) or the IP address of the target NMS.
traps	This keyword is used to send traps to the NMS, which is the default.
informs	This keyword is used to send Inform messages to the NMS.
version	This keyword is used to specify the SNMP version to use. In order to send Inform messages, you must use SNMPv2 or SNMPv3.
community-string	This keyword is used to specify the SNMP community string. It is recommended that this string be configured using the snmp-server community command before it is used with this command.
notification-type	This keyword is used to specify the type of notification to send to the NMS. The options available will vary based on router IOS image, as well as platform. For example, the options for Cisco 7200 series routers will vary from those available for Cisco 2600 series routers.

In addition to the snmp-server host… global configuration command, administrators can also use the snmp-server enable traps [notification-type] global configuration command to enable all traps (default) or specific traps. These are then sent to the NMS specified in the snmp-server host global configuration command.

As was done with community strings, we will go through a few examples demonstrating basic SNMP configuration. Please note that these examples will be based only on SNMPv1 or SNMPv2. SNMPv3 configuration is beyond the scope of the IINS course requirements.

The first configuration example illustrates how to configure a router to send OSPF traps to an NMS with the IP address 10.1.1.254 using the community string !in5s3cur!ty:

R3(config)#snmp-server enable traps ospf R3(config)#snmp-server host 10.1.1.254 !in5s3cur!ty

The second configuration example illustrates how to send all configuration informs to an NMS with an IP address of 192.168.1.254 using the community string !in5s3cur!ty:

R3(config)#snmp-server enable traps config R3(config)#snmp-server host 192.168.1.254 informs version 2c !in5s3cur!ty config

Chapter Summary 

The following section is a summary of the major points you should be aware of in this chapter:

Access Control List Overview

• An ACL is a list of permit and deny statements that controls network access
• There are two broad categories for data received by a router:

1. It is traffic that passes through the router via the forwarding path; or
2. It is traffic destined for the router for route processor handling

ACLs provide administrators great flexibility and they can be used for:

1. Filter routing information received from or sent to adjacent neighbors
2. Control access to networks by permitting or denying particular types of traffic
3. Control interactive access to the router itself, e.g. Telnet, HTTPS and SSH
4. Define interesting traffic that can be used to initiate ISDN connections
5. Define interesting traffic for IPSec Virtual Private Network (VPN) encryption
6. Define queuing and Quality of Service (QoS) features, allowing traffic to be prioritized
7. Use in security techniques such as TCP Intercept and the Cisco IOS Firewall
8. Define traffic for Network Address Translation (NAT)
9. Mitigate IP spoofing, SMURF and other similar network attacks

Access Control List Types

• The different types of IP ACLs that are available in Cisco IOS software are:

1. IP Standard ACLs – Filter based on source IP address or subnet
2. IP Extended ACLs – Filter based on source and destination IP address, port(s), flag(s)
3. IP Named ACLs – Can be standard or extended and do the same as numbered ACLs
4. Dynamic ACLs – Lock-and-Key ACLs; they allow dynamic, per-used access control
5. Reflexive ACLs – Allow IP packets to be filtered based on upper-layer session information
6. Time-based ACLs – They are used to control network access based on the time
7. Turbo ACLs – Designed to process ACLs more efficiently and improve router performance
8. Receive ACLs – used to increase security on Cisco 12000 routers by protecting the GRP
9. Infrastructure Protection ACLs – Used to reduce the risk of network infrastructure attacks
10. Transit ACLs – Used to permit only legitimate traffic into the network
11. Classification ACLs – Used to classify and categorize Denial of Service (DoS) attacks

ACL Processing and Packet Flow Rules

• When an inbound ACL is applied to an interface, the router checks the received packets against the statements in the ACL looking for a match

• When an outbound ACL is applied on an interface, the router first performs a route lookup for the destination address in the routing table to determine the egress interface via which the packet should be forwarded 

Implementing ACLs

There are two basic steps required in the implementation of ACLs:

1. Create the ACL
2. Apply the ACL

The following table illustrates the most common ACL numbers in Cisco IOS software:

Protocol	ACL Number Range
IP standard	1 – 99 and 1300 – 1999
IP extended	100 – 199 and 200 – 2699
Protocol type-code	200 – 299
MAC ACL	700 – 799
Extended MAC ACL	1100 – 1199

• Standard ACLs should always be applied as close to the destination as possible
• Extended ACLs should be applied as close to the source as possible
• The general guidelines that should be used when implementing ACLs are:

1. ACLs can be assigned to multiple interfaces on a device. This refers to either different ACLs or even the same ACL.

2. Only one ACL is allowed per protocol per interface per direction; you can have one inbound and one outbound ACL applied using this rule.

3. ACLs are processed from the top down; therefore, take care when planning ACEs in ACLs. More specific entries should appear first.

4. When creating an ACL, the router appends each ACE to the end of the ACL; however, in newer versions of IOS, beginning with 12.2, administrators have the ability to insert ACEs between current entries in the ACL.

5. There is an implicit deny for all traffic that is not explicitly permitted. You will never see any matches or log entries against this implicit deny in an ACL. If an ACL does not have at least one permit statement, all traffic will be blocked.

6. Always create an ACL before applying it to an interface. Additionally, when editing an ACL, always remove it from the interface, make the desired modifications, and then reapply it to the interface, otherwise you may block legitimate traffic or even yourself from the router. This is a very important point to remember.

7. Outbound ACLs applied to router interfaces only check for traffic traversing the router; they do not and will not filter traffic that is originated by the router itself.

Using ACLs to Mitigate Network Layer Attacks

• The following ACLs can be used to mitigate against and identify potential Layer 3 attacks:

1. Established ACLs – Permit external TCP traffic only if it was originated internally
2. ACLs and Fragmented Packets – Prevent the Tiny and Overlapping fragment attacks
3. Using ACLs to characterize SMURF attacks – Match on ICMP echo and echo-reply packets
4. Using ACLs to characterize SYN attacks – Match on TCP SYN packets
5. Using ACLs to prevent IP address spoofing attacks – use recommendations in RFC 2827
6. Unicast Reverse Path Forwarding with ACLs – ACL permit or deny packets that fail RPF

 Using ACLs to secure Telnet Access

• Telnet is one of the most common network management applications
• The shortcomings of Telnet, from a security point of view are:

1. By default, Telnet does not encrypt any data sent over the connection
2. Most implementations of Telnet have no authentication
3. Commonly used Telnet daemons have several vulnerabilities

• The access-class line configuration command is used to secure Telnet in Cisco IOS routers

Using ACLs to secure SNMP Access

• SNMP provide a means to monitor and control network devices
• SNMP is an Application Layer (Layer 7) protocol uses UDP ports 161 and 162
• An SNMP-managed network consists of:

1. A management system (NMS)
2. Agents
3. Managed devices

• Currently, the IETF has defined three versions of SNMP, which are versions 1, 2, and 3
• SNMPv1 is the initial implementation of the SNMP protocol
• SNMPv2 includes improvements in the areas of performance, security, confidentiality
• SNMPv3 message integrity, authentication, and encryption
• The snmp-server community command is used to enable and secure SNMP access
• The snmp-server host command is used to specify a trap or inform destination
• The snmp-server enable traps command is used to generate and send SNMP traps

Read the Cisco ACL command guide.

Commands Used in this Chapter

The following section is a summary of the commands used in this chapter: 

Command	Description
access-list [1-99| 1300-1999]	Used to configure IP standard ACLs
access-list [100-199| 2000-2699]	Used to configure IP extended ACLs
log-input	Used to provide detailed logging in extended ACLs
show ip access-lists [name]	Used to view configured ACLs
show logging	Used to view the local router log messages
ip access-list	Used to configure named standard or extended ACLs
access-list compiled	Used to configure turbo ACLs
show access-list compiled	Used to view configured turbo ACLs
ip receive-access-list	Used to configure receive ACLs (rACLs)
ip access-group	Used to apply an ACL to an interface
show interfaces	Used to view interface statistics
show ip traffic	Used to view IP traffic statistics
no ip directed-broadcast	Used to disable directed Broadcast forwarding
ip tcp intercept list	Used to specify the ACL to be used for TCP Intercept
ip tcp intercept mode	Used to specify the mode TCP Intercept operates in
ip verify unicast reverse-path	Used to enable uRPF; can also be used with an ACL
access-class	Used to apply an ACL to VTY lines
snmp-server community	Used to configure the SNMP community string
snmp-server host	Used to configure an NMS to send traps or informs
snmp-server enable traps	Used to enable SNMP traps