Security Handbook

Network Management Card 3, Firmware Version

2.3.x
Network Management Card for Easy UPS, 1-Phase
& 3-Phase, Firmware v2.x
990-91251H-001
Publication Date: August, 2022
Schneider Electric IT Corporation Legal Disclaimer
The information presented in this manual is not warranted by the Schneider Electric IT Corporation to be
authoritative, error free, or complete. This publication is not meant to be a substitute for a detailed operational
and site specific development plan. Therefore, Schneider Electric IT Corporation assumes no liability for
damages, violations of codes, improper installation, system failures, or any other problems that could arise
based on the use of this Publication.
The information contained in this Publication is provided as is and has been prepared solely for the purpose of
evaluating data center design and construction. This Publication has been compiled in good faith by Schneider
Electric IT Corporation. However, no representation is made or warranty given, either express or implied, as to
the completeness or accuracy of the information this Publication contains.
IN NO EVENT SHALL SCHNEIDER ELECTRIC IT CORPORATION, OR ANY PARENT, AFFILIATE OR
SUBSIDIARY COMPANY OF SCHNEIDER ELECTRIC IT CORPORATION OR THEIR RESPECTIVE
OFFICERS, DIRECTORS, OR EMPLOYEES BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE, SPECIAL, OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR
LOSS OF BUSINESS, CONTRACT, REVENUE, DATA, INFORMATION, OR BUSINESS INTERRUPTION)
RESULTING FROM, ARISING OUT, OR IN CONNECTION WITH THE USE OF, OR INABILITY TO USE THIS
PUBLICATION OR THE CONTENT, EVEN IF SCHNEIDER ELECTRIC IT CORPORATION HAS BEEN
EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SCHNEIDER ELECTRIC IT
CORPORATION RESERVES THE RIGHT TO MAKE CHANGES OR UPDATES WITH RESPECT TO OR IN
THE CONTENT OF THE PUBLICATION OR THE FORMAT THEREOF AT ANY TIME WITHOUT NOTICE.
Copyright, intellectual, and all other proprietary rights in the content (including but not limited to software, audio,
video, text, and photographs) rests with Schneider Electric IT Corporation or its licensors. All rights in the
content not expressly granted herein are reserved. No rights of any kind are licensed or assigned or shall
otherwise pass to persons accessing this information.
This Publication shall not be for resale in whole or in part.
Table of Contents
Introduction ........................................................................ 1
Content and Purpose of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Types of User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Secure SHell (SSH) and Secure CoPy (SCP) for the Command Line Interface 7
Transport Layer Security (TLS) for the Web interface . . . . . . . .7
Creating and Installing Digital Certificates . . . . . . . . . . . . . . . . .8
Choosing a Method for your System . . . . . . . . . . . . . . . . . . . . . .9
Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Vulnerability Reporting and Management . . . . . . . . . . . . . . . . . . . . . . 12

How to report a vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Using the NMC Security Wizard CLI Utility...................... 13

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authentication by Certificates and Host Keys . . . . . . . . . . . . . .13
Files you Create for TLS and SSH Security . . . . . . . . . . . . . . .14

Create a Root Certificate and Server Certificates . . . . . . . . . . . . . . . . 14

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Procedure for Creating the CA Root Certificate . . . . . . . . . . . .15
Load the CA Root Certificate to your Browser . . . . . . . . . . . . .16
Create an SSL/TLS Server Certificate . . . . . . . . . . . . . . . . . . .16
Load the Server Certificate to the Management Card or Device 16

Create a Server Certificate and Signing Request. . . . . . . . . . . . . . . . . 17

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Procedure for Creating the Certificate Signing Request (CSR) 17
Import the Signed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Load the Server Certificate to the Management Card or Device 18

Create an SSH Host Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Procedure for Creating the Host Key . . . . . . . . . . . . . . . . . . . .18
Load the Host Key to the Management Card or Device . . . . . .19

Security Handbook i
Using the ssl command in the Command Line Interface .20
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Configure the NMC’s HTTPS certificate . . . . . . . . . . . . . . . . . . . . . . . 20

Display the current NMC HTTPS certificate . . . . . . . . . . . . . . 20
Create a new private key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Configure the certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

NMC Security Wizard CLI Utility Backwards Compatibility . . . . . . . . . 21

Command Line Interface Access and Security ................22

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Telnet and Secure SHell (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Web Interface Access and Security .................................24

HTTP and HTTPS (with TLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

RADIUS ...........................................................................26
Supported RADIUS Functions and Servers. . . . . . . . . . . . . . . . . . . . . 26
Supported functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Supported RADIUS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Configure the Management Card or Device . . . . . . . . . . . . . . 26
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Configure the RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . 27
Example using Service-Type Attributes . . . . . . . . . . . . . . . . . 27
Examples using Vendor Specific Attributes . . . . . . . . . . . . . . . 27
RADIUS Users file with VSAs . . . . . . . . . . . . . . . . . . . . . . . . . 28
Example with UNIX shadow passwords . . . . . . . . . . . . . . . . . 29

Secure Disposal Guidelines.............................................30

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Delete device contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Dispose of physical device . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Appendix 1: Network Management Card Security Deployment

Guide ...............................................................................31
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Best Practices for the Network Management Card . . . . . . . . . 31

ii Security Handbook
 Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Description of Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Device Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Software Patch Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Privileged Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Use of Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Minimum Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
SSH Host Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
No Unattended Console Sessions . . . . . . . . . . . . . . . . . . . . . .33
No Unnecessary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Background and Description of Risk . . . . . . . . . . . . . . . . . . . . .33
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Network Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Other Security Detection and Monitoring Tools . . . . . . . . . . . .34

Appendix 2: Network Management Card Security Hardening

Checklist .......................................................................... 35

Security Handbook iii

 Introduction

Content and Purpose of this Guide

This guide documents security features for firmware version 2.3.x of the APC® Network Management
Card 3, firmware v2.x of the Network Management Card for Easy UPS, and for devices with embedded
components of APC Network Management Cards, which enable the devices to function remotely over the
network.
This guide documents the following protocols and features, how to select which ones are appropriate for
your situation, and how to set up and use them within an overall security system:
• Telnet and Secure SHell v2 (SSH)
• Transport Layer Security (TLS) v1.1 and v1.2
• RADIUS
• Extensible Authentication Protocol over LAN (EAPoL)
• SNMPv1 and SNMPv3
• Wi-Fi
• Secure Boot with Root of Trust for enhanced security
In addition, this guide documents how to use the NMC Security Wizard CLI utility, and the ssl and ssh
commands in the Command Line Interface (CLI) to create the components required for the high security
available through TLS and SSH.
Note: The NMC Security Wizard CLI utility can create security components for Management Cards or
devices running firmware version 1.1.0.16 and higher. The ssl and ssh commands are available in
firmware version 1.4 and higher.
Note: If you upgrade to firmware version 2.0.x or higher, you cannot downgrade to a firmware version
lower than 2.0.x.

User Management
Types of User Accounts
The Network Management Card has five basic levels of access:
• A Super User: can use all of the management menus available in the Web interface and all of the
commands in the command line interface.
• Administrative User: can use all of the management menus available in the Web interface and all of
the commands in the command line interface.
• A Device User: can access the event log and data log (but cannot delete the contents of either log),
and can use the device-related menus and commands.
• Network-Only User: can only access network-related information.
• A Read-Only User: can access the event log, data log, and device-related menus, but cannot
change configurations, control devices, delete data, delete the content of logs, or use file transfer
options.
Note: Some APC devices have additional user accounts, e.g., outlet users for Switched Rack PDUs and
an A/C Manager for some NetworkAIR devices. For information on the additional account type, see the
User’s Guide provided with the device.
Note: A Super User is an Administrator account which is persistent and cannot be deleted but can still be
enabled or disabled.

Security Handbook 1
 Note: The Administrative, Device, Network-Only, and Read-Only user accounts are disabled by default,
and cannot be enabled until a password is set for each user account.

Security
Security Features

Protection of passwords and passphrases

No password or passphrase is stored on the Network Management Card in plain text.
• Passwords are hashed using a one-way hash algorithm.
• Passphrases, which are used for authentication and encryption, are encrypted before they are
stored on the Network Management Card.

Summary of access methods

Serial access to the command line interface.
Security Access Description

Access is by user Always enabled

name and password
and by security level

Remote access to the command line interface

Security Access Description

Available methods: Available methods:

• User name and • Telnet
password
• Selectable server port – With Telnet, the user name and password are
• Access protocols that transmitted as plain text.
can be enabled or • SSH
disabled.
• Secure SHell (SSH) – For high security, use SSH. SSH provides
encrypted access to the command line
interface, to provide additional protection
from attempts to intercept, forge, or alter data
during transmission. If you select SSH as
your remote access protocol, disable Telnet.

Note: Telnet is disabled, and SSH is enabled by default.

2 Security Handbook
 SNMPv1 and SNMPv3
Security Access Description

Available methods For both SNMPv1 and SNMPv3, the host name restricts
(SNMPv1)*: access to the Network Management System (NMS) at that
• Community Name location only, and the NMS IP filters allow access only to the
• Host Name
NMSs specified by one of the IP address formats in the
• NMS IP filters
• Agents that can be following examples:
enabled or disabled • 159.215.12.1: Only the NMS at the IP address
• Four access 159.215.12.1.
communities
• 159.215.12.255: Any NMS on the 159.215.12
• with read/write/disable
capability segment.
• 159.215.255.255: Any NMS on the 159.215
Available methods
(SNMPv3): segment.
• Four User Profiles • 159.255.255.255: Any NMS on the 159 segment.
• Authentication through
an authentication • 0.0.0.0 or 255.255.255.255: Any NMS.
passphrase • SNMPv3 has additional security features that
• Encryption through a include the following:
privacy passphrase
• SHA or MD5 – An authentication passphrase to ensure that
authentication an NMS trying to access the Management
• AES or DES encryption Card or device is the NMS it claims to be.
algorithm – Encryption of data during transmission, with a
• NMS IP filters privacy passphrase required for encrypting
and decrypting.

Note: SNMPv1 and SNMPv3 are disabled by default.

* SNMPv2c is also supported by SNMPv1 and its configuration settings.

File transfer protocols

Security Access Description

Available methods: Available methods:

• User name and
• FTP
password
• Selectable server port – With FTP, the user name and password are
• Access protocols that transmitted as plain text, and files are
can be enabled or transferred without encryption.
disabled. • SCP
• Secure CoPy (SCP)
– Use SCP to encrypt the user name and
password and the files being transferred,
such as firmware updates, configuration files,
log files, .fwl files, Transport Layer Security
(TLS) certificates, EAPoL certificates, and
Secure SHell (SSH) host keys. If you choose
SCP as your file transfer protocol, enable
SSH and disable FTP.

Note: FTP is disabled, and SCP is enabled by default.

Security Handbook 3
 Web Server
Security Access Description

Available methods: Available methods:

• User name and • HTTP
password
– In basic HTTP authentication mode, the user
• Selectable server port
name and password are transmitted as plain
• Web interface access text (with no encoding or encryption).
that can be enabled or
• TLS
disabled
• Transport Layer Security – TLS is available on Web browsers supported
(TLS) for use with the Management Card or
network-enabled device and on most Web
servers. The Web protocol HyperText
Transfer Protocol over Secure Sockets Layer
(HTTPS) encrypts and decrypts page
requests to the Web server and pages
returned by the Web server to the user.

Note: HTTP is disabled, and HTTPS is enabled by default.

RADIUS
Security Access Description

Available methods: RADIUS (Remote Authentication Dial-In User Service) is an

• A server secret shared authentication, authorization, and accounting service used to
between the RADIUS centrally administer remote access for each Management
server and the Card or device. (APC supports the authentication and
Management Card or authorization functions.)
device
• The RADIUS server
name or IP address (IPv4
or IPv6) and port

EAPoL (802.1X Security)

Security Access Description

Available methods: Extensible Authentication Protocol (EAP) over LAN (EAPoL) is

• Access to network ports a network port authentication protocol used in 802.1X (port-
based on RADIUS server based Network Access Control)
authorization

Wi-Fi
Security Access Description

Available methods: Wi-Fi (wireless fidelity) is a wireless network technology that

• Network name (SSID) allows the Management Card or device to interface with the
and security type (WPA, Internet, and is an alternative to using a wired LAN
WPA2-AES, WPA2- connection.
Mixed, WPA2-TKIP, or
WPA2-Enterprise)

4 Security Handbook
 Change default user names and passwords immediately
After installation and initial configuration of the Management Card or network-enabled device,
immediately change the user names and passwords from their defaults to unique user names and
passwords to establish basic security. You are required to change the default Super User password at first
log in as a security measure.
Note: You cannot change the user name of the Super User. It is recommended that the Super User
account is disabled, once any additional Administrator accounts are created.
Port assignments
If the Telnet, FTP, SSH/SCP, or the Web server uses a non-standard port, a user must specify the port in
the command line or Web address used to access the Management Card or device. A non-standard port
number provides an additional level of security. The ports are initially set at the standard “well known
ports” for the protocols. To increase security, change the ports to any unused port numbers from 5001 to
32768 for the FTP server and from 5000 to 32768 for the other protocols and servers. (The FTP server
uses both the specified port and the port one number lower than the specified port.)
User names, passwords, and community names with SNMPv1
All user names, passwords, and community names for SNMPv1 are transferred over the network as plain
text. A user who is capable of monitoring the network traffic can determine the user names and passwords
required to log on to the accounts of the command line interface or Web interface of the Management
Card or network-enabled device. If your network requires the higher security of the encryption-based
options available for the command line interface and Web interface, disable SNMPv1 access or set its
access to Read. (Read access allows you to receive status information and use SNMPv1 traps.)
To disable SNMPv1 access on the Configuration tab, select Network on the top menu bar and select
Access under the SNMPv1 heading. Clear the Enable SNMPv1 access check box and click Apply.
To set SNMPv1 access to Read, perform the following steps: On the Configuration tab select Network.
Select SNMPv1 and then Access Control. For each configured Network Management System (NMS),
click the community names and set the Access Type to Read. Select Apply.
Note: SNMPv1 is disabled by default and the Community Names are blank.
Wi-Fi Security
Wi-Fi support is available in firmware version v1.4.x and higher with the optional APC USB Wi-Fi Device
(AP9834). Enabling wi-fi will disable the wired LAN connection. The NMC will reboot when the wi-fi
settings are configured. After the reboot, the wired connection will be disabled and the NMC will attempt to
connect to the given Network Name (SSID).
To enable wi-fi, a Security Type must be selected: WPA, WPA2-AES, WPA2-Mixed, WPA2-TKIP, or
WPA2-Enterprise. If you have an enterprise network with RADIUS, it is highly recommended that you
choose WPA2-Enterprise as this is the most secure option. If you do not have an enterprise network, it is
recommended you select WPA2-AES which uses a pre-shared password. However, AES may not be
supported on older access points.
If your access point does not support AES, it is recommended you choose WPA2-Mixed which will use
AES, TKIP, or WPA depending on what is supported. Selecting WPA2-TKIP will use TKIP for encryption,
which is deprecated and not recommended. WPA is the oldest and least secure option and also not
recommended.
For information on how to configure wi-fi, refer to the APC USB Wi-Fi Device Quick Start Guide, NMC 3
User Guide, and NMC 3 CLI Guide.
For a list of supported TLS ciphers and key exchanges of the Wi-Fi Device, see Knowledge Base article
FA416486.

Security Handbook 5
 Authentication
You can choose security features for the Management Card or network-enabled device that control
access by providing basic authentication through network port access, user names, passwords, and IP
addresses, without using encryption. These basic security features are sufficient for most environments in
which sensitive data are not being transferred.
As an added layer of security, network-based port access via EAPoL can also be utilized to request
network access at the individual port level via the network’s switch or router (where applicable) which the
Management Card is connected.

Password Requirements and Recommendations

It is highly recommended that you enable strong passwords. If enabled, new passwords created for user
accounts require:
• Minimum 8 and maximum 64 characters in length
• One upper and lower case letter
• One number and special character
• The username also cannot be part of the password.
For enhanced security, it is recommended that you also enable the Password Policy and Bad Login
Attempts features in the Web UI (Configuration > Security > Local Users > Default Settings).
• Password Policy: If enabled, all user account passwords must be changed after a user-specified
duration between 0 - 365 days. The default value is 0, never.
• Bad Login Attempts: This feature mitigates brute force attacks by locking user accounts after a
user-specified number of unsuccessful logins between 0-99. When a user account is locked, it
must be re-enabled by the Super User account, or a user account with Administrator privileges.

SNMP GETS, SETS, and Traps

For enhanced authentication when you use SNMP to monitor or configure the Management Card or
network-enabled device, choose SNMPv3. The authentication passphrase used with SNMPv3 user
profiles ensures that a Network Management System (NMS) attempting to communicate with the
Management Card or device is the NMS it claims to be, that the message has not been changed during
transmission, and that the message was not delayed, copied, and sent again later at an inappropriate
time. SNMPv3 is disabled by default.
The APC implementation of SNMPv3 allows the use of the SHA-1 or MD5 protocol for authentication.
Web interface and command line interface
To ensure that data and communication between the Management Card or network-enabled device and
the client interfaces (the command line interface and the Web interface) cannot be intercepted, you can
provide a greater level of security by using one or more of the following encryption-based methods:
• For the Web interface, use the Transport Layer Security (TLS) protocol
• To encrypt user names and passwords for command line interface access, use the Secure SHell
(SSH) protocol
• To encrypt user names, passwords, and data for the secure transfer of files, use the Secure CoPy
(SCP) protocol.
Note: For more information on encryption-based security, see Encryption.

6 Security Handbook
 Encryption

SNMP, GETS, SETS, and Traps

For encrypted communication when you use SNMP to monitor or configure the Management Card or
network-enabled device, choose SNMPv3. The privacy passphrase used with SNMPv3 user profiles
ensures the privacy of the data (by means of encryption, using the AES or DES encryption algorithm) that
an NMS sends to or receives from the Management Card or device.

Secure SHell (SSH) and Secure CoPy (SCP) for the Command Line Interface

The Secure SHell protocol

SSH provides a secure mechanism to access computer consoles, or shells, remotely. The protocol
authenticates the server (in this case, the Management Card or network-enabled device) and encrypts all
transmissions between the SSH client and the server.
• SSH is a high-security alternative to Telnet. Telnet does not provide encryption.
• SSH protects the user name and password, which are the credentials for authentication, from being
used by anyone intercepting network traffic.
• To authenticate the SSH server (the Management Card or network-enabled device) to the SSH
client, SSH uses a host key unique to the SSH server. The host key is an identification that cannot
be falsified, and it prevents an invalid server on the network from obtaining a user name and
password by presenting itself as a valid server.
Note: For information on supported SSH client applications, see Telnet and Secure SHell (SSH). To
create a host key, see Create an SSH Host Key.
The Management Card or device supports SSHv2, which provides protection from attempts to intercept,
forge, or change data during transmission.
• When you enable SSH, you should disable Telnet. Note: Telnet is disabled, and SSH is enabled by
default.
• The interface, user accounts, and user access rights are the same whether you access the
command line interface through SSH or Telnet.

Secure CoPy
SCP is a secure file transfer application that you can use instead of FTP. SCP uses the SSH protocol as
the underlying transport protocol for encryption of user names, passwords, and files.
• When you enable and configure SSH, you automatically enable and configure SCP. No further
configuration of SCP is needed.
• You must explicitly disable FTP. It is not disabled by enabling SSH. To disable FTP, on the
Configuration tab, select Network and then FTP Server. Clear the Enable check box and click
Apply. Note: Telnet is disabled, and SSH is enabled by default.

Transport Layer Security (TLS) for the Web interface

For secure Web communication, enable Transport Layer Security (TLS) by selecting HTTPS as the
protocol mode to use for access to the Web interface of the Management Card or network-enabled
device. HyperText Transfer Protocol over Secure Sockets Layer (HTTPS) is a Web protocol that encrypts
and decrypts page requests from the user and pages that are returned by the Web server to the user. The
Management Card or network-enabled device supports Transport Layer Security (TLS) versions 1.1 and
1.2.

Security Handbook 7
 Note: The Management Card automatically negotiates to use the highest supported protocol or cipher
suite that is supported by the Management Card and the client. Use the client-side settings to enable/
disable certain protocols or cipher suites. Alternatively, the various cipher suites/algorithms the
Management Card supports can be configured via the CLI interface. The Minimum Protocol field can also
be configured to be used to force the minimal protocol (TLS 1.1 or TLS 1.2 to use when negotiating a
connection.
Note: When TLS is enabled, your browser displays a small lock icon.
TLS uses a digital certificate to enable the browser to authenticate the server (in this case, the
Management Card or device). The browser verifies the following:
• The format of the server certificate is correct.
• The expiration date and time of the server certificate have not passed.
• The DNS name or IP address specified when a user logs on matches the Common Name (or
Subject Alt Name) in the server certificate.
• The server certificate is signed by a trusted certifying authority Each major browser manufacturer
distributes CA root certificates of the commercial Certificate Authorities in the certificate store
(cache) of its browser so that it can compare the signature on the server certificate to the signature
on a CA root certificate.

You can use the NMC Security Wizard CLI utility to create a certificate signing request to an external
Certificate Authority, or if you do not want to use an existing Certificate Authority, you can create an APC
root certificate to upload to the certificate store (cache) of the browser. You can also use the utility to
create a server certificate to upload to the Management Card or device.
Note: See Creating and Installing Digital Certificates for a summary of how these certificates are used. To
create certificates and certificate requests, see Create a Root Certificate and Server Certificates and
Create a Server Certificate and Signing Request.
SSL/TLS also uses various algorithms and encryption ciphers to authenticate the server, encrypt data,
and ensure the integrity of the data, i.e., that it has not been intercepted and sent by another server.
Note: Web pages that you have recently accessed are saved in the cache of your Web browser and allow
you to return to those pages without re-entering your user name and password. Always close your
browser session before you leave your computer unattended.

Creating and Installing Digital Certificates

Purpose
For network communication that requires a higher level of security than password encryption, the Web
interface of the Management Card or network-enabled device supports the use of digital certificates with
the Transport Layer Security (TLS) protocol. Digital certificates can authenticate the Management Card or
device (the server) to the Web browser (the TLS client).
Note: In firmware version 1.4.x and higher, you can generate ECDSA keys. It is highly recommended you
generate ECDSA keys over RSA keys as they provide a higher level of security.
The sections that follow summarize the three methods of creating, implementing, and using digital
certificates to help you determine the most appropriate method for your system.
• Method 1: Use the default certificate auto-generated by the Network Management Card or network-
enabled device (ECDSA P-256-bit).
Note: AOS 1.1.0.16 and higher use a SHA-2 signature algorithm.
• Method 2: Use the NMC Security Wizard CLI utility to create a CA certificate and a server
certificate.
• Method 3: Use the NMC Security Wizard CLI utility to create a certificate-signing request to be
signed by the root certificate of an external Certificate Authority and to create a server certificate.
Note: You can also use Method 3 if your company or agency operates its own Certificate Authority.

8 Security Handbook
 Use the NMC Security Wizard CLI utility in the same way, but use your own Certificate Authority in
place of a commercial Certificate Authority.
• Method 4: Use the ssh and ssl commands in the CLI. See Using the ssl command in the
Command Line Interface for more information.

Choosing a Method for your System

Using the Transport Layer Security (TLS) protocol, you can choose any of the following methods for using
digital certificates.
Method 1: Use the default certificate auto-generated by the Network Management Card or
network-enabled device.
When you enable TLS, you must reboot the Management Card or device. During rebooting, if no server
certificate exists, the Management Card or device generates a default server certificate that is self-signed
but that you cannot configure.
Method 1 has the following advantages and disadvantages.
Advantages:
• Before they are transmitted, the user name and password and all data to and from the
Management Card or device are encrypted.
• You can use this default server certificate to provide encryption-based security while you are
setting up either of the other two digital certificate options, or you can continue to use it for the
benefits of encryption that TLS provides.

Disadvantages:
• This method does not include the authentication provided by a CA certificate (a certificate signed
by a Certificate Authority) that Methods 2 and 3 provide. There is no CA Certificate cached in the
browser. Therefore, when you log on to the Management Card or device, the browser generates a
security alert, indicating that a certificate signed by a trusted authority is not available, and asks if
you want to proceed. To avoid this message, you must install the default server certificate into the
certificate store (cache) of the browser of each user who needs access to the Management Card or
device, and each user must always use the fully qualified domain name of the server when logging
on to the Management Card or device.
• The default server certificate has the serial number of the Management Card or device in place of a
valid Common Name or Subject Alt Name (the DNS name or the IP address of the Management
Card or device). Therefore, although the Management Card or device can control access to its
Web interface by user name, password, and account type (e.g., Super User, Administrator,
Device-Only User, or Read-Only User), the browser cannot authenticate which Management
Card or device is sending or receiving data. Note: The Common Name will be the hostname of the
NMC after it completes its reset operation.

Method 2: Use the NMC Security Wizard CLI utility to create a CA certificate and a server
certificate
Use the NMC Security Wizard CLI utility to create two digital certificates:
• CA root certificate (Certificate Authority root certificate) that the NMC Security Wizard CLI utility
uses to sign all server certificates and which you then install into the certificate store (cache) of the
browser of each user who needs access to the Management Card or device.
• A server certificate that you upload to the Management Card or device. When the NMC Security
Wizard CLI utility creates a server certificate, it uses the CA root certificate to sign the server
certificate.

Security Handbook 9
 The Web browser authenticates the Management Card or device sending or requesting data:
• To identify the Management Card or device, the browser uses the Common Name or Subject Alt
Name (IP address or DNS name of the Management Card or device) that was specified in the
server certificate’s distinguished name when the certificate was created.
• To confirm that the server certificate is signed by a “trusted” signing authority, the browser
compares the signature of the server certificate with the signature in the root certificate cached in
the browser. An expiration date confirms whether the server certificate is current.
Method 2 has the following advantages and disadvantages.
Advantages
Before they are transmitted, the user name and password and all data to and from the Management Card
or device are encrypted.
• You choose the length of the public key (RSA key) that is used for encryption when setting up a
TLS session (use 2048-bit to provide complex encryption and a high level of security).
• The server certificate that you upload to the Management Card or device enables TLS to
authenticate that data is being received from and sent to the correct Management Card or device.
This provides an extra level of security beyond the encryption of the user name, password, and
transmitted data.
• The root certificate that you install to the browser enables the browser to authenticate the server
certificate of the Management Card or device to provide additional protection from unauthorized
access.

Disadvantage
Because the certificates do not have the digital signature of a commercial Certificate Authority, you must
load a root certificate individually into the certificate store (cache) of each user’s browser. (Browser
manufacturers already provide root certificates for commercial Certificate Authorities in the certificate
store within the browser, as described in Method 3.)

10 Security Handbook
 Method 3: Use the NMC Security Wizard CLI utility to create a certificate-signing request
to be signed by the root certificate of an external Certificate Authority and to create a
server certificate.
Use the NMC Security Wizard CLI utility to create a request (a .csr file) to send to a Certificate Authority.
The Certificate Authority returns a signed certificate (a .crt file or .cer file typically) based on information
you submitted in your request. You then use the NMC Security Wizard CLI utility to create a server
certificate (a .p15 file) that includes the signature from the root certificate returned by the Certificate
Authority. Upload the server certificate to the Management Card or device.
Note: You can also use Method 3 if your company or agency operates its own Certificate Authority. Use
the NMC Security Wizard CLI utility in the same way, but use your own Certificate Authority in place of a
commercial Certificate Authority.
Method 3 has the following advantages and disadvantages.
Advantages
Before they are transmitted, the user name and password and all data to and from the Management Card
or device are encrypted.
• You have the benefit of authentication by a Certificate Authority that already has a signed root
certificate in the certificate cache of the browser. (The CA certificates of commercial Certificate
Authorities are distributed as part of the browser software, and a Certificate Authority of your own
company or agency has probably already loaded its CA certificate to the browser store of each
user’s browser.) Therefore, you do not have to upload a root certificate to the browser of each user
who needs access to the Management Card or device.
• You choose the length of the public key (RSA key) that is used for setting up a TLS session (use
2048-bit to provide complex encryption and a high level of security).
• The server certificate that you upload to the Management Card or device enables TLS to
authenticate that data are being received from and sent to the correct Management Card or device.
This provides an extra level of security beyond the encryption of the user name, password, and
transmitted data.
• The browser matches the digital signature on the server certificate that you uploaded to the
Management Card or device with the signature on the CA root certificate that is already in the
browser’s certificate cache to provide additional protection from unauthorized access.

Disadvantages
Setup requires the extra step of requesting a signed root certificate from a Certificate Authority.
• An external Certificate Authority may charge a fee for providing signed certificates.

Security Handbook 11
 Firewalls
Although some methods of authentication provide a higher level of security than others, complete
protection from security breaches is almost impossible to achieve. Well-configured firewalls are an
essential element in an overall security scheme.
Logs: The Active Firewall Policy Log lists the most recent firewall events, including the protocol, traffic,
action, and rule priority, in reverse chronological order.
Note: This log is not persistent and can hold up to 50 events.
Configuration: Enable or disable the overall firewall functionality.
Active Policy: Select an active policy from the available firewall policies.
Active Rules: Lists the individual rules that are being enforced based on the current active policy. Note:
This option is only available when the firewall is enabled.
Create/Edit Policy: Create a new policy or edit an existing one.
Load Policy: Load a policy file (.fwl suffix) from a source external to this device.
Test Policy: Temporarily enforce the rules of a chosen policy.

Vulnerability Reporting and Management

How to report a vulnerability
Please direct your submission to Technical Support and include the following information:
• Product Line
• Vulnerable version
• Vulnerability type [CWE ID, if available]
• Organization name
• Email
• Phone number
• Country

12 Security Handbook
 Using the NMC Security Wizard CLI Utility

Overview
The NMC Security Wizard CLI utility creates components needed for high security for a Management
Card or network-enabled device on the network when you are using Transport Layer Security (TLS) and
related protocols and encryption routines.
Note: The NMC Security Wizard CLI utility can create security components for Management Cards or
devices running firmware 1.1.0.16 or higher.

Authentication by Certificates and Host Keys

Authentication verifies the identity of a user or a network device (such as an APC Network Management
Card or network-enabled device). Passwords typically identify computer users. However, for transactions
or communications requiring more stringent security methods on the Internet, the Management Card or
device supports more secure methods of authentication.
• Transport Layer Security (TLS), used for secure Web access, uses digital certificates for
authentication. A digital CA root certificate is issued by a Certificate Authority (CA) as part of a
public key infrastructure, and its digital signature must match the digital signature on a server
certificate on the Management Card or device.
• Secure SHell (SSH), used for remote terminal access to the command line interface of the
Management Card or device, uses a public host key for authentication.

How certificates are used

Most Web browsers, including all browsers supported by Network Management Cards or network-
enabled devices, contain a set of CA root certificates from all of the commercial Certificate Authorities.
Authentication of the server (in this case, the Management Card or device) occurs each time a connection
is made from the browser to the server. The browser checks to be sure that the server’s certificate is
signed by a Certificate Authority known to the browser. For authentication to occur:
• Each server (Management Card or device) with TLS enabled must have a server certificate on the
server itself.
• Any browser that is used to access the Web interface of the Management Card or device must
contain the CA root certificate that signed the server certificate. If authentication fails, a browser
message asks you whether to continue even though it cannot authenticate the server.
If your network does not require the authentication provided by digital certificates, you can use the default
certificate that the Management Card or device generates automatically. The default certificate’s digital
signature will not be recognized by browsers, but a default certificate enables you to use TLS for the
encryption of transmitted user names, passwords, and data. (If you use the default certificate, the browser
prompts you to agree to unauthenticated access before it logs you on to the Web interface of the
Management Card or device.)
How SSH host keys are used
An SSH host key authenticates the identity of the server (the Management Card or device) each time an
SSH client contacts that server. Each server with SSH enabled must have an SSH host key on the server
itself.

Security Handbook 13
 Files you Create for TLS and SSH Security
Use the NMC Security Wizard CLI to create these components of a TLS and SSH security system:
• The server certificate for the Management Card or network-enabled device, if you want the benefits
of authentication that such a certificate provides. You can create either of the following types of
server certificate:
a. A server certificate signed by a custom CA root certificate also created with the NMC
Security Wizard CLI. Use this method if your company or agency does not have its own
Certificate Authority and you do not want to use an external Certificate Authority to sign the
server certificate.
b. A server certificate signed by an external Certificate Authority. This Certificate Authority can
be one that is managed by your own company or agency or can be one of the commercial
Certificate Authorities whose CA root certificates are distributed as part of a browser’s
software.
• A certificate signing request containing all the information required for a server certificate except
the digital signature. You need this request if you are using an external Certificate Authority.
• A CA root certificate
• An SSH host key that your SSH client program uses to authenticate the Management Card or
device when you log on to the command line interface.
Note: You define whether the public keys for TLS certificates and the host keys for SSH that are created
with the NMC Security Wizard CLI are 2048-bit RSA keys (the default setting), or 1024-bit RSA keys,
which provide complex encryption and a higher level of security.
Note: NMC Security Wizard CLI uses the SHA-2 signature algorithm.
Note: If you do not create and use TLS server certificates and SSH host keys with the NMC Security
Wizard CLI, the Management Card or device generates 2048-bit RSA keys using the SHA-2 signature
algorithm.
Only APC server management and key management products can use server certificates, host keys, and
CA root certificates created by the NMC Security Wizard CLI. These files will not work with products such
as OpenSSL® and Microsoft® Internet Information Services (IIS).

Create a Root Certificate and Server Certificates

Summary
Use this procedure if your company or agency does not have its own Certificate Authority and you do not
want to use a commercial Certificate Authority to sign your server certificates.
Note: Define the size of the public RSA key that is part of the certificate generated by the NMC Security
Wizard CLI. You can generate a 1024-bit key, or you can generate a 2048-bit key, which provides complex
encryption and a higher level of security. (The default key generated by the Management Card or network-
enabled device, if you do not use the NMC Security Wizard CLI, is 2048 bits.)

14 Security Handbook
 Create a CA root certificate that will sign all server certificates to be used with Management Cards or
devices. During this task, two files are created:
• The file with the .p15 suffix is an encrypted file that contains the Certificate Authority’s private key
and public root certificate. This file signs server certificates.
• The file with the .crt suffix contains only the Certificate Authority’s public root certificate. Load this
file into each Web browser that will be used to access the Management Card or device so that the
browser can validate the server certificate of that Management Card or device.
• Create a server certificate, which is stored in a file with a .p15 suffix. During this task, you are
prompted for the CA root certificate that signs the server certificate.
• Load the server certificate onto the Management Card or device.
• For each Management Card or device that requires a server certificate, repeat the tasks that create
and load the server certificate.

Procedure for Creating the CA Root Certificate

1. If the NMC Security Wizard CLI is not already extracted to a folder on your computer, double-click
the self-extracting archive to extract the necessary files.
2. Open a command prompt and navigate to the folder containing the extracted NMC Security
Wizard CLI files.
3. Issue the below command and complete the fields to create the CA Root Certificate:
NMCSecurityWizardCLI --caroot -o <file> -n <common_name> -c <country> [-
m <state_province> -l <locality> -g <organization> -u <organization-
al_unit> -e <email> -f <validity_from> -t <validity_to> -i <uri_name> -d
<dns_name> -a <ip_address>]
Note: Enter a name for this file using the -o flag, which will contain the certificate authority’s public root
certificate and private key. The file must not contain a suffix/file extension and, by default, will be created in
the current folder.
Note: You can use the -k flag to specify the length of the key to generate (use 1024 bits or 2048 bits,
which is the default setting, to provide complex encryption and a high level of security).
Note: When you provide the information to an internal/public CA, the Country and Common Name fields
are the only required fields. For the Common Name field, enter an identifying name of your company or
agency. Use only alphanumeric characters, with no spaces.
Note: By default, a CA root certificate is valid for 4 years from the current date, but you can edit the Validity
Period Start and Validity Period End fields.

Security Handbook 15
 Load the CA Root Certificate to your Browser
Load the .crt file to the browser of each user who needs to access the management card or device.
Note: See the help system of the browser for information on how to load the .crt file into the browser’s
certificate store (cache). Following is a summary of the procedure for Microsoft Internet Explorer.
1. Select Tools, then Internet Options from the menu bar.
2. In the dialog box, on the Content tab click Certificates and then Import.
3. The Certificate Import Wizard guides you through the rest of the procedure. The file type to select
is X.509, and the CA Public Root Certificate is the .crt file created in the procedure Create a Root
Certificate and Server Certificates.
Create an SSL/TLS Server Certificate
1. Open a command prompt and navigate to the folder containing the extracted NMC Security
Wizard CLI files.
2. Issue the below command and complete the fields to create the SSL Server Certificate:
NMCSecurityWizardCLI --sslcert -o <file> -r <file> -n <common_name> -c
<country> [-m <state_province> -l <locality> -g <organization> -u <orga-
nizational_unit> -e <email> -f <validity_from> -t <validity_to> -i
<uri_name> -d <dns_name> -a <ip_address>]
Note: Enter a name for this file using the -o flag, which will contain the SSL server certificate and
corresponding browser certificate. The file must not contain a suffix/file extension and, by default,
will be created in the current folder with the .p15 and .crt extensions respectively.
Note: Enter the name for the CA Public Root Certificate using the -r flag. The value must not
contain the suffix/file extension of the actual file.
Note: You can use the -k flag to specify the length of the key to generate (use 1024 bits or 2048
bits, which is the default setting, to provide complex encryption and a high level of security).
Note: When you provide the information to configure the CA root certificate, the Country and
Common Name fields are the only required fields. For the Common Name field, enter an identify-
ing name of your company or agency. Use only alphanumeric characters, with no spaces.
Note: By default, a CA root certificate is valid for 4 years from the current date, but you can edit the
Validity Period Start and Validity Period End fields.
Note: Because the configuration information is part of the signature, the information for every cer-
tificate must be unique. The configuration of a server certificate cannot be the same as the config-
uration of the CA root certificate. (The expiration date is not considered part of the unique
configuration. Some other configuration information must also differ.
3. The output will then display the certificate issuer and certificate subject information. If any
information is incorrect, rerun the command with the correct values.
Load the Server Certificate to the Management Card or Device
1. Select: Configuration > Network > Web > SSL Certificate tab
2. Select Add or Replace Certificate File, and browse to the server certificate, the .p15 file you
created in the procedure Create a Root Certificate and Server Certificates.
Note: You can use FTP or Secure CoPy (SCP) instead to transfer the server certificate. An example
command for SCP to transfer a certificate named cert.p15 to a Management Card or device with an IP
address of 156.205.6.185 would be: scp cert.p15 apc@156.205.6.185:ssl/cert.p15. Then, import the
server certificate using the ssl command in the CLI. For example: ssl key -i ssl/cert.p15. For
more information, see the CLI Guide.
Note: SCP utilities may have different command syntax.

16 Security Handbook
 Create a Server Certificate and Signing Request
Summary
Use this procedure if your company or agency has its own Certificate Authority or if you plan to use a
commercial Certificate Authority to sign your server certificates.
• Create a Certificate Signing Request (CSR). The CSR contains all the information for a server
certificate except the digital signature. This process creates two output files:
a. The file with the .p15 suffix contains the private key of the Management Card or device.
b. The file with the .csr suffix contains the certificate signing request, which you send to an
external Certificate Authority.
• When you receive the signed certificate from the Certificate Authority, import that certificate.
Importing the certificate combines the .p15 file containing the private key and the file containing the
signed certificate from the external Certificate Authority. The output file is a new encrypted server
certificate file with a .p15 suffix.
• Load the server certificate onto the Management Card or device.
• For each Management Card or device that requires a server certificate, repeat the tasks that create
and load the server certificate.

Procedure for Creating the Certificate Signing Request (CSR)

1. If the NMC Security Wizard CLI is not already extracted to a folder on your computer, double-click
the self-extracting archive to extract the necessary files.
2. Open a command prompt and navigate to the folder containing the extracted NMC Security
Wizard CLI files.
3. Issue the below command and complete the fields to create the Certificate Signing Request:
NMCSecurityWizardCLI --csr -o <file> -n <common_name> -c <country>
[-m <state_province> -l <locality> -g <organization> -u <organization-
al_unit> -e <email> -i <uri_name> -d <dns_name> -a <ip_address>]

Note: Enter a name for this file using the -o flag, which will contain the certificate signing request
and corresponding private key. The file must not contain a suffix/file extension and, by default, will
be created in the current folder with the .csr and .p15 extensions respectively.
Note: You can use the -k flag to specify the length of the key to generate (use 1024 bits or 2048
bits, which is the default setting, to provide complex encryption and a high level of security).
Note: When you provide the information to configure the CA root certificate, the Country and
Common Name fields are the only required fields. For the Common Name field, enter an identify-
ing name of your company or agency. Use only alphanumeric characters, with no spaces.
Note: By default, a CA root certificate is valid for 4 years from the current date, but you can edit the
Validity Period Start and Validity Period End fields.
4. Send the certificate signing request to an external Certificate Authority, either a commercial
Certificate Authority or, if applicable, a Certificate Authority managed by your own company or
agency.
Note: See the instructions provided by the Certificate Authority regarding the signing and issuing of server
certificates.

Security Handbook 17
 Import the Signed Certificate
When the external Certificate Authority returns the signed certificate, import the certificate. This procedure
combines the signed certificate and the private key into an SSL/TLS server certificate that you then
upload to the Management Card or device.
1. Open a command prompt and navigate to the folder containing the extracted NMC Security
Wizard CLI files
2. Issue the below command and complete the fields to create the SSL/TLS Server Certificate:
NMCSecurityWizardCLI --import -o <file> -s <file> -p <file>

Note: Enter a name for this file using the -o flag, which will contain the SSL/TLS server certificate.
The file must not contain a suffix/file extension and, by default, will be created in the current folder
with the .p15 extension.
Note: Enter a name for this file using the -s flag, which contains the signed server certificate. The
file must contain a suffix/file extension of .cer or .crt.
Note: Enter a name for this file using the -p flag, which contains the private key. The file must not
contain a suffix/file extension, but locally will have the .p15 extension.
3. The output will then display the Issuer Information on the summary screen which confirms that the
external Certificate Authority signed the certificate.
Load the Server Certificate to the Management Card or Device
1. Select: Configuration > Network > Web > SSL Certificate
2. Select Add or Replace Certificate File, and browse to the server certificate, the .p15 file you
created in the procedure Create a Root Certificate and Server Certificates.
Note: You can use FTP or Secure CoPy (SCP) instead to transfer the server certificate. An example
command for SCP to transfer a certificate named cert.p15 to a Management Card or device with an IP
address of 156.205.6.185 would be: scp cert.p15 apc@156.205.6.185:ssl/cert.p15. Then, import the
server certificate using the ssl command in the CLI. For example: ssl key -i ssl/cert.p15. For
more information, see the CLI Guide.
Note: SCP utilities may have different command syntax.

Create an SSH Host Key

Summary
This procedure is optional. If you select SSH encryption, but do not create a host key, the Management
Card or device generates a 2048-bit RSA key when it reboots. You define whether the host keys for SSH
that are created with the NMC Security Wizard CLI are 1024-bit or 2048-bit RSA keys.
Note: You can generate a 1024-bit key, or you can generate a 2048-bit key, which provides complex
encryption and a higher level of security.
• Use the NMC Security Wizard CLI to create a host key, which is encrypted and stored in a file with
the .p15 suffix.
• Load the host key onto the Management Card or device.

Procedure for Creating the Host Key

1. If the NMC Security Wizard CLI is not already extracted to a folder on your computer, double-click
the self-extracting archive to extract the appropriate files.
2. Open a command prompt and navigate to the folder containing the extracted NMC Security
Wizard CLI files.
3. Issue the below command and complete the fields to create the SSH Server Host Key:

NMCSecurityWizardCLI --sshkey -o <file>

18 Security Handbook
 Note: Enter a name for this file using the -o flag, which will contain the SSH server host key. The
file must not contain a suffix/file extension and, by default, will be created in the current folder with
the .p15 extension.
Note: You can use the -k flag to specify the length of the key to generate (use 1024 bits or 2048
bits, which is the default setting, to provide complex encryption and a high level of security).
Load the Host Key to the Management Card or Device
1. Select: Configuration > Network > Console > SSH Host Key
2. Select Add or Replace Host Key, and browse to the host key, the .p15 file you created in the
procedure Create the host key.
3. At the bottom of the User Host Key page, note the SSH fingerprint. Log on to the Management
Card or device through your SSH client program and verify that the correct host key was uploaded
by verifying that these fingerprints match the fingerprints that the client program displays.
Note: Alternatively, you can use FTP or Secure CoPy (SCP) to transfer the host key file to the
Management Card or device. An example command for SCP to transfer a host key named hostkey.p15
to a Management Card or device with an IP address of 156.205.6.185 would be: scp hostkey.p15
apc@156.205.6.185:ssh/hostkey.p15. Then, import the server certificate using the ssh command in the
CLI. For example: ssh key -i ssh/cert.p15. For more information, see the CLI Guide.
Note: SCP utilities may have different command syntax.

Security Handbook 19
 Using the ssl command in the Command
Line Interface

Overview
The topic details how to use the ssl command in the Command Line Interface (CLI) to configure the
NMC’s Web UI (HTTPS) certificate. It can be used as an alternative to the NMC Security Wizard CLI
utility.
Note: The ssl command is available in firmware version 1.4 and higher.

The examples provided assumes that:

• “apc” is the NMC admin user
• “192.168.1.204” is the NMC IPv4 address
• “nmc.csr” is the created Certificate Signing Request (CSR)
• “nmc.crt” is the certificate signed by a Certificate Authority (CA)
The examples below show a shorthand syntax where the NMC CLI command follows an SSH invocation.
All the commands following “ssh apc@192.168.1.204” are NMC CLI commands and may be typed at any
NMC CLI command prompt. For more information, see the CLI Guide.
Note: You will be prompted to enter your NMC user name and password.

Configure the NMC’s HTTPS certificate

Display the current NMC HTTPS certificate
Display the currently configured NMC HTTPS certificate:
ssh apc@192.168.1.204 ssl cert -s

Create a new private key

1. Delete the existing NMC HTTPS key:
ssh apc@192.168.1.204 ssl key -d
2. Generate a new NMC HTTPS key:
ssh apc@192.168.1.204 ssl key -ecdsa 256
Configure the certificate
Configuring the certificate is a three step process:
1. Create a Certificate Signing Request (CSR) and download it from the NMC:
a. Create a Certificate Signing Request (CSR) from active configuration:
ssh apc@192.168.1.204 ssl csr -q
b. Download the created CSR:
scp apc@192.168.1.204:ssl/nmc.csr nmc.csr

20 Security Handbook
 2. Create a certificate signed by a Certificate Authority (CA). How a CA creates a certificate from a
CSR is beyond the scope of this example. There are many examples online on how to use
Certificate Authorities to sign certificates, including how to create your own CA.
– The Certificate Authority (CA) creates a signed certificate (nmc.crt) from the CSR (nmc.csr).
3. Upload and import the signed certificate. Note: The NMC certificate to be imported must match
the NMC key used to create the NMC CSR in step 1.
a. Upload the NMC certificate using Secure Copy:
scp nmc.crt apc@192.168.1.204:ssl/nmc.crt
b. Import the certificate:
ssh apc@192.168.1.204 ssl cert -i ssl/nmc.crt

The NMC HTTPS certificate configuration is complete and the NMC HTTPS interface is available for
immediate use.

NMC Security Wizard CLI Utility Backwards Compatibility

The ssl and ssh commands in the Command Line Interface (CLI) provide backwards compatibility with
the NMC Security Wizard CLI Utility.
• Upload an NMC Security Wizard CLI utility nmc.p15 file:

scp nmc.p15 apc@192.168.1.204:ssl/nmc.p15

• Import an NMC Security Wizard CLI utility nmc.p15 file:

ssh apc@192.168.1.204 ssl key -i ssl/nmc.p15

Security Handbook 21
 Command Line Interface Access and
Security

Introduction
All user accounts can access the command line interface through Telnet or Secure SHell (SSH),
depending on which is enabled. (A Super User or Administrator can enable these access methods by
selecting the Configuration > Network > Console > Access. By default, Telnet is disabled, and SSH is
enabled.
The CLI commands available will depend on the user account accessing the command line interface. For
example: the console command is only available to the Super User, Administrator, and Network Only
User accounts.

Telnet for basic access. Telnet provides the basic security of authentication by user name and
password, but not the high-security benefits of encryption.
SSH for high-security access. If you use the high security of TLS for the Web interface, use Secure
SHell (SSH) for access to the command line interface. SSH encrypts user names, passwords and
transmitted data.

The interface, user accounts, and user access rights are the same whether you access the command line
interface through SSH or Telnet, but to use SSH, you must first configure SSH and have an SSH client
program installed on your computer.

Telnet and Secure SHell (SSH)

If SSH is enabled, you should disable Telnet access the command line interface, for improved security.
Enabling SSH enables SCP automatically.
Note: When SSH is enabled and its port is configured, no further configuration is required to use Secure
CoPy (SCP). SCP uses the same configuration as SSH. To use SSH, you must have an SSH client
installed. Most Linux and other UNIX® platforms include an SSH client, but Microsoft Windows operating
systems do not. SSH clients are available from various vendors.
To configure the options for Telnet and Secure SHell (SSH):
• On the Configuration tab of the Web interface, select Network on the top menu bar, and select
Access under the Console heading.
• Configure the port settings for Telnet and SSH.
Note: For information on the extra security a non-standard port provides, see Port assignments.
• Select: Configuration > Network > Console > SSH Host Key. Specify a host key file previously
created with the APC Security Wizard, and load it to the Management Card or device.
• Import the SSH key using the ssh command in the CLI. For example: ssh key -i ssh/
cert.p15. For more information, see the CLI Guide.
If you do not specify a host key file here, if you install an invalid host key, or if you enable SSH with no host
key installed, the Management Card or device generates an ECDSA host key of 256 bits. For the
Management Card or device to create a host key, it must reboot. The Management Card or device can
take up to 1 minute to create this host key, and SSH is not accessible during that time.

22 Security Handbook
 Note: Alternatively, from a command line interface such as the command prompt on Windows operating
systems, you can use FTP or Secure CoPy (SCP) to transfer the host key file.
• Display the fingerprint of the SSH host key for SSH version 2. Most SSH clients display the
fingerprint at the start of a session. Compare the fingerprint displayed by the client to the fingerprint
that you recorded from the Web interface or command line interface of the Management Card or
device.

Security Handbook 23
 Web Interface Access and Security

HTTP and HTTPS (with TLS)

HyperText Transfer Protocol (HTTP) provides access by user name and password, but does not encrypt
user names, passwords, and data during transmission. HyperText Transfer Protocol over Secure Sockets
Layer (HTTPS) encrypts user names, passwords, and data during transmission, and provides
authentication of the Management Card or device by means of digital certificates. By default, HTTP is
disabled, and HTTPS is enabled.
Note: See Creating and Installing Digital Certificates to choose among the several methods for using
digital certificates.
To configure HTTP and HTTPS:
• On the Configuration tab, select Network on the top menu bar and Access under the Web tab.
• Enable either HTTP or HTTPS and configure the ports that each of the two protocols will use.
Changes take effect the next time you log on. When TLS is activated, your browser displays a
small lock icon.
Note: For information on the extra security a non-standard port provides, see Port assignments.
• Select: Configuration > Network > Web > SSL Certificate to determine whether a server
certificate is installed on the Management Card or device. If a certificate was created with the NMC
Security Wizard CLI utility but is not installed:
a. In the Web interface, browse to the certificate file and upload it to the Management Card or
device.
b. Alternatively, use the Secure CoPy (SCP) protocol or FTP to upload the certificate file to the
/ssl folder of the Management Card or device. Then, import the certificate using the ssl
command in the CLI. For example: ssl key -i ssl/cert.p15. For more information,
see the CLI Guide.
Note: Creating and uploading a server certificate in advance reduces the time required to enable HTTPS.
If you enable HTTPS with no server certificate loaded, the Management Card or device creates one when
it reboots.
Note: A certificate that the Management Card or device generates has some limitations. See Method 1:
Use the default certificate auto-generated by the Network Management Card or network-enabled device.
• If a valid digital server certificate is loaded, the Status field displays the link Valid Certificate. Click
the link to display the parameters of the certificate.

24 Security Handbook
 Parameter Description

Common Name (CN): The IP Address or DNS name of the

Management Card or device. This field controls how you must
log on to the Web interface.
• If an IP address was specified for this field when the
certificate was created, use an IP address to log on.
• If the DNS name was specified for this field when the
certificate was created, use the DNS name to log on.

Note: Full certificate properties can be verified via the

browser.

Issued To: If you do not use the IP address or DNS name that was
specified for the certificate, authentication fails, and you
receive an error message asking if you want to continue. For
a server certificate generated by default by the Management
Card or device, this field displays the serial number of the
Management Card or device instead. Organization (O),
Organizational Unit (OU), and Locality, Country: The
name, organizational unit, and location of the organization
using the server certificate. For a server certificate generated
by default by the Management Card or device, the
Organizational Unit (OU) field displays “N/A.” Serial
Number: The serial number of the server certificate.

Common Name (CN): The Common Name as specified in

the CA root certificate. For a server certificate generated by
default by the Management Card or device, this field is the
host name of the device.
Issued By:
Organization (O) and Organizational Unit (OU): The name
and organizational unit of the organization that issued the
server certificate. If the server certificate was generated by
default by the Management Card or device, this field displays
“Internally Generated Certificate.”

Issued on: The date and time at which the certificate was
issued.
Validity:
Expires on: The date and time at which the certificate
expires.

Each of the two fingerprints is a long string of alphanumeric

characters, punctuated by colons. A fingerprint is a unique
identifier to further authenticate the server. Record the
fingerprints to compare them with the fingerprints contained in
the certificate, as displayed in the browser.
Fingerprints
SHA1 Fingerprint: A fingerprint created by a Secure Hash
Algorithm (SHA-1).

Note: This does not represent the signature hash algorithm

used on the certificate.

Security Handbook 25
 RADIUS

Supported RADIUS Functions and Servers

Supported functions
APC supports the authentication and authorization functions of Remote Authentication Dial-In User
Service (RADIUS). Use RADIUS to administer remote access for each Management Card or network-
enabled device centrally. When a user accesses the Management Card or device, an authentication
request is sent to the RADIUS server to determine the permission level of the user.
Note: For more information on permission levels, see Types of user accounts.

Supported RADIUS Servers

FreeRADIUS v1.x and v2.x, and Microsoft Server 2008 and 2012 Network policy Server (NPS) are
supported. Other commonly available RADIUS applications may work, but may not have been fully tested.

Configure the Management Card or Device

Authentication
Note: RADIUS user names used with APC Network Management Cards or devices are limited to 64
characters.
On the Configuration tab, select Security on the top menu bar. Then, under Remote Users on the left
navigation menu, select authentication to define an authentication method:
• Local Authentication Only: RADIUS is disabled. Local authentication is enabled.
• RADIUS, then Local Authentication: Both RADIUS and local authentication are enabled.
Authentication is requested from the RADIUS server first; local authentication is used only if the
RADIUS server fails to respond.
• RADIUS Only: RADIUS is enabled. Local authentication is disabled.
Note: If RADIUS Only is selected, and the RADIUS server is unavailable, improperly identified, or
improperly configured, remote access is unavailable to all users. You must use a serial connection to the
command line interface and change the RADIUS access setting to local or radiusLocal to regain access.
For example, the command to change the access setting to local would be: radius -a local.
Note: RADIUS configuration supports Password Authentication Protocol (PAP) only.
Note: To login serially to RADIUS, Remote Authentication Override (Configuration > Security >
Session Management) and Serial Remote Authentication Override (Configuration > Security >
Local Users > Management) must be enabled. For more information, see the NMC User Guide.

RADIUS
To configure RADIUS, on the Configuration tab, select Security on the top menu bar. Then, under
Remote Users on the left navigation menu, select RADIUS.
Settings Description

The server name or IP address of the RADIUS server.

RADIUS

The port of the RADIUS server (1812 by default). The NMC

Port
also supports ports 0-65535.

The secret shared between the RADIUS server and the

Secret
Management Card or device.

26 Security Handbook
 Settings Description

The time in seconds that the Management Card or device

Reply Timeout
waits for a response from the RADIUS server.

Enter the Administrator user name and password to test the

Test Settings
RADIUS server configuration.

Skip Test and Apply Do not test the RADIUS server configuration.

Configure the RADIUS Server

You must configure your RADIUS server to work with the Management Card or device. The examples in
this section may differ somewhat from the required content or format of your specific RADIUS server. In
the examples, any reference to outlets applies only to APC devices that support outlet users.
• Add the IP address of the Management Card or device to the RADIUS server client list (file).
• Users must be configured with Service-Type attributes unless Vendor Specific Attributes (VSAs)
are defined instead. If no Service-Type attribute is configured, the user has read-only access (to
the Web interface only). The two acceptable values for Service-Type are Administrative-User (6),
which gives the user Administrator permissions, and Login-User (1), which gives the user Device
permissions.
Note: See your RADIUS server documentation for information about the RADIUS users file.

Example using Service-Type Attributes

In the following example of a RADIUS users file:
– UPSAdmin corresponds to Service-Type: Administrative-User, (6)
– UPSDevice corresponds to Service-Type: Login-User, (1)
– UPSReadOnly corresponds to Service-Type: null

UPSAdmin Auth-Type = Local, Password = "admin"

Service-Type = Administrative-User
UPSDevice Auth-Type = Local, Password = "device"
Service-Type = Login-User
UPSReadOnly Auth-Type = Local, Password = "readonly"

Examples using Vendor Specific Attributes

Vendor Specific Attributes (VSAs) can be used instead of the Service-Type attributes provided by your
RADIUS server. This method requires a dictionary entry and a RADIUS users file. In the dictionary file,
you can define the names for the ATTRIBUTE and VALUE keywords, but not the numeric values. If you
change the numeric values, RADIUS authentication and authorization will not work correctly. VSAs take
precedence over standard RADIUS attributes.
Dictionary file. Following is an example of a RADIUS dictionary file (dictionary.apc):
#
# dictionary.apc
#
#
VENDOR APC 318
#

Security Handbook 27
 # Attributes
#
ATTRIBUTE APC-Service-Type 1 integer APC
ATTRIBUTE APC-Outlets 2 string APC
VALUE APC-Service-Type Admin 1
VALUE APC-Service-Type Device 2
VALUE APC-Service-Type ReadOnly 3
#
# For devices with outlet users only
#
VALUE APC-Service-Type Outlet 4

RADIUS Users file with VSAs

Following is an example of a RADIUS users file with VSAs:
VSAAdmin Auth-Type = Local, Password = "admin"
APC-Service-Type = Admin
VSADevice Auth-Type = Local, Password = "device"
APC-Service-Type = Device
VSAReadOnly Auth-Type = Local, Password = "readonly"
APC-Service-Type = ReadOnly
# Give user access to device outlets 1, 2 and 3.
VSAOutlet Auth-Type = Local, Password = "outlet"
APC-Service-Type = Outlet,
APC-Outlets = "1,2,3"

Note: The information below applies to AP8xxx SKUs when using the Network Port Sharing (NPS)
feature.
# give user access to outlets 1,2, and 3 on unit 1,
# outlet 7 on unit 2, outlets 1 through 6
# on unit 3, and outlets 1,2,4 through 6, 7 through 10,
# and 20 on unit 4
newOutletUser Auth-Type = Local, User-Password = "newoutlets"
APC-Service-Type = Outlet,
APC-Outlets = "1[1,2,3];2[7];3[1-6];4[1,2,4-6,7-10,20];"
Note: See the following related topics:
• Types of User Accounts for information on the three basic user permission levels (Super User/
Administrator, Device User, and Read-Only User). If your APC device has an additional user
account type, e.g., outlet user for a Switched Rack PDU, see the User’s Guide provided with your
device for information on the additional account type.
• Supported RADIUS Servers for information on RADIUS servers tested and supported by APC.

28 Security Handbook
 Example with UNIX shadow passwords
If UNIX shadow password files are used (/etc/passwd) with the RADIUS dictionary files, the following two
methods can be used to authenticate users:
• If all UNIX users have administrative privileges, add the following to the RADIUS “user” file. To
allow only Device Users, change the APC-Service-Type to Device.
DEFAULT Auth-Type = System
APC-Service-Type = Admin
• Add user names and attributes to the RADIUS "user" file, and verify the password against /etc/
passwd. The following example is for users bconners and thawk:
bconners Auth-Type = System
APC-Service-Type = Admin
thawk Auth-Type = System
APC-Service-Type = Outlet
APC-Outlets = "1,2,3"
Additionally, the Network Management Card provides a mechanism for RADIUS to be overridden on a
per-user basis. This allows a specific account to login serially even when the NMC authentication is set to
RADIUS. To enable this feature, navigate to Configuration > Security > Session Management and
enable the Remote Authentication Override feature. Now you can go into each user account
(Configuration > Security > Local Users > Management) and enable the Serial Remote Authentication
Override check box for each user you want to allow this override for.

Security Handbook 29
 Secure Disposal Guidelines

Introduction
This topic outlines how to reset the Network Management Card to its default settings and erase all user
information and configurations.

Delete device contents

To reset the Network Management Card or network-enabled device:
• Method 1: Hold down the Reset button on the NMC’s faceplate for 20 seconds, ensuring the
NMC’s Status LED is pulsing green during this time. When the LED changes to amber or orange,
release the Reset button to allow the format function to complete and for the NMC to complete its
reboot process.
• Method 2: Log in to the command line interface as a Super User or Administrator and issue the
format command, followed by the reboot command. For more information on these commands,
see the CLI Guide on the APC website.
NOTE: This will reset the Management Card to its default values and remove all information. If
you are copying your configuration to another NMC, it is recommended you export your
config.ini file before resetting the device. See Knowledge Base article FA156131 for
information on how to retrieve the config.ini file.

Dispose of physical device

For information on how to physically dispose of the Network Management Card or network-enabled
device and destroy its volatile memory, please consult the Statement of Volatility document available on
the APC website.

30 Security Handbook
 Appendix 1: Network Management Card
Security Deployment Guide

Overview
As network security continues to grow and change in the fast-paced IT industry, user requirements for
security solutions are becoming a requirement for system delivery. The Network Management Card
(NMC) interfaces are implemented to provide users with as much flexibility as possible. Industry standard
security implementation coupled with the flexibility of the Network Management Card, enables products to
exist in different user environments.

Best Practices for the Network Management Card

To maintain security throughout the deployment lifecycle, Schneider Electric recommends reviewing the
following considerations for:
• Physical Security
• Device Security
• Network Security
Note: Different deployments may require different security considerations.
This document provides general security guidance to help you decide on an appropriate secure
deployment based on your specific security requirements.

Physical Security
Deploy the equipment in a secure location
Custodians should secure equipment from unauthorized physical access.
• Access should be restricted to those who require access to maintain the equipment.
• Restricted areas should be clearly marked for authorized personnel only.
• Restricted areas should be secured by locked doors.
• Access to the restricted areas should produce a physical or electronic audit trail.

Secure access to the device front panel and console port

Deploy the device in a rack or cage that can be locked with a suitable key, or other physical methods. This
will prevent access to the physical ports of the device.

Description of Risk
Attackers with physical access to covered equipment can access the device without authorization.

Recommendations
Physical security must be in place to control physical access to restricted areas and facilities containing
devices. Devices should be locked behind cabinets or protected by physical restraints that prevent
unauthorized access or removal from restricted areas. Access to areas containing covered equipment
should only be granted to personnel who require access based on their job function.
Restricted areas should display signs that clearly indicate access is for authorized personnel only.
Facilities containing covered devices should give minimum indication of their purpose, with no obvious
signs identifying the presence of related functions.

Security Handbook 31
 Physical access control devices, such as key card readers, doors and cabinet locks, should be tested
prior to use and on a periodic basis (e.g. annually). Resource custodians should produce physical or
electronic audit trails to record all personnel's physical access to restricted areas for security incident
investigation. Inventory of who has physical access to control devices should be regularly reviewed, and
any inappropriate access identified during the review should be promptly removed.

Device Security
Note: For more information on Device Security options, refer to Appendix 2: Network Management
Card Security Hardening Checklist.

Software Patch Updates

Schneider Electric strongly recommends that, prior to deployment, customers ensure their devices have
been updated with the latest firmware versions.
Customers are also strongly advised to review security bulletins that relate to their Schneider Electric
products. For information on new and updated security bulletins, visit the Schneider Electric Security
Bulletins web page.
Network Management Card devices must only run software for which security patches are made available
in a timely fashion. All currently available security patches must be applied on a schedule appropriate to
the severity of the risk they mitigate.

Privileged Accounts
Privileged and super-user accounts (Administrator, root, etc.) must not be used for non-administrator
activities. Network services must run under accounts assigned the minimum necessary privileges.
Also minimize the number of local accounts.

Certificates

Replace the Default SSL/TLS Certificate

Default SSL/TLS certificates are created during the initial configuration of the device. These certificates
are not intended for use in production deployments and should be replaced. Schneider Electric
recommends that customers configure the device to use certificates either from a reputable Certificate
Authority (CA) or appropriate certificates from your enterprise CA.

Use of Authentication
Network services and local (console) device access must require authentication by means of passphrases
or other secure authentication mechanisms unless the explicit purpose of the service/device is to provide
unauthenticated access. Schneider Electric supports the authentication and authorization functions of
Remote Authentication Dial-In User Service (RADIUS). You can configure the device to use RADIUS to
authenticate remote users. [Configuration;Security;Remote Users;Authentication]

Minimum Protocol
Set the minimum allowed Transport Layer Security Protocol that Hypertext Transfer Protocol over Secure
Sockets Layer (HTTPS) uses to secure the communication between the browser and the device. This
should be set to TLS 1.2. [Configuration;Network;Webaccess]

SSH Host Key

Schneider Electric recommends the use of an SSH host key. An SSH host key authenticates the identity
of the server (the Management Card or device) each time an SSH client contacts that server. Each server
with SSH enabled must have an SSH host key on the server itself. Use the NMC Security Wizard CLI
utility to create this key or generate using the ssh command in the CLI. For more information, see Using
the ssl command in the Command Line Interface.

32 Security Handbook
 Logging
Schneider Electric recommends enabling the generation (and therefore, the logging) of Syslog messages
for events that have Syslog configured as a notification method. To configure notification methods for
events, navigate to Configuration > Logs > Syslogs. Use the available functionality to integrate with
Syslog. Use TCP/IP only for logging.
Note: NTP should be enabled on the device.

No Unattended Console Sessions

Devices must be configured to “lock” or log out and require a user to re-authenticate if left unattended for
more than a specified number of minutes. By default, this is set to 3 minutes.
[Configuration;Security;Local Users;Management - General User]

No Unnecessary Services
If a network service is not necessary for the intended purpose or operation of the device, ensure that
service is not running.

Network Security
When deploying a Network Management Card to a production environment, Schneider Electric strongly
recommends that the below key configuration changes are made.

Firewalls

Deploy a Network Layer Firewall

Schneider Electric strongly recommends that the device is not exposed to the public Internet and is
deployed behind an appropriate Stateful Packet Inspection (SPI) firewall.

Enable Device Firewall Software

The device’s Firewall software must be running and configured to block all inbound traffic that is not
explicitly required for the intended use of the device (default: deny). Use of a network-based firewall does
not obviate the need for host-based firewalls.
Use a ‘Default Deny’ policy.
Schneider Electric recommends that administrators configure the Application Firewall with a deny all
policy at the global level to block all requests that do not match the Application Firewall policy.

Background and Description of Risk

Insufficient restrictions on system access over the network increases exposure to attacks from viruses,
worms, and spyware, and may also facilitate undesired access to resources. Not having a rule in place
that denies incoming traffic unnecessarily exposes a system to compromise.

Recommendations

Log firewall activity

A firewall will reduce the likelihood of compromise, but cannot prevent all attacks. Firewall logs, if enabled,
can be used to identify successful attacks. In the event of a system compromise, these logs are used in
forensic analysis to determine the extent of the compromise and nature of the attack.
Enable logs; retain at least 30 days of data; and collect at least source and destination IP addresses and
ports, application, protocol, direction, date and time, and rule.
Log files should be read-only, and with write access granted only to the firewall service account.

Security Handbook 33
 Allow incoming traffic from Information Security scanners
Configure your firewalls to allow network-based scanning by Information Security (IS) vulnerability
scanners. IS should scan hosts on the network and determine if hosts are vulnerable to common network
threats, or if a system appears to have been compromised.

Network Segmentation
Schneider Electric strongly recommends that network traffic to the device’s management interface is
separated, either physically or logically, from normal network traffic. A flat network architecture makes it
easier for malicious actors to move around within the network; whereas with network segmentation,
organizations can enhance network security by controlling access to sensitive data in the form of enabling
or denying network access. A strong security policy entails segmenting the network into multiple zones,
with varying security requirements, and rigorously enforcing the policy on what is allowed to move from
zone to zone.

Other Security Detection and Monitoring Tools

Schneider Electric recommends that the environment is protected and monitored by appropriate physical,
technical and administrative tools for network intrusion and monitoring such as IDS/IPS and appropriate
SIEM solutions.

34 Security Handbook
 Appendix 2: Network Management Card
Security Hardening Checklist
Upgrade to the latest firmware version
Visit the Schneider Electric website to verify you are running the latest firmware for your device. This will
help ensure security vulnerabilities and features are up-to-date for your protection. NOTE: If you upgrade
to firmware version 2.0.x or higher, you cannot downgrade to a firmware version lower than 2.0.x.

Disable HTTP and enable HTTPS

By default, HTTP is disabled on Network Management Card-enabled products. Disable HTTP if it is
enabled, and enable HTTPS for a more secure and encrypted channel for web communication.

Upload a custom HTTPS certificate

Your Network Management Card-enabled device creates an internally-generated HTTPS certificate. It is
recommended that you use the NMC Security Wizard CLI utility or the ssl command in the CLI tocreate a
custom certificate to help strengthen authenticity. For more information, see Using the NMC Security
Wizard CLI Utility and Using the ssl command in the Command Line Interface.

Disable older versions of TLS

Transport Layer Security (TLS) is a cryptographic protocol that provides communication security over the
internet. Ensure that older versions of TLS are disabled on your Network Management Card-enabled
device, and use the latest version available.

Disable Telnet and enable SSH

By default, Telnet is disabled on Network Management Card-enabled products. Disable Telnet if it is
enabled, and enable SSH for a more secure and encrypted channel for web communication.

Disable FTP
Disable FTP when it is not in use to help harden security on your device. If SSH is enabled, SCP, which is
more secure than FTP, can be used for file transfers. Note: By default, FTP is disabled.

Disable SNMPv1 and enable SNMPv3

If enabled and configured, your device can be accessed via SNMP. It is recommended to use SNMPv3 as
it is more secure than SNMPv1. By default, SNMPv1 and SNMPv3 are disabled.

Configure SNMPv3 to use AES/SHA

Configure SNMPv3 to use the most secure algorithms, AES and SHA, to provide encryption and
authentication.

Use custom network ports where applicable

By using a non-standard port, your device may not be detected by scans looking only for standard ports.
This applies to protocols such as HTTPS, SSH, SMTP, Syslog, etc.

Change the Super User account password

After installation and initial configuration of your Network Management Card-enabled device, immediately
change the default Super User account password. Note: You will be prompted to change the Super User
password at first login to the NMC.

Security Handbook 35
 Disable Super User account
Ensure there is at least one Administrator account enabled on your device. Once an Administrator
account is configured, it is recommended that the Super User account is disabled. The Administrator
account has the same privileges as the Super User account.

Delete Read-Only/Device User accounts (if applicable)

Read-Only and Device User accounts are automatically created on your Network Management Card-
enabled device. If not required, disabled or delete these accounts to manage access control. Note: The
Read-Only and Device user accounts are disabled by default.

Enable Strong Passwords

Enable this feature to ensure strong passwords are created. All passwords will be required to be a
minimum length and contain special characters to make passwords harder to guess.

Enable Force Password Change

Enable this feature to force all passwords to be changed after a user-specified number of days.

Disable unused network addressing protocols (IPv4/IPv6)

To help secure your device, disable unused addressing protocols such as IPv4 and IPv6.

Disable Ping Response (IPv4)

IPv4 Ping Response allows your device to respond to network pings. Disable this feature to help make
your device undetectable.

Enable internal firewall with appropriate access rules

Your Network Management Card-enabled device has an inbuilt firewall that can be used to restrict access
to and from your device for various protocols and addresses.

36 Security Handbook
Copyright Notices
Cryptlib Cryptology Library
Cryptlib copyright © Digital Data Security New Zealand Ltd 1998.

Berkeley Database
Copyright © 1991, 1993 The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following
acknowledgement: This product includes software developed by the University of California, Berkeley
and its contributors.
4. Neither the name of the University nor the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.

Lua
Copyright © 1994–2021 Lua.org, PUC-Rio.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions ofthe
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH
THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 APC by Schneider Electric
Worldwide Customer Support
Customer support for this or any other product is available at no charge in any of the following ways:
• Visit the APC by Schneider Electric web site, to access documents in the APC Knowledge Base
and to submit customer support requests.
– www.apc.com (Corporate Headquarters)
Connect to localized APC by Schneider Electric web site for specific countries, each of which
provides customer support information.
– www.apc.com/support/
Global support searching APC Knowledge Base and using e-support.
• Contact the APC by Schneider Electric Customer Support Center by telephone or e-mail.
– Local, country-specific centers: go to www.apc.com/support/contact for contact information.

For information on how to obtain local customer support, contact the APC by Schneider Electric
representative or other distributor from whom you purchased your APC by Schneider Electric product.

© 2022 Schneider Electric. All Rights Reserved. Schneider Electric, APC and Network Management
Card are trademarks and the property of Schneider Electric SE, its subsidiaries and affiliated
companies. All other trademarks are property of their respective owners.

990-91251H-001 8/2022