Securing Network Switches
Each switch in the network provides a variety of services that span beyond frame switching. These services range from management web interface, Cisco Discovery Protocol (CDP) neighbor discovery, to Telnet and preconfigured ports. Several of these services can be enabled by default to facilitate the switch initial integration into the network infrastructure. Some services might need to stay enabled, whereas others should be disabled when the integration is complete and if they are not needed. This section describes how to secure Layer 2 devices by protecting physical and virtual ports, disabling unneeded services, forcing the encryption of sessions, and enabling logging at the device level.
Neighbor Discovery Protocols
Neighbor Discovery Protocols (NDP) provide a summary of directly connected switches, routers, and other Cisco devices, as shown in Figure 6-25. CDP is the more commonly deployed NDP Layer 2 protocol enabled by default. The Link Layer Discovery Protocol (LLDP) is a vendor-neutral Layer 2 protocol equivalent to Cisco Discovery Protocol (CDP) that enables a network device to advertise its identity and capabilities on the local network. The protocol has been formally ratified as IEEE standard 802.1AB in 2005 and is also supported on Cisco devices. LLDP is disabled by default on Cisco devices.
Cisco Discovery Protocol
Cisco Discovery Protocol (CDP) is a hello-based protocol, and all Cisco devices that run CDP periodically advertise their attributes to their neighbors by using a multicast address. CDP packets advertise a Time-To-Live (TTL) value in seconds, which indicates the length of time to retain the packet before discarding it. Cisco devices send CDP packets with a TTL value that is not 0 after an interface is enabled. A TTL value of 0 is sent immediately before an interface is idled. Sending a CDP packet with a TTL value of 0 enables a network device to quickly discover a lost neighbor.
By default, all Cisco devices receive CDP packets and cache the information in the packet. The cached information is then available to an NMS using SNMP.
If any information changes from the last received packet, the device caches the new information and discards the previous information even if its TTL value has not yet expired.
For security reasons, you should block SNMP access to CDP data (or any other data) from outside your network and from subnets other than your management station subnet.
Configuring CDP
- no cdp run disables CDP globally.
- no cdp enable disables CDP on an interface.
When CDP is enabled the command show cdp neighbor displays a summary of which devices are seen on which ports, as shown in Example 6-12. You can get more detailed information about all neighbors with the command show cdp neighbor detail, as shown in Example 6-13.
Example 6-12: Displaying CDP Information
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
c2960-8 Fas 0/8 168 S I WS-C2960-Fas 0/8
Example 6-13: Displaying Detailed CDP Information About Neighboring Cisco Devices
-----------------------
Device ID: TBA03501074(SwitchA-6500)
Entry address(es):
IP address: 10.18.2.137
Platform: WS-C6506, Capabilities: Trans-Bridge Switch IGMP
Interface: FastEthernet3/21, Port ID (outgoing port): 3/36
Holdtime : 170 sec
Version :
WS-C6506 Software, Version McpSW: 7.6(1) NmpSW: 7.6(1)
Copyright © 1995-2003 by Cisco Systems
advertisement version: 2
VTP Management Domain: '0'
Native VLAN: 1
Duplex: full
-----------------------
Device ID: SwitchC-4503
Entry address(es):
IP address: 10.18.2.132
Platform: cisco WS-C4503, Capabilities: Router Switch IGMP
Interface: FastEthernet3/27, Port ID (outgoing port): FastEthernet3/14
Holdtime : 130 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-I5S-M), Version 12.1(19)EW,
CISCO ENHANCED PRODUCTION VERSION
Copyright © 1986-2003 by cisco Systems, Inc.
Compiled Tue 27-May-03 04:31 by prothero
advertisement version: 2
VTP Management Domain: 'cisco'
Native VLAN: 1
Duplex: full
Configuring LLDP
- lldp run enables LLDP globally.
- lldp enable enables LLDP on an interface.
Just like CDP, when LLDP is enabled the command show lldp neighbor displays a summary of which devices are seen on which ports, as shown in Example 6-14. You can get more detailed information about all neighbors with the command show lldp neighbor detail. If you need detailed information about only one neighbor on one link, you can also use (for example) show lldp neighbor interface f0/8 detail.
Example 6-14: Configuring and Displaying LLDP Neighbors
switch(config)# end
switch# show lldp neighbor
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
c2960-8 Fa0/8 120 B Fa0/8
Total entries displayed: 1
CDP Vulnerabilities
Attackers with knowledge of how CDP works could find ways to take advantage of the clear-text CDP packets to gain knowledge of the network, as shown in Figure 6-26. The CDP runs at Layer 2 and enables Cisco devices to identify themselves to other Cisco devices. However, the information sent through CDP is transmitted in clear text and is unauthenticated. Utilizing a packet analyzer, attackers could glean information about the network device from CDP advertisements.
CDP is necessary for management applications such as the Cisco Works-LAN Management Suite (LMS) and cannot be disabled without impairing some network-management applications. However, CDP can be selectively disabled on interfaces where management is not being performed.
Table 6-7 describes how CDP can be used maliciously.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Open table as spreadsheet Securing Switch Access
Network administrators typically use telnet to access switches. But nowadays, SSH is becoming standard in enterprises due to stricter requirements for security. Similarly, accessing devices via HTTP is being replaced with secure HTTPS.
Telnet Vulnerabilities
Telnet is not a secure protocol and has vulnerabilities as follows:
- All usernames, passwords, and data sent over the public network in clear text are vulnerable, as shown in Figure 6-27.
- A user with an account on the system could gain elevated privileges.
- A remote attacker could crash the Telnet service, preventing legitimate use of that service by performing a DoS attack such as opening too many bogus Telnet sessions.
- A remote attacker could find an enabled guest account that might be present anywhere within the trusted domains of the server.
Telnet is being replaced by SSH, which is more secure, and ACL should be configured to restrict access only to authorized users accessing the device through VTY line ACL. Both of these topics are explained in the following sections.
Secure Shell
SSH is a client and server protocol used to log in to another computer over a network to execute commands in a remote machine and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. It is a replacement for rlogin, rsh, rcp, and rdist in addition to Telnet.
When using the SSH login (instead of Telnet), the entire login session, including transmission of password, is encrypted, as shown in Figure 6-28; therefore, it is almost impossible for an outsider to collect passwords.
Although SSH is secure, vendors’ implementations of SSH might contain vulnerabilities that could enable a remote attacker to execute arbitrary code with the privileges of the SSH process or to cause a DoS. Most of the SSH vulnerabilities have been addressed in the latest Cisco IOS Software.
| Note |
|
To activate SSH on a vty interface, use the transport input ssh command.
SSH configuration on an IOS switch is done with the following steps:
|
|
|
|
|
|
|
|
|
|
|
|
Example 6-15 shows a configuration commands required for configuring SSH.
Example 6-15: SSH Configuration
switch(config)# ip domain-name xyz.com
switch(config)# crypto key generate rsa
switch(config)# ip ssh version 2
switch(config)# line vty 0 15
switch(config-line)# login local
switch(config-line)# transport input ssh
VTY ACLs
Cisco provides ACLs to permit or deny Telnet/SSH access to the vty ports of a switch. Cisco devices vary in the number of vty ports available by default. When configuring vty ACLs, ensure that all default ports are removed or have a specific vty ACL applied.
Telnet/SSH filtering is normally considered an extended IP ACL function because it is filtering a higher-level protocol. However, because the access-class command is used to filter incoming Telnet/SSH sessions by source address and to apply filtering to vty lines, standard IP ACL statements can be used to control vty access. The access-class command also applies standard IP ACL filtering to vty lines for outgoing Telnet/SSH sessions that originate from the switch.
You can apply vty ACLs to any combination of vty lines. The same ACL can be applied globally to all vty lines or separately to each vty line. The most common practice is to apply the same ACL to all vty lines.
To configure vty ACLs on a Cisco switch, create a standard IP ACL and apply the ACL on the vty interfaces. Rather than applying the ACL to a data interface, apply it to a vty line or range of lines with the access-class command, as shown in Figure 6-29.
HTTP Secure Server
A web interface is available to configure most switches. The main weakness of the web interface is that it is not encrypted, and part of it does not offer any filtering. By default, it can be viewed by any user entering the switch IP address in a web browser address bar.
To protect the web service, you can take several steps:
- Use HTTPS instead of unprotected HTTP by using the command ip http secure-server instead of the ip http server command.
- To use HTTPS, the web server residing on the switch needs to send a certificate. This certificate can be downloaded to the switch if the network uses a Public Key Infrastructure (PKI), a key management infrastructure, or is generated on the switch locally with the command crypto key generate rsa. A domain name must be defined to generate a certificate.
- Access to the web service should be filtered so that only the administrator machine or subnet can gain access to the web interface. This is done by creating an access list. In this example, machines on subnet 10.1.9.0/24 have the right to access any IP address of the Layer 3 switch. The access list filter is then applied to the web service with the command http access-class.
- Users accessing the web service might use it to configure the switch. These users should be authenticated. The http authentication local command decides that the switch contains a local list of user credentials. The username xyz password abc123 creates a local user.
Following are the configurations steps for enabling HTTP access:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example 6-16 shows configuration of HTTPS on a switch.
Example 6-16: HTTPS Configuration
sw(config)# username xyz password abc123
sw(config)# ip domain-name xyz.com
sw(config)# crypto key generate rsa
sw(config)# no ip http server
sw(config)# ip http secure-server
sw(config)# http access-class 100 in
sw(config)# http authentication local
Authentication Authorization Accounting (AAA)
The AAA network-security services provide the primary framework through which you set up access control on a Cisco IOS switch, as shown in Figure 6-30. AAA is an architectural framework for configuring a set of three independent security functions in a consistent manner.
AAA provides a modular way of performing the following services:
- Authentication
- Authorization
- Accounting
| Note |
|
Authentication
Authentication provides a method for handling the following:
- User identification
- Login and password dialog
- Challenge and response
- Messaging
- Encryption
Authentication identifies users prior to accessing the network and network services. AAA configures authentication by defining a named list of authentication methods and then applying that list to various interfaces. The method list defines the types of authentication performed and their sequence. These methods are applicable on a per-interface basis. However, all interfaces on Cisco routers and switches adhere to a default method list named Default when no other authentication methods are defined. A defined method list always overrides the default method list.
All authentication methods, except for local, line password, and enable authentication, require the use of AAA.
Authorization
Authorization provides the method for remote access control. This remote access control includes one-time authorization or authorization for each service on a per-user account list or a user group basis.
The AAA authorization process on switches or routers works by contacting a common, centralized database of a set of attributes that describe the network user’s authorized services, such as access to different parts of the network. The centralized server returns a result of allowed services to the switch or router in question to execute the user’s actual capabilities and restrictions. This database is generally a centrally located server, such as a RADIUS or TACACS+ security server. However, using a local database is possible. The remote security servers, such as RADIUS and TACACS+, authorize users for specific rights by associating their attribute-value pairs (AVP). TACACS+ and RADIUS use these AVPs for configurations that are applied to users or a group of users. Each AVP consists of a type identifier associated with one or more assignable values. AVPs specified in user and group profiles define the authentication and authorization characteristics for their respective users and groups.
For example, with TACACS+ authorization, an AVP of Outacl=10 applies the out ACL 10 to a user; the AVP of Idletime=30 sets an idle timeout value for a user to 30 minutes.
AVPs are usually in the form a=b or a*b, in which a is the attribute and b is the value. The = separator indicates that the AVP is mandatory. The * separator indicates that the AV pair is optional. Table 6-8 and Table 6-9 illustrate examples of RADIUS AVPs and TACACS+ AVPs, respectively.
|
| |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All authorization methods require the use of AAA. As with authentication, AAA authorization is applicable on a per-interface basis.
Accounting
Accounting provides the method for collecting and sending security server information used for billing, auditing, and reporting. This type of information includes user identities, network access start and stop times, executed commands (such as PPP), number of packets, and number of bytes. This information is useful for auditing and improving security as each switch or router monitors each user.
In many circumstances, AAA uses protocols such as RADIUS, TACACS+, or 802.1X to administer its security functions. If your switch is acting as a network access server, AAA is the means through which a switch establishes communication between your network access server and your RADIUS, TACACS+, or 802.1X security server.
AAA is dynamic in that it enables configuration of authentication and authorization on a per-line (per-user) or per-service (for example, IP, IPX, or virtual private dial-up network [VPDN]) basis. Creating method lists and then applying those method lists to specific services or interfaces achieves the per-line or per-user application.
Configuring AAA Authentication
The AAA security services facilitate a variety of login authentication methods. Before configuring any AAA security, use the aaa new-model command to initialize a AAA access control model on Cisco IOS switches or routers. Furthermore, use the aaa authentication login command to enable AAA login authentication in Cisco IOS. With the aaa authentication login command, configure one or more lists of authentication methods that each switch or router tries per user during login. These lists are configurable using the following Cisco IOS configuration commands:
login authentication line {default | list-name} method1 [method2...]
list-name defines the list name, whereas method1 [method2...] defines the authentication methods in order, such as TACACS+ or RADIUS. list-name is case-sensitive, as with any other Cisco named lists.
To apply the authentication list to an input line, use the following line command:
login authentication {default | list-name}
Example 6-17 illustrates configuring of the VTY terminals in Cisco IOS for TACACS+ authentication as the first method. The second method, local login, occurs when the TACACS+ server is unreachable.
Example 6-17: Example of Configuring AAA Authentication in Cisco IOS
Switch(config)# aaa authentication login TEST tacacs+
Switch(config)# tacacs-server host 192.168.100.100
Switch(config)# line vty 0 4
Switch(config-line)# login authentication TEST
First-time users of AAA might find the configuration daunting. With some practice, though, configuring AAA becomes fairly simple. When configuring AAA, always use a console connection to avoid locking yourself out of the router or switch through misconfiguration. To illustrate the simplicity of configuring AAA, the following example presents a step approach to configuring AAA for authentication using TACACS+ on a Catalyst 3750 running Cisco IOS:
For more information on Authentication, Authorization and Accounting, refer to the following URL on Cisco.com:
- www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html
For more information about RADIUS, TACACS+, refer to the following URL:
- www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml
For more information about 802.1x, refer to the following URL:
- www.cisco.com/en/US/products/ps6662/products_ios_protocol_option_home.html
Configuring AAA Authorization
Switches and routers use AAA authorization to limit the services that are available to specific users. AAA authorization uses information retrieved from the user’s profile, which is located either in the local user database on the switch or on the security server, to configure the user’s session. Afterward, the switch or router grants access to services requested by the user only if the information in the user profile allows for it. These services include the ability to execute commands, use network access such as PPP, or enter configuration options.
In addition, you should create method lists, which are similar to the AAA authentication configuration, to define authorizations. Method lists are specific to the authorization type requested. The following options are available for AAA authorization:
- Auth-proxy: Applies security policies on a per-user basis. With the use of auth-proxy, each user brings up a web browser to authenticate to a TACACS+ or RADIUS server before accessing the network. Upon successful authentication, the authentication server passes additional ACL entries and profile information to the router or switch to enable the users into the network.
- Commands: Applies authorization to all EXEC commands, including configuration commands associated with a specific privilege level. An example is limiting network operation users to only show commands when accessing switches and routers in the enterprise network for normal operations.
- EXEC: Refers to the attributes associated with a user EXEC terminal session.
- Network: Applies to the types of network connections. An example of using network authorization is authorization granting remote users access to network protocols such as PPP, SLIP, or ARAP during login for remote access.
- Reverse access: Refers to reverse Telnet sessions commonly used on console servers for access to different lines.
Similar to the configuration of AAA authentication, AAA authorization uses named method lists in its configuration. AAA supports the following five different methods of authorization:
- TACACS+: A client/server method that stores specific rights for users by associating AVPs for each user. The AAA authorization daemon on the Cisco switch or router communicates with the TACACS+ server to determine correct authorization for different options, such as EXEC and network access.
- RADIUS: Similar to TACACS+ in that RADIUS is also a server/client model for a Cisco router or switch to request authorization about a specific user. RADIUS servers store specific rights about users by associating specific attributes.
- If-authenticated: Enables a user to access any requested function as long as the AAA daemon previously and successfully authenticated the user.
- None: Effectively disables authorization for the respective interface.
- Local: Uses a database of usernames and passwords configured on the respective switch or router. Local databases on Cisco IOS routers and switches configure using the username command and enable only a subset of feature-controlled functions.
To configure AAA authorization using named method lists, use the following commands in the global and interface configuration modes, respectively:
aaa authorization {auth-proxy | network | exec | commands level | reverse-
access | configuration | ipmobile} {default | list-name} [method1
[method2...]] authorization {arap | commands level | exec | reverse-access}
{de fault | list-name}
To have the multilayer switch request authorization information via a TACACS+ security server, use the aaa authorization command with the group tacacs+ method keyword. The group tacacs+ method instructs the switch to use a list of all TACACS+ servers for authentication; refer to the Cisco IOS command reference for AAA on the Cisco.com website for additional methods. To allow users to access the functions they request as long as they have been authenticated, use the aaa authorization command with the if-authenticated method keyword. If you select this method, all requested functions are automatically granted to authenticated users.
To select local authorization, which means that the router or access server consults its local user database to determine which functions a user is permitted to use, use the aaa authorization command with the local method keyword. The functions associated with local authorization are defined by using the username global configuration command. To have the network access server request authorization via a list of RADIUS security servers, use the aaa authorization command with the group radius method keyword. Example 6-18 illustrates configuring AAA authorization for users via VTY access for shell commands.
Example 6-18: Configuring AAA Authorization in Cisco IOS
Switch(config)# aaa authorization commands 0 default if-authenticated group tacacs+
Switch(config)# line vty 0 4
Switch(config-line)# authorization commands 0 default
Configuring AAA Accounting
AAA supports the following six different accounting types:
- Network accounting: Provides information for all PPP, SLIP, or ARAP sessions, including packet and byte counts.
- Connection accounting: Provides information about all outbound connections made from the network, such as Telnet and rlogin.
- EXEC accounting: Provides information about user EXEC terminal sessions (user shells) on the network access server, including username, date, start and stop times, the access server IP address, and (for dial-in users) the telephone number from which the call originated.
- System accounting: Provides information about all system-level events (for example, when the system reboots and when accounting is turned on or off).
- Command accounting: Provides information about the EXEC shell commands for a specified privilege level executed on a network access server.
- Resource accounting: Provides start and stop record support for calls that have passed user authentication.
To configure AAA accounting in Cisco IOS, first configure the global accounting method list and enable accounting using the following command:
aaa accounting {system | network | exec | connection | commands level}
{default | list-name} {start-stop | stop-only | none} [method1 [method2...]]
Second, apply the accounting method to an interface or line using the following command:
accounting {arap | commands level | connection | exec} {default | list-name}
Example 6-19 illustrates configuring accounting on the vty lines.
Security Using IEEE 802.1X Port-Based Authentication
The IEEE 802.1X standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports, as shown in Figure 6-31. The authentication server authenticates each workstation that is connected to a switch port before making available any services offered by the switch or the LAN.
Until the workstation is authenticated, 802.1X access control enable only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the workstation is connected. After authentication succeeds, normal traffic can pass through the port.
With 802.1X port-based authentication, the devices in the network have specific roles, as follows:
- Client: The device (workstation) that requests access to LAN and switch services and then responds to requests from the switch. The workstation must be running 802.1X-compliant client software, such as what is offered in the Microsoft Windows XP operating system. (The port that the client is attached to is the supplicant [client] in the IEEE 802.1X specification.)
- Authentication server: Performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. The RADIUS security system with Extensible Authentication Protocol (EAP) extensions is the only supported authentication server.
- Switch (also called the authenticator): Controls physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client (supplicant) and the authentication server, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch uses a RADIUS software agent, which is responsible for encapsulating and decapsulating the EAP frames and interacting with the authentication server.
The switch port state determines whether the client is granted access to the network. When configured for 802.1X port-based authentication, the port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic except for 802.1X protocol packets. When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally.
If the switch requests the client identity (authenticator initiation) and the client does not support 802.1X, the port remains in the unauthorized state, and the client is not granted access to the network.
In contrast, when an 802.1X-enabled client connects to a port and the client initiates the authentication process (supplicant initiation) by sending the EAPOL-start frame to a switch that is not running the 802.1X protocol, no response is received, and the client begins sending frames as if the port is in the authorized state.
You control the port authorization state by using the dot1x port-control interface configuration command:
dot1x port-control {auto | force-authorized | force-unauthorized}
The following is an explanation of the keywords:
- force-authorized: Disables 802.1X port-based authentication and causes the port to transition to the authorized state without any authentication exchange required. The port transmits and receives normal traffic without 802.1X-based authentication of the client. This is the default setting. This configuration mode supports any non-dot1x-enabled client.
- force-unauthorized: Causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the interface. This configuration mode can be enabled to prevent connections from any users from unauthorized ports.
- auto: Enables 802.1X port-based authentication and causes the port to begin in the unauthorized state, enabling only EAPOL frames to be sent and received through the port. The authentication process begins when the link state of the port transitions from down to up (authenticator initiation) or when an EAPOL-start frame is received (supplicant initiation). The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. The switch uniquely identifies each client attempting to access the network by using the client MAC address. This configuration mode can be used on ports that connect to a 802.1X client.
If the client is successfully authenticated (receives an “accept” frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are enabled through the port.
If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can retransmit the request. If no response is received from the server after the specified number of attempts, authentication fails, and network access is not granted.
When a client logs out, it sends an EAPOL-logout message, causing the switch port to transition to the unauthorized state.
Configuring 802.1X
To implement 802.1X port-based authentication, follow these steps:
Figure 6-32 shows a scenario where a PC is attached to FA0/1 on the switch and the device is getting authenticated via 802.1X with a Radius server. Example 6-20 shows the configuration for the scenario in Figure 6-32.
Example 6-20: 802.1X Configuration
sw(config)# radius-server host 10.1.1.50 auth-port 1812 key xyz123
sw(config)# aaa authentication dot1x default group radius
sw(config)# dot1x system-auth-control
sw(config)# interface fa0/1
sw(config-if)# description Access Port
sw(config-if)# switchport mode access
sw(config-if)# dot1x port-control auto
Switch Security Considerations
Network security vulnerabilities include loss of privacy, data theft, impersonation, and loss of integrity. Basic security measures should be taken on every network to mitigate adverse effects of user negligence or acts of malicious intent.
Best practices following these general steps are required whenever placing new equipment in service.
|
|
|
|
|
|
|
|
|
Organizational Security Policies
You should consider the policies of an organization when determining what level of security and what type of security should be implemented. You must balance the goal of reasonable network security against the administrative overhead that is clearly associated with extremely restrictive security measures.
A well-established security policy has these characteristics:
- Provides a process for auditing existing network security
- Provides a general security framework for implementing network security
- Defines disallowed behaviors toward electronic data
- Determines which tools and procedures are needed for the organization
- Communicates consensus among a group of key decision makers and defines responsibilities of users and administrators
- Defines a process for handling network security incidents
- Enables an enterprisewide, all-site security implementation and enforcement plan
Securing Switch Devices and Protocols
Implementation of a basic security configuration on every installed Cisco device is a requirement for preventing network vulnerabilities. Cisco recommends the following security measures on every Cisco device in your network to aid in network-security protection:
- Configure strong system passwords.
- Restrict management access using ACLs.
- Secure physical access to the console.
- Secure access to vty lines.
- Configure system warning banners.
- Disable unneeded or unused services.
- Trim and minimize the use of CDP/LLDP.
- Disable the integrated HTTP daemon (where appropriate).
- Configure basic system logging (syslog).
- Secure SNMP.
- Limit trunking connections and propagated VLANs.
- Secure the spanning-tree topology.
The techniques listed here are simple and easy to understand for those interested in implementing a minimum level of security on Cisco switches. This list is not a complete list, and you should review additional product security configurations per platform. Furthermore, these security principles are applicable to other Cisco products, including routers, SAN switches, and network appliances. The following sections discuss each item in the previous list in more detail.
Configuring Strong System Passwords
Use the enable secret command to set a password that grants enabled access to the Cisco IOS system, instead of using the enable password command. Because the enable secret command simply implements an MD5 hash on the configured password, that password remains vulnerable to dictionary attacks. Therefore, standard practices in selecting a feasible password apply. Try to pick passwords that contain letters, numbers, and special characters. An example of a feasible password is “$pecia1$”—that is, the word “specials,” where each “s” has been replaced by “$” and the letter “l” has been replaced with the numeral “1.”
Restricting Management Access Using ACLs
Creating ACLs to limit management and remote access traffic aids in prevention of unauthorized access and DoS attacks against management interfaces. Example 6-21 illustrates a sample ACL configuration that limits traffic to the management VLAN (in this case, VLAN 601) to only system administrators in the 10.1.3.0/24 subnet.
In Example 6-21, the subnet 10.1.2.0/24 is used for accessing all network devices for management purposes. This subnet does not pass user data traffic. Limiting access to this subnet for system administrators in another specific subnet, 10.1.3.0/24, prevents typical enterprise users from accessing the management subnet. As a result, ACLs that limit management traffic reduce vulnerability of the network devices and limit unauthorized access to the management subnet.
Example 6-21: Sample ACL for Restricting Access to Management Subnet
!
interface Vlan600
description User LAN
ip address 10.1.1.1 255.255.255.0
!
interface Vlan601
description Management VLAN
ip address 10.1.2.1 255.255.255.0
ip access-group 100 in
!
interface Vlan602
description IT LAN
ip address 10.1.3.1 255.255.255.0
!
(text delete)
!
!
access-list 100 permit ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
access-list 100 deny ip any any log
!
Securing Physical Access to the Console
Physical security of switches or routers is often overlooked but is a valuable security precaution. Console access requires a minimum level of security both physically and logically. An individual who gains console access to a system gains the ability to recover or reset the passwords or to reload the system, thereby enabling that individual to bypass all other security measures implemented on that system. Consequently, it is imperative to physically secure access to the console by using security personnel, closed circuit television, card-key entry systems, locking cabinets, access logging, or other means to control physical access as standard practice.
Securing Access to vty Lines
The minimum recommended security practices for securing access to vty lines are
- Apply ACLs on all vty lines to limit in-band access only to management stations from specific subnets.
- Configure strong passwords for all configured vty lines.
- Use Secure Shell Protocol (SSH) instead of Telnet to access the device remotely.
Configuring System Warning Banners
For both legal and administrative purposes, configuring a system warning banner to display prior to login is a convenient and effective way of reinforcing security and general usage policies. Clearly stating the ownership, usage, access, and protection policies prior to a login aids in stronger prosecution if unauthorized access occurs. Use the global configuration banner command to configure system banner messages. For more information about configuring banners, refer to the following URL:
- www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_connections_ps6350_TSD_Products_Configuration_Guide_Chapter.html.
Disabling Unneeded or Unused Services
By default, in Cisco IOS versions 11.2 and earlier, Cisco routers implement multiple TCP and UDP servers to facilitate management and integration into existing environments. However, in Cisco IOS versions 11.3 and later, most TCP and UDP servers are disabled by default. In addition, most installations do not require these services, and disabling them reduces overall security exposure. Multilayer switched networks typically do not use the following services:
- TCP Small Servers (Echo, Chargen, Discard, Daytime)
- UDP Small Servers (Echo, Discard, Chargen)
- Finger
- Auto config
- Packet Assembler and Disassembler (PAD)
- BOOTP server
- Identification service
- NTP without authentication
- Source routing
- IP Proxy-ARP
- ICMP unreachables
- ICMP redirects
- Directed broadcast forwarding
- Maintenance Operation Protocol (MOP)
For a description and the associated commands to disable these services, consult Cisco.com.
For a secure network, you should carefully evaluate every device configuration before applying it. For example, only appropriate VLANs should be allowed on the trunk to other devices, instead of allowing all VLANs. Another example is disabling Dynamic Trunk Protocol (DTP) and Port Aggregation Protocol (PAgP) protocols on end user ports where those features are not needed. Some of these features are enabled by default on Catalyst switches, so you need to make careful considerations for the default configuration and for additional configuration by the user. Avoiding unneeded services and making the configuration deterministic makes the network less susceptible to attack. The premise of plug-n-play might bode well for ease of installation, but it tremendously increases vulnerability of your network. Cisco customers generally want plug-n-play for ease of use, and as the products evolve, more and more security features become plug-n-play. Nevertheless, using a default security configuration on any device, Cisco or not, is a security risk.
Keep in mind that this chapter focuses on the discussion of Cisco devices. Securing your network includes securing not only your Cisco devices but also your hosts, servers, and any other network device.
Trimming and Minimizing Use of CDP/LLDP
Security with CDP/LLDP remains fairly controversial. Although CDP/LLDP propagates detailed information about respective network devices, correct planning and configuration of CDP/LLDP enables it to be a fairly safe protocol. This is a great advantage because auxiliary VLANs and specific solutions in many multilayer switched networks require CDP/LLDP. For a practical and secure deployment of CDP/LLDP, adhere to the following CDP/LLDP configuration guidelines:
- Disable CDP/LLDP on a per-interface basis. Run CDP/LLDP only for administrative purposes, such as on interswitch connections and interfaces where IP Phones reside.
- Confine CDP/LLDP deployment to run between devices under your control. Because CDP/LLDP is a link-level (Layer 2) protocol, it does not propagate end-to-end over a MAN or WAN unless a Layer 2 tunneling mechanism is in place. As a result, for MAN and WAN connections, CDP tables might include the service provider’s next-hop router or switch and not the far-end router under your control.
- Do not run CDP/LLDP to any unsecured connection, such as Internet connections.
Disabling the Integrated HTTP Daemon
Although Cisco IOS provides an integrated HTTP server for ease of management, the recommendation is to disable this feature, especially in multilayer switched networks that do not use this method for management. Otherwise, any unauthorized user might gain access via the web interface and make configuration changes. A user might also send numerous HTTP requests to the switch or router, which might cause high CPU utilization, resulting in a DoS-type attack on the system. In Cisco IOS, the integrated HTTP server is disabled by default. If HTTP access is necessary, use a different HTTP port, and use ACLs to isolate access from only trusted subnets or workstations. Use the following command in Cisco IOS to disable HTTP server access on a switch:
no ip http server
Example 6-22 illustrates disabling HTTP server access.
Example 6-22: Disabling IP HTTP Server Access
Enter configuration commands, one per line. End with CNTL/Z.
svs-san-msfc(config)# no ip http server
svs-san-msfc(config)# end
If HTTP access is needed, it is recommended to change the default TCP port number (80) using the ip http port port-no command. Secure HTTP is recommended over http access. Secure HTTP can be enabled via the ip http secure-server command.
Configuring Basic System Logging
To assist and simplify both problem troubleshooting and security investigations, monitor switch subsystem information received from the logging facility. To render the on-system logging useful, increase the default buffer size; generally, the default buffer size is not adequate for logging most events.
For more information about system logging, refer to the “System Logging” section in Chapter 5, “Implementing High Availability and Redundancy in a Campus Network.”
Securing SNMP
Whenever possible, avoid using SNMP read-write features. SNMPv2c authentication consists of simple text strings that are communicated between devices in clear, unencrypted text. In most cases, a read-only community string is sufficient. To use SNMP in a secure method, use SNMPv3 with an encrypted password and use ACL to limit SNMP from only trusted workstations and subnets. SNMP is covered in more detail in Chapter 5.
For additional information on how to secure SNMP, refer to the following document on Cisco.com: “Securing Simple Network Management Protocol,” Document ID: 20370, www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094489.shtml.
Limiting Trunking Connections and Propagated VLANs
By default, specific models of Catalyst switches that are running Cisco IOS automatically negotiate trunking capabilities. This poses a security risk because the negotiation enables the introduction of an unauthorized trunk port into the network. If an unauthorized trunk port is used for traffic interception and to generate DoS attacks, the consequences can be far more serious than if only an access port is used. (A DoS attack on a trunk port might affect multiple VLANs, whereas a DoS attack on an access port affects only a single VLAN.) To prevent unauthorized trunks, disable automatic negotiation of trunking on host and access ports. In addition, remove unused VLANs from trunks manually or by using VTP. Refer to Chapter 2 for more information on how to disable automatic negotiation of trunking and other VLAN configurations such as VTP.
Securing the Spanning-Tree Topology
It is important to protect the Spanning Tree Protocol (STP) process of the switches that compose the infrastructure. Inadvertent or malicious introduction of STP BPDUs potentially overwhelms a device or creates a DoS. The first step in stabilizing a spanning-tree installation is to positively identify the intended root and designated bridge in the design and to hard-set that bridge’s STP bridge priority to an acceptable root value. Configuring specific bridge priorities aids in prevention of inadvertent shifts in the STP root due to an uncontrolled introduction of a new switch. Enable the STP root-guard feature to prevent authorized bridges with lower priorities from taking over the legitimate one.
In addition, use the STP BPDU Guard feature to prevent host devices from maliciously sending BPDUs to a port. This feature, when enabled, works with the STP PortFast feature to protect the network from unwanted BPDU traffic injection. Upon receipt of an unauthorized STP BPDU, the feature automatically disables the port until user intervention occurs or a time-out value is reached.
Mitigating Compromises Launched Through a Switch
Follow these best practices to mitigate compromises through a switch:
- Proactively configure unused router and switch ports.
- Execute the shutdown command on all unused ports and interfaces.
- Place all unused ports in a “parking-lot” VLAN used specifically to group unused ports until they are proactively placed into service.
- Configure all unused ports as access ports, disallowing automatic trunk negotiation.
- Physical device access: Physical access to the switch should be closely monitored to avoid rogue device placement in wiring closets with direct access to switch ports.
- Access port–based security: Specific measures should be taken on every access port of any switch placed into service. Ensure that a policy is in place outlining the configuration of unused switch ports in addition to those that are in use.
-
For ports enabled for end-device access, there is a macro called switchport host, which when executed on a specific switch port, takes these actions: sets the switch port mode to access, enables spanning tree PortFast, and disables channel grouping.
| Note |
|
The command is a macro that executes several configuration commands. There is no command such as no switchport host to revoke the effect of the switchport host command. To return an interface to its default configuration, use the default interface interface-id global configuration command. This command returns all interface configurations to the default.
0 comments
Post a Comment