About Basic Control Plane Security
Basic system security starts from system configuration and standard protocol best practices.
The main categories of best practices to start from are:
- Limiting switch management access
- Disabling unused services
- Setting up a fabric password
- Using secure versions of management and control protocols
- Enabling system logging
- Implementing user Authentication, Authorization and Accounting (AAA)
Limiting Switch Management Access
NetVisor OS is managed through a command line interface or a corresponding REST API. The CLI and API are equivalent in terms of functionality and both interfaces require a username and a password for user authentication.
Limiting switch access means setting up proper user credentials and privileges to implement strict access control policies based on essential/minimum access requirements.
Usernames and passwords may be managed locally on each network node, or globally on all nodes of the fabric. They can also be managed remotely using AAA servers. A user may have read-write or read-only access. See the Configuring Users Accounts and Setting Credentials for more details.
You can use the user-create command to create a user and assign him/her a password and an access policy. By default, the access policy is read-write. For users that do not need to configure the system, you can create a read-only role with the role-create command and then use it as part of the user creation command.
Furthermore, a user may have access to the entire system or may be constrained to managing only the configuration of a specific vNET.
vNET
A vNET allows the NetVisor OS administrator to delegate the management of a set of network resources to a tenant (vNET administrator). In the vnet-create command it is possible to specify the administrator for the vNET and his/her username.
Tenants have restricted access to NetVisor OS and can only see and manage resources assigned to their respective vNET thanks to the use of container technology (see the Configuring Virtual Networks section for more details).
SSH & SSHD
The NetVisor OS CLI may be accessed through the serial console or by using SSH. Non-secure protocols such as Telnet, rlogin, and FTP are not enabled.
In NetVisor OS version 6.1.1, a shell script is included in the /usr/bin directory and ensures that the SSH and SSHD configurations in NetVisor OS are better compliant with Common Criteria requirements.
To setup a system for SSH conformance, the script available in /usr/bin/setup-cc-ssh-config.ksh should be executed on the target switch. To run the script, as a root user, type:
root@switch: /usr/bin/setup-cc-ssh-config.ksh
When you run this new script, the previously existing script, /etc/ssh/sshd_config is saved to the /etc/ssh/sshd_config.save directory.
Warning: Running this script removes any previously customized configuration for SSH and SSHD configurations.
Later, if desired, you can restore the earlier sshd_config by using the command as a root user:
/usr/bin/cp /etc/ssh/sshd_config.save /etc/ssh/sshd_config
Note: You must restart the SSH daemon service after restoring the earlier configuration.
When you upgrade to NetVisor OS version 6.1.1, the following changes are made to the configuration for a more secured SSH daemon. The changes are:
- Supported ciphers include:
- AES256-CTR
- AES256-CBC
- Supported set of Message Authentication Codes (MACs) include:
- HMAC-SHA2-512
- HMAC-SHA2-256
- The set of key exchange methods that are used to generate per-connection keys (KexAlgorithms) include:
- ECDH-SHA2-NISTP521
- ECDH-SHA2-NISTP384
- ECDH-SHA2-NISTP256
- Supported set of HostKeyAlgorithms include:
- ECDSA-SHA2-NISTP521
- ECDSA-SHA2-NISTP384
- ECDSA-SHA2-NISTP256
- SSH-RSA
- SSH's RekeyLimit (the maximum amount of data that may be transmitted before the session key is renegotiated) is: 1 GbE for 3600 seconds
- LogLevel is set to VERBOSE
- The SSH variables KeyRegenerationInterval and ServerKeyBits are removed.
SFTP
Admins should only use the SFTP protocol to upload to or download from a NetVisor OS device. SFTP is disabled by default, so it needs to be explicitly enabled and a password needs to be configured as shown in the Enabling Administrative Services section in the Installing NetVisor OS and Initial Configuration chapter.
REST API
REST APIs are accessed through a system’s HTTP services, either globally for the entire switch or on a per-vNET basis. In particular, users should only use REST API access over HTTPS (TLS), which can be enabled with the web-ssl option as explained in the Enabling Administrative Services section.
TLS also requires you to configure a server certificate with the following steps:
- Use the web-cert-self-signed-create command to create a private key and a self-signed certificate
- Use the web-cert-request-create command to create a certificate signing request (CSR) using the public key from the self-signed certificate
- Download the certificate signing request from the switch using SFTP
- Get the certificate signing request signed by a certificate authority (CA)
- Upload the signed certificate to the switch using SFTP
- Use the web-cert-import command to import the signed certificate.
For more details refer to the Managing NetVisor OS Certificates and Configuring REST API Access sections in the Installing NetVisor OS and Initial Configuration chapter, and to the Using OpenSSL TLS Certificates for OVSDB section in the Configuring Open Virtual Switch chapter.
In addition, it’s a best practice to include a warning message in a text banner to be displayed at login. Typically, this message includes some specific warning about monitoring and logging of user activities in compliance with local regulations. A banner can also be used to inform about access limits and other restrictions imposed on the users.
For example, the command switch-setup-modify banner banner-string can be used to configure a simple banner to warn unauthorized users, like so:
* Welcome to Arista Networks Inc. Netvisor(R). This is a monitored system.
*
* ACCESS RESTRICTED TO AUTHORIZED USERS ONLY *
In some legal jurisdictions it may not be possible to prosecute and may be illegal to monitor malicious users unless they have been notified that they are not permitted to use the system. One common method to provide such notification is to place that information into a properly crafted banner message (as shown above).
Legal notification requirements are complex, vary by jurisdiction and situation, and therefore should be discussed with a legal counsel. For example, a banner text can be put together to provide some or all of the following information:
- A notice that the system can be logged in to and used only by authorized personnel
- Carefully chosen information about who can authorize use of the system
- A warning that any unauthorized use of the system is unlawful and can be subject to civil and criminal penalties
- A notice that any use of the system can be logged and monitored without further notice and that the resulting logs can be used as evidence in court.
Plus, additional notices may be required by local laws.
However, a login banner should only contain legal text. It should not contain information that can be exploited by a malicious user. From a security point of view, a login banner should not contain specific information about the device such as name, model, software version, ownership, or any other information that may be abused by malicious users.
Disabling Unused Services
It is a common hardening best practice for any system to disable any service that is unused or that will remain unused for an extended period of time (it can always be enabled on demand when necessary).
To achieve this with basic NetVisor OS administrative services, on a local or fabric scope, you can use the admin-service-modify command to disable any unused services on the management interface and/or on the front panel ports.
In most cases the default settings are okay, but they are not always optimal. For example, if not needed, SNMP can be disabled on both management and front panel ports. Also, unencrypted HTTP services can be disabled (also on the management interface) after the web-ssl services have been set up and tested by the admin.
Setting up a Fabric Password
Within a fabric NetVisor OS switches communicate with each other using the TCP protocol to exchange status messages, perform fabric transactions, make remote procedure calls and proxy CLI commands between fabric nodes.
Fabric communication over TCP is secured using TLS with mutual certificate authentication, with an additional bi-directional challenge/response where each side proves it knows the fabric password by computing an HMAC SHA256 digest of a nonce from the other side along with the fabric password and the TLS session key. The certificates used are provisioned during manufacturing and do not need to be configured by the customer.
A fabric password can be set up by using the fabric-create password command, as explained in the Creating an Initial Fabric section. You can only create a password when you create a fabric for the first time. After you create a password, a password is required to add a new node to a fabric.
Using Secure Versions of Management and Control Protocols
As explained above, REST API access can be configured to use TLS encryption and authentication.
If SNMP is also required by the admin (for example, for interoperability with SNMP-based tools), version 3 (SNMPv3) can be enabled to secure the communication as described in RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414 and RFC 3415. SNMPv3 provides secure access to devices by authenticating and optionally encrypting SNMP messages over the network.
SNMPv3’s user creation process through the snmp-user-create command provides three configuration options, of which only one provides full privacy:
- no-auth — This mode does not implement any authentication or encryption of SNMP packets
- auth — This mode enforces authentication of SNMP packets without encryption
- priv — This mode enforces both authentication and encryption (privacy) of SNMP packets.
By default, the community names, public and private, are not allowed. An authoritative engine ID must exist in order to use the SNMPv3 security mechanisms, authentication or authentication and encryption, to handle SNMP packets. By default, the engine ID is generated locally. The engine ID can be displayed with the snmp-engineid-show command. For more configuration details, refer to the Understanding and Configuring SNMP section.
Security of Routing Protocols
The Border Gateway Protocol (BGP) is the routing foundation of the Internet. As such, any organization with more than modest connectivity requirements often uses BGP, which can be targeted by attackers because of its ubiquity and the set-and-forget nature of BGP configurations in smaller organizations. However, there are various BGP-specific security features that can be leveraged to increase the security of a device configuration. They can be configured as options of the vrouter-bgp-add command.
The first recommended step is to enable mutual BGP peer authentication using an MD5 digest for each packet sent as part of a BGP session. Specifically, portions of the IP and TCP headers, of the TCP payload, and a secret key are used in order to generate the MD5 digest.
The second recommendation is to configure a maximum limit to the number of BGP prefixes.
Prefixes are stored by a router in memory. The more prefixes a router must hold, the more memory BGP must consume. In some configurations, a subset of all Internet prefixes should be stored, such as in configurations that leverage only a default route or routes for a provider’s customer networks.
In order to prevent memory exhaustion, it is recommended to configure the maximum number of prefixes that is accepted on a per-peer basis. The max-prefix parameter can be used for that purpose.
Furthermore, it is recommended to filter BGP prefixes with prefix lists to implement stricter control over routes.
Prefix lists allow a network administrator to permit or deny specific prefixes that are sent or received via BGP. Prefix lists should be used wherever possible in order to ensure that network traffic is sent over the intended paths. They should be applied to each eBGP peer in both inbound and outbound directions.
Configured prefix lists limit the prefixes that are sent or received to those specifically permitted by the routing policy of a network. If this is not feasible due to the large number of prefixes received, a prefix list should be configured to specifically block known bad prefixes. These known bad prefixes include, for instance, unallocated IP address space and networks that are reserved for internal or testing purposes by RFC 3330. Outbound prefix lists should be configured to specifically permit only the prefixes that an organization intends to advertise. For more details, refer to the Configuring BGP on a vRouter section.
Similarly for OSPF, in the vrouter-ospf-area-add command, it is possible to specify inbound and outbound prefix lists to filter incoming and outgoing packets. For more details, refer to the Configuring Open Shortest Path First (OSPF) section.
Enabling System Logging
NetVisor OS maintains audit, system and event logs. All CLI commands and REST API calls that modify the system are logged in the audit log. Changes in system state and important alerts are logged in the system log. Details regarding the operation of various NetVisor OS features may optionally be logged to the event log for troubleshooting/monitoring purposes.
Log messages are accessible by using any of the following services: the CLI, the REST APIs, SFTP, or when syslog is enabled.
In general, users are advised to send logging information to a centralized syslog server. This makes it possible to correlate and audit network and security events across network devices more effectively.
To use the syslog service, the administrator has to specify which syslog servers the log messages should be forwarded to. The administrator can also select which messages should be transmitted, and how NetVisor OS’s log parameters are translated to syslog parameters.
Messages can be sent to syslog servers using either TCP/TLS or UDP. TCP/TLS is recommended over UDP because with the former syslog messages are reliably delivered over a secure transport. TCP/TLS can be selected in the admin-syslog-create command by using the tcp-tls parameter. In addition, it is necessary to provision a client certificate with the syslog-tls-cert-* commands. For more information, refer to the Understanding Logging section.
In addition to the audit, system and event logs, NetVisor OS stores real-time data and history about TCP connections, endpoints accessing the network, routes, fabric communication, as well as flow, port, VLAN, VXLAN, tunnel, hardware, system, class of service and control statistics. This real-time data and history is extremely useful for operational and security purposes. In particular, the user can leverage the connection-show command to monitor TCP connections going through the device.
Starting with NetVisor OS version 6.1.1, the system log component of NetVisor uses OpenSSL version 1.1.1. Due to the upgrade to OpenSSL version 1.1.1, the following changes are available in NetVisor OS version 6.1.1’s syslog client:
- SSL options are changed to support hardened approaches.
- Validation is now performed on Local Certificate chains during import.
- Validation is now performed on Local Certificate chains prior to connection.
- Validation is now performed on over-the-wire certificates from the peer.
- SSLv2, v3, and TLS version 1 and version 1.1 are deprecated and are no longer allowed.
- Select Ciphers are supported. For details, see the SSH & SSHD section.
- Audit messages are now produced for all failure cases.
- Certificate revocation list (CRLs) are now supported as in:
- If no CRL can be loaded or an error is encountered loading the CRLs, then execution continues as normal and certificates are not verified against the CRL.
- If a CRL can be loaded, the revocation status will be read from it and applied during verification if applicable.
- CRLs should be periodically updated manually.
Prior to NetVisor OS version 6.1.1, importing syslog certificates by using the syslog-tls-cert-import command delivered a success message whether the certificates provided were valid for use or not.
However, with NetVisor OS version 6.1.1 onward, the certificates are validated at import and displays the following message upon failure: “syslog-tls-cert-import: Failed to verify syslog certificate”.
The complete validation messages are available in perror.log file.
Note: While configuring the syslog targets under TCP-TLS, the hostname of the target syslog server must match the hostname in the CN of the certificate. For example,
If your server is address is server.example.com, and the generated certificate CN states the hostname as server.example.com, then the hostname supplied to the syslog target creation must also be 'server.example.com'. Any mismatch here prevents the connection from being made.
For details on the log messages, see the Log Messages document.
Implementing user Authentication, Authorization and Accounting (AAA)
AAA is a set of features that are critical in order to secure interactive access to network devices. AAA provides a highly configurable environment that can be tailored based on the needs of the network admin. Arista NetVisor OS supports the TACACS+ standard for AAA.
TACACS+ is an authentication protocol that NetVisor OS switches can use for authentication of management users against a remote AAA server. These management users can access the switch using SSH or HTTPS. TACACS+ authentication, or more generally AAA authentication, provides the ability to use individual credentials for each network administrator. When you do not depend on a single shared password, the security of the network is improved and your accountability is strengthened.
TACACS+ can be used for any combination of Authentication, Authorization and Accounting (AAA), which means that it can be used to authorize session access as well as individual commands.
Command authorization with TACACS+ permits or denies each command that is entered by an administrative user. When the user enters a CLI command or an API client invokes an API call, NetVisor OS sends the command to the configured AAA server. The AAA server then looks up any configured policies in order to permit or deny the command for that particular user.
TACACS+ can be configured with the aaa-create command. In addition, for service continuity, it is recommended to use redundant AAA server. And for stronger security it is important to use a shared secret to secure TACACS+ traffic to/from the servers.
For more information, refer to the Configuring TACACS+ section.