For Cisco IOS devices, basic access mode is denoted by the > prompt after the host name; privileged access is denoted by the # prompt after the host name. Table 9-1 shows the commands accessible for basic access; Table 9-2 shows the commands for privileged access (that is, enable mode). The basic access commands are just a subset of the privileged access commands.

How to get initial basic level access is discussed in the section, “Line Access Controls.” Here, take a closer look at how to allow privileged level (that is, enable mode) access. The authentication of enable mode in Cisco IOS devices can take one of these forms:

Example 9-1 is taken from a router in configuration mode to see the options for configuring authentication for enable mode.

Router(config)#enable ?
last-resort           Define enable action if no TACACS servers respond
password              Assign the privileged level password
secret                Assign the privileged level secret
use-tacacs            Use TACACS to check enable passwords

Router(config)#enable password ?
0        Specifies that an unencrypted password will follow
7        Specifies that a hidden password will follow
LINE     The unencrypted (cleartext) enable password
level    Set exec level password
Router(config)#enable secret ?
0        Specifies that an unencrypted password will follow
5        Specifies that an encrypted secret will follow
LINE     The unencrypted (cleartext) enable secret
level    Set exec level password

Router(config)#enable secret 0 thisisasecret

enable secret 5 $1$dLOD$QR.onv68q3326pzM.Zexj1

Router(config)#enable secret 5 $1$dLOD$QR.onv68q3326pzM.Zexj1

Router# show configuration
hostname Tallinn
!
enable secret 5 $1$dLOD$QR.onv68q3326pzM.Zexj1
enable password 7 047E050200335C465817

Router(config)#aaa authentication enable default ?
enable     Use enable password for authentication
group      Use server-group
line       Use line password for authentication
none       NO authentication

Router(config)#aaa authentication enable default group?
WORD       Server-group name
radius     Use list of all radius hosts
tacacs+    Use list of all tacacs+ hosts

Router(config)#enable password level 10 ?
0           Specifies that an unencrypted password will follow
7           Specifies that a hidden password will follow
LINE        The unencrypted (cleartext) enable password
Router(config)# enable secret level 10 ?
0           Specifies that an unencrypted password will follow
5           Specifies that an encrypted secret will follow
LINE        The unencrypted (cleartext) enable secret

Hostname Tallinn
!
privilege exec level 9 show
privilege exec level 9 reload
enable secret level 9 5 $1$dLOD$QR.onv68q3326pzM.Zexj1

router> enable 9
password: <secret for level 9>

username showconfig password foo
username showconfig priv 15 autocommand write terminal

Router(config)#aaa authorization ?
auth proxy                 For authentication proxy services
commands                   For exec (shell) commands
config-commands            For configuration mode commands
configuration              For downloading configurations from
 AAA server
exec                       For starting and exec (shell)
ipmobile                   For mobile IP services
network                    For network services (PPP, SLIP, ARAP)
reverse-access             For reverse-access connections

aaa authorization command 15 tacacs+ none

group=partner_company {
    default service = permit
    cmd = crypto {
       deny .*
    }
    cmd = aaa {
       deny .*
    }
    cmd = tacacs-server {
       deny .*
    }
    cmd = no {
       deny crypto.*
       deny aaa.*
       deny tacacs.*
    }
}
user = luser {
    login = des slslkdfjse
    member=partner_company
}

The Catalyst family of switches (Catalyst 4000, Catalyst 5000, and Catalyst 6000 running CatOS) also has a basic and more privileged access mode. The privileged mode has supported some form of authentication, beginning in the 2.2 code. Enhancements have been added with later versions, and listed here are the most basic commands to get started. For Cisco Catalyst switches, basic access mode is denoted by the > prompt after the system prompt; privileged access is indicated by the word (enable) in the system prompt. Table 9-4 displays the basic mode commands; Table 9-5 shows the privileged mode commands. (Both tables list the commands available when your system is equipped with a Supervisor Engine I or II module.)

To authenticate a user for privileged access on Cisco switches, multiple forms of authentication are possible:

The commands required to specify the authentication are as follows:

set authentication enable {radius | tacacs | kerberos} {enable | disable}
    [console | telnet | http | all] {primary}
set authentication enable local {enable | disable}
    [console | telnet | http | all]
set authentication enable attempt {count} [console | remote]
set authentication enable lockout {time} [console | remote]

The default is that local authentication is enabled for console and Telnet sessions. When the keyword primary is used, it specifies which authetication method is tried first. If a primary method is not specified, the authentication is tried in the order in which the authentication methods were enabled. In addition, it is possible to specify the number of login attempts and the period of time a user is locked out of the switch after unsuccessfully attempting to log in. The keyword remote applies to remote logins such as Telnet, Secure Shell (SSH), Kerberos, and HTTP.

The locally defined enable password is configured using the set enablepass command. The command prompts you for the old password. If the password you enter is valid, you are prompted to enter a new password and to verify the new password. A zero-length password is allowed. Example 9-8 shows how you would configure a locally defined enable password.

Console> (enable) set enablepass
Enter old password: <old_password>
Enter new password: <new_password>
Retype new password: <new_password>
Password changed.
Console> (enable)

If TACACS+ is used as the enable authentication method, the switch also has the capability to authorize privileged mode session events. This is accomplished with the following command:

set authorization enable enable {option} {fallbackoption}
    [console | telnet | both]

The option can be one of three values:

Example 9-9 shows the commands required to provide enable authentication and authorization using TACACS+.

! Make sure there is a back door available in case the TACACS+
! server is unavailable.

set authentication enable local enable

! Enable TACACS+ authentication and TACACS+ server parameters.

set authentication enable tacacs enable primary
set tacacs server 144.254.5.9
set tacacs key LetMeIn

! Set the number of console and remote login enable mode attempts to 3.

set authentication enable attempt 3

! Set the enable mode lockout time to 5 minutes for console login.

set authentication enable lockout 300 console

! Set the enable mode lockout time to 10 minutes for remote login.

set authentication enable lockout 600 remote

! Configure the switch to require enable authorization.  Allow for
! no authorization if the server is down.


set authorization enable enable tacacs+ none both

Starting in CatOS version 7.5.1, local user authentication is possible where a username/password combination can be used to authenticate/authorize users. This is accomplished using the following commands:

set localuser user username password userpassword privilege [0 | 15]
set localuser authentication enable

There are only two privilege levels for local user authentication, 0 or 15. Level 0 is the nonprivileged EXEC level. Level 15 is the privileged enable level. Note that if a user is set as using privilege level 0 but knows the enable mode password, that user can continue to authenticate for enable mode. A maximum of 25 local users can be configured on each switch. The defined user password is encrypted in the configuration file.

The Private Internet Exchange (PIX) firewall contains a command set based on Cisco IOS technologies. The unprivileged basic mode is available when you first access the PIX firewall; this mode displays the > prompt and specifies commands with privilege level 0. The basic mode enables you to view restricted settings. Privileged mode displays the # prompt and enables you to change current settings—these commands are at privilege level 15. Any unprivileged command also works in privileged mode. To show the privilege levels settings for all commands, issue the command show privilege all. Tables 9-6 and 9-7 display the basic mode and privileged mode commands for the PIX firewall.

To authenticate a user for privileged access on PIX firewalls, you can use either a privileged mode password or a AAA authentication. The privileged mode password can be specified with this command:

enable password <password> [encrypted]

The password is encrypted in the configuration file using MD5. If you use the word encrypted during configuration, you are specifying that the password you enter is already encrypted. The encrypted password must be 16 characters in length.

Example 9-10 shows an example of entering the enable password command unencrypted.

enable password thisisasecret
show enable password
enable password feCkwUGktTCAgIbD encrypted

Example 9-11 shows an example of entering the enable password command encrypted.

enable password thisisgibberish encrypted
show enable password
enable password thisisgibberish encrypted

A more scalable authentication method is to use AAA, which is accomplished using the following command:

aaa authentication [serial | enable | telnet | ssh | http] console group_tag

When used with the console option, it enables authentication service for access to the PIX firewall console over Telnet or from the console connector on the PIX firewall unit. TACACS+, RADIUS, or a locally defined user authentication database can be specified. To use a locally defined user authentication base, the word local is specified as the group tag. Example 9-12 shows a configuration in which enable access is authenticated using a locally defined user database.

! Set up the local database with user merike with enable-mode privilege level.

username merike password ThisIsASecret privilege 15

! Set up the AAA mechanism to use the local user database.

aaa-server LOCAL protocol local
aaa authentication enable console LOCAL

Privilege [show | clear | configure] level level mode [enable | configure]
    command command

! Define the username with associated privilege level.

username Cathy password MySecret privilege 6

! Set up the specified commands to correspond to privilege level 6.

privilege show level 6 command alias
privilege show level 6 command arp
privilege show level 6 command conn
privilege show level 6 command block

Cisco IOS devices can be accessed via console ports, auxiliary ports, and virtual terminal ports. The following sections detail how to effectively secure them.

! The following command turns on AAA.

aaa new-model

! The username and password that follow constitute the local
! authentication database.

username merike  password 7 082C495C0012001E010F02
username cathy  password 7 0574837212001E010F0296

! The next commands define a radius server and key.

radius-server host  144.254.5.5
radius server key LetMeIn

! The following commands define the default authentication login  method list.
! If the RADIUS server
! fails, the local database is used for authentication.

aaa authentication login default group radius local

! The following are the console-specific commands where authentication
! is specified as requiring a login
! username/password as defined by AAA authentication.

line console 0
   transport input ssh
   exec-timeout 1 30
   login authentication default

transport input {all | lat | mop | nasi | none | pad | rlogin | telnet | v120}

line aux 0
 no exec
 transport input none

access-list 3 permit 144.254.9.0 0.0.0.255
access-list 3 permit 144.254.19.0 0.0.0.255
!
line vty 0 4
 access-class 3 in

You can access the switch command-line interface (CLI) from a console terminal connected to an EIA/TIA-232 port or through remote methods including Telnet, HTTP, or SSH sessions. The set authentication login command enables you to designate the authentication mechanism to use for either console or remote login access:

set authentication login {radius | tacacs | kerberos} {enable | disable}
    [console | telnet | http | all]

The deafult is local authentication and a maximum of three login attempts are permitted. If TACACS+ is used as the authentication method, the switch also has the capability to authorize session events. This is accomplished with the following command:

set authorization commands enable {config | enable | all} {option}
    {fallbackoption} [console | telnet | both]

This is similar to the authorization commands specifically for privileged access (enable mode). However, it does not replace it.

The Cisco switches also have the capability to restrict access to specified hosts through the set ip permit command. When you enable this feature, Telnet access, SSH access, and SNMP services are authorized only for the IP addresses of the hosts configured on the permit list. Up to 100 entries can be configured. The IP permit list is the first level of security for the Telnet and SNMP protocols. All other Transmission Control Protocol/Internet Protocol (TCP/IP) services continue to work for any hosts when you enable the IP permit list. Outbound Telnet, Trivial File Transfer Protocol (TFTP), and other IP-based services remain unaffected by the IP permit list. SNMP from nonpermitted IP addresses have no response—that is, the request times out. Notifications of unauthorized access attempts are available through SNMP traps and syslog options.

Before enabling the IP permit feature, be sure that you configure your IP address in the permit list, especially when configuring through SNMP. Failure to do so results in immediate disconnection from the system being configured. (I recommend that you disable the IP permit feature before clearing the IP permit entries or host addresses.)

Example 9-23 shows a configuration for allowing a switch to accept SSH connections from network 144.254.9.0 and network 144.254.19.0.

! First generate the 1024-bit RSA public/private key pair used for SSH.

 set crypto key rsa 1024

! Define the range of ip addresses from where to allow connections.

set ip permit 144.254.9.0 0.0.0.255
set ip permit 144.254.19.0 0.0.0.255

! Restrict IP access to only allow remote login SSH connections.

set ip permit enable ssh

The PIX firewall CLI can be accessed using the serial console connector or over remote login using Telnet or SSH. The following command enables authentication using either TACACS+ or RADIUS:

aaa authentication [serial | enable | telnet | ssh | http] console group_tag

When used with the console option, this command enables authentication service for access to the PIX firewall console over Telnet or from the serial console connector on the PIX firewall unit. This command is used together with the aaa-server command:

aaa-server group-tag (interface_name) host server-IP-address shared-key
    timeout seconds
aaa-server group_tag protocol [tacacs+ | radius]

You can define 14 groups of servers with a maximum of 14 servers each. Certain types of AAA services can be directed to different servers; such as TACACS+ servers for inbound traffic and another for outbound traffic. Services can also be set up to fail over to multiple servers. The interface name defines on which interface the authentication server resides.

Telnet access to the PIX firewall console is available for both the inside and outside interface. For Telnet access to work from the outside interface, however, an IPsec client needs to be set up to initiate a VPN connection to the PIX using IPsec. Inside interface refers to the interface connected to the corporate network, whereas outside interface refers to the interface connected to the Internet, as shown in Figure 9-2.

Figure 9-2. The Inside and Outside Interfaces of the PIX Firewall

Telnet access requires use of the telnet command:

telnet ip-address [netmask] [inside | outside]

The telnet command enables you to decide who can access the PIX firewall with Telnet. Up to 16 hosts or networks are allowed access to the PIX firewall console with Telnet, five simultaneously.

To set up a password for Telnet access to the console, you must configure the passwd command:

passwd password [encrypted]

The default password is cisco. The passwd command sets a password for Telnet and gives the PIX Firewall Manager access to the firewall console. An empty password can be used and is also changed into an encrypted string. Any use of a write command displays or writes the password in encrypted form. After passwords are encrypted, they cannot be changed back to plaintext. Consider Example 9-24.

passwd secretforpix
show passwd

passwd jMorNbK0514fadBh encrypted

It is much more scalable to set up AAA mechanisms to authenticate Telnet access. Example 9-25 shows a configuration where Telnet access is authenticated using AAA.

! Set up Telnet access for specified hosts.

telnet 144.254.9.0 0.0.0.255  inside
!Define the server group TelnetAccess and the protocol to use, RADIUS.

aaa-server TelnetAccess protocol radius

! Set up the AAA server parameters which includes IP address of RADIUS
! server and shared key.

aaa-server TelnetAccess (inside) host 144.254.5.5 ThisIsASecret timeout 60
! Configure AAA authentication for Telnet access.
aaa authentication telnet console TelnetAccess

SSH access to the PIX firewall console is available from any interface without IPsec configured, and requires use of the ssh command. Older software that does not support AAA authentication requires that the Telnet password be used to authenticate SSH access. Example 9-26 illustrates the use of SSH for secure and authenticated access using AAA.

! The following two commands define the PIX host name and domain name.
! The RSA keys used for SSH
! are named using these parameters.

hostname PIX-Venice
domain-name cisco.com

! The next command is used to generate a default 1024-bit RSA key pair.

ca generate rsa key 1024

! Save the key to Flash memory.

ca save all
! Accept SSH connections from the outside interface from any host
! from a particular network and specify
! that the connection will timeout after 5 minutes of inactivity.

ssh 208.251.229.0 0.0.0.255 outside
ssh timeout 5

! Set up the AAA server parameters using a TACACS+ server.

aaa-server SSHAccess protocol tacacs+
aaa-server SSHAccess (inside) host 144.254.5.9 ThisIsAKey  timeout 10
! Configure AAA authentication for SSH access.
aaa authentication ssh console SSHAccess

The Simple Network Management Protocol (SNMP) is often used to gather statistics and remotely monitor network infrastructure devices. It is a very simplistic protocol and therefore has virtually no security built in to its original version. In SNMP version 1 (SNMPv1), community strings (passwords) are sent in cleartext. These community strings are used to authenticate messages sent between the SNMP manager and the agent. These community strings can easily be stolen by someone eavesdropping on the wire.

SNMPv2 addresses some of the known security weaknesses of SNMPv1. Specifically, version 2 uses the MD5 algorithm to authenticate messages between the SNMP server and the agent.

In most devices, SNMP has two options:

Whenever possible, configure filters to allow only specified hosts to have SNMP access to devices. In addition, use just the read-only option to gather statistics because the read-write option is rarely used and creates additional security risks.

SNMPv3 has recently been added to some Cisco products. This version of SNMP added authentication through the use of the HMAC-MD5 or HMAC-SHA algorithms, as well as confidentiality through the use of 56-bit DES encryption. Specific details on how to set up SNMPv3 are available at http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a00800878fa.html.

To facilitate configuration and management of network devices, many manufacturers are implementing HTTP servers into devices to create cross-platform, easy management solutions. Keep in mind that the communication between the HTTP client and the HTTP server embedded into the network infrastructure devices should be secured (that is, encrypted). This means that you must use some of the technologies (such as HTTPS, SSL, SSH, or possibly even IPsec) discussed in Chapter 2, “Security Technologies.”

Most Cisco IOS routers, catalyst switches, and PIX firewalls have incorporated mechanisms to authenticate and restrict access for HTTP remote access. It is extremely important that these be configured. Some versions of software will have HTTP access turned off by default. It is recommended that if there is no need for HTTP access, that the HTTP server be explicitly disabled.

Router(config)#access-class         Restrict access by access class
authentication       Set HTTP authentication method
port                 HTTP port
server               Enable HTTP server

Router(config)#ip http authentication ?
enable        Use enable passwords
local         Use local username and passwords
tacacs        Use TACACS+ to authorize user

ip http server

access-list 6 permit 144.254.5.0 0.0.0.255
!
ip http server
ip http  access-class 6
ip http authentication enable

http ip_address [netmask] [if_name]
passwd password

For critical network segments that cannot have any routing outages, the Cisco IOS devices supporting these segments should be configured with the Hot Standby Router Protocol (HSRP). HSRP provides high network availability because it routes IP traffic from hosts on Ethernet, FDDI, or Token Ring networks without relying on the availability of any single router.

When HSRP is configured on a network segment, it provides a virtual MAC address and an IP address that is shared among routers in a group of routers that is running the HSRP. One of these devices is selected by the protocol to be the active router. The active router receives and routes packets destined for the group's MAC address. For n routers running the HSRP, there are n + 1 IP and MAC addresses assigned.

The HSRP detects when the designated active router fails, at which point a selected standby router assumes control of the hot standby group's MAC and IP addresses. A new standby router is also selected at that time.

Devices running the HSRP send and receive multicast UDP-based hello packets to detect router failure and to designate active and standby routers.

The HSRP feature is configured with the following interface command:

standby [group-number] ip [ip-address [secondary]]

You can configure a number of group attributes to affect how the local router participates in the HSRP. Here is an example of these attributes:

Router(config)#int e 0
Router(config-if)#standby ?
<0-255>                 Group number
authentication          Authentication string
ip                      Enable hot standby protocol for IP
mac-address             Specify virtual MAC address for the virtual router
preempt                 Overthrow lower priority designated routers
priority                Priority level
timers                  Hot standby timers
track                   Priority tracks this interface state
use-bia                 Hot standby uses interface's burned-in address

Consider the scenario shown in Figure 9-7.

Figure 9-7. An Example of HSRP Implementation

The configuration of a primary router is shown in Example 9-31.

hostname Primary
!
interface Ethernet1
  ip address 144.254.1.1 255.255.255.0
  no ip redirects
  standby priority 200
  standby preempt
  standby ip 144.254.1.3

The configuration of a standby router is shown in Example 9-32.

hostname Standby
!
interface Ethernet1
  ip address 144.254.1.2 255.255.255.0
  no ip redirects
  standby priority 101
  standby ip 144.254.1.3

Switches are normally connected hierarchically, as shown in Figure 9-8. Although there still exist large flat networks built with switches, a hierarchtical architecture is much more manageable and can use features to address security issues, such as the ones discussed in this section.

Figure 9-8. An Example of Switch Hierarchy

In simple networks, the upper two levels of the hierarchy can be collapsed into a single backbone layer. Figure 9-8 shows the network topology after the spanning tree converges into a loop-free topology. The spanning tree has blocked the redundant links to avoid loops. Every access switch and distribution switch in the figure has a redundant uplink.

The time it takes to detect and correct failures is important. For Cisco switches, the Spanning Tree Protocol UPlinkFast and BackboneFast features reduce spanning-tree convergence times. UPlinkFast provides fast convergence after a spanning-tree topology change and achieves load balancing between redundant links using uplink groups. An uplink group is a set of ports (per VLAN), only one of which is forwarding at any given time. Specifically, an uplink group consists of the root port (which is forwarding) and a set of blocked ports, except for self-looping ports. The uplink group provides an alternative path in case the currently forwarding link fails. Be warned that the topology must not allow loops during a change. The topology must be architected so that one can turn off spanning tree's normal behavior and make the link transition without creating any loops.

To configure a switch as the primary root switch, enter this command:

set spantree root vlans [diameter network_diameter] [hello hello_time]

This command reduces the bridge priority (the value associated with the switch) from the default (32,768) to a significantly lower value, which allows the switch to become the root switch.

To configure a switch as the secondary root switch, enter this command:

set spantree root [secondary] vlans [dia network_diameter] [hello hello_time]

You can run this command on more than one switch to create multiple backup switches in case the primary root switch fails.

The BackboneFast Convergence feature reduces the time needed for the spanning tree to converge after experiencing a topology change caused by indirect link failures. This feature complements the UPlinkFast feature just described. However, the BackboneFast Convergence feature is designed for all switches that experience indirect link failures.

To configure the BackboneFast Convergence feature, enter this command:

set spantree backbonefast enable

The Multiple Default IP Gateways feature enables you to configure up to three default IP gateways. Defining multiple default IP gateways provides redundancy. In the event that the primary gateway cannot be reached, the switch uses the secondary default IP gateways in the order in which they are configured. This feature is configured with the following command:

set ip route destination gateway [metric] [primary]

Use the primary keyword to give a default IP gateway higher priority than the other default IP gateway(s). If you do not designate a primary default IP gateway, the system chooses the default IP gateway based on the order in which the gateways were configured. If two or more gateways are designated as primary gateways, the system chooses the last primary gateway configured to be the default IP gateway.

The Cisco PIX firewall is usually a critical device in most corporate infrastructures. To eliminate it being a single point of failure, it is prudent to install a redundant PIX firewall and to use the failover command to ensure fast dynamic recovery in the event that the primary PIX has a power failure or some other type of failure. There are two modes of failover:

The default failover setup uses serial cable failover, where the serial failover cable is a cross-over cable. For serial cable failover, use the failover command without an argument after you connect the optional failover cable between your primary PIX firewall and a secondary PIX firewall. The default configuration has failover enabled. Enter no failover in the configuration file for the PIX firewall if you will not be using the failover feature. Use the show failover command to verify the status of the connection and to determine which unit is active.

LAN-based failover requires explicit LAN-based failover configuration using the failover lan commands. The show failover lan command displays LAN-based failover information. In addition, for LAN-based failover, you must install a dedicated 100-Mbps or Gigabit Ethernet, full-duplex VLAN switch connection for failover operations. Failover is not supported using a crossover Ethernet cable between two PIX firewall units. Although the same dedicated interface can also be used for stateful failover, it is recommended to use two separate interfaces because many times the dedicated interface does not have enough capacity to handle both the LAN-based failover and stateful failover traffic.

It is possible to force a failover by using the failover active command to initiate a failover switch from the standby unit, or the no failover active command from the active unit to initiate a failover switch. This proves useful when returning a previously failed unit to service, or to force an active unit off line for maintenance.

Failover IP addresses must be configured on each interface card. The active unit of the failover pair uses the system IP addresses and the primary unit's MAC address; the standby unit uses the failover IP addresses and the secondary unit's MAC address. The system IP addresses and the failover IP addresses must be on the same subnet with no router between them.

The failover mac address command is used to configure a virtual MAC address for a PIX firewall failover pair. It sets the PIX firewall to use the virtual MAC address stored in the PIX firewall configuration after failover, instead of obtaining a MAC address by contacting its failover peer. This enables the PIX firewall failover pair to maintain the correct MAC addresses after failover. If a virtual MAC address is not specified, the PIX firewall failover pair uses the burned-in network interface card (NIC) address as the MAC address. For LAN-based failover, this command is not needed because the IP and MAC addresses do not change when a failover occurs.

Both units in a failover pair communicate through the failover cable. The two units send special failover hello packets to each other over all network interfaces and the failover cable every 15 seconds. The failover feature in PIX firewall monitors failover communication, the power status of the other unit, and the hello packets received at each interface. If two consecutive hello packets are not received within a time determined by the failover feature, failover starts testing the interfaces to determine which unit has failed and transfers active control to the standby unit.

Although it is very difficult to actually recognize spoofed packets, you can use some mechanisms to help prevent some more obvious spoofs. Some of these packets may be caused by simple misconfigurations and routing loops. Whenever possible, filters should be put into place to ensure that only valid network addresses are permitted past the routers. All corporate infrastructure routers should have filters in place to disallow any obviously bogus traffic. For example, any edge router should deny traffic whose source address is one of the RFC reserved addresses shown in Table 9-9.

These IP addresses are specified for special use and are therefore designated as nonroutable in the Internet infrastructure. (That is, no Internet service provider will route these networks; therefore, no edge routers connecting to the Internet should receive packets with these addresses as a source.)

Some devices also have features to assist in tracking down the source of packets with invalid source addresses. For Cisco IOS devices, this is an extension of the access list logging feature that will show the input interface for packets. (For a detailed discussion on Cisco IOS access lists, refer to Chapter 10, “Securing Internet Access.”) It is enabled by adding log-input to an access list entry:

access-list 100 permit ip any host 171.69.233.3 log-input

The output from this command looks like this:

%SEC-6-IPACCESSLOGP: list 100 permitted udp 171.69.2.132(53)
(Ethernet0/0)-> 171.69.233.3(5775), 1 packet
%SEC-6-IPACCESSLOGDP: list 100 permitted icmp 171.69.2.75
(Ethernet0/0) -> 171.69.233.3 (0/0), 1 packet

To deter any attack based on fragments, the device must have an option to reassemble the original packet, ensure that the packet is valid, and then fragment the packet again before forwarding it. This check can severely limit system performance; think carefully before rushing off to implement this feature on every device. It is best to determine the most critical, vulnerable area and then place the deterrent there. In most instances in a large corporate network, the most vulnerable areas are at the network access points, such as Internet access or dial-in access.

Some attacks are based on flooding networks with traffic based on directed broadcast addresses, such as the Smurf and Fraggle attacks discussed in Chapter 5, “Threats in an Enterprise Network.” The Cisco IOS command no ip directed-broadcast should be configured on every interface to avoid traffic being broadcast out.

An effective mechanism to be alerted to these types of attacks is to configure filters that would permit ICMP echo requests/replies (for Smurf attacks) or UDP echo requests (for Fraggle attacks). By logging and monitoring this traffic, it is possible to detect whether such an attack is in progress. The source addresses are the addresses of the Smurf or Fraggle reflectors. By looking up the owners of these address blocks in the appropriate Internet “whois” databases, the administrators of these networks can be located and asked for their help in dealing with the attack.

It's important to remember that these reflectors are fellow victims, not attackers. It's extremely rare for attackers to use their own source addresses on IP packets in any DoS flood, and impossible for them to do so in a working Smurf attack. Any address in a flood packet should be assumed to be either completely falsified, or the address of a compromised victim. The most productive approach for the ultimate target of a Smurf attack is to contact the reflectors, either to ask them to reconfigure their networks to shut down the attack, or to ask for their assistance in tracing the attack stream.

It is important to recognize that it is nearly impossible to stop a TCP SYN flooding attack. What can be done, however, is to constrain its impact on critical parts of the network.

Typically, a firewall is set up to act as a proxy when a TCP connection is established. A TCP proxy is a server that acts as an intermediary between a client and a destination server. Clients establish connections to the TCP proxy server, which then establishes a connection to the destination server. The proxy server sends data received from the client to the destination server and forwards data received from the destination server to the client. The TCP proxy server acts as both a server and a client.

The firewall checks for incoming TCP connection requests and then acts as the TCP proxy. (See Figure 9-9.)

Figure 9-9. A TCP Proxy

In the case of bogus requests, the firewall usually also has parameters to set very aggressive timeouts on half-open connections; it also has parameters to set threshold levels for the number of both outstanding connections and the incoming rate of TCP-connection requests.

On the Cisco IOS devices, the command to use against TCP SYN attacks is this one:

ip tcp intercept access-list-number
ip tcp intercept mode watch

This command keeps track of the following information:

For the PIX firewall, you can issue the following command to limit the number of half-open TCP connections and total number of TCP connections allowed:

static 172.17.1.12 10.1.1.2 [max_conns] [em_limit]

In this syntax, max_conns is the maximum number of TCP connections allowed, and em_limit is the embryonic connection (half-open connection) limit. Refer to Chapter 10 for a more complete description.

Syslog messages are based on the User Datagram Protocol (UDP) and are received on UDP port 514. The message text is kept under 512 bytes to ensure that the UDP packet is smaller than 576 bytes—the smallest packet that must be accepted by a host without packet fragmentation.

Syslog messages are categorized by eight priority levels, shown in Table 9-10.

Syslog messages generated by various devices can be logged locally or redirected to a log file or syslog management server. A syslog management server can be used to collect all syslog information that is deemed critical as part of the corporate network for auditing purposes.

Example 9-33, Example 9-34, and Example 9-35 illustrate how to configure syslog logging on a Cisco IOS router, Catalyst switch, and PIX firewall, respectively.

! These commands configure the granularity of the time stamps.

service timestamps debug datetime localtime show-timezone
service timestamps log datetime localtime show-timezone

! Allow an internal buffer to log up to 32000 bytes of data.
! When the maximum is reached, the older data will be overwritten.

logging buffered 32000 informational

! Do not allow for logging on the console interface.

no logging console

! Set up all messages with a severity of up to 6 (informational) to be
! sent to the syslog server.

logging trap informational

! Specify the facility expected by the syslog server in the messages sent to it.

logging facility local1

! Specify the syslog server IP address.

logging 144.254.5.5

! Configure multiple NTP time sources for redundancy.

ntp server 192.5.41.40
ntp server 192.36.143.150

! Turn logging on.

set logging server enable

! Specify the facility expected by the syslog server in the messages sent to it.

set logging server facility local 2

! Set up all messages with a severity of up to 6 (informational) to
! be sent to the syslog server.

set logging server severity 6

! Specify the syslog server IP address.

set logging server 144.254.5.5

! Turn on NTP in client mode so that it interacts with an NTP master device.

set ntp client enable

! Configure multiple NTP master devices for redundancy.

ntp server 192.5.41.40
ntp server 192.36.143.150

! Turn logging on.

logging on

! Specify the facility expected by the syslog server in the messages sent to it.

logging  facility 3

! Set up all messages with a severity of up to 6 (informational)
! to be sent to the syslog server.

logging trap informational

! Specify the syslog server IP address.

logging host inside 144.254.5.5

! Configure multiple NTP master devices for redundancy.

ntp server 192.5.41.40
ntp server 192.36.143.150

The Cisco IOS Image needs to include the Cisco Secure Integrated (that is, the firewall/intrusion detection system [IDS]) Software to use it as an IDS sensor. It has so far incorporated 59 of the most common attack signatures that are used to detect patterns of misuse in network traffic. They are categorized as information signatures, such as port scans and echo requests, or as attack signatures, such as common DoS attacks. The router can be configured to send an alarm, drop traffic, or perform TCP resets for any traffic it considers malicious. In addition, the router has the capability to disable the use of a specific signature if it causes too many false alarms.

Routers log the alarm events via syslog. The router can also interact with a management system using the Post Office Protocol (UDP port 45000) such as the Cisco Secure Policy Manager or the Cisco Secure IDS Director (also called Netranger Director) to receive alarm information. This communication is not confidential, and IPsec should be used to provide authentication and confidentiality for the management communication.

Configuration of the router IDS sensor requires the use of the ip audit commands. Example 9-36 illustrates a sample configuration where the logs are sent to a syslog server. Only the relevant IDS commands are shown.

! Specify the syslog server IP address.

logging 144.254.5.5

! Initialize the IDS facility with the following command.
! It denotes the maximum number of e-mail recipients
! in a given mail message before the mail is categorized as spam.

ip audit smtp spam 200

! Configure the IDS alerts to be sent to syslog and a buffered log.

ip audit notify log

! Define the audit rule that will be used to take action on informational
! signatures and attack signatures.
! For informational signatures only an alarm will be logged but for attack
! signatures an alarm will
! be logged and the traffic will be dropped and the TCP connection will be reset.

ip audit name E10Audit info action alarm
ip audit name E10Audit attack action alarm drop reset

! Apply the rule to the Ethernet 1/0 interface.

interface Ethernet 1/0
   description Connection to Branch Office
   ip audit E10Audit in

You can make the PIX firewall act as an IDS sensor by using the ip audit commands. The PIX does not communicate with a management console, but all alarms can be logged via syslog. Because the sensing module sits on the packet path, it inspects the packets inline. The PIX can be configured to send an alarm, drop traffic, or perform TCP resets for any traffic it considers malicious. Example 9-37 illustrates a sample configuration showing only the relevant IDS commands.

! Specify the syslog server IP address.

logging host inside 144.254.5.5

! Define the audit rule that will be used to take action
! on informational signatures.
! In this case, only an alarm will be logged.

ip audit name InfoAudit info action alarm

! Define the audit rule that will be used to take action on
! attack signatures – offending packets
! will be dropped and the connections will be reset.
! An alarm will also be logged.

ip audit name AttackAudit attack action alarm drop reset

! The rules are now applied to an interface.  Up to two rules can be
! applied per interface.

ip audit interface outside InfoAudit
ip audit interface outside AttackAudit