You can install the SmartServer IoT in a private network, with or without an internet connection. You can also install the SmartServer in the DMZ of an IP router or connect it directly to the Internet. To prevent exposure to malicious attacks, you can also install the SmartServer on a VPN. You can secure the communication between any web browser clients and the SmartServer using certificates.  Certificates use a public and private key pair to encrypt communication from a web browser to the SmartServer. Certificates may be self-signed or signed. Self-signed certificates are signed and validated by the SmartServer. Self-signed certificates provide encryption, but they do not authenticate that you are communicating with the SmartServer you intended to communicate with. You can authenticate the SmartServer by using a signed certificate where the certificate is validated by an external certificate authority. When using a signed certificate, you can use a signed certificate included with the SmartServer, or for enhanced security you can provide your own custom signed certificate.

The following sections describe the various network architecture scenarios, how to access a SmartServer from the Internet, and the use of both self-signed and signed certificates along with DDNS.

Enabling / Disabling Enhanced Security

Enabling / Disabling enhanced security is available with SmartServer 3.5 and higher.

Enhanced security is enabled by default on:

• A factory-configured SmartServer that is shipped with 3.5 or higher
• A SmartServer with 3.5 or higher after a factory reset
• A SmartServer that is  re-imaged with 3.5 or higher

Enhanced security is disabled by default on a SmartServer that is updated to 3.5 or higher from a release prior to 3.5.

Enhanced Security has no effect when using SAML or OAuth 2.0 Authentication Methods. Enhanced Security passwords are used when the Authentication Method is set to Basic. 

Enhanced security enables/disables the following features:

• Password (pwd) – controls whether strong passwords are required and whether the console times out. Strong password requirements are: must have at least 14 characters, including digits, as well as lower-case, upper-case, and special characters. 
  

  With SmartServer 3.6 and higher, if you log into the SmartServer Configuration pages and Enhanced Security is enabled, and your password does not meet the strength requirements, then you will be required to change your password. See Changing Passwords for Enhanced Security in the Managing SmartServer IoT Passwords section.

  Since the Enhanced Security feature is enabled by default, and the default factory password does not meet the enhanced security password requirements, you will always be required to change your password the first time you log into the SmartServer Configuration pages with SmartServer 3.6.

  If the Enhanced Security feature is disabled, then strong passwords are not enforced and changing the password will not be required. For example, if you upgrade to SmartServer 3.6 from previous release that has the Enhanced Security disabled, and you have a simple password, then the first time you log into the SmartServer Configuration pages, you will not be forced to change your password.
  
  

• SCP (scp) – SCP (secure copy protocol) controls permissions for root access over SSH. With enhanced security enabled, root access over SSH is not allowed.
• Firewall (fw) – controls whether the firewall is enhanced or not (default is enhanced). The enhanced feature sets the default to deny outgoing and routed ports, and resets port rules to factory defaults. Ports will be opened for enabled services dynamically, except for incoming MQTT ports on the Features Configuration page. When disabled, the default for outgoing ports is set to allow.

You can enable/disable enhanced security using an option on the System Configuration page or using the SmartServer Secure Utility. These options are described in the sections that follow.

For SmartServer Pi, you can enable enhanced security using the CMS Settings widget. See Configuring Security (Authentication Method).

Using the System Configuration Page

To disable/re-enable enhanced security for the SmartServer IoT using the System Configuration page, perform the following steps:

1. Open the SmartServer Configuration page as described in Accessing the SmartServer IoT Configuration Page. The Network tab appears as the default SmartServer Configuration page. Once the network settings are configured for the SmartServer system, then the System tab will appear as shown in the next step.

   
   
   SmartServer IoT Network tab
   
   

2. Click the System tab if needed. The System tab appears.

   
   
   SmartServer IoT System tab
   
   

3. Enable the Enhanced Security option.
   
   
   SmartServer IoT System tab
   
   The commands following commands are used by the System Configuration page to enable or disable enhanced security:

   • Enable:  sudo /sbin/smartserver-secure +all
   • Disable:  sudo /sbin/smartserver-secure -all



4. Click Update. 
   

   A fresh login session is required for changes to take effect after the enhanced security option has been modified.

Using the SmartServer Secure Utility

The SmartServer Secure Utility provides a way to enable/disable enhanced security features using the console. 

To use the SmartServer Secure Utility, perform the following steps:

1. Log into the SmartServer console using USB or SSH.
   
   

2. Use the following command to enable or disable enhanced security options:

   smartserver-secure [Option] [-|+<feat> ...]

   If all the options are enabled, the command output is all.

   • The help option outputs enabled features and provides information about the utility.
   • Features are as follows:
      +<feat> to enable a feature
     -<feat> to disable a feature
     
     where <feat> is one of the following:
     
     • pwd –  controls whether strong passwords are required and whether the console times out. Strong password requirements are: must have at least 14 characters, including digits, as well as lower-case, upper-case, and special characters. A fresh login session is required for changes to take effect.
     • scp – SCP (secure copy protocol) controls permissions for root access over SSH. With enhanced security enabled, root access over SSH is not allowed.
     • fw  – controls whether the firewall is enhanced or not (default is enhanced). The enhanced feature sets the default to deny outgoing and routed ports, and resets port rules to factory defaults. Ports will be opened for enabled services dynamically, except for incoming MQTT ports on the Features Configuration page. When disabled, the default for outgoing ports is set to allow.

     • all – controls all features.
       
       Examples:

       To enable all features

       smartserver-secure +all

       Output is all.
       
       

       To disable strong passwords and console timeouts

       smartserver-secure -pwd

       If this command followed the previous example, then the output is scp fw.
       
       

       To output the currently enabled features

       smartserver-secure

       If this command followed the previous example, then the output is scp fw.
       
       

The SmartServer Secure Utility restores the current security settings when you update the SmartServer system. These security settings are not preserved when you re-image the SmartServer system.

Private Networks

The following figure illustrates an isolated private network and another one connected to the Internet, but without external access to the SmartServer.

Within the private network, a DHCP server that is typically part of a network address translation (NAT) router assigns non-routable IP addresses to devices, typically within the following IP address ranges:

10.0.0.0 → 10.255.255.255
172.16.0.0 → 172.31.255.255
192.168.0.0 → 192.168.255.255

Only the external-facing interface of the router is assigned a routable IP address, which may be dynamically or statically allocated by the service provider.

To access a SmartServer from within a private network, use one of the methods described in Connecting to Your SmartServer.

By default, the SmartServer is configured to use self-signed certificates, and therefore when trying to establish a secure connection to a SmartServer, a browser will always indicate the connection is insecure, as shown below.  However, you can safely proceed to the web page.

A typical use-case is illustrated below, where a SmartServer is connected to a private network, which uses a cellular connection to the Internet, and where the SmartServer can be accessed over the internet.

To access a SmartServer located in a private network from the Internet, network address translation (NAT) is used.  With NAT, traffic that arrives at the external interface of the NAT router is forwarded to the internal SmartServer on a port by port basis. Each type of NAT router has a different method to set up port forwarding.  Following is an example from a Netgear router:

You can forward any of the following ports to a SmartServer.  You can use the SSH port for console access, the SFTP port for file transfer access, the HTTPS port for web browser access, and the MQTT port for IAP access.

For enhanced security, only open those ports absolutely necessary for operation, leaving everything else blocked from external access.  For extra enhanced security, and only accept traffic from specific IP addresses. If you have multiple SmartServers in the same private network, use different external inbound ports for each.

For simplified setup, use a router or modem that connects to the Internet using a fixed routable public IP address supplied by the service provider.  This address becomes the public facing external address of the SmartServer. Most cellular providers will be able to supply fixed IP address SIM cards either directly, or through third party suppliers.  

Some routers support NAT loopback, which is where a local SmartServer can be accessed from inside the private network using its external address or name.

The internet connection may also be DSL or fiber-based as illustrated below.

The external address, a DNS entry in the customer domain in question or a local hosts file entry can be used to reference the SmartServer's external address. However, this will not resolve the security issues associated with using self-signed certificates when accessing the SmartServer, especially from the Internet.

Signed Certificates and DDNS

The SmartServer supports DDNS (dynamic DNS) and signed certificates, where a SmartServer can be referenced by a fully qualified domain name (FQDN) that matches its signed certificate. The combination of the two facilitates secure connections to the SmartServer, from outside the private network and also from inside, if NAT loopback is available.

The default signed certificate included with the SmartServer requires an Internet connection to authenticate the certificate with a public certificate authority.  If you are using the SmartServer on a private network that is not connected to the Internet, you can use your own signed certificates that is validated by a certificate authority within your private network. See Customer Certificates for details.

The following figure illustrates an example use-case with cellular connection:

To enable signed certificates, follow these steps:

1. Ensure that the SmartServer has a good internet connection by pinging a know site such as google.com from a console connection. See Connecting to Your SmartServer for information regarding connecting to the SmartServer using the console.
   
   

2. Open the SmartServer Configuration page. The Network tab appears as the default SmartServer Configuration page. Once the network settings are configured for the SmartServer system, then the System tab will appear as shown in the next step.

   
   
   SmartServer IoT Network tab
   
   

3. Click the System tab if needed. The System tab appears.

   
   
   SmartServer IoT System tab
   
   

4. Enable the Signed Certificates option.
   
   
   SmartServer IoT System tab
   
   

5. Reboot the SmartServer.
   
   Once you enable signed certificates, the SmartServer will automatically update its DDNS entry for the hostname printed on the label on the bottom of your SmartServer appended with echelon.cloud, checking every 30 minutes if the SmartServer's external address has changed. If an external address change is detected, the SmartServer will update DDNS accordingly, allowing for network reconfiguration if required. The SmartServer automatically renews the signed certificates with a certificate authority every 90 days.

   Even though DDNS is supported, the use of non-fixed IP address SIM cards for cellular connections may cause frequent communication disruptions because the external address may change as frequently as once a minute.  Any change to the SmartServer's external IP address requires some time to be reflected in the global DNS.  Frequent external IP address changes can cause complete loss of external access. 
6. Refer to the SmartServer by its registered FQDN within the global DNS to provide secure access. The registered FQDN consists of the hostname concatenated with .echelon.cloud as shown in this example:
   
   smartserver-17q3jd2.echelon.cloud
   
   
7. You can manually update the SmartServer's DDNS entry from a console connection having logged in as root (see Logging into the SmartServer in the Connect to Your SmartServer section for more information) using the following command. The update will require some time to propagate through the global DNS:
   

   /sbin/aws-update
   
   

8. To verify the correct DNS entry for the SmartServer, ping <smartserver hostname>.echelon.cloud and compare this to the result of the dig command shown below, which you can use to find the SmartServer's external address from a console connection.
   

   dig myip.opendns.com @resolver1.opendns.com

Once you have enabled signed certificates and the FQDN DNS entry has been updated to reflect the external address of the SmartServer, you can check the validity of the certificate installation using one of the many available public services such as https://www.geocerts.com/ssl-checker as shown below.

SSL Server Certificate

Common Name: smartserver-abcdefg.echelon.cloud
Issuing CA: Let's Encrypt Authority X3
Organization:
Valid: August 17, 2020 to November 15, 2020
Key Size: 4096 bits

Subject Alternative Names (SANs)

smartserver-17q4rsx.echelon.cloud

Certificate Expiration

This certificate will expire in 87 days.

Certificate Common Name (CN) and Hostname Match?

The hostname (smartserver-17q4rsx.echelon.cloud) matches the certificate and the certificate is valid.

DNS, etc.

smartserver-abcdefg.echelon.cloud resolves to 555.199.202.99.

Server type: nginx/1.10.3 (Ubuntu)

Certificate Chain Complete?

All of the correct Intermediate CA Certificates are installed. Your SSL certificate is installed correctly and should be supported in all the major web browsers without problems.

Common Name: smartserver-abcdefg.echelon.cloud
Organization:
Valid: August 17, 2020 to November 15, 2020
Issuer: Let's Encrypt Authority X3

Common Name: Let's Encrypt Authority X3
Organization: Let's Encrypt
Valid: March 17, 2016 to March 17, 2021
Issuer: DST Root CA X3

Common Name: DST Root CA X3
Organization: Digital Signature Trust Co.
Valid: September 30, 2000 to September 30, 2021
Issuer: DST Root CA X3

DMZs, Direct Connections and VPNs

In addition to using NAT and a private network, you can connect a SmartServer to a NAT routers DMZ or directly access it as shown below.

Alternatively, you can use a  VPN to connect a remote SmartServer to your internal network. For example, a cellular provider may be able to supply a VPN connection from the external edge of their network to a VPN server in the remote network (as would be typical for AWS usage). Therefore, a single VPN can support all the SmartServers attached to the cellular provider's network, and none would be exposed to attacks from the public Internet as illustrated below.

Customer Certificates

You can use your own signed certificates to further improve security, and to support signed certificates without Internet access. In this case, you do not need to set Enable Signed Certificates in the SmartServer Configuration page, as described in the section Signed Certificated and DDNS.

To use your own signed certificates, follow these steps:

1. Place your signed certificates in a suitably named directory within /var/apollo/data/certs as shown in the figure below.
   
   
   
   As an example, with signed certificates enabled, the contents of /etc/nginx/sites-enabled/certs.conf are as follows for smartserver-17q4rsx.echelon.cloud:
   

   # ======= SSL keys - CA Signed ======
   ssl_certificate         /var/apollo/data/certs/smartserver-17q4rsx.echelon.cloud/fullchain.pem;
   ssl_certificate_key     /var/apollo/data/certs/smartserver-17q4rsx.echelon.cloud/privkey.pem;
   ssl_dhparam             /var/apollo/data/certs/smartserver-17q4rsx.echelon.cloud/dhparams.pem;
   # ===================================

   The expected names of signed certificate files are fullchain.pem and privkey.pem, which are soft links to the actual files. The expected names of self-signed certificate files are server.crt and server.key, which are not soft-links.
   
   

2. Edit /etc/nginx/sites-enabled/certs.conf to reflect your own certificates.
   
   
3. Restart nginx from a console connection using the following command, or simply reboot your SmartServer:
   

   sudo systemctl restart nginx

   See Connecting to Your SmartServer for information regarding connecting to the SmartServer using the console.

4. Populate your own DNS to reflect the SmartServer’s hostname and chosen domain such that it matches the certificate common name.

802.1x Mutual Authentication

The 802.1x Mutual Authentication option is available with SmartServer 3.6 and higher.

You can enable wired 802.1x mutual authentication using the EAP-TLS EAP mode (i.e., Extensible Authentication Protocol mode that tunnels over Transport Layer Security) using the System Configuration page or the BACnet Configuration page. Doing so enables wired 802.1x mutual authentication with EAP-TLS as shown in the figure below, where the supplicant is a SmartServer or Remote CMS host, the authenticator is an Ethernet switch with 802.1x support, and the authentication server is a RADIUS server or equivalent.

MAC Authentication Bypass (MAB) fallback will be used for initial provisioning to support SmartServer or Remote CMS host authentication prior to availability of an 802.1x compatible certificate. To install a new SmartServer, the SmartServer or Remote CMS host MAC address will be added to the authentication server allowed MAC ID-list. Doing so will enable the listed SmartServer or Remote CMS host to connect to the network for initial provisioning. Once provisioned, the MAC ID can be removed from the list.

Enabling 802.1x mutual authentication using the System Configuration page or the BACnet Configuration page requires that: