Hardening ProCurve Switches White Paper
Hardening ProCurve Switches White Paper
Hardening ProCurve Switches White Paper
When executing ip ssh filetransfer, the TFTP client and server will be disabled automatically. To disable the TFTP client and server manually, execute the following commands: ProCurve Switch(config)# no tftp server ProCurve Switch(config)# no tftp client
IP Stack Management
IP Stack Management allows ProCurve stackable devices to be managed as a group using only a single IP address. There are a number of advantages, though they are more related to ease of use than security. For those who choose not to deploy IP Stack Management, it is advisable to disable the feature to prevent potential hijacking of the switch. To determine whether the stacking protocol is enabled, execute the command:
See the ProCurve Advanced Traffic Management Guide for more information on IP Stack Management and a list of devices on which it is supported.
Access Control
Secure Management VLAN
Secure Management VLANs are designed to restrict management access to the switch to only those nodes connected to the Management VLAN. That is, only clients who are connected to ports who are members of the Secure Management VLAN can be allowed to gain management access to the ProCurve device. This sharply limits the universe of devices that can attempt unauthorized access. Configuring a Management VLAN takes only one command: ProCurve Switch(config)# management-vlan <vid | vlan-name> Any VLAN can be assigned as the management VLAN. Take care to ensure that the same VLAN is configured as Management VLAN on all ProCurve switches that are to be members of the management VLAN. There are a few restrictions on Secure Management VLANs worth noting:
Only one VLAN per switch can be identified as the Secure Management VLAN. IP addresses must be assigned manually to the Secure Management VLAN. The switch will not
allow the Management VLAN to acquire its address through DHCP/Bootp.
To maintain the secure nature of the management VLAN, only ProCurve switch ports that are
connecting authorized management stations, or those extending the management VLAN to other ProCurve switches, should be members of the Management VLAN.
Internet Group Management Protocol (IGMP) is not supported on the Management VLAN. Routing to or from the Secure Management VLAN is not permitted. Routing can be enabled on
the switch and all other VLANs will be routable, but the Secure Management VLAN will remain isolated.
For more information on the Secure Management VLAN see the Advanced Traffic Management Guide manual for your product at the ProCurve Networking Web site, (http://www.hp.com/rnd/support/manuals/index.htm).
Authorized IP Managers
In cases where configuring a Secure Management VLAN is too restrictive, its possible to identify up to 10 IP addresses or address groups that are allowed management access to the switch via the network. The command to configure the management stations is as follows: ProCurve Switch(config)# ip authorized-manager <IP address> mask <mask bits> <operator | manager> Once configured, only those addresses identified will be granted access to the switch over the network. The addresses are configured using a mask to allow the 10 entries to be either a single host (using a mask of 255.255.255.255) or groups of hosts. Note that the access level is also configurable. Some addresses can be limited to operator access while others are granted full manager status. Its important to keep in mind that this is not fool-proof access control. IP spoofing will defeat this protection, as will an authorized workstation whose security has been compromised. It also does not protect against unauthorized access through the serial console. Its recommended that this feature be used in conjunction with a secondary authentication scheme, such as password protection. Consider the following standard ACL: ip access-list standard "mgmt-traffic"
10 permit 10.1.1.0 0.0.0.255
20 permit 10.1.0.50 0.0.0.0
exit
This list, when applied inbound on the VLAN or port on which the management interface resides, will allow only hosts from 10.1.1.0/24 or 10.1.0.50 to access the switch. All traffic from other source IP addresses is dropped. Note that all ACLs have an implicit deny any at the bottom. Traffic must be permitted explicitly in order to pass through an applied ACL. ACL options and configuration can vary by switch platform. For more information on Access Control Lists, see the Advanced Traffic Management Guide manual for your product at the ProCurve Networking website, http://www.hp.com/rnd/support/manuals/index.htm.
Authentication
By default, no user authentication is configured, thus leaving the switch open to anyone with physical or remote access. Two types of users can be configured to provide different levels of access to the switch.
Each access method (console, Telnet, etc.) allows you to configure a primary and secondary way of authenticating users. ProCurve switches default to the following: ProCurve Switch# show authentication Status and Counters - Authentication Information
Login Attempts: 3
Respect Privilege: Disabled
| Login Access Task | Primary Login Secondary Enable Primary Enable Secondary
----------- + ---------- ---------- ---------- ---------Console Telnet | Local | Local None None Local Local None None
Port-Access | Local Webui SSH Web-Auth MAC-Auth | Local | Local | ChapRadius | ChapRadius None None Local Local None None
Note: Port-access (802.1x), Web-Auth and MAC-Auth are means of securing the network from unauthorized users, not the switch itself, and therefore are not covered in the scope of this document. The default number of login attempts is 3, meaning the user has three chances to successfully supply access credentials. Once this limit is reached the user must re-initiate a login. The
6
number of login attempts allowed can be changed by entering the configuration context and using the following command: ProCurve Switch 5406zl(config)# aaa authentication num-attempts <1-10> The Respect Privilege option instructs the switch to allow the authenticating server to supply the privilege level of the user. See the Server-Supplied Privilege Level section below for more information. If the primary authentication method fails for any reason, (e.g., the authenticating server(s) are unreachable), the secondary method will be used to authenticate users. In the above configuration, when no Local username/passwords are configured everyone has manager permission. Most access methods allow three methods of authenticating users:
Local uses the switchs locally stored usernames and passwords RADIUS uses a RADIUS server to authenticate users TACACS+ uses a TACACS server to authenticate users Local Authentication
Local username and passwords are configured on a per-switch basis and provide the most basic form of authentication. The switch allows you to configure manager and operator passwords, as well as an optional username for each. Local authentication is often used as the secondary login method so as to provide a minimum level of security should the primary method fail.
RADIUS Authentication
Authenticating users via RADIUS provides a centralized way to manage access to the switch. This allows the administrator to make modifications to the set of authorized users without having to make changes on every network device. To enable RADIUS authentication as the primary method, and Local as the secondary method, use the following configuration command: ProCurve Switch (config)# aaa authentication <console|telnet|ssh|web> <enable|login> radius local SSH also includes authentication for SCP and SFTP. Note: If the secondary access method is None or Local with no passwords configured, the user will be granted manager-level access if the primary method fails for any reason.
TACACS Authentication
Authenticating users via TACACS also provides a centralized way to manage access to the switch. TACACS authentication works along the same lines as a RADIUS authentication, allowing the administrator to manage users from a central server. To enable TACACS authentication as the primary method, and Local as the secondary method, use the following configuration command: ProCurve Switch (config)# aaa authentication <console|telnet|ssh|web> <enable|login> tacacs local Note on RADIUS and TACACS keys: When copying off a switch configuration, certain security parameters, including the RADIUS and TACACS keys, are not included in the copied configuration. If this configuration is then used to restore a device configuration, it will not include this information, possibly resulting in a user being denied access due to a mismatched password that is no longer encrypted. For more information on configuring Local passwords, RADIUS, or TACACS servers see the Access Security Guide manual for your product at the ProCurve Networking website, (http://www.hp.com/rnd/support/manuals/index.htm).
the login context and proceed immediately to enable context, thus eliminating the need for a manager-level user to login twice. To allow the switch to accept the privilege level provided by the server, use the following configuration command: ProCurve Switch(config)# aaa authentication login privilege-mode To supply a privilege level via RADIUS, specify the Service-Type attribute in the users credentials.
Service-Type = 6 allows manager-level access Service-Type = 7 allows operator-level access A user with Service-Type not equal to 6 or 7 is denied access A user with no Service-Type attribute supplied is denied access when privilege mode is
enabled To supply a privilege level via TACACS specify the Max Privilege level in the users credentials.
Max-privilege = 15 allows manager-level access Max-privilege = 14 allows operator-level access A user with Max-Privilege of 14 or lower is granted operator-level access
Attack Prevention
Dynamic ARP Protection
Address Resolution Protocol (ARP) allows hosts to communicate over the network by creating an IP to MAC address mapping used in the transmission of packets. Attackers can use ARP to generate bogus mappings, thereby allowing them to spoof other clients MAC addresses and intercept traffic destined to them. Additionally, an attacker could generate an unlimited number of artificial ARP entries, filling up the caches of other clients on the network and creating a Denial of Service. Dynamic ARP Protection works by intercepting ARP packets and verifying their authenticity before forwarding them. Packets with invalid IP to MAC address bindings advertised in the source protocol address and source physical address fields are discarded, ensuring that only valid ARP requests and replies are forwarded or used to update the local ARP table. ARP Protection authenticates IP to MAC bindings stored from a lease maintained by DHCP Snooping, or by using static bindings configured for non-DHCP clients. It is configured per VLAN and categorizes ports in two ways, trusted and untrusted (default). ARP packets received on trusted ports are forwarded normally without validating their authenticity, provided no authorized servers are configured. Note: Enabling ARP protection without first configuring DHCP Snooping and/or static bindings will cause all ARP packets to be dropped. ARP Protection also can be configured to drop:
ARP request or response packets, where the source MAC address in the Ethernet header does
not match the sender MAC address in the body of the ARP packet.
Unicast ARP response packets, where the destination MAC address in the Ethernet header
does not match the target MAC address in the body of the ARP packet.
ARP packets, where the sender or target IP address is invalid. Invalid IP addresses include
0.0.0.0, 255.255.255.255, all IP multicast addresses, and all Class E IP addresses. For more information on configuring Dynamic ARP Protection or DHCP Snooping, see the Access Security Guide manual for your product at the ProCurve Networking website, http://www.hp.com/rnd/support/manuals/index.htm.
Physical Security
Password Clear Protection Front-Panel Security
ProCurve devices utilize the Reset and Clear buttons on the front panel to help users reset the switch configuration to factory default or to reset the console password. This capability creates a security risk anywhere its impossible to prevent physical access to the switch. ProCurve makes it possible to disable this functionality to protect from malicious use of these features. There are two components to front-panel security: password clear and factory reset. Both must be disabled to fully secure the device. In the switchs default mode, a malicious user can utilize the front-panel clear button to reset a console password stored locally on the switch. To disable this feature, issue the command: ProCurve Switch(config)# no front-panel-security password-clear The other capability built into ProCurve switches is the ability to reset the switch configuration to the factory default mode: ProCurve Switch(config)# [no] front-panel-security factory-reset Executing this command prevents reset of the switch configuration by use of the front-panel Reset and Clear buttons. Its critical to understand that disabling these features severely restricts administrator options if the password is lost or forgotten. Before making these changes, users are strongly encouraged to review all considerations outlined in the Access and Security Guide for your model.
Conclusion
The security features described by this white paper are an excellent starting point for hardening ProCurve networks, and should be used in the context of an organization's greater security policy. Good security practice dictates that an organization have a well-thought security policy that relies on a thorough threat assessment and defensein-depth strategy. Only after creating a security policy can an organization best capitalize on the many security features present in ProCurve devices, such as MAC lockdown, DHCP protection, BPDU Port Protection and Dynamic IP Lockdown.
To find out more about ProCurve Networking products and solutions, visit our Web site at
www.procurve.com
2007 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA1-0313ENW, 02/2007