Open

Release notes | Network controller | rootFS v-6.12.03 Open

Pluto ApolloN

1. Introduction

The Pluto Rootfs v6-12.02 is based on Ubuntu 20.04.6 LTS and kernel 5.4.142. 
Rootfs v6-12.02 will be introduced in iProtect 10.04.

When you first start the controller, a Configuration Wizard will help you determine which iProtect the controller will communicate with. After activation, the "normal" maintenance page will open.

1.1 Version overview

1.2 Highlights

• Small size Rootfs (160MB)

• Based on Ubuntu Base minimal rootfs

• Use of NetworkManager

• Support for IEEE 802.1x

• Initial Configuration Wizard

• Default dual boot SDcard image v6-12.02.20 / v5-68a

• Applied to CIS level 2 Server Benchmarking

• Easy rootfs partition switch

• OTG only factory user for Factory Default.

• Firewall using IPtables and Firewalld userpace package.

2. Changes and new functions

2.1 Ubuntu Base rootfs

The Pluto RootFS is based on the Ubuntu Base operating system. It is the smallest implementation of Ubuntu. Ubuntu Base is a minimal rootfs for use in the creation of custom images for specific needs. Ubuntu Base strives to create a suitable minimal environment for use in Board Support Packages, constrained or integrated environments like the Controllers.
The packed size of Ubuntu Base is about 23MB. Installed it will have a size of about 160MB. This is much smaller than the rootFS v6-11 and lower, that are sized around 500MB.

The Pluto Linux Kernel is based on the Variscite i.MX linux-imx kernel source 5.4-2.1.x-imx_var01 for the Freescale (NXP) i.MX6 armhf processor. The kernel is updated to support firewalling, WireGuard, Apparmor and specific Controller I/O functionality.

2.2 NetworkManager

Until Pluto rootFS v6-11 the network configuration was handled by ifupdown. Configuration was set via the /etc/network/interfaces file.
From v6-12.02.02 on, the NetworkManager network configuration is used. To be backward compatible, the interfaces file will be updated too. This way it is still possible to downgrade to v6-11 and lower.

The network configuration is still done the same way via the Serverbox. The Serverbox is the default way to set the network configuration. It will guarantee that all components involved in setting the network will be configured correctly. This involves the NetworkManager configuration, the legacy interfaces file and the Network-restore configuration present in the flash memory.
Because the network configuration can involve security related info like passwords (IEEE 802.1x), the content of the NetworkManager connection file and network-restore file can only be accessed by users with root privileges like administrator. Of course the configuration can always be done via the Serverbox.

The NetworkManager connection file is located at /etc/NetworkManager/system-connections/Pluto-eth0.nmconnection. The Network-restore configuration file is located at /var/controller/flash_internal/network/plutoconfig.json.

2.3 IEEE 802.1x

IEEE 802.1X is an IEEE Standard for port-based network access control (PNAC). It is part of the IEEE 802.1 group of networking protocols. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. The authentication is performed by a switch or router (authenticator) the device (supplicant) is connected to. Most of the time, the switch or router will use an external authentication server (Radius server) to perform the actual authentication. The device/supplicant in our case is the Pluto/ApolloN Controller.

Configuration of the router/switch and Authentication server will not be discussed here. Please refer to the related documentation for that.

Two methods of authentication are supported when configuring 802.1x on a Controller.

• Use username and password. It uses PEAP ( Protected Extensible Authentication Protocol)

• Some authentication methods require use of certificates. EAP-TLS uses both server side and client certificates whereas EAP-PEAP and EAP-TTLS only require the server side certificate. When client certificate is used, a matching private key (with passphrase) file has to also be included in configuration. The Pluto supports EAP-TLS. In that case each Pluto needs:
  - CA certificate
  - Client certificate
  - Private key
  - Private key passphrase

The IEEE 802.1x configuration can be done in the Serverbox at “Network settings” → Configuration.

PEAP Configuration

Be sure the username/password are configured on the Authentication server (like Radius).
Fill in the username and password at the Authentication form entry of IEEE 802.1x.
Press ‘Save’. A red popup window will ask for confirmation.
Press ‘Yes’ if you are sure and wait for result window below. There you can see the result of the configuration. It will tell if IEEE 802.1x is configured, authenticated and activated.
Also a state icon next to the Save button will indicate the status of IEEE 802.1x, also available at the System menu of the serverbox.
If the icon is green, the 802.1x connection is activated. If it is cyan, 802.1x is configured, but the connection not authenticated. Check the configuration on the authenticator or authentication server or check your username/password.

EAP-TLS configuration

If using certificates, then use the TLS option as ‘EAP option’.

Customer certificates

If the customer is providing the certificates, then set “Own certificate” to No.
Provide the CA, client certificate and Private Key (encrypted with passphrase) files by posting them all three seperately.

Fill in the password for the private key at “Authentication” Password. Also fill in the Username. It will only be used as ‘Identity’ in the router. It can be handy to use the Pluto hostname here, so it can be found easily in the router.
Be sure to post all files. If Post button is red, the file is not posted yet!
Press the Save button and wait for the result message below it.

As seen below the Username is visible in the router/switch.

iProtect Own-CA certificates

In the rare situation that the customer does not provide its own certificates, the iProtect own-CA certificates can be used.
Be sure that the iProtect own-CA root certificate is present on the Authentication server, together with a certificate and private key. They can be retrieved for instance by creating a dummy line and get the certificates from that and place them on the Authentication server. Be aware of the certificates expire date.

Set “Own certificate” to Yes.
Again the Username is only as reference. The Password will be used to set a passphrase on the ‘own private key’. At default the private key does not has a passphrase.

Important remarks!

Using IEEE-802.1x and the fact that the Controller is a headless device, it can happen , if not taken the right actions, the connection can be cut of.

Actions that can disconnect you permanently from the Controller:

• Having working 802.1x configured, disable the 802.1x configuration on the Controller.

• Having working 802.1x configured, downgrade to a Controller version lower than v6-12.02

• Having working 802.1x configured, misreconfigure 802.1x

If you are locked-out of the COntroller, please contact theadministrator of the Authenticator (switch/router) connected to the Controller to let them disable the 802.1x configuration on the port connected to the Controller.

2.4 Dual-boot rootfs SDcard image

The new default SDcards will have two different rootFS’s.
On partition1 rootFS v5-68a and on partition2 rootFS v6-12.02 (or higher).

This way we can still support customers running an old iProtect (<10.02) with Controllers having v5.68a.
RootFS v5.68a will not be supported anymore in iProtect 10.04. That means that if the Controller has to be managed by an iProtect higher than 10.01, it is better or necessary to set the Controller to partition2 to activate the v6-12.02 rootFS. How to do this is explained in the next section ‘2.5 Configuration Wizard’.

2.5 Configuration Wizard

The Configuration Wizard is a boarding web-page present on a new SDcard image. The wizard will guide you through the first configuration steps to setup a new Controller with the right rootFS version and network configuration. Once the configuration is done, the normal Serverbox web-page will be presented.

There are several situations that a new SDcard will be inserted:

1. A new Controller from the shelf

2. A Controller already operational

The bootloader defines from what partition the Controller will boot. If starting up the Controller you never know what partition it will boot from (only if you interrupt the bootloader via OTG).
New Controllers most probably will boot into partition1 because the default setting for ‘bootpartition’ in a clean bootloader is partition1. Already used Controllers can have either partition1 or partition2 active.
So you are never sure from what partition the Controller will boot.

Besides the bootpartition, one can also not tell what bootloader version is present on the Controller. Especially if the Controller is already used before. RootFS v5-68a’s default bootloader version is '201712081051'. The bootloader version for rootFS v6-12.02 is '202302091003'.
To have a clean consistent Controller, the right bootloader has to be flashed for the chosen rootFS version.

Furthermore, if present, the Network-restore functionality must not be ruined by setting the Pluto to default using the wizard. If a new SDcard is placed into a operational Controller, the network restore configuration (if) present in the flash, must be used. Otherwise you will loose connection to this Controller!

To have control on what bootpartition and therefore what rootFS version the Controller will be made active, and if needed and present, also use Network-restore configuration, the wizard is created.

When starting up the Controller with a new SDcard, you will get presented with the window as in above picture. If it is a new Controller, most probably the IP address will be the default 192.168.1.195.

Select what version iProtect will going to manage this Controller. Choosing iProtect 10.1 and lower will going to activate rootFS v5.68a. Choosing iProtect 10.2 and higher will going to activate rootFS v6-12.02.
The rootFS version will get highlighted.

The “Network Configuration” will present the network config as is present in the /etc/network/interfaces file or if present, the network configuration from the Network-restore in the flash.

As mentioned, if there is a Network-restore configuration in the flash, you will see an option “Restore flash Ntwk config” checkbox. If the chosen rootFs is v5.68a, then the checkbox will disappear because v5.68a does not support Network-restore.

When you are Ok with the network configuration and the rootFS version, prepare the configuration by applying it via the Submit button.

The network will be configured and the Submit button will change to a “Activate” button. If needed the configuration can be changed still. The Activate button will then be replaced again by the Submit button and changed config can be submitted again.

When Activating the configuration, the configuration will be executed and activated. Depending on the configuration and begin state , it is possible that the Controller reboots or stay on the current partition.
Also depending on the configuration it can take some time to complete. Please be patient and be sure no OTG cable is connected to the Controller during this action.

2.6 RootFS partition switch

To quickly switch from the active partition to the standby partition, there is the “Switch partition” option in the Advanced menu of the Serverbox.

The text behind the “Switch partition” button indicates to what partition with what rootFS version the Controller will boot. If the Controller is managed by iProtect and enabled as line, the switch will be prohibited.

A complete version overview can be seen at the System menu.

Be aware that it just switch to the other partition. This means that the bootloader stays the same. Because of this it can happen that if switching from v6-12.02 to v5-68a, the becoming active v5-68a will have the newer bootloader and vice-versa.
Also be aware that switching can disconnect you from the Controller if the network configuration on the not-active partition differs from the active one.

2.7 Managing iProtect

If an iProtect is managing the Controller and the line is set active, the iProtect host/ip address will be presented on the Serverbox system tab.
If the line is not enabled or no iProtect is managing the Controller, it will state “Not active”.

2.8 OTG console-only user for Factory Default

As last resort, if no credentials of the controller user are available anymore and the Controller was set to Secure mode when removed from the field, one can use the ‘factory’ account.

The factory account is only available via the OTG console. It is a restricted user that only can perform a Factory Default. The Factory Default will only be possible if the Controller is not managed by an iProtect.

2.9 Firewall

The Controller uses firewalld as firewall frontend to iptables. Firewalld is a more powerful package than for instance the standard Ubuntu package ufw.
Two custom zones are created for the Pluto and ApolloN, named respectively . The corresponding zone is set automatically at boottime.
A firewall zone defines the trust level for a connection, interface or source address binding. This is a one to many relation, which means that a connection, interface or source can only be part of one zone, but a zone can be used for many network connections, interfaces and sources.
The zones defining the services/ports that are able to connect to the Controller. These are the nodemanager ports 20200 and 20600, the SSH port 22, HTTPs port 443. For the ApolloN the SNMP port 161 and SNMPtrap port 162 are added.

To enable or disable specific ports in the firewall (e.g. intrusion panel), please go to page: Firewall settings rootFS v6-12

2.10 CIS Benchmarking

The Center for Internet Security (CIS), develops the CIS benchmark documents for Ubuntu LTS releases. As these documents contain a large number of hardening rules, compliance and auditing can be very efficient when using the openSCAP tooling to automate compliance and auditing.
For Ubuntu machines with amd64 processors, USG is available, an Ubuntu native package, based on openSCAP.
The rootFS is audited using the CIS Ubuntu 20.04 Level 2 Server Benchmark profile:
Guide to the Secure Configuration of Ubuntu 20.04 | OpenSCAP Security Guide
A CIS report will be added to the rootFS download files location.