You are on page 1of 23

Technical white paper

Management Security for HP Networking


Provision Switches
October 2012

Table of contents
Executive Summary

Step 0: Determine the Plane


Management Plane
Data Plane
Plane Separation
Physical Security

3
3
3
4
4

Step 1: Protecting the Data Plane

Step 2: Configuring Management Access


Management Plane: Serial Console
Management Plane: OOBM
Data Plane: Management VLAN
Data Plane: Loopback IP Addresses

5
6
6
7
8

Step 3: Network Management Protocols


Telnet vs. Secure Shell
Secure Shell Clients
HTTP vs. HTTPS
TFTP vs. SFTP and SCP
SNMPv1/2c vs.SNMPv3
Legacy IP Stack Management

10
10
11
11
13
13
14

Step 4: Protecting Management Access

14

Step 5: Authentication and Accounting


Username and Password Length
Authentication Server
Recommendations
Configuring Local Users
TACACS+ Authentication
RADIUS Authentication
Server-Supplied Privilege Level
RADIUS Accounting

20
20
20
20
21
21
22
22
23

Step 6: Logging and Time

23

Executive Summary
Security is a growing concern in todays 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-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
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
doesnt 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 well discuss these throughout the document.

Data Plane
Management Virtual Local Area Network (VLAN): A VLAN with severe network restrictions focused only on switch
management.

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 dont know. If the network connection of the console server is on the Data Plane, well,
that probably wasnt 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 dont want to put Management VLAN ports or
other Data Plane ports on that network we wouldnt be maintaining separation just as we wouldnt 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 switchs 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.

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 modules 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)

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 switchs
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.
HP E3800
24G-2SFP+
Switch

LED
Mode

Act

FDx

Spd

PoE

Usr

Cmd

Stk

Stacking
Status

Fan

Mdl

PS

Status of
the Back

Spd Mode:

J9573A

Fault
Locator

Status

Off = 10 Mbps,

flash = 100 Mbps,

on = 1000+ Mbps

1-GbE/10-GbE SFP+ Ports

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


Link

Mode

11

Link

13

Mode

15

17

19

21

23

Link

25

Mode

Link

Mode

10

12

Link

14

Mode

16

18

20

22

24

Link

26

Mode

Mgmt

PoE
Tmp
Test

Console

Aux
Port

Reset

Clear

External

OOBM
192.168.0.50/24

RADIUS
SYSLOG
SNMP

Use only supported transceivers

Power

Internal Network
172.16.0.0/16
fd79:b0fa:2d9f:8000::/56

SNTP

Internal Subnets
172.16.0 172.16.255/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 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 doesnt 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]

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

Status
RPS
Tmp

Fault

Fan

10/100Base-TX Ports (1-20)

off = 10Mbps
flash = 100Mbps

All RJ-45 Ports (1-24T) are Auto MDIX

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

Link

Mode

11

Link

13

Mode

15

17

19

21T

23T

Link

21 S

Mode

23 S

Link

Mode

10

12

Link

14

Mode

16

18

20

22T

24T

Link

22 S

Mode

24 S

on = 1000Mbps

LED
Mode

FDx

Reset

Clear

Spd
Usr

Test

Locator

Spd Mode

Act

Console

Auxiliary Port

Use only one (T or S) for each Port

HP ProCurve
3500-24
Switch
J9470A

Power

MANAGEMENT VLAN
172.30.1.50/24
fd79:b0fa:2d9f:2::50/64

External

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

SNTP
SYSLOG

RADIUS

SNMP

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:

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.

Status
RPS
Tmp

Fault

Fan

10/100Base-TX Ports (1-20)

off = 10Mbps
flash = 100Mbps

All RJ-45 Ports (1-24T) are Auto MDIX

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

Link

Mode

11

Link

13

Mode

15

17

19

21T

23T

Link

21 S

Mode

23 S

Link

Mode

10

12

Link

14

Mode

16

18

20

22T

24T

Link

22 S

Mode

24 S

on = 1000Mbps

LED
Mode

FDx

Reset

Clear

Spd
Usr

Test

Locator

Spd Mode

Act

Console

Auxiliary Port

Use only one (T or S) for each Port

HP ProCurve
3500-24
Switch
J9470A

Power

Loopback 0
172.31.0.50/24
fd79:b0fa:2d9f::50/64

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

Management
172.16.1.0/24
Fd79:b0fa:2d9f:80001::50/64

Management
Workstation
RADIUS
SYSLOG
SNTP

SNMP

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

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 >

10

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 switchs serial port,
using a show command to display the switchs 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 clients 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:

11

Step 2 Select Create CA


Request

Step 1 Select SSL

Fill in the CA request and click Create request

12

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.

13

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 its 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 shouldnt
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

14

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

flash = 100Mbps

Act
LED
Mode

FDx

Reset

Clear

Fan

10/100Base-TX Ports (1-20)

off = 10Mbps

All RJ-45 Ports (1-24T) are Auto MDIX

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

Link

Mode

11

Link

13

Mode

15

17

19

21T

23T

Link

21 S

Mode

23 S

Link

Mode

10

12

Link

14

Mode

16

18

20

22T

24T

Link

22 S

Mode

24 S

on = 1000Mbps

Tmp

Spd
Usr

Test

Locator

Spd Mode

Console

Auxiliary Port

Use only one (T or S) for each Port

HP ProCurve
3500-24
Switch
J9470A
Status
RPS

Loopback 0
172.31.0.50/24
fd79:b0fa:2d9f::50/64

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

Management
172.16.1.0/24
Fd79:b0fa:2d9f:80001::50/64

Management
Workstation
RADIUS
SYSLOG
SNTP

SNMP

Lets 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 doesnt 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
DNS, SSH, SSL, SNMP, fd79:b0fa:2d9f:8001::/64
172.16.1.0/24
SNMP Trap, SNTP,
TACACS+, RADIUS
Auth, RADIUS Acct,

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

15

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
IPv6
DNS, SSH, SSL, SNMP, Any
Any IPv4
SNMP Trap, SNTP,
TACACS+, RADIUS
Auth, RADIUS Acct,
Syslog
DNS, SSH, SSL, SNMP, 172.16.0.50
fd79:b0fa:2d9f:8000::50
SNMP Trap, SNTP,
TACACS+, RADIUS
Auth, RADIUS Acct,
Syslog

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

Any IPv6
Any IPv4

Lets combine the two tables into one which will form the beginning of any ACL used by the switch.

Protocols
Source
fd79:b0fa:2d9f:8001::/64
PERMIT
172.16.1.0/24
DNS, SSH, SSL, SNMP,
SNMP Trap, SNTP,
TACACS+, RADIUS
Auth, RADIUS Acct,
Syslog
fd79:b0fa:2d9f::50/128
PERMIT DNS, SSH,
172.31.0.50/32
SSL, SNMP, SNMP
Trap, SNTP,
TACACS+, RADIUS
Auth, RADIUS Acct,
Syslog
::/0
DENY
0.0.0.0 0.0.0.0
DNS, SSH, SSL, SNMP,
SNMP Trap, SNTP,
TACACS+, RADIUS
Auth, RADIUS Acct,
Syslog

16

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

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

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

Lets 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
permit udp
172.16.1.0
0.0.0.255
permit udp
172.16.1.0
0.0.0.255

172.31.0.50
172.31.0.50
172.31.0.50

0.0.0.0
0.0.0.0
0.0.0.0

eq 22
eq 123
eq 161

17

permit tcp
172.16.1.0
0.0.0.255
172.31.0.50
0.0.0.0
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
deny
udp
172.16.1.0
0.0.0.255
172.31.0.50
0.0.0.0
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

eq 443
log
log

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.
Lets 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

deny
udp
fd79:b0fa:2d9f:8000::50/128
deny
tcp
fd79:b0fa:2d9f:8000:50/128
deny
udp
fd79:b0fa:2d9f:8000:50/128
deny
tcp
fd79:b0fa:2d9f:8000::50/128
deny
udp
fd79:b0fa:2d9f:8000::50/128
deny
tcp
fd79:b0fa:2d9f:8000:50/128
deny
udp
fd79:b0fa:2d9f:8000:50/128
deny
tcp
fd79:b0fa:2d9f:8000::50/128
deny
udp
fd79:b0fa:2d9f:8000::50/128
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

any
any
any
any
any
any
any
any
any

eq 53
eq 162
eq 162
eq 514
eq 514
eq 1812
eq 1812
eq 1813
eq 1813

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

19

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, weve 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

20

Configure all management access for authentication


Use different usernames than the well-known manager and operator

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

21

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 users 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 users credentials.
Service-Type = 6 allows manager-level access
Service-Type = 7 allows operator-level access
A user with Service-Type not equal to 6 or 7 is denied access
A user with no Service-Type attribute supplied is denied access when privilege mode is enabled
To supply a privilege level via TACACS specify the Max Privilege level in the users credentials.

22

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>

23

You might also like