Technical white paper

Management Security for HP Networking Provision Switches

October 2012

Table of contents

Executive Summary 3

Step 0: Determine the Plane 3

Management Plane 3

Data Plane 3

Plane Separation 4

Physical Security 4

Step 1: Protecting the Data Plane 5

Step 2: Configuring Management Access 5

Management Plane: Serial Console 6

Management Plane: OOBM 6

Data Plane: Management VLAN 7

Data Plane: Loopback IP Addresses 8

Step 3: Network Management Protocols 10

Telnet vs. Secure Shell 10

Secure Shell Clients 11

HTTP vs. HTTPS 11

TFTP vs. SFTP and SCP 13

SNMPv1/2c vs.SNMPv3 13

Legacy IP Stack Management 14

Step 4: Protecting Management Access 14

Step 5: Authentication and Accounting 20

Username and Password Length 20

Authentication Server 20

Recommendations 20

Configuring Local Users 21

TACACS+ Authentication 21

RADIUS Authentication 22

Server-Supplied Privilege Level 22

RADIUS Accounting 23

Step 6: Logging and Time 23

2

3

Executive Summary

Security is a growing concern in today’s Information Technology (IT) infrastructure. Upper level managers and IT 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. This 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 http://www.hp.com/networking/support and view product manuals. The version of software used for these examples is PP.15.09.xxxx where PP refers to any Platform such as “K” or “KA” and xxxx is a minor build change. This document is one of three documents on security of HP Networking Provision Switches. All three are described as follows:

• Management Security for HP Networking Provision Switches – covers switch management protocols such as SSH and recommended management configurations.

• Network-Connection Security for HP Networking Provision Switches – 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 Security for HP Networking Provision Switches – covers protecting the network, using capabilities such as traffic classification, when valid clients and valid servers violate network parameters.

Step 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-of-band?” 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 Serial Console: For the out-of-band, every Provision switch supports a serial console allowing a laptop or console server to connect. This 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 RADIUS, SNMP, or Syslog – where the switch is acting like a client.

Out-of-band Management (OOBM): This 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.

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: There 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 Separation 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 Serial Console connections to manage switches, is that Data Plane or Management Plane connection? The 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.

The 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 Security This document will not discuss physical security of the HP network equipment. For those interested in physical security, HP has FIPS 140-2 certified network equipment. This certification covers physical security and provides the best protection for those concerned about the physical security of their networking equipment.

5

Step 1: Protecting the Data Plane

One key item is we want to closely control is the configuration of ports on the data plane. Towards this goal, we can look at a following sample configuration:

vlan 1

name "DEFAULT_VLAN"

no untagged 1-24 no ip address forbid 1-24 exit vlan 10 name "Internal" untagged 1-12 no ip address forbid 24 exit vlan 11 name "External" untagged 24 no ip address forbid 1-23 exit vlan 666 name "UNUSED-PORTS" untagged 13-23 no ip address exit

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 DEFAULT_VLAN and the UNUSED-PORTS 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 Services 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 DEFAULT_VLAN and they should be moved to the UNUSED-VLAN manually. In addition, any ‘forbid’ commands need to have their port list expanded to include the new ports.

Step 2: Configuring Management Access

This 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 Serial Console Access (Management Plane) Configure one of the following: • OOBM (Management Plane) • A Management VLAN (Data Plane)

6

• A Loopback Interface for Management and Dedicated VLAN for Management Servers (Data Plane) There are various restrictions on all these management interfaces and they will be covered here.

Management Plane: Serial Console Many switches differ on their serial console cable and serial communication settings. Be sure to refer to the switch’s Installation and Getting Started Guide to configure a serial console for the switch.

Management Plane: OOBM In the figure that follows, the network breakdown is shown.

PoE + Integrated 10/100/1000Base-T Ports (1 - 24) - Ports are Auto-MDIX

24

23

22

21

20

19

18

17

16

15

14

13Link Mode

Link Mode12

11

10

9

8

7

6

5

4

3

2

1Link Mode

Link Mode

Spd Mode: Off = 10 Mbps, flash = 100 Mbps, on = 1000+ MbpsStackingStatus

Status ofthe BackAct FDx Spd PoE Usr Cmd Stk Fan Mdl PSLED

Mode

Console

LocatorFaultPower

Reset ClearAuxPort

Test

Status Mgmt

Tmp

PoE

Link Mode

Link Mode26

25

Use only supported transceivers

1-GbE/10-GbE SFP+ Ports

J9573ASwitch24G-2SFP+HP E3800

Internal Network

172.16.0.0/16

fd79:b0fa:2d9f:8000::/56

Internal Subnets

172.16.0 – 172.16.255/24

fd79:b0fa:2d9f:8000::/64 -

fd79:b0fa:2d9f:80FF::/64

ExternalOOBM

192.168.0.50/24

RADIUS

SNMP

SYSLOG

SNTP

Management

Workstation

IPv4 and IPv6 In the configuration steps that follow, the Management Plane IP address range will be 192.168.0.0/24. The OOBM interface on HP Provision Switches supports IPv4 and does not support IPv6. Configuration HP-Provision-Switch(config)# oobm enable HP-Provision-Switch(config)# oobm interface speed-duplex auto HP-Provision-Switch(config)# oobm ip address 192.168.0.50/24 HP-Provision-Switch(config)# oobm ip default-gateway 192.168.0.1 The 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: SNTP: [no] sntp server priority <priority> <ip-address> [oobm] [version]

7

RADIUS: [no] radius-server host <ip-address> [oobm] TACACS+: [no] tacacs-server host <ip-address> [oobm] DNS: [no] ip dns server-address priority <priority> <ip-address> [oobm] Syslog: [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. That 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. This sharply limits the universe of devices that can attempt unauthorized access. Here is what we plan on configuring

Power

Fault

Locator

Status

LED

ModeFan

Test

Reset Clear

RPS

Tmp

Usr

Dual-Personality Port 10/100/1000-T (T) or Mini-GBIC (S)Spd Mode

Use o

nly

on

e (

T o

r S

) fo

r each

Po

rt

Auxiliary PortConsole

Link Mode

Link Mode

Link Mode

Link Mode

Link Mode

Link Mode22

21

24

23

22

21

24

23

T

T

T

T

20181614

19171513

121086

11975

42

31

off = 10Mbps

flash = 100Mbps

on = 1000Mbps

10/100Base-TX Ports (1-20) All RJ-45 Ports (1-24T) are Auto MDIX

S

S

S

S

Act

FDx

Spd

HP ProCurve

3500-24

Switch

J9470A

Internal Network

172.16.0.0/16

fd79:b0fa:2d9f:8000::/56

Internal Subnets

172.16.0 – 172.16.255/24

fd79:b0fa:2d9f:8000::/64 -

fd79:b0fa:2d9f:80FF::/64

ExternalMANAGEMENT VLAN

172.30.1.50/24

fd79:b0fa:2d9f:2::50/64

RADIUSSNMP

SYSLOGSNTP

Management

Workstation

Here is an example to configure a management VLAN using the previous configuration: HP-Provision-Switch(config)# vlan 12 HP-Provision-Switch(vlan-12)# name "DATA PLANE MANAGEMENT VLAN" HP-Provision-Switch(vlan-12)# untagged 13 HP-Provision-Switch(vlan-12)# forbid 1-12,14-24 HP-Provision-Switch(vlan-12)# ip address 172.30.1.50 255.255.255.0 HP-Provision-Switch(vlan-12)# ipv6 address fd79:b0fa:2d9f:2::1/64 HP-Provision-Switch(vlan-12)# exit HP-Provision-Switch(config)# management-vlan 12 Here is what our new configuration looks like:

8

vlan 1 name "DEFAULT_VLAN" no untagged 1-24 no ip address forbid 1-24 exit vlan 10 name "Internal" untagged 1-12 no ip address forbid 24 exit vlan 11 name "External" untagged 24 no ip address forbid 1-23 exit vlan 12 name "DATA PLANE MANAGEMENT VLAN" untagged 13 ip address 172.30.1.50 255.255.255.0 ipv6 address fd79:b0fa:2d9f:2::1/64 forbid 1-12,14-24 exit vlan 666 name "UNUSED-PORTS" untagged 14-23 no ip address exit 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-Switch(config)# ip source-interface all vlan 12 HP-Provision-Switch(config)# snmp-server response-source vlan 12 HP-Provision-Switch(config)# snmp-server trap-source vlan 12 Any VLAN can be assigned as the management VLAN. Take 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. There are severe restrictions on the 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 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.

9

Power

Fault

Locator

Status

LED

ModeFan

Test

Reset Clear

RPS

Tmp

Usr

Dual-Personality Port 10/100/1000-T (T) or Mini-GBIC (S)Spd Mode

Us

e o

nly

on

e (

T o

r S

) fo

r e

ac

h P

ort

Auxiliary PortConsole

Link Mode

Link Mode

Link Mode

Link Mode

Link Mode

Link Mode22

21

24

23

22

21

24

23

T

T

T

T

20181614

19171513

121086

11975

42

31

off = 10Mbps

flash = 100Mbps

on = 1000Mbps

10/100Base-TX Ports (1-20) All RJ-45 Ports (1-24T) are Auto MDIX

S

S

S

S

Act

FDx

Spd

HP ProCurve

3500-24

Switch

J9470A

Internal Network

172.16.0.0/16

fd79:b0fa:2d9f:8000::/56

Internal Subnets

172.16.0 – 172.16.255/24

fd79:b0fa:2d9f:8000::/64 -

fd79:b0fa:2d9f:80FF::/64

External

Loopback 0

172.31.0.50/24

fd79:b0fa:2d9f::50/64

RADIUS

SNMPSYSLOG

SNTP

Management

Workstation

Management

172.16.1.0/24

Fd79:b0fa:2d9f:80001::50/64

HP-Provision-Switch(config)# interface loopback 0 HP-Provision-Switch(lo0)# ip address 172.31.0.50 HP-Provision-Switch(lo0)# ipv6 address fd79:b0fa:2d9f::50 Although loopback addresses are always either /32 or /128, we are going to reserve 172.31.0.0/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 172.31.0.50 ipv6 address fd79:b0fa:2d9f::50 exit vlan 1 name "DEFAULT_VLAN" no untagged 1-24 no ip address forbid 1-24 exit vlan 10 name "Internal" untagged 1-12 ip address 172.16.0.50 255.255.255.0 ipv6 address fd79:b0fa:2d9f:8000::50/64 forbid 24 exit

10

vlan 11 name "External" untagged 24 no ip address forbid 1-23 exit vlan 666 name "UNUSED-PORTS" untagged 14-23 no ip address exit 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-Switch(config)# ip source-interface all loopback 0 HP-Provision-Switch(config)# snmp-server response-source loopback 0 HP-Provision-Switch(config)# snmp-server trap-source loopback 0

Step 3: Network Management Protocols

Out of the box, HP Network Provision Switches run Telnet, Simple Network Management Protocol v1/2c (SNMP v1/2c), Trivial File Transfer Protocol (TFTP), and Hypertext Transfer Protocol (HTTP) for device management purposes. These 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.

Telnet vs. Secure Shell Telnet sends all traffic across the wire in clear text. This 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 Secure Shell (SSH) server instead of Telnet server on the switch. SSH uses asymmetric authentication to exchange keys and create a secure encrypted session. It can use DSA and RSA keys and the examples that follow will use RSA. A key size of 2048 is supported and is used in these examples, but some switches can also support 3072. Larger key sizes allow for better security, so be sure to use the largest your switch supports. Follow these steps to enable SSH and disable Telnet: OOBM HP-Provision-Switch(config)# crypto key generate ssh rsa 2048 HP-Provision-Switch(config)# ip ssh listen oobm HP-Provision-Switch(config)# no telnet-server Management VLAN or Loopback Interface Management HP-Provision-Switch(config)# crypto key generate ssh rsa 2048 HP-Provision-Switch(config)# ip ssh listen data HP-Provision-Switch(config)# no telnet-server For all SSH connections, it is always good practice to specify an inactivity timer that will automatically terminate sessions that have been idle for too long. The values are in minutes and you should select one that is best for the way you manage your switches. console inactivity-timer < 0 | 1 | 5 | 10 | 15 | 20 | 30 | 60 | 120 >

11

Secure Shell Clients When an SSH 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. This 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 SSH Client as a “known host”. Many SSH clients support this feature and usually have a help or documentation to describe how to add SSH server public keys to the SSH client. To display an SSH server public key on the switch, use the following command: HP-Provision-Switch(config)# show crypto host-public-key Additional security can be provided by enforcing SSH clients to have public keys of their own. Many SSH 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. The switch can store up to 10 client public keys representing 10 different SSH clients. HP-Provision-Switch(config)# copy tftp pub-key-file <TFTP IP Address> HP-Provision-Switch(config)# aaa authentication ssh login public-key none Only an SSH client with a public key that the switch recognizes will be allowed to establish a connection with the switch. This procedure prevents unknown SSH clients from being able to establish SSH connections with the switch and attempt to find login credentials.

HTTP vs. HTTPS HP Provision switches can be configured through the HTTP interface. The HTTP interface that is started by default has the same limitations as Telnet while an HTTPS interface is HTTP traffic running over a Secure Sockets Layer (SSL). When using HTTPS, it is extremely important the browser be able to validate the HTTPS certificate on the switch. Signed 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 HTTP be disabled and HTTPS not be used. HP-Provision-Switch(config)# no web-management plaintext If the environment can support a signed certificate (i.e., a PKI is in place), the HTTPS interface be configured initially with the HTTP interface. A key pair must be generated, then the HTTP 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 HTTPS interface can be enabled and tested. Once the testing has completed, then the HTTP interface can be disabled. HP-Provision-Switch(config)# crypto key generate cert rsa bits 2048 Then, using the web interface:

12

Fill in the CA request and click “Create request”

Step 2 – Select Create CA Request

Step 1 – Select SSL

13

The Certificate Request can now be copied and sent to the CA in order to issue the certificate. The 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-Switch(config)# web-management ssl HP-Provision-Switch(config)# no web-management plaintext

TFTP vs. SFTP and SCP

Important: This section assumes that the SSH server has been setup as recommended in the SSH section. TFTP client and server should be disabled as they do not require any authentication. Secure File Transfer Protocol (SFTP) and Secure Copy Protocol (SCP) are part of the SSH protocol suite. They provide an encrypted session using public/private keys between client and server just like SSH. 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-Switch(config)# ip ssh filetransfer 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: HP-Provision-Switch(config)# no tftp server HP-Provision-Switch(config)# no tftp client

SNMPv1/2c vs.SNMPv3

SNMP version 2c is enabled by default. This protocol is used to manage switches and routers from a central management server such as PCM. SNMPv2c uses community names for read and write access, much like passwords are used for authentication. These community names are sent across the wire as clear text. If a malicious user were to capture these community names, they could issue SNMP set commands to reconfigure your network device.

14

SNMP version 3 was developed to overcome these weaknesses. It uses cryptography to encrypt and authenticate SNMP traffic over the wire. HP-Provision-Switch(config)# snmpv3 enable HP-Provision-Switch(config)# snmpv3 only For additional configuration examples for SNMPv3, please reference the product manual. It is important to consider user names, groups and privileges when configuring SNMPv3. Further considerations should include cryptography settings. If for any reason SNMPv3 is not an option for your network, you can enable SNMPv2c in restricted mode. This will allow management devices to “get” information from a networking device, but not “set” or change any settings on the networking device. HP-Provision-Switch (config)# snmp-server community <community_name> restricted Some security policies may mandate that SNMP be disabled altogether. HP-Provision-Switch(config)# no snmp-server enable

Legacy IP Stack Management

IP Stack Management allows Legacy Provision 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 Legacy 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: HP-Provision-Switch(config)# show stack Once it’s determined that the IP Stack Management is enabled, it only requires one command to disable: HP-Provision-Switch(config)# no stack Once the IP Stack Management protocol is disabled, the switch cannot become a Commander or a Member.

Step 4: Protecting Management Access

OOBM The 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 The management VLAN is on the Data Plane. As a result, there may be services such as the SSH server that are listening on both the Management VLAN as well as other VLAN IP addresses. We will want to prohibit access to the SSH server on the switch by limiting SSH 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 There 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 Servers 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

15

The 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:

172.16.1.0/24 fd79:b0fa:2d9f:8001::/64

The network diagram is as follows:

Power

Fault

Locator

Status

LED

ModeFan

Test

Reset Clear

RPS

Tmp

Usr

Dual-Personality Port 10/100/1000-T (T) or Mini-GBIC (S)Spd Mode

Us

e o

nly

on

e (

T o

r S

) fo

r e

ac

h P

ort

Auxiliary PortConsole

Link Mode

Link Mode

Link Mode

Link Mode

Link Mode

Link Mode22

21

24

23

22

21

24

23

T

T

T

T

20181614

19171513

121086

11975

42

31

off = 10Mbps

flash = 100Mbps

on = 1000Mbps

10/100Base-TX Ports (1-20) All RJ-45 Ports (1-24T) are Auto MDIX

S

S

S

S

Act

FDx

Spd

HP ProCurve

3500-24

Switch

J9470A

Internal Network

172.16.0.0/16

fd79:b0fa:2d9f:8000::/56

Internal Subnets

172.16.0 – 172.16.255/24

fd79:b0fa:2d9f:8000::/64 -

fd79:b0fa:2d9f:80FF::/64

External

Loopback 0

172.31.0.50/24

fd79:b0fa:2d9f::50/64

RADIUS

SNMPSYSLOG

SNTP

Management

Workstation

Management

172.16.1.0/24

Fd79:b0fa:2d9f:80001::50/64

Let’s describe at a high level what we want to accomplish with Access Control: • We only want the Management Server VLAN to communicate with the Loopback Interface over specific protocols • We only want the Loopback Interface to communicate with the Management Server 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 Source Destination

DNS, SSH, SSL, SNMP, SNMP Trap, SNTP, TACACS+, RADIUS Auth, RADIUS Acct,

fd79:b0fa:2d9f:8001::/64 172.16.1.0/24

fd79:b0fa:2d9f::50/128 172.31.0.50/32

16

Syslog

DNS, SSH, SSL, SNMP, SNMP Trap, SNTP, TACACS+, RADIUS Auth, RADIUS Acct, Syslog

fd79:b0fa:2d9f::50/128 172.31.0.50/32

fd79:b0fa:2d9f:8001::/64 172.16.1.0/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: 172.16.0.50/24 and fd79:b0fa:2d9f:8000::50/64 Here is our Deny table:

Deny Protocols Source Destination

DNS, SSH, SSL, SNMP, SNMP Trap, SNTP, TACACS+, RADIUS Auth, RADIUS Acct, Syslog

Any IPv6 Any IPv4

172.16.0.50 fd79:b0fa:2d9f:8000::50

DNS, SSH, SSL, SNMP, SNMP Trap, SNTP, TACACS+, RADIUS Auth, RADIUS Acct, Syslog

172.16.0.50 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 Source Destination

PERMIT DNS, SSH, SSL, SNMP, SNMP Trap, SNTP, TACACS+, RADIUS Auth, RADIUS Acct, Syslog

fd79:b0fa:2d9f:8001::/64 172.16.1.0/24

fd79:b0fa:2d9f::50/128 172.31.0.50/32

PERMIT DNS, SSH, SSL, SNMP, SNMP Trap, SNTP, TACACS+, RADIUS Auth, RADIUS Acct, Syslog

fd79:b0fa:2d9f::50/128 172.31.0.50/32

fd79:b0fa:2d9f:8001::/64 172.16.1.0/24

DENY DNS, SSH, SSL, SNMP, SNMP Trap, SNTP, TACACS+, RADIUS Auth, RADIUS Acct, Syslog

::/0 0.0.0.0 0.0.0.0

172.16.0.50 fd79:b0fa:2d9f:8000::50

17

Let’s define our incoming ACLs for internal networks so that the switch can understand them. This means that a client will be communicating with some service on the switch. An exception to this is SNTP, which will use a source port of 123. Some ACEs are stricken to indicate they were evaluated but not needed. This 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 SSH 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 SNTP 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 SNMP 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 HTTPS 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 172.16.1.0 0.0.0.255 172.31.0.50 0.0.0.0 eq 22 permit udp 172.16.1.0 0.0.0.255 172.31.0.50 0.0.0.0 eq 123 permit udp 172.16.1.0 0.0.0.255 172.31.0.50 0.0.0.0 eq 161

18

permit tcp 172.16.1.0 0.0.0.255 172.31.0.50 0.0.0.0 eq 443 permit icmp 172.16.1.0 0.0.0.255 172.31.0.50 0.0.0.0 remark deny everything else from the management server subnet to loopback deny tcp 172.16.1.0 0.0.0.255 172.31.0.50 0.0.0.0 log deny udp 172.16.1.0 0.0.0.255 172.31.0.50 0.0.0.0 log remark deny management services to switch IP addresses on VLANs deny tcp any 172.16.0.50 0.0.0.0 eq 22 deny udp any 172.16.0.50 0.0.0.0 eq 123 deny udp any 172.16.0.50 0.0.0.0 eq 161 deny tcp any 172.16.0.50 0.0.0.0 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. Traffic 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

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 172.31.0.50 0.0.0.0 eq 22 172.16.1.0 0.0.0.255 permit udp 172.31.0.50 0.0.0.0 eq 22 172.16.1.0 0.0.0.255 permit tcp 172.31.0.50 0.0.0.0 eq 123 172.16.1.0 0.0.0.255 permit udp 172.31.0.50 0.0.0.0 eq 123 172.16.1.0 0.0.0.255 permit tcp 172.31.0.50 0.0.0.0 eq 161 172.16.1.0 0.0.0.255 permit udp 172.31.0.50 0.0.0.0 eq 161 172.16.1.0 0.0.0.255 permit tcp 172.31.0.50 0.0.0.0 eq 443 172.16.1.0 0.0.0.255 permit udp 172.31.0.50 0.0.0.0 eq 443 172.16.1.0 0.0.0.255 permit tcp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 49 permit udp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 49 permit udp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 53 permit udp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 162 permit udp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 514 permit tcp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 1812 permit udp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 1812 permit tcp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 1813 permit udp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 eq 1813 permit icmp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 remark deny everything else from loopback to management server subnet deny tcp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 log deny udp 172.31.0.50 0.0.0.0 172.16.1.0 0.0.0.255 log remark deny management services to switch IP addresses on VLANs deny tcp 172.16.0.50 0.0.0.0 eq 22 any deny udp 172.16.0.50 0.0.0.0 eq 123 any deny udp 172.16.0.50 0.0.0.0 eq 161 any deny tcp 172.16.0.50 0.0.0.0 eq 443 any deny tcp 172.16.0.50 0.0.0.0 any eq 49 deny udp 172.16.0.50 0.0.0.0 any eq 49 deny tcp 172.16.0.50 0.0.0.0 any eq 53 deny udp 172.16.0.50 0.0.0.0 any eq 53 deny tcp 172.16.0.50 0.0.0.0 any eq 162 deny udp 172.16.0.50 0.0.0.0 any eq 162 deny tcp 172.16.0.50 0.0.0.0 any eq 514 deny udp 172.16.0.50 0.0.0.0 any eq 514 deny tcp 172.16.0.50 0.0.0.0 any eq 1812 deny udp 172.16.0.50 0.0.0.0 any eq 1812 deny tcp 172.16.0.50 0.0.0.0 any eq 1813 deny udp 172.16.0.50 0.0.0.0 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-Switch(config)# vlan 10 ip access-group extended inside-to-inside-outbound out

20

HP-Provision-Switch(config)# vlan 10 ip access-group extended inside-to-inside-inbound in HP-Provision-Switch(config)# vlan 10 ipv6 access-group extended inside-to-inside-outbound out HP-Provision-Switch(config)# vlan 10 ipv6 access-group extended inside-to-inside-inbound in

Step 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. Two 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 Status 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. These credentials, based upon the role they are associated with, grant the user the appropriate permissions.

Username and Password Length The limit on username and password length is 64 characters for our switch management interfaces. Usernames and passwords are case-sensitive. ASCII characters in the range of 33-126 are valid, including: A through Z uppercase characters a through z lower case characters 0 through 9 numeric characters Special characters ‘ ~ ! @ # $ % ^ & * ( ) - _ = + [ ] { } \ | ; : ‘ “ , < > / ? The SPACE character is allowed to form a username or password pass-phrase.The username must be in quotes, for example “The 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 Server

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 RADIUS or TACACS+. The 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 RADIUS server is often a Microsoft IAS/NPS or FreeRADIUS. The various parameters controlling password complexity, 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 Server rather than on the switch itself. HP Provision switches are restricted to using IPv4 when communicating with RADIUS or TACACS+ authentication servers.

Recommendations

• Configure all management access for authentication • Use different usernames than the well-known ‘manager’ and ‘operator’

21

• Use RADIUS or TACACS+ as your primary authentication method • If using RADIUS, use PEAP-MSCHAPv2 as the protocol. • Be sure to configure on your authentication server things like password complexity, 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 RADIUS or TACACS+ 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 RADIUS or TACACS+ is involved, it is better to start with configuring local users even though it will only be used when the RADIUS or TACACS+ server is unavailable. password <manager | operator > [user-name ASCII-STR] [<plaintext | sha1> ASCII-STR] An example of a recommended configuration (except for the actual password value) for local users would be as follows: HP-Provision-Switch(config)# password manager user-name Brontosaurus plaintext 1qazXSW@ HP-Provision-Switch(config)# password manager user-name MammalsRule plaintext 3edcVFR$

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: HP-Provision-Switch (config)# aaa authentication <console|telnet|ssh ><enable|login> tacacs local Caution: TACACS+ cannot authenticate the web agent. Therefore, if the web agent is being used, RADIUS should be used instead. When using TACACS+ servers, you may specify up to three. HP-Provision-Switch (config)# tacacs-server host < ip-addr > [key < key-string > | encrypted-key <keystring>] | [oobm] HP-Provision-Switch (config)# aaa authentication console login tacacs local HP-Provision-Switch (config)# aaa authentication console enable tacacs local HP-Provision-Switch (config)# aaa authentication telnet login tacacs local HP-Provision-Switch (config)# aaa authentication telnet enable tacacs local HP-Provision-Switch (config)# aaa authentication ssh login tacacs local HP-Provision-Switch (config)# aaa authentication ssh enable tacacs local If your TACACS+ servers are on the Data Plan: HP-Provision-Switch (config)# tacacs-server host 10.10.10.2 key HP9Switch~ HP-Provision-Switch (config)# tacacs-server host 10.10.10.3 key HP9Switch~ HP-Provision-Switch (config)# tacacs-server host 10.10.10.4 key HP9Switch~ If your TACACS+ servers are on the Management Plan: HP-Provision-Switch (config)# tacacs-server host 10.10.10.2 key HP9Switch~ oobm HP-Provision-Switch (config)# tacacs-server host 10.10.10.3 key HP9Switch~ oobm HP-Provision-Switch (config)# tacacs-server host 10.10.10.4 key HP9Switch~ oobm

22

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: HP-Provision-Switch (config)# aaa authentication <console|telnet|ssh|web> <enable|login> <radius | peap-mschapv2> local SSH also includes authentication for SCP and SFTP. 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 RADIUS servers, you may specify up to three. HP-Provision-Switch (config)# radius-server host < ip-addr > [key < key-string > | encrypted-key <keystring>] | [oobm] Here are the commands to enable RADIUS authentication as the primary method, and Local as the secondary method, for all the switch management functions HP-Provision-Switch (config)# aaa authentication console login peap-mschapv2 local HP-Provision-Switch (config)# aaa authentication console enable peap-mschapv2 local HP-Provision-Switch (config)# aaa authentication ssh login peap-mschapv2 local HP-Provision-Switch (config)# aaa authentication ssh enable peap-mschapv2 local HP-Provision-Switch (config)# aaa authentication web login peap-mschapv2 local HP-Provision-Switch (config)# aaa authentication web enable peap-mschapv2 local If your RADIUS servers are on the Data Plan: HP-Provision-Switch (config)# radius-server host 10.10.10.2 key HP9Switch~ HP-Provision-Switch (config)# radius-server host 10.10.10.3 key HP9Switch~ HP-Provision-Switch (config)# radius-server host 10.10.10.4 key HP9Switch~ If your RADIUS servers are on the Management Plan: HP-Provision-Switch (config)# radius-server host 10.10.10.2 key HP9Switch~ oobm HP-Provision-Switch (config)# radius-server host 10.10.10.3 key HP9Switch~ oobm HP-Provision-Switch (config)# radius-server host 10.10.10.4 key HP9Switch~ oobm

Server-Supplied 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. This 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. To allow the switch to accept the privilege level provided by the server, use the following configuration command: HP-Provision-Switch (config)# aaa authentication login privilege-mode To supply a privilege level via RADIUS, specify the “Service-Type” attribute in the user’s 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 user’s credentials.

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

RADIUS Accounting It is useful to understand what a user is doing when they login and that is the part RADIUS accounting plays. For the purpose of this whitepaper, the following settings are recommended: HP-Provision-Switch (config)# aaa accounting exec start-stop radius HP-Provision-Switch (config)# aaa accounting system stop-only radius HP-Provision-Switch (config)# aaa accounting commands stop-only radius Note: RADIUS accounting information can be sent to a syslog server rather than a RADIUS server using the following syntax: HP-Provision-Switch (config)# aaa accounting exec start-stop syslog HP-Provision-Switch (config)# aaa accounting system stop-only syslog HP-Provision-Switch (config)# aaa accounting commands stop-only syslog To configure a syslog server, please see the next section.

Step 6: Logging and Time

The 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-Switch (config)# logging <IPv4 or IPv6 address> There are options available for the switch to filter which events are sent to the syslog server. These 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. The 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 SNTP as shown below HP-Provision-Switch (config)# timesync sntp HP-Provision-Switch (config)# sntp authentication key-id xxxxx authentication-mode md5 keyvalue xxxx HP-Provision-Switch (config)# sntp unicast HP-Provision-Switch (config)# sntp server priority 1 <IPv4 or IPv6 address> HP-Provision-Switch (config)# sntp server priority 2 <IPv4 or IPv6 address>