SOFTWARE

Nodegrid Default Users and Permissions

The Nodegrid OS comes with three default user types:

• “admin” user:
  • Full access to all features and functions on both the Web Interface and CLI.
  • Login options include Console, SSH, WebUI, API and ZPE Cloud.
  • From CLI, the admin user can switch to SHELL with limited privileges.
  • From CLI, the admin user can switch to root SHELL with full privileges.
• “root” user:
  • By default, can only be accessed by logging in as another user with "sudo" privileges and switching to "root"
  • No access to the web interface.
  • Has full privileges on SHELL
• “ansible” user:
  • Intended for internal use, for systems-to-systems automation.
  • No access to the web interface.
  • Has access to SHELL and CLI with limited privileges.

Telnet service is disabled by default.

Factory Reset Options

The Nodegrid OS has multiple options to reset its configuration to the factory default:

• Reset via WebUi/CLI/API (as for the WebUI, by: System -> Toolkit -> Restore to Factory Default Settings)
• Software downgrade when using "Apply factory default configuration" option
• Software upgrade/downgrade (any method, such as via UI or USB) when using "Format Partitions" option
• Using triggers (like geofencing trigger, refer to Geofencing section)
• ZPE Cloud, by doing ‘Connect’ to the Nodegrid Unit

(And then, System -> Toolkit -> Restore to Factory Default Settings)

Lasty, Nodegrid appliances have the physical Reset Button (RST) which can be used for a soft reboot by pressing quickly (less than 3s) or it can be used to reset the configuration of the unit to the factory default settings by pressing at least 10 seconds. The Console port LEDs start flashing when it is complete and reboots the unit.

Security Packages and Cipher Suites

The Nodegrid OS is built on top of a constantly updated list of open source packages. At the time of the redaction of this document, the most up to date Nodegrid OS version is v6.0.2 and has:

• Linux Kernel 6.1.15,
• Critical security open-source packages (e.g., OpenSSL, OpenSSH, Apache Webserver) frequently updated,
• Any packages with detected Critical CVEs upgraded or patched as soon as possible,
• The following cipher suites:

FIPS disabled (default):

FIPS enabled:

Guideline to secure the Nodegrid

Security is a common concern to Nodegrid deployments. The following steps provide a guideline on where to find specific security related options and provide a best practice guide which can be used to plan and implement the required security.

The steps are the following:

• Default User Configuration.
  • Change the passwords for the default users (root and admin)
  • Add new users to the admin group.
  • Create an operational admin group with limited permissions.
  • Disable built-in admin user.
• Disable not required services.
  • Disable HTTP access.
  • Disable unused services.
  • Configure WebUI security.
• Network
  • Setup the Network interfaces
  • Configure the Firewall
  • Configure Fail2Ban
• Configure Logging and Event Notifications
• Secure BIOS and Bootloader with password
• Use UEFI Boot Mode and Enable Secure Boot
• Enable Self Encryption Drive
• If required, disable Console Access through Serial port and Keyboard/Video

The complete guideline is available on our Knowledge Base. Please reach the link below for the latest version:

https://support.zpesystems.com/portal/en/kb/articles/steps-to-secure-nodegrid

In the next subsections, we shall focus on 3 aspects of the hardening of the Nodegrid: Services, Firewall (Iptables) and Geofencing.

Services

You can view, enable and disable services and ports from one single location, which is accessible via CLI, REST API, or via WebUI.

As with any system it is recommended to only run services which are required. The Nodegrid comes by default with some services enabled, which help during the deployment but might not be needed in all cases during or after the units are deployed. It is therefore recommended to disable all services which are not required.

Two examples are SNMP and Bluetooth. These services help some deployment use cases, but the recommendation is to disable these services if they are not being used.

Most services can be enabled or disabled from a single page, on Security -> Services:

The complete guideline to secure the Nodegrid’s services is given on:https://support.zpesystems.com/portal/en/kb/articles/steps-to-secure-nodegrid, in section ‘Protocols and Services’.

Firewall

The Nodegrid OS is natively equipped with the firewall Iptables.

The guideline to configure the firewall is given in Appendix F. It lists all the required and recommended firewall rules, to ensure a proper working of the solution. The list needs to be adjusted based on specific customer requirements.

The firewall rules are composed of:

• General rules: loopbacks, in ipv4 and ipv6.
• Client rules: icmp, http, https, ssh.
• Nodegrid to Nodegrid rules: https, ssh, cluster Nodegrid, nodes discovery.
• Feature rules: dns, ntp, snmp, smtp, nfs, syslog, ftp, sftp, tftp, http, https, scp, dhcp/ztp, pxe, dhcp server, ldap, ldaps, tacacs+, radius, Kerberos, ssl vpn server & client, ipsec.
• Target device rules

Geofencing

Nodegrid can track GPS physical location, notify perimeter crossing and take customizable actions.

When enabled, the Geofence compares the GPS coordinates configured (+ a radius perimeter, also configurable) with the GPS coordinates received from the antennas. When that perimeter is crossed, an event is generated and a customizable action script is executed. A script to reset the unit to factory settings and templates for customer scripts are provided by default.

SSL Certificates

By default, the Nodegrid OS WebUI uses a self-signed certificate for HTTPS access. The user is able to replace this certificate in two ways:

1. Upload a custom certificate, along with the private key, through Nodegrid’s WebUI, OR
2. Create a CSR (Certificate Signing Request) on the Nodegrid’s WebUI, download it, sign with a Certificate Authority, and upload the resulting certificate. With this process, Nodegrid generates the Private Key internally and never exposes it.

If the certificate is not signed by a commonly trusted authority, it can be imported to the user’s regular web browser or operating system..

VPN

The Nodegrid supports the following types of VPN:

• IPsec: in Site-to-Site configuration, with X.509, PSK and Certificates keys.
• SSL: server and client.
• Wireguard: server and client.

Alternatively, Nodegrid can also execute a VNF, inside its hypervisor KVM, and that VNF will establish the VPN. The Nodegrid is certified by the vendors Palo Alto and Juniper but has been tested and validated by most of the well-known vendors of the market, including Fortinet and Checkpoint.

Connection to the Nodegrid OS from an end user device

To connect a user’s laptop or desktop to the Nodegrid OS, we have the following options:

• The most used is to access in simple connexion https. You can disable in the Nodegrid OS the HTTP, and only accept the HTTPS. The traffic will therefore be encrypted in SSL/TLS. Nodegrid OS supports TLS v1.3 (the latest version of TLS at the time of the redaction of the document).
• If you want to connect in IPsec to the Nodegrid, you just have to:
  • Install an IPsec client on your laptop.
  • Configure the other peer on the Nodegrid side. IPSEC is natively supported by Nodegrid. It can be configured graphically. We support different connection scenarios, including host-to-host, host-to-site, site-to-site, and road-warrior.
  • Reference: User Guide, section ‘IPsec VPN’.
• A recommended alternative to IPsec to establish a VPN with the Nodegrid, is the Wireguard protocol. You just have to :
  • Install a Wireguard client on your laptop. The client, for windows, can be downloaded at: https://www.wireguard.com/install/
  • Configure the server on Nodegrid side. The Wireguard is natively supported by Nodegrid. It can be configured graphically. Wireguard has the advantage to have a good client support, as well under Windows, MacOS, as Linux.
  • Reference: User Guide, section ‘VPN drop-down > Wireguard’.
• Finally, another possibility: you can connect to the Nodegrid OS via SSH, in which case the traffic will also be encrypted.

802.1x network port authentication

The Nodegrid supports in the 802.1x network port authentication. This function is only available on Nodegrid Gate SR, Bold SR, Link SR, Net SR, and Hive SR devices. You can add a Profile in which you select the internal EAP server, Radius Server or Supplicant (user):

Clustering

Cluster establishes a secure and resilient connection with a set of Nodegrid devices. When enabled, a Nodegrid device that is part of the Cluster can access and manage other devices. By logging into any Nodegrid device, all devices in the Cluster can be reached with a single interface. This allows for vertical and horizontal scalability.

Nodegrid Clustering – Mesh Mode

The Clustering uses the SSL Tunnel (port 9966) between the Nodegrids, so that each Nodegrid unit communicates with the other 2 nodes and their respective devices. Example with Nodegrid Serial Console (NSC) in Mesh mode:

SSH connection from the user located on Site A to a Target Device located on Site C, via NSC-A:

Nodegrid Clustering – Star Mode

The Clustering uses the SSL Tunnel (port 9966) between the Nodegrid Coordinator and the peer, so that the coordinator can communicate with each peer and their respective devices, but peers don’t see other peers and the Coordinator.

Example with Node grid Serial Console (NSC) and Nodegrid Bold SR (BSR) in Star mode:

The workflow to connect to a target device in Star-mode cluster is:

Multi-Cluster

Multi-cluster is an extension of the clustering feature that allows for increased scalability and handling of high availability scenarios by implementing the concept of cluster of clusters.

It allows the coordinator of a cluster to join remote clusters of both mesh and star modes thus gaining access to all devices of all peers of the remote cluster. This coordinator may or may not have local peers.

When a coordinator joins a remote cluster, a single unidirectional connection is kept from the coordinator to the remote cluster's coordinator which will handle all requests to the other peers of that remote cluster, thus limiting the number of resources required to access the entire infrastructure.

Multiple coordinators may join the same remote clusters to provide alternative access in case of failure, allowing a centralized view with redundancy.

This uses the same protocol and port (9966) over SSL as clustering, so no additional port needs to be opened in firewalls.

AAA (Authentication, Authorization, Accounting)

The Authentication, Authorization, and Accounting features of the Nodegrid OS are detailed in the following sections.

Group and user permissions

The Nodegrid OS supports RBAC (Role Based Access Control). It allows you to create users and groups, and set the appropriate permissions for them, in terms of functionality (Configure System, Tracking, …) as well as in terms of target devices.

Authentication Servers

The Nodegrid OS supports the following Authentication servers:

• LDAP/AD
• RADIUS
• TACACS+
• Kerberos

Factor Authentication

The Two-Factor Authentication (2FA) currently supported in Nodegrid OS is with OTP (One-Time Password) and RSA.

Admin users can configure Nodegrid to be authenticated with a remote authentication server such as AD or Radius, and then confirm the identify with OTP or RSA token code authentication.

DUO 2-factor on the WebUI depends on the DUO account configuration, and DUO is set in SSO page.

Single Sign On

The Nodegrid supports Single Sign On. It implements the SAML2 protocol and tested and verified to work with the leading security providers Duo, Okta, Ping Identity, Microsoft Active Directory Federation Services (ADFS) and Microsoft Azure Active Directory.

You can implement your Zero Trust Security posture with these trusted authentication & identity management partners.

Single Sign-On workflow

Single Sign-On (SSO) implementation in Nodegrid Software was done via Security Assertion Markup Language (SAML).

SAML is primarily used to enable Web browser single sign-on (SSO). This allows a user to authenticate once and gain access to separately secured systems without resubmitting credentials. The security objective is to ensure the authentication requirements are met at each security checkpoint.

In an SSO transaction, the SAML services implemented at each secured system exchange requests and assertions to determine whether to allow access. The SAML assertions used in SSO transactions include authentication statements and attribute statements.

1. User navigates to Nodegrid's login page.
2. If user clicks one of the IdP's sign in buttons, or user had navigated to Nodegrid using a custom URL (http(s)://<ip>/sso/<IdP>/), then Nodegrid will generate a SAML request.
3. Nodegrid will redirect user to the IdP SSO URL endpoint that user had configured in the configuration page in Nodegrid.
4. Browser will send user to the IdP SSO URL endpoint.
5. IdP will authenticate the user.
6. If successful in the authentication, the IdP will redirect the user to Nodegrid's Assertion Consumer Service URL (this needs to be configured in the IdP side) with the SAML response.
7. Browser will send user back to Nodegrid's ACS URL with SAML response.
8. Nodegrid will verify SAML response, using a public key that the user uploaded as a certificate when configuring the IdP in the Nodegrid.

If everything was successful, user is logged in to Nodegrid.

Identity Provider (IdP): Service that performs the authentication process on the user and sends a response to the Service Provider. ex: Duo, Okta, and Ping Identity.

Service Provider (SP): Web application that requests and obtains the user's authentication from the Identity Provider.

Configuration of SSO

Admin user may add SSO servers or import the metadata under Security, Authentication, SSO page.

Add a SSO server:

Import Metadata:

Events and Alerts

The Nodegrid OS supports the following events and alerts:

System Data Logging:

• All users’ interactions are recorded.
• Data stream is inspected, and events are issued upon string match.

AAA and System Events:

• Events are triggered on successful and failed logins.
• Start and stop session events are issued for every access.

Login Banner:

• Warn users prior to login about legal policies.
• Assert consent for monitoring the session.
• Uniquely identify the system.

Password Enforcement:

• Configure Password Complexity.
• Based on pam_cracklib, allows to enforce required number of lowercase and uppercase letters, digits and special characters as well as minimum password length.

Fail2ban:

• System and application log messages are monitored.
• Temporary firewall rules are automatically added to block specific access based on malicious signs like too many password failures and exploit attempts.

Event and Logging Destination:

Events and Data logs are stored locally by default. The Data logging for the appliance can be enabled under system -> logging.

Additional destinations are configured under the auditing menu:

- File, local or NFS

- Syslog, local or remote

- E-mail

- SNMPTrap

Splunk integration is also supported. Splunk is a software for searching, monitoring, and analyzing machine-generated data via a Web-style interface. It helps to capture, index and correlate real-time data in a searchable repository, from which it can generate graphs, reports, alerts, dashboards and visualizations.

Splunk provides a native Linux client which is supported on the Nodegrid platform. Splunk forwarder can directly be installed on a Nodegrid unit, through 2 different methods: either with Docker, or natively.

System Configuration Checksum

Nodegrid System Configuration Checksum is the security feature that generates a fingerprint of all the Nodegrid configuration files. Users can view the current system configuration checksum, create a baseline, and compare it with the configuration checksum of any time. Both MD5 and SHA256 checksum types are available.

The configuration can be audited to ensure only authorized changes.

Remove for brevity […]

After auditing, you can generate a baseline or compare your current one to an existing baseline.

To create a baseline file, you can do as following, and the checksum file will be saved under /var/local/CFG:

To compare your baseline to an existing one:

Remove for brevity […]

Virtualization

The security of the virtualization on the Nodegrid is addressed in two ways:

- the security of the VM itself, provided by the vendor of the VM (for instance, Palo Alto Networks).

- the security of the hypervisor. The hypervisors supported on the Nodegrid are KVM and Docker. KVM is a Linux module, and for Docker, the Nodegrid uses the Linux version of that platform. Both are tested and secured as the other Linux components of the box and are subject to Qualys Vulnerability tests (cf section § Qualys Vulnerability Scan).

Reference documents

The reference documents in terms of guidelines to configure the Nodegrid OS are listed below:

• Steps to Secure Nodegrid

https://support.zpesystems.com/portal/en/kb/articles/steps-to-secure-nodegrid

• Network Settings Configuration

https://support.zpesystems.com/portal/en/kb/articles/network-configuration-via-cli

• User Guide

https://www.zpesystems.com/resources/product-resources/user-manuals/ 

• ZPE Knowledge Base and FAQs

https://support.zpesystems.com/support/zpesystemsinc/ShowHomePage.do#Solutions