Deny any packet from the "outside" with a source that matches our "inside" network.

Deny any packet from the "outside" with a source IP address in the private range of
10.0.0.0/8.
Deny any packet from the "outside" with a source IP address in the private range of
172.16.0.0/12.
Deny any packet from the "outside" with a source IP address in the private range of
192.168.0.0/16.
Deny any packet from the "outside" with a source IP address of 0.0.0.0/32 (an all 0s
source address).
Deny any packet from the "outside" with a source IP address of 255.255.255.255 (an all
1s broadcast address).

Cisco Discovery Protocol (CDP)
Cisco Discovery Protocol (CDP) uses Layer 2 inquiries to find information about neighboring
devices. CDP, enabled by default on IOS versions 11 and later, is extremely useful for both
managing and troubleshooting devices. However, CDP has an inherent flaw: it will answer any
device that sends the proper request. Because CDP information contains such items as the IOS
version number, the name of the device, the network address of the device, and how that
device is connected, the administrator should limit on which interfaces CDP packets are
answered and sent.
If CDP is not being used internally on the network, it can be disabled with the following global
command:
no cdp run
If CDP is required on the interior of the network, the administrator should still disable CDP on
all external interfaces. To disable CDP on any given interface, enter the following interface
command:
no cdp enable

Hypertext Transfer Protocol (HTTP) Configuration Services
Many Cisco devices allow the use of a Web browser for configuration and monitoring. Although
this method of configuration might be convenient, especially for the new administrator, special
considerations are required to ensure security. HTTP services are also used on the Cisco 1003,
1004, and 1005 routers for use with the Cisco IOS ClickStart software.
Access lists must be used on perimeter routers to limit who can access a router from outside
of the local network. If HTTP services are used, you need to adjust access lists to allow only
specific IP addresses access to routers through WWW services.
HTTP services are turned on with the ip http server command. Use the no form of the
command to disable this service. HTTP services run by default on TCP port 80; this can be
changed to virtually any port required. It is recommended that you change the default port.
Changing from the default port of 80 requires a hacker to know which port is in use before
being able to exploit any possible security holes.
Control over who accesses the HTTP services is managed by a standard access list, as well as
by the ip http access-class command. Note that unlike other access-class commands, the
ip http access-class command is entered in the global configuration mode. Additional
security can be achieved through AAA authentication, which is covered in Chapter 10. If AAA
authentication is not used, the enable password is used for logging onto the router.
The following is an example of setting HTTP services on a router, creating and applying an
access list, and adding AAA authentication. Note that all commands are entered in the global
configuration mode. Also note that the use o f an exclamation mark (!) at the beginning of a
line indicates that the line is a comment.
ip http server
!Starts HTTP services on the router.
!Services can be stopped with the no ip http services command.
ip http port 10120
!This changes the port used for management from port 80 to port 10120.
!Port 10120 was an arbitrary number chosen because it is not commonly used.
!To change the port back to 80, use the no ip http port command.
access-list 91 permit host 10.1.1.50
!Allow host 10.1.1.50 access.
access-list 91 permit host 10.1.1.52
!Allow host 10.1.1.52 access.
access-list 91 deny any any
!Deny all others. This line is included for clarity.
!All access lists have an implied deny all at the end.
ip http access-class 91
!Apply access list 91 to HTTP services.
ip http authentication aaa tacacs
!Use TACACS for authentication.
Simple Network Management Protocol (SNMP)
Simple Network Management Protocol (SNMP) is used by a variety of programs involved with
network management. The beauty of SNMP is intertwined with its dangers. Because SNMP is
designed to allow an administrator to monitor and configure devices remotely, SNMP can also
be used in attempts to penetrate the corporate network. This section explores how to
minimize vulnerability while using SNMP.
A few simple configuration changes, as well as a few logical choices that should be made by
the administrator, can greatly reduce the risks involved with SNMP. Both logical choices and
configuration considerations are covered in this section.
The first consideration an administrator should make regarding SNMP is to turn it off. If SNMP
is not being used, running it only takes away from available bandwidth, needlessly burns CPU
cycles, and exposes the network to unnecessary vulnerabilities.
Before using SNMP in read/write mode, rethink the requirement to do so. Running SNMP in
read/write mode with just a few minor configuration errors can leave the whole of your
network susceptible to attacks. A great number of tools can scan any network over SNMP.
These can map out your entire network if SNMP has a hole left open.
In late February of 2001, Cisco released information that there are also security issues with
SNMP even when using only the read mode. Due to a defect within the Cisco IOS versions
11.0 and 12.0, SNMP is vulnerable to certain denial of service attacks designed to confuse
products such as CiscoWorks. In order to fix these potential security problems, an IOS
upgrade must be accomplished. If you have not upgraded your IOS since this time, it is
strongly recommended that you read the information at the following two URLs to see if your
specific equipment is affected:
www.cisco.com/warp/public/707/ios-snmp-ilmi-vuln-pub.shtml
www.cisco.com/warp/public/707/ios-snmp-community-vulns-pub.shtml
SNMP is available in versions 1, 2, and 3. There are some major differences between versions.
First, version 1 sends passwords in clear-text format, and version 2 allows password
encryption using the MD5 encryption algorithms. Second, although virtually all management
programs can use SNMP version 1, the choice is limited when using SNMP version 2. One of
the original goals of version 2 was to provide commercial-grade security through
authentication, privacy, and authorization. Version 2 failed to accomplish these goals because
version 2c, while having the endorsement of the Internet Engineering Task Force (IETF), failed
to implement these security measures. Versions 2u and 2* implemented security but failed to
gain acceptance from the IETF.
Version 3, available on the standard Cisco IOS since release 12.0(3)T, uses MD5, Secure Hash
Algorithm (SHA), and keyed algorithms to protect against data modification and masquerade
attacks. Version 3 can optionally use Data Encryption Standard (DES) in the cipher block
chaining mode when security is required.
From a security viewpoint, the passing of clear-text passwords should become a primary
concern, especially because most SNMP applications send passwords repeatedly during normal
operations. If your management software and equipme nt is compatible with version 2, there is
no reason to run version 1. Assuming that the network in question is using only SNMP version
2, the administrator can ensure encryption by using the following command:
snmp-server enable traps snmp authentication md5
This command replaces the older and no longer valid command:
snmp-server trap-authentication
Unless you are purposely using SNMP version 1, the following command must be avoided at all
costs:
snmp-server communityname
This command not only sets the community name, but also enables SNMP version 1 instead of
version 2.
If version 1 is running, pay close attention to the name of the community. Because the
community name is passed in clear text, this name should give no indication of either the
company name or the type of company associated with the name. For example, assume that
the company in question is Cisco Systems. Using the word " cisco" in any part of the
community name might alert hackers that they have gained access to Cisco Systems. Using a
community name "routers" might also give hackers unnecessary information. When using SNMP
version 1, Cisco suggests that all equipment use differing community names. Although this
might seem like an unreasonable restriction in a large network, using multiple community
names will reduce the number of routers that are vulnerable because of the revealing of a
single community name. If it is not possible to assign a different community name for all
devices, find a balance between using a single community name and using a differing name on
each piece of equipment. Finally, avoid using the names "public" or "private," because they
are so commonly used.
Most networks have a few select management stations from which SNMP messages can
legitimately originate. When using version 1 and the community name command, it is
recommended that the optional access list number be included. This allows the administrator
to control which stations have access, through a standard access list (numbered 199) applied
to the SNMP services as if SNMP were an inbound router port.
Access control lists (ACLs) should be placed close to the edge of your network, preventing
outside parties from probing your network over SNMP. Additionally, if the CPU cycles are
available on interior routers, it might be worth the effort to add ACLs on certain routers in the
interior of the network. This allows for the limitation of breaches, if they do occur.
If you are using SNMP in read-only mode, you need to ensure that it is set up with appropriate
access controls . An example of proper protection follows:
access-list 7 permit 172.30.1.45
access-list 7 permit 10.1.1.53
snmp-server community 85tres76n RO 7
snmp-server trap-source Loopback0
snmp-server trap-authentication
snmp-server enable traps config
snmp-server enable traps envmon
snmp-server contact Joe Admin [jadmin@hotmail.com]
snmp-server location main server room router 8
snmp-server enable traps bgp
snmp-server enable traps frame-relay
snmp-server host 172.30.1.45 85tres76n
snmp-server host 10.1.1.53 85tres76n
snmp-server tftp-server-list 7
The preceding example uses ACL 7 and allows SNMP messages from only two IP addresses to
be accepted. Because there are only two possible SNMP servers (172.30.1.45 and 10.1.1.53),
these are the only IP addresses where SNMP is allowed to respond. SNMP messages from all
other IP addresses would be implicitly denied.
Because the community string is not encrypted, care is taken to use "85tres76n," which has
no known relation to the company or the services that the company offe rs. Once a community
string is known outside of the organization, a point of possible attack is created. Unless SNMP
is set up to pass community-name authentication failure traps, and the SNMP management
device is configured to react to the authentication failure trap, the community name is easily
discovered.
Keep in mind that accepting SNMP from only known good IP addresses does not necessarily
guarantee security because of IP address spoofing. Unless serious antispoofing measures are
in place, you cannot rely on IP addresses as the primary means of security on any system.
With all security configurations, the objective of the administrator should be to build many
obstacles to unauthorized personnel while providing seamless operation to authorized users.
Notice that even the e -mail address of the administrator is not a company e-mail address. This
is done in case the SNMP does become violated. If the SNMP system is violated, this
information could give clues about the company name to the violator.
The snmp-server host configuration shown in the preceding example lists the hosts to which
SNMP information can be sent. If a means of collecting SNMP traps is not available, don't
configure snmp-server hosts. When using an SNMP server host, make sure that this host is
configured to receive and respond to SNMP traps. Read/write community strings should not be
used on networks in order to limit the risk of SNMP sets being used by unauthorized parties.
Denying RFC 1918 Routes
All border routers within a company that is conce rned with security should have some specific
routes denied. RFC 1918 defines the ranges of IP addresses available for use on the Internet,
as well as those considered private. A private IP address should not be used on the Internet.
The source or destination addresses of all packets on the Internet should not be within these
private ranges. Common attack methods rely on private addresses to hide the true source of
the attack. This section shows a typical method of blocking access from these forms of attack.
With the exception of Network Address Translation (NAT), no one from the Internet or from
within your own network should be sending packets from any of the addresses in the following
list. The following is a sample ACL that will be applied to routing updates to prohibit the
private address spaces as defined by RFC 1918:
access-list 191 deny ip host 0.0.0.0 any
!This prevents packets with a source address of 0.0.0.0
!from traversing the network
access-list 191 deny ip any host 0.0.0.0
access-list 191 deny ip 10.0.0.0 0.255.255.255 any
!10.0.0.0 through 10.255.255.255 is a non-routable address range
!and should not traverse the network from the Internet.
access-list 191 deny ip 127.0.0.0 0.255.255.255 any
!127.0.0.0 through 127.255.255.255 addresses are used for loopback testing
!and should never traverse the Internet.
access-list 191 deny ip 169.254.0.0 0.0.255.255 any
!169.254.0.0 is reserved by Microsoft as the address given to a host
!unsuccessfully attempting to use DHCP services.
access-list 191 deny ip 172.16.0.0 0.15.255.255 any
!172.16.0.0 through 172.31.255.255 are non-routable addresses.
access-list 191 deny ip 192.168.0.0 0.0.255.255 any
!192.168.0.0 through 192.168.255.255 are non-routable addresses
!and should never be traveling over the Internet.
access-list 191 deny ip 224.0.0.0 31.255.255.255 224.0.0.0 31.255.255.255
!224.0.0.0 through 255.255.255.255 as a source address is invalid
!because these are reserved for multicast broadcasts.
!Here, you are stopping these packets from traversing the network if the
!destination is a multicast and the source is a multicast.
!A correctly formed multicast packet will have a valid source address
!with a multicast destination address between 224.0.0.0 and
255.255.255.255.
access-list 191 deny ip any 255.255.255.0 0.0.0.255
!Packets should not be sent to the 255.255.255.0 network,
!because this is a reserved network.
access-list 191 permit ip any any
!You need to allow traffic that is not specifically blocked
!through the router.
deny any any
!The deny any any line is shown for clarity.
!This line is implied by all access lists.
!Any packets that are not specifically allowed are denied.
This access list should be applied to both the inbound and outbound interfaces of border
routers. If you are running NAT services, some of these interfaces will not necessarily apply.
For example, if you are using the 10.0.0.0 network inside your organization, you will need to
allow this network to travel to the device providing NAT services. Additionally, on the inbound
interface of all border routers, the internal network addresses should be specifically denied.
The preceding list is a minimum list that is designed to prevent commonly spoofed IP
addresses from being allowed to traverse your network. If other routes are known to be
invalid, they should also be prohibited. Besides specifically preventing packets with a source
address matching your internal network from entering through the Internet, administrators
should consider ways in which they can prohibit unauthorized external network addresses from
traversing to the outside of the network. This will help prevent someone from using the
network to launch an attack on a third party.
As with all access lists, these might cause excessive CPU usage on routers. However, the
additional CPU usage is usually justified by the added security provided by the access lists. If
your router is unable to effectively function with the preceding access lists, chances are that
the router is already overworked and should be upgraded.
User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) Servers
The User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) servers are
generally those with port numbers below 10. These typically include echo ports and discard
ports. Echo ports replay the packet (echo) out of the port received. Discard throws away the
packet. Because either throwing away or echoing packets consumes CPU cycles, they are
commonly used in denial of service (DoS) attacks. When too many packets requesting echoes
overload a router, for example, the router must delay other processes. This delay can cause
problems, such as an inability to process routing updates. Therefore, both of these should be
disabled unless there is a specific reason to run them. This is especially important on the
router directly connected to the Internet. These can be disabled as follows:
no service-udp-small-servers
no service-tcp-small-servers
Finger Service
The finger service can be used to resolve usernames on remote systems. Specifically, finger
was designed to show active users on a system. Although the prevalence of finger has been
reduced in the last few years, several administrators still allow finger requests to traverse
their networks. Because of the many known ways that finger can be abused, no router should
ever run finger unless there is a very specific reason to do so. An administrator can (and
should) stop finger services with the following command:
no service finger
IP Unreachables
By default, when a router receives a nonbroadcast packet with an unrecognized protocol
whose destination address belongs to that router, it will send an Internet Control Message
Protocol (ICMP) Protocol Unreachable message back toward the source. A router will also send
back an ICMP Host Unreachable message if it receives a packet whose destination address is
not known.
Although this behavior might seem reasonable, it also opens the router to vulnerability from
ICMP DoS attacks. If a router spends all of its time responding to ICMP messages, something
else is not being processed. Additionally, disabling ICMP unreachables might help out the
innocent victim of a DoS attack.
A DoS attack can occur in many ways. Here is just one scenario: When sending an ICMP echo
request, the perpetrator changes the originating IP address on the packet to a legitimate IP
address of the victim. The perpetrator sends numerous ICMP requests to the network
broadcast address of the bystander. The bystander, who is unaware of what is occurring,
responds to these ICMP requests. The response is sent to the IP address within the original
request. If the source address is valid, some router will start receiving these responses. Take
a moment to look at
In this case, the ICMP requests were sent to the broadcast network address on the
bystander's network. Each host on the network received the request and responded. This
means that the bystander amplified the power of the effectiveness of the requests by the
number of hosts responding. Very quickly, the bystander's available bandwidth will be used by
ICMP messages. The victim's bandwidth will also be used by these ICMP messages. In effect,
both the victim and the bystander lose all effective co mmunication capabilities. It becomes
very hard to tell exactly who the intended victim is in this case. If the perpetrator sends out
requests to more than one bystander at a time, the effect can be devastating to the victim.
It is recommended that all exte rnal interfaces be configured not to respond in this manner.
Preventing a router from sending out ICMP Host and Protocol Unreachable messages is easily
accomplished with the following interface command:
no ip unreachable
ICMP Redirect Messages
Under certa in circumstances, routes might not be optimal. Although most of these cases can
be prevented by proper configuration, it is usually prudent for the administrator to ensure that
routers do not send packets out the same interface over which they have been re ceived. When
a packet is sent back out the interface on which it was received, an ICMP Redirect message is
also sent.
The ICMP Redirect message tells the sender of the original packet to remove the route and
substitute a specified device that has a more direct route. This feature is enabled by default,
but it becomes disabled when the Hot Standby Router Protocol (HSRP) is in use on the
particular interface.
Because you should be concerned about any ICMP messages leaving your network, you should
manually disable this feature. Instead of using your bandwidth to inform other, usually
unknown routers where a network exists, you should reserve your bandwidth for your own
purposes. This is especially important on external interfaces where large amounts of these
ICMP messages might be a form of DoS attack. Figure 2-10 gives an example of how ICMP
Redirect works. To manually disable this behavior, use the following interface command:
no ip redirects
Directed Broadcasts
It is possible within the IP protocols to send a directed broadcast, which is when a packet that
is received contains a request to translate the broadcast packet to another interface on the
device, usually the LAN interface. If this is left enabled, the LAN might experience excessive
broadcasts from a DoS attack. The default on IOS 12.0 and later is to have directed
broadcasts disabled. However, the administrator should still specifically disable it with the
following command:
no ip directed-broadcast
TCP Intercept
TCP Intercept tracks, intercepts, and validates TCP connection requests. This shields the local
host from being contacted directly by a nontrusted network or host. Therefore, any DoS
attacks attempted on the host are actually carried out against the router, which will be
prepared to survive such attacks. TCP Intercept uses fast switching, except on the RS/RP/SSPbased
Cisco 7000 series, which only uses process switching.
TCP Intercept operates in one of two modes, monitor mode and intercept mode. Monitor mode
allows connections directly to the local host while monitoring the status of these connections.
The router, because of the number of open connections or timeout limitations, drops existing
and partially opened connections as needed to protect the local host. Intercept mode is used
to protect the local host from all direct contact with the remote host. The router, acting in a
manner similar to that of a proxy server, responds to requests from the remote host. The
router then establishes its own connection with the local host and merges the connections
between the two hosts. Figure 2-13 shows a router acting in intercept mode.
Exceeding preset thresholds in either mode causes aggressive behavior mode to start.
Dropping back below another set of thresholds causes the router to move back to normal.
During aggressive behavior mode, new connection attempts force a drop of an existing partial
connection. Additionally, the retransmission and watch timeouts are cut in half.
TCP Intercept is relatively easy to configure by a five-step process:
Step 1. Create an intercept access list.
Step 2. Enable TCP Intercept.
Step 3. Set interce pt mode.
Step 4. Set thresholds.
Step 5. Set drop mode.
The following example configuration shows how to accomplish all of these tasks and gives
comments on parameters available:
!Create an extended access list.
!TCP Intercept access lists must be extended access lists (101199).
access-list 101 permit 172.30.1.15 255.255.255.255 host 10.1.1.1
!Allow access from the single host at 172.30.1.15 to the single host at
10.1.1.1.
access-list 101 permit 172.30.2.0 255.255.255.0 host 10.1.1.2
!Allow any host on the 172.30.2.0 network to get to host 10.1.1.2.
!
!Enable TCP Intercept.
ip tcp intercept list 101
!Starts IP Intercept for the hosts listed as permitted in access list 101.
!
!Set the intercept mode.
ip tcp intercept mode intercept
!Sets the mode to intercept. The other possible mode is watch.
!
!Set the thresholds.
ip intercept connection-timeout 3600
!Connections will be reset after 3600 seconds (1 hour) of no activity.
!The default is 86400 seconds (24 hours).
!
ip tcp intercept finrst-timeout 3
!Sets the time in seconds (3) after receiving a reset or FIN that the
connection
!remains managed. The minimum is 1 second. The default is 5 seconds.
!
ip tcp intercept max-incomplete high 900
!Sets the maximum number of half-open connections (900) before the router
goes
!into aggressive behavior mode. The default is 1100. The maximum is
2147483647.
!The minimum is 1.
!
ip tcp intercept max-incomplete low 700
!Sets the number of half-open connections (700) below which the router
leaves
!aggressive behavior mode. The default is 900. The maximum is 2147483647.
!The minimum is 1.
!
ip tcp intercept one-minute high 800
!Sets the maximum number of connection requests (800) that may be received
in a
!one-minute period before the router goes into aggressive behavior mode.
!The default is 1100. The maximum is 2147483647. The minimum is 1.
!
ip tcp intercept one-minute low 600
!Sets the number of connection requests (600) that may be received in a
!one-minute period below which the router leaves aggressive behavior mode.
!The default is 900. The maximum is 2147483647. The minimum is 1.
!
ip tcp intercept watch-timeout 20
!Sets the time in seconds (20) for a partially opened connection to
complete
!the connection sequence before sending a reset command to the local host.
!
!Set the drop mode.
ip tcp intercept drop-mode random
!Sets the drop mode (random) to randomly choose which half-open connection
!while in aggressive behavior mode. The default (oldest) will drop the
oldest
!partial connection first.