Foundation Topics

Switch AAA

You can manage user activity to and through a switch with authentication, authorization, and accounting (AAA) features. AAA uses standardized methods to challenge users for their credentials before access is allowed or authorized. Accounting protocols also can record user activity on a switch.

Authentication

Switch or network access can be granted only after a user's identity has been validated. User authentication commonly is used on switches and routers to limit Telnet access to the network-administration staff. In this case, when someone uses Telnet to log on to a switch, that individual first is challenged with a username and password. The individual's credentials then are submitted to a device that can grant the user access.

User authentication can be handled by several methods:

• Usernames and passwords configured locally on the switch

• One or more external Remote Authentication Dial-In User Service (RADIUS) servers

• One or more external Terminal Access Controller Access Control System+ (TACACS+) servers

Any combination of these methods can be used. In fact, authentication must be defined by grouping the desired methods into a method list. The list contains the types or protocols that will be used, in the sequential order that they will be tried.

To use authentication on a Catalyst switch, you must configure several things in the following order:

Step 1.	Enable AAA on the switch. By default, AAA is disabled. Therefore, all user authentication is handled locally by configuring usernames and passwords. To enable AAA, use the following global configuration command: Switch(config)# aaa new-model The new-model refers to the use of method lists, by which authentication methods and sources can be grouped or organized. The new model is much more scalable than the "old model," in which the authentication source was explicitly configured.
Step 2.	Define the source of authentication. You can compare user credentials against locally configured usernames and passwords, or against a database managed by external RADIUS or TACACS+ servers. Use locally configured usernames and passwords as a last resort, when no other authentication servers are reachable or in use on the network. To define a username, use the following global configuration command: Switch(config)# username username password password RADIUS or TACACS+ servers are defined in groups. First, define each server along with its secret shared password. This string is known only to the switch and the server, and provides a key for encrypting the authentication session. Use one of the following global configuration commands: Switch(config)# radius-server host {hostname | ip-address} [key string] Switch(config)# tacacs-server host {hostname | ip-address} [key string] Then define a group name that will contain a list of servers, using the following global configuration command: Switch(config)# aaa group server {radius | tacacs+} group-name Define each server of the group type with the following server-group configuration command: Switch(config)# server ip-address You can define multiple RADIUS or TACACS+ servers by repeating these commands.
Step 3.	Define a list of authentication methods to try. You can list switch login authentication methods by giving the method a descriptive name or using the unnamed "default" method. List each method or protocol type in the order that it should be tried. If none of the servers for the first method responds, the switch tries the servers in the next method listed. Use the following global configuration command to define a method list: Switch(config)# aaa authentication login {default | list-name} method1 [method2 ...] Here the methods refer to these values: tacacs+ Each of the TACACS+ servers configured on the switch is tried, in the order that it was configured. radius Each of the RADIUS servers configured on the switch is tried, in the order that it was configured. local The user's credentials are compared against all the username commands configured on the local switch. line The line passwords authenticate any connected user. No usernames can be used. Tip Be sure to add either the local or line methods at the end of the list, as a last resort. This way, if all the RADIUS or TACACS+ servers are unavailable or the switch is completely isolated from the rest of the network, a locally configured authentication method eventually will be used. Otherwise, you will never be able to get into the switch.
Step 4.	Apply a method list to a switch line. First, select a line (console or vty for Telnet access) using the line line command. Then trigger the user authentication on that line to use an AAA method list. Use the following line-configuration command: Switch(line)# login authentication {default | list-name} You can use the default method list if only one list is sufficient for all circumstances on the switch. Otherwise, if you have configured named method lists, you can reference one of them here.
Step 5.	After authentication is configured on a switch, it is a good idea to stay logged in on one session so that the authentication can be tested. If you exit the configuration session, you will not be able to log in again if the authentication is misconfigured. While you stay logged in on the original session, bring up a new Telnet session to the switch. If you can authenticate successfully, everything is configured properly.

Authorization

After a user is authenticated, the switch allows access to certain services or switch commands based on the user's privilege level. Authenticating puts the user at the EXEC level, by default. Certain commands, such as show interface, are available at the EXEC level. Other commands, such as configure terminal, are accessible only if the user is able to move into the privileged EXEC or enable mode.

Authorization provides a means of granting specific users the ability to perform certain tasks. As with authentication, authorization is performed by querying external RADIUS or TACACS+ servers. If the authorization server has an entry for a user and a service or command, the switch allows the user to perform that task.

You configure authorization by first defining any RADIUS or TACACS+ servers that will be used. These normally are defined as part of the authentication configuration and do not need to be redefined for authorization.

Next, define a method list of authorization methods that will be tried in sequence using the following global configuration command:

Switch(config)# aaa authorization {commands | config-commands | configuration | exec | network | reverse-access} {default | list-name} method1 [method2 ...]

Here you specify the function or service needing authorization with one of the following values:

• commands The server must return permission to use any switch command at any privilege level.

• config-commands The server must return permission to use any switch-configuration command.

• configuration The server must return permission to enter the switch-configuration mode.

• exec The server must return permission for the user to run a switch EXEC session. The server also can return the privilege level for the user so that the user immediately can be put into privileged EXEC (enable) mode without having to type in the enable command.

• network The server must return permission to use network-related services.

• reverse-access The server must return permission for the user to access a reverse Telnet session on the switch.

You can identify the method with a descriptive name (list-name) if you are configuring more than one list. Otherwise, a single unnamed list is called the default list. Each authorization method then is listed in the order it will be tried. The methods can be any of the following values:

• group group-name Requests are sent to the servers in a specific group.

• group {radius | tacacs+} Requests are sent to all servers of this type.

• if-authenticated Requests are granted if the user already is authenticated.

• none No external authorization is used; every user is authorized successfully.

Tip

Only TACACS+ servers can authorize users with permission to use specific commands. RADIUS servers offer more of an all-or-nothing approach.

Next, you can apply an authorization method list to a specific line on the switch. Users accessing the switch through that line will be subject to authorization. Use the following line-configuration command:

Switch(config-line)# authorization {commands level | exec | reverse-access} {default | list-name}

If you do not use this command, the default group is used for all lines.

Accounting

Catalyst switches also support the capability to use AAA for producing accounting information of user activity. RADIUS and TACACS+ servers also can collect this accounting information from switches, if wanted. Again, the RADIUS and TACACS+ servers already must be configured and grouped as part of the authentication configuration.

As usual, you must define a method list giving a sequence of accounting methods by using the following global configuration command:

Switch(config)# aaa accounting {system | exec | commands level} {default | list-name} {start-stop | stop-only | wait-start | none} method1 [method2 ...]

The function triggering the accounting can be one of the following:

• system Major switch events such as a reload are recorded.

• exec User authentication into an EXEC session is recorded, along with information about the user's address and the time and duration of the session.

• commands level Information about any command running at a specific privilege level is recorded, along with the user who issued the command.

You can specify that certain types of accounting records be sent to the accounting server using the following keywords:

• start-stop Events are recorded when they start and stop.

• stop-only Events are recorded only when they stop.

• none No events are recorded.

Next, you can apply an accounting method list to a specific line on the switch. Users accessing the switch through that line will have their activity recorded. Use the following line-configuration command to accomplish this:

Switch(config-line)# accounting {commands level | connection | exec} {default | list- name}

If you do not use this command, the default group will be used for all lines.

Port Security

In some environments, a network must be secured by controlling what stations can gain access to the network itself. Where user workstations are stationary, their MAC addresses always can be expected to connect to the same access-layer switch ports. If stations are mobile, their MAC addresses can be learned dynamically or added to a list of addresses to expect on a switch port.

Catalyst switches offer the port security feature to control port access based on MAC addresses. To configure port security on an access-layer switch port, begin by enabling it with the following interface-configuration command:

Switch(config-if)# switchport port-security

Next, you must identify a set of allowed MAC addresses so that the port can grant them access. You can explicitly configure addresses or they can be learned dynamically from port traffic. On each interface that uses port security, specify the maximum number of MAC addresses that will be allowed access using the following interface-configuration command:

Switch(config-if)# switchport port-security maximum max-addr

By default, only one MAC address will be allowed access on each switch port. You can set the maximum number of addresses in the range of 1 to 1024.

Each interface using port security dynamically learns MAC addresses by default and expects those addresses to appear on that interface in the future. These are called sticky MAC addresses. MAC addresses are learned as hosts transmit frames on an interface. The interface learns up to the maximum number of addresses allowed. Learned addresses also can be aged out of the table if those hosts are silent for a period of time. By default, no aging occurs.

For example, to set the maximum number of MAC addresses that can be active on a switch port at any time to two, you could use the following command:

Switch(config-if)# switchport port-security maximum 2

You also can statically define one or more MAC addresses on an interface. Any of these addresses are allowed to access the network through the port. Use the following interface-configuration command to define a static address:

Switch(config-if)# switchport port-security mac-address mac-addr

The MAC address is given in dotted-triplet format. If the number of static addresses configured is less than the maximum number of addresses secured on a port, the remaining addresses are learned dynamically. Be sure to set the maximum number appropriately.

You can use the following command to configure a static address entry on an interface:

Switch(config-if)# switchport port-security mac-address 0006.5b02.a841

Finally, you must define how each interface using port security should react if a MAC address is in violation by using the following interface-configuration command:

Switch(config-if)# switchport port-security violation {shutdown | restrict | protect}

A violation occurs if more than the maximum number of MAC addresses are learned or if an unknown (not statically defined) MAC address attempts to transmit on the port. The switch port takes one of the following configured actions when a violation is detected:

• shutdown The port immediately is put into the errdisable state, which effectively shuts it down. It must be re-enabled manually or through errdisable recovery to be used again.

• restrict The port is allowed to stay up, but all packets from violating MAC addresses are dropped. The switch keeps a running count of the number of violating packets and can send an SNMP trap and a syslog message as an alert of the violation.

• protect The port is allowed to stay up, as in the restrict mode. Although packets from violating addresses are dropped, no record of the violation is kept.

As an example of the restrict mode, a switch interface has received the following configuration commands:

interface GigabitEthernet0/11/  switchport access vlan 991  switchport mode access  switchport port-security  switchport port-security violation restrict  spanning-tree portfast

When the default maximum of one MAC address is exceeded on this interface, the condition is logged but the interface stays up. This is shown by the following syslog message:

Jun 3 17:18:41.888 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0000.5e00.0101 on port GigabitEthernet0/11.

Tip

If an interface is undergoing the restrict or protect condition, you might need to clear the learned MAC addresses so that a specific host can use the switch port. You can clear a MAC address or the complete port cache with the following command:

Switch# clear port-security dynamic [address mac-addr | interface type mod/num]

In the shutdown mode, the port security action is much more drastic. When the maximum number of MAC addresses is exceeded, the following syslog messages indicate that the port has been shut down in the errdisable state:

Jun 3 17:14:19.018 EDT: %PM-4-ERR_DISABLE: psecure-violation error detected on Gi0/11, putting Gi0/11 in err-disable state Jun 3 17:14:19.022 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0003.a089.efc5 on port GigabitEthernet0/11. Jun 3 17:14:20.022 EDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface Gigabit Ethernet0/11, changed state to down Jun 3 17:14:21.023 EDT: %LINK-3-UPDOWN: Interface GigabitEthernet0/11, changed state to down

You also can show the port status with the show port-security interface command, as demonstrated in Example 17-1.

Example 17-1. Displaying Port Security Port Status

Switch# show port-security interface gigabitethernet 0/11 Port Security              : Enabled Port Status                : Secure-shutdown Violation Mode             : Shutdown Aging Time                 : 0 mins Aging Type                 : Absolute SecureStatic Address Aging : Disabled Maximum MAC Addresses      : 1 Total MAC Addresses        : 0 Configured MAC Addresses   : 0 Sticky MAC Addresses       : 0 Last Source Address        : 0003.a089.efc5 Security Violation Count   : 1 Switch# 

To see a quick summary of only ports in the errdisable state, along with the reason for errdisable, you can use the show interfaces status err-disabled command, as demonstrated in Example 17-2.

Example 17-2. Displaying Summary Information for Ports in the Errdisable State

Switch# show interfaces status err-disabled Port      Name              Status       Reason Gi0/11    Test port         err-disabled psecure-violation Switch#

Tip

When a port is moved to the errdisable state, you must either manually cycle it or configure the switch to automatically re-enable ports after a prescribed delay. To manually cycle a port and return it to service, use the following commands:

Switch(config)# interface type mod/num Switch(config-if)# shutdown Switch(config-if)# no shutdown

Finally, you can display a summary of the port-security status with the show port-security command, as demonstrated in Example 17-3.

Example 17-3. Displaying Port Security Status Summary Information

Switch# show port-security Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action                 (Count)        (Count)          (Count) ---------------------------------------------------------------------------      Gi0/11              5            1                  0         Restrict      Gi0/12              1            0                  0         Shutdown --------------------------------------------------------------------------- Total Addresses in System (excluding one mac per port)      : 0 Max Addresses limit in System (excluding one mac per port)  : 6176 Switch# 

Port-Based Authentication

Catalyst switches can support port-based authentication, a combination of AAA authentication and port security. This feature is based on the IEEE 802.1x standard.

Basically, a switch port will not pass any traffic until a user has authenticated with the switch. If the authentication is successful, the user can use the port normally.

For port-based authentication, both the switch and the end user's PC must support the 802.1x standard, using the Extensible Authentication Protocol over LANs (EAPOL). The 802.1x standard is a cooperative effort between the client and the switch offering network service. If the client PC is configured to use 802.1x but the switch does not support it, the PC abandons the protocol and communicates normally. However, if the switch is configured for 802.1x but the PC does not support it, the switch port remains in the unauthorized state so that it will not forward any traffic to the client PC.

Note

802.1x EAPOL is a Layer 2 protocol. At the point that a switch detects the presence of a device on a port, the port remains in the unauthorized state. Therefore, the client PC cannot communicate with anything other than the switch by using EAPOL. If the PC does not already have an IP address, it cannot request one. The PC also has no knowledge of the switch or its IP address, so any means other than a Layer 2 protocol is not possible. This is why the PC also must have an 802.1x-capable application or client software.

An 802.1x switch port begins in the unauthorized state so that no data other than the 802.1x protocol itself is allowed through the port. Either the client or the switch can initiate an 802.1x session. The authorized state of the port ends when the user logs out, causing the 802.1x client to inform the switch to revert back to the unauthorized state. The switch also can time out the user's authorized session. In this event, the client must reauthenticate to continue using the switch port.

802.1x Configuration

Port-based authentication uses a variety of methods to authenticate potential clients. A method list is configured, defining the methods to be tried in sequence. Begin by configuring an 802.1x method list with the following global configuration command:

Switch(config)# aaa authentication dot1x {default | list-name} method1 [method2 ...]

Be sure that the aaa new-model command already has been configured. Here, a method is defined by one of the following keywords:

• group {group-name | radius | tacacs+} Authentication servers are used to authenticate the user. These are configured as the group group-name. Otherwise, all the available RADIUS or TACACS+ servers are tried. These servers are configured exactly the same as with the AAA feature.

• enable The enable password authenticates the user.

• line The line password authenticates the user. This applies only when 802.1x is being used on a switch line (console or vty).

• local The locally defined usernames and passwords are used to authenticate the user.

• none No authentication is performed.

If RADIUS or TACACS+ servers are used as a method, including one of the local methods at the end of the line is wise. This gives a predictable last-resort method if all the authentication servers are unavailable. Otherwise, users or support staff could be locked out of the switch.

Next, enable the use of 802.1x on the switch with the following global configuration command:

Switch(config)# dot1x system-auth-control

You must configure each switch port that will use 802.1x. Use the following interface-configuration command to set the authentication state:

Switch(config-if)# dot1x port-control {force-authorized | force-unauthorized | auto}

Here, the 802.1x state is one of the following:

• force-authorized The port is forced to always authorize any connected client. No authentication is necessary. This is the default state for all switch ports when 802.1x is enabled.

• force-unauthorized The port is forced to never authorize any connected client. As a result, the port cannot move to the authorized state to pass traffic to a connected client.

• auto The port uses an 802.1x exchange to move from the unauthorized to the authorized state, if successful. This requires an 802.1x-capable application on the client PC.

It might be obvious that port-based authentication is tailored to controlling access to a single host PC that is connected to a switch port. However, it also supports cases in which multiple hosts are attached to a single switch port through an Ethernet hub or another access-layer switch.

If the switch should expect to find multiple hosts present on the switch port, use the following interface-configuration command:

Switch(config-if)# dot1x multi-hosts

Mitigating Spoofing Attacks

Malicious users sometimes can send spoofed information to trick switches or other hosts into using a rogue machine as a gateway. The attacker's goal is to become the "man-in-the-middle," with a naïve user sending packets to the attacker as if it were a router. The attacker can glean information from the packets sent to it before it forwards them normally. This section describes two Cisco Catalyst featuresDHCP snooping and dynamic ARP inspectionthat prevent certain types of spoofing attack.

DHCP Snooping

A DHCP server normally provides all the basic information a client PC needs to operate on a network. For example, the client might receive an IP address, a subnet mask, a default gateway address, DNS addresses, and so on.

Suppose that an attacker could bring up a rogue DHCP server on a machine in the same subnet as that same client PC. Now when the client broadcast its DHCP request, the rogue server could send a carefully crafted DHCP reply with its own IP address substituted as the default gateway.

When the client receives the reply, it begins using the spoofed gateway address. Packets destined for addresses outside the local subnet then go to the attacker's machine first. The attacker can forward the packets to the correct destination, but in the meantime, it can examine every packet that it intercepts. In effect, this becomes a type of man-in-the-middle attack; the attacker is wedged into the path and the client doesn't realize it.

Cisco Catalyst switches can use the DHCP snooping feature to help mitigate this type of attack. When DHCP snooping is enabled, switch ports are categorized as trusted or untrusted. Legitimate DHCP servers can be found on trusted ports, while all other hosts sit behind untrusted ports.

A switch intercepts all DHCP requests coming from untrusted ports before flooding them throughout the VLAN. Any DHCP replies coming from an untrusted port are discarded because they must have come from a rogue DHCP server. In addition, the offending switch port automatically is shut down in the errdisable state.

DHCP snooping also keeps track of the completed DHCP bindings as clients receive legitimate replies. This database contains the client MAC address, IP address offered, lease time, and so on.

You can configure DHCP snooping first by enabling it globally on a switch with the following configuration command:

Switch(config)# ip dhcp snooping

Next identify the VLANs where DHCP snooping should be implemented with the following command:

Switch(config)# ip dhcp snooping vlan vlan-id [vlan-id]

You can give a single VLAN number as vlan-id or a range of VLAN numbers by giving the start and end VLAN IDs of the range.

By default, all switch ports are assumed to be untrusted so that DHCP replies are not expected or permitted. Only trusted ports are allowed to send DHCP replies. Therefore, you should identify only the ports where known, trusted DHCP servers are located. You can do this with the following interface-configuration command:

Switch(config)# interface type mod/num Switch(config-if)# ip dhcp snooping trust

For untrusted ports, an unlimited rate of DHCP requests is accepted. If you want to rate-limit DHCP traffic on an untrusted port, use the following interface-configuration command:

Switch(config)# interface type mod/num Switch(config-if)# ip dhcp snooping limit rate rate

The rate can be 1 to 2048 DHCP packets per second.

You also can configure the switch to use DHCP option-82, the DHCP Relay Agent Information option, which is described in RFC 3046. When a DHCP request is intercepted on an untrusted port, the switch adds its own MAC address and the switch port identifier into the option-82 field of the request. The request then is forwarded normally so that it can reach a trusted DHCP server.

Adding option-82 provides more information about the actual client that generated the DHCP request. In addition, the DHCP reply (if any) echoes back the option-82 information. The switch intercepts the reply and compares the option-82 data to confirm that the request came from a valid port on itself. This feature is enabled by default. You can enable or disable option-82 globally with the following configuration command:

Switch(config)# [no] ip dhcp snooping information option

When DHCP snooping is configured, you can display its status with the following command:

Switch# show ip dhcp snooping [binding]

Using the binding keyword results in a display of all the known DHCP bindings that have been overheard. The switch maintains these in its own database. Otherwise, only the switch ports that are trusted or that have rate limiting applied are listed. All other ports are considered to be untrusted with an unlimited DHCP request rate.

As an example, interfaces FastEthernet 0/35 and 0/36 use access VLAN 104, are considered untrusted, and have DHCP rate limiting applied at three per second. A known DHCP server is located on the GigabitEthernet 0/1 uplink. Example 17-4 shows the configuration for this scenario.

Example 17-4. DHCP Snooping Configuration

Switch(config)# ip dhcp snooping Switch(config)# ip dhcp snooping vlan 104 Switch(config)# interface range fastethernet 0/35 - 36 Switch(config-if)# ip dhcp snooping limit rate 3 Switch(config-if)# interface gigabitethernet 0/1 Switch(config-if)# ip dhcp snooping trust

Example 17-5 shows the resulting DHCP snooping status.

Example 17-5. DHCP Snooping Status Display

Switch# show ip dhcp snooping Switch DHCP snooping is enabled DHCP snooping is configured on following VLANs: 104 Insertion of option 82 is enabled Interface               Trusted         Rate limit (pps) -------------------     -------         ---------------- FastEthernet0/35        no              3 FastEthernet0/36        no              3 GigabitEthernet0/1      yes             unlimited Switch#

Dynamic ARP Inspection

Hosts normally use the Address Resolution Protocol (ARP) to resolve an unknown MAC address when the IP address is known. If a MAC address is needed so that a packet can be forwarded at Layer 2, a host broadcasts an ARP request that contains the IP address of the target in question. If any other host is using that IP address, it responds with an ARP reply containing its MAC address. The ARP process works well among trusted and well-behaved users. However, suppose that an attacker could send its own crafted ARP reply when it overhears an ARP request being broadcast. The reply could contain its own MAC address, causing the original requester to think that it is bound to the IP address in question. The requester would add the bogus ARP entry into its own ARP cache, only to begin forwarding packets to the spoofed MAC address.

In effect, this scheme places the attacker's machine right in the middle of an otherwise legitimate path. Packets will be sent to the attacker instead of another host or the default gateway. The attacker will be able to intercept packets and (perhaps) will forward them on only after examining the packets' contents.

This attack is known as ARP poisoning or ARP spoofing, and it is considered to be a type of man-in-the-middle attack. The attacker wedges into the normal forwarding path, transparent to the end users. Cisco Catalyst switches can use the dynamic ARP inspection (DAI) feature to help mitigate this type of attack.

DAI works much like DHCP snooping. All switch ports are classified as trusted or untrusted. The switch intercepts and inspects all ARP packets that arrive on an untrusted port; no inspection is done on trusted ports.

When an ARP reply is received on an untrusted port, the switch checks the MAC and IP addresses reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured entries or from dynamic entries in the DHCP snooping database. In the latter case, DHCP snooping must be enabled in addition to DAI.

If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log message is generated. This action prevents invalid or spoofed ARP entries from being sent and added to other machines' ARP caches.

You can configure DAI by first enabling it on one or more client VLANs with the following configuration command:

Switch(config)# ip arp inspection vlan vlan-range

The VLAN range can be a single VLAN ID, a range of VLAN IDs separated by a hyphen, or a list of VLAN IDs separated by commas.

By default, all switch ports associated with the VLAN range are considered to be untrusted. You should identify trusted ports as those that connect to other switches. In other words, the local switch will not inspect ARP packets arriving on trusted ports; it will assume that the neighboring switch also is performing DAI on all of its ports in that VLAN. Configure a trusted port with the following interface-configuration command:

Switch(config)# interface type mod/num Switch(config-if)# ip arp inspection trust

If you have hosts with statically configured IP address information, there will be no DHCP message exchange that can be inspected. Instead, you can configure an ARP access list that defines static MAC-IP address bindings that are permitted. Use the following configuration commands to define the ARP access list and one or more static entries:

Switch(config)# arp access-list acl-name Switch(config-acl)# permit ip host sender-ip mac host sender-mac [log] [Repeat the previous command as needed] Switch(config-acl)# exit

Now the ARP access list must be applied to DAI with the following configuration command:

Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]

When ARP replies are intercepted, their contents are matched against the access list entries first. If no match is found, the DHCP snooping bindings database is checked next. You can give the static keyword to prevent the DHCP bindings database from being checked at all. In effect, this creates an implicit deny statement at the end of the ARP access list; if no match is found in the access list, the ARP reply is considered to be invalid.

Finally, you can specify further validations on the contents of ARP reply packets. By default, only the MAC and IP addresses contained within the ARP reply are validated. This doesn't take the actual MAC addresses contained in the Ethernet header of the ARP reply.

To validate that an ARP reply packet is really coming from the address listed inside it, you can enable DAI validation with the following configuration command:

Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Be sure to specify at least one of the options:

• src-mac Check the source MAC address in the Ethernet header against the sender MAC address in the ARP reply.

• dst-mac Check the destination MAC address in the Ethernet header against the target MAC address in the ARP reply.

• ip Check the sender's IP address in all ARP requests; check the sender's IP address against the target IP address in all ARP replies.

Example 17-6 demonstrates where DAI is enabled for all switch ports associated with VLAN 104 on an access-layer switch. The uplink to a distribution switch is considered to be trusted.

Example 17-6. Configuring DAI to Validate ARP Replies

Switch(config)# ip arp inspection vlan 104 Switch(config)# arp access-list StaticARP Switch(config-acl)# permit ip host 192.168.1.10 mac host 0006.5b02.a841 Switch(config-acl)# exit Switch(config)# ip arp inspection filter StaticARP vlan 104 Switch(config)# interface gigabitethernet 0/1 Switch(config-if)# ip arp inspection trust

You can display DAI status information with the show ip arp inspection command.

Best Practices for Securing Switches

You can configure and use many different features on Cisco Catalyst switches. You should be aware of some common weaknesses that can be exploited. In other words, don't become complacent and assume that everyone connected to your network will be good citizens and play by the rules. Think ahead and try to prevent as many things as possible that might be leveraged to assist an attacker.

This section presents a brief overview of many best-practice suggestions that will help secure your switched network.

• Configure secure passwords Whenever possible, you should use the enable secret command to set the privileged-level password on a switch. This command uses a stronger encryption than the normal enable password command and stores the password in a secure location in NVRAM.

  You also should use external AAA servers to authenticate administrative users whenever possible. The usernames and passwords are maintained externally, so they are not stored or managed directly on the switch. In addition, having a centralized user management is much more scalable than configuring and changing user credentials on many individual switches and routers.

  Finally, you always should use the service password-encryption configuration command to automatically encrypt password strings that are stored in the switch configuration. Although the encryption is not strong, it can prevent casual observers from seeing passwords in the clear.

• Use system banners When users successfully access a switch, they should be aware of any specific access or acceptable use policies that are pertinent to your organization. You should configure system banners so that this type of information is displayed right when users log in to a switch. The idea is to warn unauthorized users (if they gain access) that their activities could be grounds for prosecutionor that they are unwelcome, at the very least.

  You should use the banner motd command to define the text that is displayed to authenticated users. Try to avoid using other banner types that display information about your organization or the switch before users actually log in. Never divulge any extra information about your network that malicious users could use.

• Disable unnecessary or insecure services Cisco devices sometimes have unused or unnecessary services enabled by default. To tighten security, you should allow only the services, features, and protocols that are needed for your infrastructure. Anything more than that can become a potential weakness that could be exploited.

  For example, you should strongly consider disabling the HTTP server on a Catalyst switch. This often is used for a web-based switch-management tool but is usually unneeded in a production environment. You can disable it with the no ip http server configuration command.

  Although Cisco IOS Software releases have begun to disable other uncommon services as the default, you should make sure that none of the following commands is present in your switch configuration:

  service tcp-small-servers service udp-small-servers service finger service config

  
  

  If any of these commands are present, disable them by preceding them with the no keyword.

• Secure the switch console In many environments, switches are locked away in wiring closets where physical security is used to keep people from connecting to the switch console. Even so, you always should configure authentication on any switch console. It is usually appropriate to use the same authentication configuration on the console as the virtual terminal (vty) lines.

• Secure virtual terminal access You always should configure user authentication on all of the vty lines on a switch. In addition, you should use access lists to limit the source IP addresses of potential administrative users who try to use Telnet or Secure Shell (SSH) to access a switch.

  You can use a simple IP access list to permit inbound connections only from known source addresses, as in the following example:

  Switch(config)# access-list 10 permit 192.168.199.10 Switch(config)# access-list 10 permit 192.168.201.100 Switch(config)# line vty 0 15 Switch(config-line)# access-class 10 in

  
  

  Be sure you apply the access list to all the line vty entries in the switch configuration. Many times, the vty lines are separated into groups in the configuration. You can use the show user all command to see every possible line that can be used to access a switch.

• Use SSH whenever possible Although Telnet access is easy to configure and use, Telnet is not secure. Every character you type in a Telnet session is sent to and echoed from a switch in the clear, with no encryption. Therefore, it is very easy to eavesdrop on Telnet sessions to overhear usernames and passwords.

  Instead, you should use SSH whenever possible. SSH uses strong encryption to secure session data. Therefore, you need a strong-encryption IOS image running on a switch before SSH can be configured and used. You should use the highest SSH version that is available on a switch. The early SSHv1 and SSHv1.5 have some weaknesses. SSHv2 is better yet but is available only in recent IOS releases, such as 12.2(25)SEB1 on the Catalyst 3750.

• Secure SNMP access To prevent unauthorized users from making changes to a switch configuration, you should disable any read-write SNMP access. These are commands of the form snmp-server community string RW.

  Instead, you should have only read-only commands in the configuration. In addition, you should use access lists to limit the source addresses that have read-only access. Don't depend on the SNMP community strings for security because these are passed in the clear in SNMP packets.

• Secure unused switch ports Every unused switch port should be disabled so that unexpected users can't connect and use them without your knowledge. You can do this with the shutdown interface-configuration command.

  In addition, you should configure every user port as an access port with the switchport mode access interface-configuration command. Otherwise, a malicious user might connect and attempt to negotiate trunking mode on a port. You also should consider associating every unused access port with a bogus or isolated VLAN. If an unexpected user does gain access to a port, he will have access only to a VLAN that is isolated from every other resource on your network.

  Tip

  You might consider using the switchport host interface-configuration command as a quick way to force a port to support only a single PC. This command is actually a macro, as seen in the following example:

  Switch(config)# interface fastethernet 1/0/1 Switch(config-if)# switchport host switchport mode will be set to access spanning-tree portfast will be enabled channel group will be disabled Switch(config-if)#

  
  
  
  

• Secure STP operation A malicious user can inject STP bridge protocol data units (BPDUs) into switch ports or VLANs, and can disrupt a stable, loop-free topology. You always should enable the BPDU guard feature so that access switch ports automatically are disabled if unexpected BPDUs are received.

• Secure the Use of CDP By default, CDP advertisements are sent on every switch port at 60-second intervals. Although CDP is a very handy tool for discovering neighboring Cisco devices, you shouldn't allow CDP to advertise unnecessary information about your switch to listening attackers.

For example, the following information is sent in a CDP advertisement in the clear. An attacker might be able to use the device ID to physically locate the switch, its IP address to target Telnet or SNMP attacks, or the native VLAN and switch port ID to attempt a VLAN hopping attack.

CDP - Cisco Discovery Protocol   Version:         2   Time to live:    180 seconds   Checksum:        0xD0AE   Device ID:       BldgA-Rm110   Version:         Cisco Internetwork Operating System Software .IOS (tm) C3750 Software (C3750-I9-M), Version 12.2(20)SE4, RELEASE SOFTWARE (fc1).Copyright 1986-2005 by cisco Systems, Inc..Compiled Sun 09-Jan-05 00:09 by antonino   Platform:        cisco WS-C3750-48P   IP Address:      192.168.100.85   Port ID:         FastEthernet1/0/48   Capabilities:    0x00000028 Switch IGMP   VTP Domain:      MyCompany   Native VLAN:     101   Duplex:          0x01 Full

CDP should be enabled only on switch ports that connect to other trusted Cisco devices. Don't forget that CDP must be enabled on access switch ports where Cisco IP Phones are connected. When the CDP messages reach the IP Phone, they won't be relayed on to a PC connected to the phone's data port. You can disable CDP on a port-by-port basis with the no cdp enable interface-configuration command.