Our switch systems, by default, work with NIST SP 800-131A, as described in the table below.
This appendix describes how to enhance the security of a system in order to comply with the NIST SP 800-131A standard. This standard is a document which defines cryptographically “acceptable” technologies. This document explains how to protect against possible cryptographic vulnerabilities in the system by using secure methods. Because of compatibility issues, this security state is not the default of the system and it should be manually set.
Some protocols, however, cannot be operated in a manner that complies with the NIST SP 800-131A standard.
|HTTP||HTTP disabled||no web http enable|
|HTTPS||HTTPS enabled||no web https enable|
|SSL ciphers = TLS1.2||web https ssl ciphers all|
|SSL renegotiation disabled||web https ssl renegotiation enable|
|SSH||SSH version = 2||ssh server min-version 1|
|SSH ciphers = aes256-ctr, aes192-ctr, aes128-ctr, |
|no ssh server security strict|
The OS supports signature generation of sha256WithRSAEncryption, sha1WithRSAEncryption self-signed certificates, and importing certificates as text in PEM format.
To configure a default certificate:
Create a new sha256 certificate.
For more details and parameters refer to the command “crypto certificate name”.
Show crypto certificate detail.
Search for “signature algorithm” in the output.
Set this certificate as the default certificate. Run:
To configure default parameters and create a new certificate:
Define the default hash algorithm.
Generate a new certificate with default values.
When no options are selected, the generated certificate uses the default values for each field.
To test strict mode connect to the WebUI using HTTPS and get the certificate. Search for “signature algorithm”.
There are other ways to configure the certificate to sha256. For example, it is possible to use “certificate generation default hash-algorithm” and then regenerate the certificate using these default values.
It is recommended to delete browsing data and previous certificates before retrying to connect to the WebUI.
Make sure not to confuse “signature algorithm” with “Thumbprint algorithm”.
SNMPv3 supports configuring username, authentication keys and privacy keys. For authentication keys it is possible to use MD5 or SHA. For privacy keys AES or DES are to be used.
To configure strict mode, create a new user with HMAC-SHA1-96 and AES-128. Run:
To verify the user in the CLI, run:
To test strict mode, configure users and check them using the CLI, then run an SNMP request with the new users.
SNMPv1 and SNMPv2 are not considered to be secure. To run in strict mode, only use SNMPv3.
By default, the OS supports HTTPS encryption using TLS1.2 only. Working in TLS1.2 mode also bans MD5 ciphers which are not allowed per NIST 800-131a. In strict mode, the switch supports encryption with TLS1.2 only with the following supported ciphers:
To enable all encryption methods, run:
To enable only TLS ciphers (enabled by default), run:
To enable HTTPS strict mode, run:
To verify which encryption methods are used, run:
On top of enabling HTTPS, to prevent security breaches HTTP must be disabled.
To disable HTTP, run:
Code signing is used to verify that the data in the image is not modified by any third-party. The operating system supports signing the image files with SHA256, RSA2048 using GnuPG.
Strict mode is operational by default.
The SSH server on the switch by default uses secure ciphers only, message authentication code (MAC), key exchange methods, and public key algorithm. When configuring SSH server to strict mode, the aforementioned security methods only use approved algorithms as detailed in the NIST 800-181A specification and the user can connect to the switch via SSH in strict mode only.
To enable strict security mode, run the following:
The following ciphers are disabled for SSH when strict security is enabled:
The no form of the command disables strict security mode.
Make sure to configure the SSH server to work with minimum version 2 since 1 is vulnerable to security breaches.
To configure min-version to strict mode, run:
Once this is done, the user cannot revert back to minimum version 1.
By default, the switches support LDAP encryption SSL version 3 or TLS1.0 up to TLS1.2. The only banned algorithm is MD5 which is not allowed per NIST 800-131a. In strict mode, the switch supports encryption with TLS1.2 only with the following supported ciphers:
To enable LDAP strict mode, run the following:
Both modes operate using SSL. The different lies in the connection initialization and the port used.