Management Security for HP Networking Provision Switches

Transcription

1 echnical white paper Management ecurity for HP Networking Provision witches October 2012 able of contents Executive ummary 3 tep 0: Determine the Plane 3 Management Plane 3 Data Plane 3 Plane eparation 4 Physical ecurity 4 tep 1: Protecting the Data Plane 5 tep 2: Configuring Management Access 5 Management Plane: erial Console 6 Management Plane: OOBM 6 Data Plane: Management VLAN 7 Data Plane: Loopback IP Addresses 8 tep 3: Network Management Protocols 10 elnet vs. ecure hell 10 ecure hell Clients 11 HP vs. HP 11 FP vs. FP and CP 13 NMPv1/2c vs.nmpv3 13 Legacy IP tack Management 14 tep 4: Protecting Management Access 14 tep 5: Authentication and Accounting 20 Username and Password Length 20 Authentication erver 20 Recommendations 20 Configuring Local Users 21 ACAC+ Authentication 21 RADIU Authentication 22 erver-upplied Privilege Level 22 RADIU Accounting 23 tep 6: Logging and ime 23

2 2

3 Executive ummary ecurity is a growing concern in today s Information echnology (I) infrastructure. Upper level managers and I managers alike are held to a higher accountability for the integrity and availability of their data. While host clients and servers often are the focus of security discussions, securing network devices such as switches and routers should not be ignored. All data traverses these devices, and properly securing them is paramount to a stable infrastructure. his document is intended to inform managers and administrators about insecure management protocols that run on HP Networking Provision switches. It will also provide a guide to follow for securing these devices. For up-to-date product CLI configuration syntax and advanced features, please select your product at and view product manuals. he version of software used for these examples is PP xxxx where PP refers to any Platform such as K or KA and xxxx is a minor build change. his document is one of three documents on security of HP Networking Provision witches. All three are described as follows: Management ecurity for HP Networking Provision witches covers switch management protocols such as H and recommended management configurations. Network-Connection ecurity for HP Networking Provision witches covers user access control to the network with 802.1X and other security measures aimed at controlling network access for users and clients. Post Network-Connection ecurity for HP Networking Provision witches covers protecting the network, using capabilities such as traffic classification, when valid clients and valid servers violate network parameters. tep 0: Determine the Plane One of the first key questions about securing an HP network switch is Is my management traffic in-band or out-ofband? We can describe the difference as follows: In-band switch management traffic travels with the network data traffic on the data plane and can be impacted when communication problems arise on the data plane Out-of-band switch management traffic travels on a different plane than the network data traffic and is not impacted when communication problems arise on the data plane. In documentation, it is common to describe out-of-band connections as being associated with the Management Plane and in-band connections as being associated with the Data Plane. Management Plane erial Console: For the out-of-band, every Provision switch supports a serial console allowing a laptop or console server to connect. his connection is speed limited and limited to the Command Line Interface. In addition, the serial interface doesn t support other types of management traffic like RADIU, NMP, or yslog where the switch is acting like a client. Out-of-band Management (OOBM): his term actually refers to an Ethernet port that is dedicated to management. A variety of protocols can be supported over the OOBM port and we ll discuss these throughout the document. Data Plane Management Virtual Local Area Network (VLAN): A VLAN with severe network restrictions focused only on switch management. 3

4 Loopback Interface Management: A loopback interface can be protected using Access Control Lists, and when combined with other security settings, can offer a high degree of security confidence when the Management VLAN is too restrictive. A Data Plane configuration for switch management may be necessary if you need to manage the switch via a Fiber connection since OOBM ports are RJ-45. In addition, using the Loopback interface method, you can have and control access from multiple VLANs in the network. Of course the downside is that such connections are in the Data Plane and subject to interruption by Data Plane troubles. Others: here are other ways of managing switches which may be even more popular than the ones outlined in this document. However, the ones outlined here are the ones recommended by HP. Plane eparation It is important to keep the Data Plane and Management Plane separate. For instance, if a network is using a network console server to establish erial Console connections to manage switches, is that Data Plane or Management Plane connection? he answer is we don t know. If the network connection of the console server is on the Data Plane, well, that probably wasn t the right thing to do as it would seem the Management Plane is the connection but it reality, to get to the Management Plane, you have to go through the Data Plane. If the network connection of the console server is on a separate management LAN, then that makes more sense and we could also have OOBM connections to that management network and still be on the Management Plane. However, we don t want to put Management VLAN ports or other Data Plane ports on that network we wouldn t be maintaining separation just as we wouldn t want to connect OOBM ports to the Data Plane. he next question is where is the management station (e.g., station where you are establishing a network connection to the console server or simply to an OOBM port)? If the management station is on the Data Plane, you should rethink that connection location as well. Lastly, if any infrastructure equipment is being used to enable access to multiple switches on the Management Plane (e.g., an unmanaged switch that connects multiple OOBM ports), this equipment should be at a minimum, just as reliable as the switch s being managed, and preferably, this equipment should be more reliable and with enhanced redundancy. Physical ecurity his document will not discuss physical security of the HP network equipment. For those interested in physical security, HP has FIP certified network equipment. his certification covers physical security and provides the best protection for those concerned about the physical security of their networking equipment. 4

5 tep 1: Protecting the Data Plane One key item is we want to closely control is the configuration of ports on the data plane. owards this goal, we can look at a following sample configuration: vlan 1 name "DEFAUL_VLAN" no untagged 1-24 no ip address forbid 1-24 vlan 10 name "Internal" untagged 1-12 no ip address forbid 24 vlan 11 name "External" untagged 24 no ip address forbid 1-23 vlan 666 name "UNUED-POR" untagged no ip address By using the forbid command, explicit work must be done to move a port from one VLAN to another and this is a good thing. Mistakes that place an internal machine on an external port could very well compromise the security of the internal machine. In addition, the DEFAUL_VLAN and the UNUED-POR VLAN do not have any IP addresses assigned to them. A couple of gotchas: When using untagged all style of commands, note that the internal ports of ervices zl modules are not moved and must be moved individually Adding a new module to a chassis switch (e.g., 5406zl) will automatically place the module s ports into the DEFAUL_VLAN and they should be moved to the UNUED-VLAN manually. In addition, any forbid commands need to have their port list expanded to include the new ports. tep 2: Configuring Management Access his document will go through configuring the four primary ways for management access. All four do not need to be configured. HP recommends the following: Always allow for erial Console Access (Management Plane) Configure one of the following: OOBM (Management Plane) A Management VLAN (Data Plane) 5

6 Power Fault Locator Console 24G-2FP+ HP E3800 J9573A witch tatus PoE mp est Aux Port Mgmt Reset LED Clear Act FDx pd PoE Usr Cmd tk tacking tatus Fan Mdl P tatus of the Back pd : Off = 10 Mbps, flash = 100 Mbps, on = Mbps PoE + Integrated 10/100/1000Base- Ports (1-24) - Ports are Auto-MDIX GbE/10-GbE FP+ Ports A Loopback Interface for Management and Dedicated VLAN for Management ervers (Data Plane) here are various restrictions on all these management interfaces and they will be covered here. Management Plane: erial Console Many switches differ on their serial console cable and serial communication settings. Be sure to refer to the switch s Installation and Getting tarted Guide to configure a serial console for the switch. Management Plane: OOBM In the figure that follows, the network breakdown is shown. Use only supported transceivers OOBM /24 External RADIU NMP NP YLOG Internal Network /16 fd79:b0fa:2d9f:8000::/56 Internal ubnets /24 fd79:b0fa:2d9f:8000::/64 - fd79:b0fa:2d9f:80ff::/64 Management Workstation IPv4 and IPv6 In the configuration steps that follow, the Management Plane IP address range will be /24. he OOBM interface on HP Provision witches supports IPv4 and does not support IPv6. Configuration HP-Provision-witch(config)# oobm enable HP-Provision-witch(config)# oobm interface speed-duplex auto HP-Provision-witch(config)# oobm ip address /24 HP-Provision-witch(config)# oobm ip default-gateway he OOBM interface can have other management protocols running on it. Unfortunately, there doesn t exist an ip source-interface all oobm command and the various protocols have to be configured separately: NP: [no] sntp server priority <priority> <ip-address> [oobm] [version] 6

7 HP ProCurve witch J9470A tatus RP mp Fan est LED Reset Act FDx pd Usr Clear Console pd Auxiliary Port off = 10Mbps flash = 100Mbps on = 1000Mbps 10/100Base-X Ports (1-20) All RJ-45 Ports (1-24) are Auto MDIX Dual-Personality Port 10/100/1000- () or Mini-GBIC () RADIU: [no] radius-server host <ip-address> [oobm] ACAC+: [no] tacacs-server host <ip-address> [oobm] DN: [no] ip dns server-address priority <priority> <ip-address> [oobm] yslog: [no] logging <ip-address> [control-descr] [oobm]] Data Plane: Management VLAN Management VLANs are designed to restrict management access to the switch to only those nodes connected to the Management VLAN. hat is, only clients who are connected to ports who are members of the Management VLAN can be allowed to gain management access to the Provision device. his sharply limits the universe of devices that can attempt unauthorized access. Here is what we plan on configuring Power Fault Use only one ( or ) for each Port Locator MANAGEMEN VLAN /24 fd79:b0fa:2d9f:2::50/64 External Internal Network /16 fd79:b0fa:2d9f:8000::/56 Internal ubnets /24 fd79:b0fa:2d9f:8000::/64 - fd79:b0fa:2d9f:80ff::/64 NP YLOG Management Workstation RADIU NMP Here is an example to configure a management VLAN using the previous configuration: HP-Provision-witch(config)# vlan 12 HP-Provision-witch(vlan-12)# name "DAA PLANE MANAGEMEN VLAN" HP-Provision-witch(vlan-12)# untagged 13 HP-Provision-witch(vlan-12)# forbid 1-12,14-24 HP-Provision-witch(vlan-12)# ip address HP-Provision-witch(vlan-12)# ipv6 address fd79:b0fa:2d9f:2::1/64 HP-Provision-witch(vlan-12)# HP-Provision-witch(config)# management-vlan 12 Here is what our new configuration looks like: 7

8 vlan 1 name "DEFAUL_VLAN" no untagged 1-24 no ip address forbid 1-24 vlan 10 name "Internal" untagged 1-12 no ip address forbid 24 vlan 11 name "External" untagged 24 no ip address forbid 1-23 vlan 12 name "DAA PLANE MANAGEMEN VLAN" untagged 13 ip address ipv6 address fd79:b0fa:2d9f:2::1/64 forbid 1-12,14-24 vlan 666 name "UNUED-POR" untagged no ip address management-vlan 12 We then want to make sure that all of our client protocols that have security implications use the loopback address as their source IP address. HP-Provision-witch(config)# ip source-interface all vlan 12 HP-Provision-witch(config)# snmp-server response-source vlan 12 HP-Provision-witch(config)# snmp-server trap-source vlan 12 Any VLAN can be assigned as the management VLAN. ake care to ensure that the same VLAN-id is configured as the Management VLAN on all Provision switches that are to be members of the management VLAN. here are severe restrictions on the Management VLANs worth noting: Only one VLAN per switch can be identified as the ecure Management VLAN. IP addresses must be assigned manually to the ecure Management VLAN. he switch will not allow the Management VLAN to acquire its address through DHCP/Bootp. o maintain the secure nature of the Management VLAN, only switch ports that are connecting authorized management stations, or those extending the Management VLAN to other Provision 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 Management VLAN is not permitted. Routing can be enabled on the switch and all other VLANs will be routable, but the Management VLAN will remain isolated. Data Plane: Loopback IP Addresses In some cases, the Management VLAN is too restrictive. What we are going to do in this case is establish loopback addresses for the purpose of management. For IPv6, we will be using a Unique Local address and for IPv4, we will be using something from the Private IP address range. 8

9 HP ProCurve witch J9470A tatus RP mp Fan est LED Reset Act FDx pd Usr Clear Console pd Auxiliary Port off = 10Mbps flash = 100Mbps on = 1000Mbps 10/100Base-X Ports (1-20) All RJ-45 Ports (1-24) are Auto MDIX Dual-Personality Port 10/100/1000- () or Mini-GBIC () Power Fault Use only one ( or ) for each Port Locator Loopback /24 fd79:b0fa:2d9f::50/64 Internal Network /16 fd79:b0fa:2d9f:8000::/56 Internal ubnets /24 fd79:b0fa:2d9f:8000::/64 - fd79:b0fa:2d9f:80ff::/64 External Management /24 Fd79:b0fa:2d9f:80001::50/64 Management Workstation RADIU YLOG NP NMP HP-Provision-witch(config)# interface loopback 0 HP-Provision-witch(lo0)# ip address HP-Provision-witch(lo0)# ipv6 address fd79:b0fa:2d9f::50 Although loopback addresses are always either /32 or /128, we are going to reserve /24 and fd79:b0fa:2d9f::/64 for the loopback range from which we will assign various switches their IP address. Doing so simply makes it easy to identify a loopback address. Here is what our configuration looks like: interface loopback 0 ip address ipv6 address fd79:b0fa:2d9f::50 vlan 1 name "DEFAUL_VLAN" no untagged 1-24 no ip address forbid 1-24 vlan 10 name "Internal" untagged 1-12 ip address ipv6 address fd79:b0fa:2d9f:8000::50/64 forbid 24 9

10 vlan 11 name "External" untagged 24 no ip address forbid 1-23 vlan 666 name "UNUED-POR" untagged no ip address We then want to make sure that all of our client protocols that have security implications use the loopback address as their source IP address. HP-Provision-witch(config)# ip source-interface all loopback 0 HP-Provision-witch(config)# snmp-server response-source loopback 0 HP-Provision-witch(config)# snmp-server trap-source loopback 0 tep 3: Network Management Protocols Out of the box, HP Network Provision witches run elnet, imple Network Management Protocol v1/2c (NMP v1/2c), rivial File ransfer Protocol (FP), and Hypertext ransfer Protocol (HP) for device management purposes. hese protocols are supported out of the box because they provide an ease of use that customers expect from the Provision product line. For the sake of securing these devices, these management protocols should be disabled and their secure counterparts configured. Because these are management protocols that operate over the network, the serial console is not discussed in this section. elnet vs. ecure hell elnet sends all traffic across the wire in clear text. his includes user names and passwords. Anyone snooping or sniffing network traffic will be able to see these passwords and use them to gain access to the switch. It is recommended that you use the ecure hell (H) server instead of elnet server on the switch. H uses asymmetric authentication to exchange keys and create a secure encrypted session. It can use DA and RA keys and the examples that follow will use RA. A key size of 2048 is supported and is used in these examples, but some switches can also support Larger key sizes allow for better security, so be sure to use the largest your switch supports. Follow these steps to enable H and disable elnet: OOBM HP-Provision-witch(config)# crypto key generate ssh rsa 2048 HP-Provision-witch(config)# ip ssh listen oobm HP-Provision-witch(config)# no telnet-server Management VLAN or Loopback Interface Management HP-Provision-witch(config)# crypto key generate ssh rsa 2048 HP-Provision-witch(config)# ip ssh listen data HP-Provision-witch(config)# no telnet-server For all H connections, it is always good practice to specify an inactivity timer that will automatically terminate sessions that have been idle for too long. he values are in minutes and you should select one that is best for the way you manage your switches. console inactivity-timer < > 10

11 ecure hell Clients When an H client connects to the switch for the first time, it is possible for a man-in-the-middle attack; that is, for an unauthorized device to pose undetected as the switch, and learn the usernames and passwords controlling access to the switch. his possibility can be removed by directly connecting the management station to the switch s serial port, using a show command to display the switch s public key, and copying the key from the display into the H Client as a known host. Many H clients support this feature and usually have a help or documentation to describe how to add H server public keys to the H client. o display an H server public key on the switch, use the following command: HP-Provision-witch(config)# show crypto host-public-key Additional security can be provided by enforcing H clients to have public keys of their own. Many H clients support generating a public/private key pair. Once they have been generated, a switch manager can copy the client s public key onto the switch. he switch can store up to 10 client public keys representing 10 different H clients. HP-Provision-witch(config)# copy tftp pub-key-file <FP IP Address> HP-Provision-witch(config)# aaa authentication ssh login public-key none Only an H client with a public key that the switch recognizes will be allowed to establish a connection with the switch. his procedure prevents unknown H clients from being able to establish H connections with the switch and attempt to find login credentials. HP vs. HP HP Provision switches can be configured through the HP interface. he HP interface that is started by default has the same limitations as elnet while an HP interface is HP traffic running over a ecure ockets Layer (L). When using HP, it is extremely important the browser be able to validate the HP certificate on the switch. igned certificates are provided by a Public Key Infrastructure (PKI) and specifically provided by a Certificate Authority (CA). If the environment does not support a PKI, then the switch cannot be provided a trusted certificate and it is recommended that HP be disabled and HP not be used. HP-Provision-witch(config)# no web-management plaintext If the environment can support a signed certificate (i.e., a PKI is in place), the HP interface be configured initially with the HP interface. A key pair must be generated, then the HP interface is used to generate a CA Certificate Request, the Certificate Request is then sent to the CA, and then the CA issued certificate be installed. Once this has been completed, the HP interface can be enabled and tested. Once the testing has completed, then the HP interface can be disabled. HP-Provision-witch(config)# crypto key generate cert rsa bits 2048 hen, using the web interface: 11

12 tep 2 elect Create CA Request tep 1 elect L Fill in the CA request and click Create request 12

13 he Certificate Request can now be copied and sent to the CA in order to issue the certificate. he CA reply is pasted into the bottom text field and then the link Install Certificate is clicked to install the signed certificate into the switch. Assuming that the certificate is installed, we can now go back to the switch command line. HP-Provision-witch(config)# web-management ssl HP-Provision-witch(config)# no web-management plaintext FP vs. FP and CP Important: his section assumes that the H server has been setup as recommended in the H section. FP client and server should be disabled as they do not require any authentication. ecure File ransfer Protocol (FP) and ecure Copy Protocol (CP) are part of the H protocol suite. hey provide an encrypted session using public/private keys between client and server just like H. In this case, the switch would be the server, and your PC would be the client. Please note that you will need a secure terminal client program running on your PC. HP-Provision-witch(config)# ip ssh filetransfer When executing ip ssh filetransfer, the FP client and server will be disabled automatically. o disable the FP client and server manually, execute the following commands: HP-Provision-witch(config)# no tftp server HP-Provision-witch(config)# no tftp client NMPv1/2c vs.nmpv3 NMP version 2c is enabled by default. his protocol is used to manage switches and routers from a central management server such as PCM. NMPv2c uses community names for read and write access, much like passwords are used for authentication. hese community names are sent across the wire as clear text. If a malicious user were to capture these community names, they could issue NMP set commands to reconfigure your network device. 13

14 NMP version 3 was developed to overcome these weaknesses. It uses cryptography to encrypt and authenticate NMP traffic over the wire. HP-Provision-witch(config)# snmpv3 enable HP-Provision-witch(config)# snmpv3 only For additional configuration examples for NMPv3, please reference the product manual. It is important to consider user names, groups and privileges when configuring NMPv3. Further considerations should include cryptography settings. If for any reason NMPv3 is not an option for your network, you can enable NMPv2c in restricted mode. his will allow management devices to get information from a networking device, but not set or change any settings on the networking device. HP-Provision-witch (config)# snmp-server community <community_name> restricted ome security policies may mandate that NMP be disabled altogether. HP-Provision-witch(config)# no snmp-server enable Legacy IP tack Management IP tack Management allows Legacy Provision stackable devices to be managed as a group using only a single IP address. here are a number of advantages, though they are more related to ease of use than security. For those who choose not to deploy Legacy IP tack Management, it is advisable to disable the feature to prevent potential hijacking of the switch. o determine whether the stacking protocol is enabled, execute the command: HP-Provision-witch(config)# show stack Once it s determined that the IP tack Management is enabled, it only requires one command to disable: HP-Provision-witch(config)# no stack Once the IP tack Management protocol is disabled, the switch cannot become a Commander or a Member. tep 4: Protecting Management Access OOBM he OOBM ports cannot be assigned to a VLAN, hence we cannot assign ACLs to protect them. In general, this shouldn t be an issue because the OOBM ports are on the Management Plane. Management VLAN he management VLAN is on the Data Plane. As a result, there may be services such as the H server that are listening on both the Management VLAN as well as other VLAN IP addresses. We will want to prohibit access to the H server on the switch by limiting H connections to the Management VLAN. Because this work is a subset of the work that needs to be done for Loopback Interfaces, it is covered in the next section. Loopback Interfaces here may be cases where the default access control restrictions on a Management VLAN are too restrictive to deploy and the loopback management interfaces were used instead. In this case, we want to be sure to protect access to those interfaces with access control lists. We will use the Management ervers VLAN to control access to/from the loopback interfaces. We will also prohibit the other switch IP addresses from being used for switch management. Access Control 14

15 HP ProCurve witch J9470A tatus RP mp Fan est LED Reset Act FDx pd Usr Clear Console pd Auxiliary Port off = 10Mbps flash = 100Mbps on = 1000Mbps 10/100Base-X Ports (1-20) All RJ-45 Ports (1-24) are Auto MDIX Dual-Personality Port 10/100/1000- () or Mini-GBIC () he next step is to determine which networks have access to the loopback IP address. We will keep things simple and just specify two management server network ranges: /24 fd79:b0fa:2d9f:8001::/64 he network diagram is as follows: Power Fault Use only one ( or ) for each Port Locator Loopback /24 fd79:b0fa:2d9f::50/64 Internal Network /16 fd79:b0fa:2d9f:8000::/56 Internal ubnets /24 fd79:b0fa:2d9f:8000::/64 - fd79:b0fa:2d9f:80ff::/64 External Management /24 Fd79:b0fa:2d9f:80001::50/64 Management Workstation RADIU YLOG NP NMP Let s describe at a high level what we want to accomplish with Access Control: We only want the Management erver VLAN to communicate with the Loopback Interface over specific protocols We only want the Loopback Interface to communicate with the Management erver VLAN. We need to specify both IPv4 and IPv6. IP Authorized Managers is a way to accomplish this, but it doesn t include the destination address. As we go through this section, it will become apparent why we decided to go with ACLs. Here is an ACL table which will explain it more specifically. Permit Protocols ource Destination DN, H, L, NMP, NMP rap, NP, ACAC+, RADIU Auth, RADIU Acct, fd79:b0fa:2d9f:8001::/ /24 fd79:b0fa:2d9f::50/ /32 15

16 yslog DN, H, L, NMP, NMP rap, NP, ACAC+, RADIU Auth, RADIU Acct, yslog fd79:b0fa:2d9f::50/ /32 fd79:b0fa:2d9f:8001::/ /24 We do not want any other switch IP address to be used for switch management purposes. In our configuration, we only have two to worry about: /24 and fd79:b0fa:2d9f:8000::50/64 Here is our Deny table: Deny Protocols ource Destination DN, H, L, NMP, NMP rap, NP, ACAC+, RADIU Auth, RADIU Acct, yslog DN, H, L, NMP, NMP rap, NP, ACAC+, RADIU Auth, RADIU Acct, yslog Any IPv6 Any IPv fd79:b0fa:2d9f:8000:: fd79:b0fa:2d9f:8000::50 Any IPv6 Any IPv4 Let s combine the two tables into one which will form the beginning of any ACL used by the switch. Protocols ource Destination PERMI DN, H, L, NMP, NMP rap, NP, ACAC+, RADIU Auth, RADIU Acct, yslog PERMI DN, H, L, NMP, NMP rap, NP, ACAC+, RADIU Auth, RADIU Acct, yslog DENY DN, H, L, NMP, NMP rap, NP, ACAC+, RADIU Auth, RADIU Acct, yslog fd79:b0fa:2d9f:8001::/ /24 fd79:b0fa:2d9f::50/ /32 ::/ fd79:b0fa:2d9f::50/ /32 fd79:b0fa:2d9f:8001::/ / fd79:b0fa:2d9f:8000::50 16

17 Let s define our incoming ACLs for internal networks so that the switch can understand them. his means that a client will be communicating with some service on the switch. An exception to this is NP, which will use a source port of 123. ome ACEs are stricken to indicate they were evaluated but not needed. his was done on IPv6 and the same evaluation was done on IPv4, but they were simply removed from the list on IPv4. Ipv6 access-list inside-to-inside-inbound remark allow management server subnet to loopback remark allow H permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 22 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 22 remark allow NP permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 123 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 123 remark allow NMP permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 161 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 161 remark allow HP permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 443 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 443 remark outbound, not needed permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 49 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 49 remark outbound, not needed permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 53 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 53 remark outbound, not needed permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 162 permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 162 remark outbound, not needed permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 514 permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 514 remark outbound, not needed permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 1812 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 1812 remark outbound, not needed permit tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 1813 permit udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 eq 1813 remark allow ICMP can be more restrictive here if necessary permit icmp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 remark deny everything else from the management server subnet to loopback deny tcp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 log deny udp fd79:b0fa:2d9f:8001::/64 fd79:b0fa:2d9f::50/128 log remark deny management services to switch IP addresses on VLANs deny tcp any fd79:b0fa:2d9f:8000::50/128 eq 22 deny udp any fd79:b0fa:2d9f:8000::50/128 eq 22 deny tcp any fd79:b0fa:2d9f:8000::50/128 eq 123 deny udp any fd79:b0fa:2d9f:8000::50/128 eq 123 deny tcp any fd79:b0fa:2d9f:8000::50/128 eq 161 deny udp any fd79:b0fa:2d9f:8000::50/128 eq 161 deny tcp any fd79:b0fa:2d9f:8000::50/128 eq 443 deny udp any fd79:b0fa:2d9f:8000::50/128 eq 443 remark permitting any ip address after this point remark which is not recommended, but is the subject of a remark different whitepaper! permit ip any any ip access-list extended inside-to-inside-inbound remark allow management server subnet to loopback permit tcp eq 22 permit udp eq 123 permit udp eq

18 permit tcp eq 443 permit icmp remark deny everything else from the management server subnet to loopback deny tcp log deny udp log remark deny management services to switch IP addresses on VLANs deny tcp any eq 22 deny udp any eq 123 deny udp any eq 161 deny tcp any eq 443 remark permitting any ip address after this point remark which is not recommended, but is the subject of a remark different whitepaper! permit ip any any Note that all ACLs have an implicit deny any at the bottom. raffic must be permitted explicitly in order to pass through an applied ACL. Let s define our outgoing ACLs for internal networks so that the switch can understand them. ipv6 access-list inside-to-inside-outbound remark allow from loopback management server subnet remark source port check permit tcp fd79:b0fa:2d9f::50/128 eq 22 fd79:b0fa:2d9f:8001::/64 permit udp fd79:b0fa:2d9f::50/128 eq 22 fd79:b0fa:2d9f:8001::/64 permit tcp fd79:b0fa:2d9f::50/128 eq 123 fd79:b0fa:2d9f:8001::/64 permit udp fd79:b0fa:2d9f::50/128 eq 123 fd79:b0fa:2d9f:8001::/64 permit tcp fd79:b0fa:2d9f::50/128 eq 161 fd79:b0fa:2d9f:8001::/64 permit udp fd79:b0fa:2d9f::50/128 eq 161 fd79:b0fa:2d9f:8001::/64 permit tcp fd79:b0fa:2d9f::50/128 eq 443 fd79:b0fa:2d9f:8001::/64 permit udp fd79:b0fa:2d9f::50/128 eq 443 fd79:b0fa:2d9f:8001::/64 remark allow from loopback management server subnet remark destination port check permit tcp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 49 permit udp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 49 permit tcp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 53 permit udp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 53 permit tcp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 162 permit udp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 162 permit tcp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 514 permit udp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 514 permit tcp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 1812 permit tcp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 1813 permit udp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 eq 1813 permit icmp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 remark deny everything else from the loopback to the management servers deny tcp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 log deny udp fd79:b0fa:2d9f::50/128 fd79:b0fa:2d9f:8001::/64 log remark deny switch IP addresses to talk management protocols remark source port check deny tcp fd79:b0fa:2d9f:8000::50/128 eq 22 any deny udp fd79:b0fa:2d9f:8000::50/128 eq 22 any deny tcp fd79:b0fa:2d9f:8000::50/128 eq 123 any deny udp fd79:b0fa:2d9f:8000::50/128 eq 123 any deny tcp fd79:b0fa:2d9f:8000::50/128 eq 161 any deny udp fd79:b0fa:2d9f:8000::50/128 eq 161 any deny tcp fd79:b0fa:2d9f:8000::50/128 eq 443 any deny udp fd79:b0fa:2d9f:8000::50/128 eq 443 any remark destination port check deny tcp fd79:b0fa:2d9f:8000::50/128 any eq 49 deny udp fd79:b0fa:2d9f:8000::50/128 any eq 49 deny tcp fd79:b0fa:2d9f:8000::50/128 any eq 53 18

19 deny udp fd79:b0fa:2d9f:8000::50/128 any eq 53 deny tcp fd79:b0fa:2d9f:8000:50/128 any eq 162 deny udp fd79:b0fa:2d9f:8000:50/128 any eq 162 deny tcp fd79:b0fa:2d9f:8000::50/128 any eq 514 deny udp fd79:b0fa:2d9f:8000::50/128 any eq 514 deny tcp fd79:b0fa:2d9f:8000:50/128 any eq 1812 deny udp fd79:b0fa:2d9f:8000:50/128 any eq 1812 deny tcp fd79:b0fa:2d9f:8000::50/128 any eq 1813 deny udp fd79:b0fa:2d9f:8000::50/128 any eq 1813 remark permitting any ip address after this point remark which is not recommended, but is the subject of a remark different whitepaper! permit ip any any ip access-list extended inside-to-inside-outbound remark allow loopback to management server subnet permit tcp eq permit udp eq permit tcp eq permit udp eq permit tcp eq permit udp eq permit tcp eq permit udp eq permit tcp eq 49 permit udp eq 49 permit udp eq 53 permit udp eq 162 permit udp eq 514 permit tcp eq 1812 permit udp eq 1812 permit tcp eq 1813 permit udp eq 1813 permit icmp remark deny everything else from loopback to management server subnet deny tcp log deny udp log remark deny management services to switch IP addresses on VLANs deny tcp eq 22 any deny udp eq 123 any deny udp eq 161 any deny tcp eq 443 any deny tcp any eq 49 deny udp any eq 49 deny tcp any eq 53 deny udp any eq 53 deny tcp any eq 162 deny udp any eq 162 deny tcp any eq 514 deny udp any eq 514 deny tcp any eq 1812 deny udp any eq 1812 deny tcp any eq 1813 deny udp any eq 1813 remark permitting any ip address after this point remark which is not recommended, but is the subject of a remark different whitepaper! permit ip any any We would apply our ACLs as follows: HP-Provision-witch(config)# vlan 10 ip access-group extended inside-to-inside-outbound out 19

20 HP-Provision-witch(config)# vlan 10 ip access-group extended inside-to-inside-inbound in HP-Provision-witch(config)# vlan 10 ipv6 access-group extended inside-to-inside-outbound out HP-Provision-witch(config)# vlan 10 ipv6 access-group extended inside-to-inside-inbound in tep 5: Authentication and Accounting At this point, we ve protected our switch management interfaces very well, but we still have not configured a way for users to authenticate. By default, no user authentication is configured, thus leaving the switch open to anyone with physical or remote access. wo types of users can be configured to provide different levels of access to the switch. Manager full access (default) Ability to make configuration changes All enable command contexts Read and write access Operator limited access tatus and counters, event-log and show commands All login command contexts Read-only access When credentials are configured, they are associated with the Manager role and the Operator role. When accessing the management interfaces of the switch, the user must enter the appropriate username and password. hese credentials, based upon the role they are associated with, grant the user the appropriate permissions. Username and Password Length he limit on username and password length is 64 characters for our switch management interfaces. Usernames and passwords are case-sensitive. ACII characters in the range of are valid, including: A through Z uppercase characters a through z lower case characters 0 through 9 numeric characters pecial characters # $ % ^ & * ( ) - _ = + [ ] { } \ ; :, < > /? he PACE character is allowed to form a username or password pass-phrase.he username must be in quotes, for example he little brown fox. A space is not allowed as part of a username without the quotes. A password that includes a space or spaces should not have quotes. Authentication erver HP Provision switches support primary and secondary methods of authentication. In larger environments, the primary method of user authentication for switch management is typically using RADIU or ACAC+. he secondary method of authentication is typically a local database on the switch. When the primary means is unavailable to respond to authentication requests, the secondary means can be invoked. In common network environments used today, the RADIU server is often a Microsoft IA/NP or FreeRADIU. he various parameters controlling password comply, account lockout, and other such security settings are often Active Directory configured or Group Policy configured settings. As a result, it is best to specify these types of settings on the Authentication erver rather than on the switch itself. HP Provision switches are restricted to using IPv4 when communicating with RADIU or ACAC+ authentication servers. Recommendations Configure all management access for authentication Use different usernames than the well-known manager and operator 20

21 Use RADIU or ACAC+ as your primary authentication method If using RADIU, use PEAP-MCHAPv2 as the protocol. Be sure to configure on your authentication server things like password comply, number of login attempts, account lockout, and so forth. Use Local as your secondary authentication method for a failsafe. Your local users can have different usernames and passwords than your RADIU or ACAC+ users. If they are different, it is best to write them down and keep them in a physically secure location because over time, it is quite likely they will be forgotten since they are not used very often. Configuring Local Users Because configuring RADIU or ACAC+ is involved, it is better to start with configuring local users even though it will only be used when the RADIU or ACAC+ server is unavailable. password <manager operator > [user-name ACII-R] [<plaintext sha1> ACII-R] An example of a recommended configuration (except for the actual password value) for local users would be as follows: HP-Provision-witch(config)# password manager user-name Brontosaurus plaintext 1qazXW@ HP-Provision-witch(config)# password manager user-name MammalsRule plaintext 3edcVFR$ ACAC+ Authentication Authenticating users via ACAC+ also provides a centralized way to manage access to the switch. ACAC+ authentication works along the same lines as a RADIU authentication, allowing the administrator to manage users from a central server. o enable ACAC+ authentication as the primary method, and Local as the secondary method, use the following configuration command: HP-Provision-witch (config)# aaa authentication <console telnet ssh ><enable login> tacacs local Caution: ACAC+ cannot authenticate the web agent. herefore, if the web agent is being used, RADIU should be used instead. When using ACAC+ servers, you may specify up to three. HP-Provision-witch (config)# tacacs-server host < ip-addr > [key < key-string > encrypted-key <keystring>] [oobm] HP-Provision-witch (config)# aaa authentication console login tacacs local HP-Provision-witch (config)# aaa authentication console enable tacacs local HP-Provision-witch (config)# aaa authentication telnet login tacacs local HP-Provision-witch (config)# aaa authentication telnet enable tacacs local HP-Provision-witch (config)# aaa authentication ssh login tacacs local HP-Provision-witch (config)# aaa authentication ssh enable tacacs local If your ACAC+ servers are on the Data Plan: HP-Provision-witch (config)# tacacs-server host key HP9witch~ HP-Provision-witch (config)# tacacs-server host key HP9witch~ HP-Provision-witch (config)# tacacs-server host key HP9witch~ If your ACAC+ servers are on the Management Plan: HP-Provision-witch (config)# tacacs-server host key HP9witch~ oobm HP-Provision-witch (config)# tacacs-server host key HP9witch~ oobm HP-Provision-witch (config)# tacacs-server host key HP9witch~ oobm 21

22 RADIU Authentication Authenticating users via RADIU provides a centralized way to manage access to the switch. his allows the administrator to make modifications to the set of authorized users without having to make changes on every network device. o enable RADIU authentication as the primary method, and Local as the secondary method, use the following configuration command: HP-Provision-witch (config)# aaa authentication <console telnet ssh web> <enable login> <radius peap-mschapv2> local H also includes authentication for CP and FP. Caution: 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. When using RADIU servers, you may specify up to three. HP-Provision-witch (config)# radius-server host < ip-addr > [key < key-string > encrypted-key <keystring>] [oobm] Here are the commands to enable RADIU authentication as the primary method, and Local as the secondary method, for all the switch management functions HP-Provision-witch (config)# aaa authentication console login peap-mschapv2 local HP-Provision-witch (config)# aaa authentication console enable peap-mschapv2 local HP-Provision-witch (config)# aaa authentication ssh login peap-mschapv2 local HP-Provision-witch (config)# aaa authentication ssh enable peap-mschapv2 local HP-Provision-witch (config)# aaa authentication web login peap-mschapv2 local HP-Provision-witch (config)# aaa authentication web enable peap-mschapv2 local If your RADIU servers are on the Data Plan: HP-Provision-witch (config)# radius-server host key HP9witch~ HP-Provision-witch (config)# radius-server host key HP9witch~ HP-Provision-witch (config)# radius-server host key HP9witch~ If your RADIU servers are on the Management Plan: HP-Provision-witch (config)# radius-server host key HP9witch~ oobm HP-Provision-witch (config)# radius-server host key HP9witch~ oobm HP-Provision-witch (config)# radius-server host key HP9witch~ oobm erver-upplied Privilege Level Login privilege level, which is optional, instructs the switch to accept the authenticating user s command level (manager or operator) that is supplied by the server. his allows manager-level users to skip the login context and proceed immediately to enable context, thus eliminating the need for a manager-level user to login twice. o allow the switch to accept the privilege level provided by the server, use the following configuration command: HP-Provision-witch (config)# aaa authentication login privilege-mode o supply a privilege level via RADIU, specify the ervice-ype attribute in the user s credentials. ervice-ype = 6 allows manager-level access ervice-ype = 7 allows operator-level access A user with ervice-ype not equal to 6 or 7 is denied access A user with no ervice-ype attribute supplied is denied access when privilege mode is enabled o supply a privilege level via ACAC specify the Max Privilege level in the user s credentials. 22

23 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 RADIU Accounting It is useful to understand what a user is doing when they login and that is the part RADIU accounting plays. For the purpose of this whitepaper, the following settings are recommended: HP-Provision-witch (config)# aaa accounting exec start-stop radius HP-Provision-witch (config)# aaa accounting system stop-only radius HP-Provision-witch (config)# aaa accounting commands stop-only radius Note: RADIU accounting information can be sent to a syslog server rather than a RADIU server using the following syntax: HP-Provision-witch (config)# aaa accounting exec start-stop syslog HP-Provision-witch (config)# aaa accounting system stop-only syslog HP-Provision-witch (config)# aaa accounting commands stop-only syslog o configure a syslog server, please see the next section. tep 6: Logging and ime he switch event log is stored in volatile memory and is lost on a reboot. It is best to configure a syslog server to handle the log on another server in non-volatile memory. For syslog: HP-Provision-witch (config)# logging <IPv4 or IPv6 address> here are options available for the switch to filter which events are sent to the syslog server. hese options are typically customer specific. In general, it is better to have an event and filter it than to not have an event and wonder what happened. he switches by by default have no sense of accurate time, which is critical for security and debugging problems. It is best to configure the switch for NP as shown below HP-Provision-witch (config)# timesync sntp HP-Provision-witch (config)# sntp authentication key-id xxxxx authentication-mode md5 keyvalue xxxx HP-Provision-witch (config)# sntp unicast HP-Provision-witch (config)# sntp server priority 1 <IPv4 or IPv6 address> HP-Provision-witch (config)# sntp server priority 2 <IPv4 or IPv6 address> 23