SimpleHelp Security Guide

SimpleHelp may be simple to use, but we don't take shortcuts, and we take security seriously.

Basic Security Overview

X	X
All sessions are always securely end-to-end encrypted.	Remote Access Services communicate monitoring and alert data over encrypted channels.

Remote Access Services communicate monitoring and alert data over encrypted channels.

Every SimpleHelp server uses high-end, industry-standard encryption algorithms to protect your data whether you are in a session transferring screen updates and files or just accessing a remote machine's files and CPU usage charts via the Access tab. SimpleHelp encryption is always applied, and the encryption process is entirely independent to the type of connection type used in a session. Data transferred over HTTP, TCP or UDP is encrypted regardless.

The primary algorithms used are 4096-bit RSA and 256-bit AES. These are widely regarded as more than sufficient to protect critical data.

Remote Access Services that register with the SimpleHelp server also encrypt any out-of-session data that is sent to the server. Additionally, services will only re-register with (and upload any data) to a SimpleHelp server that is recognised. A service is able to recognise a SimpleHelp server as a secure server ID is fetched on first registration. If a new server appears with a different server ID then services will cease to register with the new SimpleHelp server until the server ID is re-instated.

Security Best Practices

By default your SimpleHelp server will secure and encrypt all connections and sensitive data, however there are some simple security measures we recommend everyone take, and some optional security features which you may want to take advantage of.

We recommend the following simple steps to ensure your SimpleHelp server is secure:

• Set a secure password (long and complex, for example a passphrase) for the SimpleHelpAdmin user. This can be set in the Administrative Password section of the Administration tab.

• Set up multifactor authentication for the SimpleHelpAdmin account. See our Authentication Guide for details on how to set up multifactor authentication.

• Create a Technician Group and configure multifactor authentication for the group. Assign all technicians to this group.

• Configure the server firewall to block incoming connections on ports excluding the SimpleHelp server's configured ports (default ports are 80 and 443) and other critical access ports (such as port 2222 for SSH Mobile VNC access).

Firewalls and NAT Devices

It is important to note that the SimpleHelp server must be publicly accessible and able to receive incoming TCP and UDP connections on the ports it has been instructed to listen on (these default to ports 80 and 443). By blocking all other ports you ensure that attacks on the server itself are limited.

UDP Security

There is no additional security risk to enabling UDP incoming connections. SimpleHelp uses TCP (straight TCP as well as HTTP/S), as well as UDP, but it does not rely on the transports to provide any sort of encryption. We encrypt all the data that is sent in a session, as well as data sent when machines register with the SimpleHelp server. This is the same encryption whether it is over TCP, UDP, HTTP or HTTPS.

Securing HTTP Access

SimpleHelp servers act as simple web servers that serve the application binaries. All distributed applications are signed to ensure authenticity, but we recommend securing HTTP access to ensure secure web access to the server.

SSL Certificates

If you are using a domain, we suggest using the built-in Let's Encrypt functionality to generate an automated SSL certificate or installing your own an SSL certificate. If the SimpleHelp server has a valid SSL certificate installed, and if the applications are downloaded over SSL, then all updates and HTTP-based communications with the server will also go over SSL. Regardless though, updates are signed, so the applications will only update themselves if the signature of the update binary checks out.

See our SSL Guide for information on setting up an SSL certificate.

For more information on encryption within SimpleHelp and SSL please see the In-Depth Security Explanation at the bottom of this document.

Redirect HTTP to HTTPS

If you have an SSL certificate configured or are using Lets Encrypt, you can have the SimpleHelp server forward all HTTP requests to HTTPS using the checkbox in the Admin tab Network Settings section. If you do use this method you should ensure you continue to maintain a valid SSL certificate otherwise downloaded apps may no longer communicate with your SimpleHelp server.

Redirecting HTTP to HTTPS can be set in the Administration tab, under the Network Settings section. See HTTPS and SSL section in the Administrator guide for more information.

Custom HTTP Headers

The SimpleHelp server runs a very restricted web server (not a full general web server like Tomcat or IIS) which will not process many typical web requests that can cause security issues. For example the SimpleHelp web server will not process any cgi, php, pl, asp or other server-side scripts. All server side logic within the SimpleHelp server is implemented within its core implementation and is therefore not subject to many of the usual web server attacks. In some cases, penetration test scripts may report issues that are not pertinent because the script is assuming the SimpleHelp server is a Tomcat or IIS based general web server, and in some cases these scripts may report missing HTTP headers.

If you wish to add any HTTP headers to your SimpleHelp server web requests to rectify these results you can do so in the Administration tab under you can do so in the Administration tab, under the Network Settings section.

HTTP security headers restrict functionality by design. The following HTTP headers can be added to provide some security benefits but they should be evaluated with your SimpleHelp integration to ensure that the SimpleHelp server is still accessible via your support site:

Securing Technician Access

It is important to secure Technician access to your SimpleHelp server. This prevents malicious users from logging in using a valid account.

Multifactor Authentication

We suggest configuring app-based multifactor authentication for the SimpleHelpAdmin user, and for all Technicians. This ensures that even if the technician username and password is compromised, a malicious user will not be able to log in to the SimpleHelp server.

Our Authentication Guide contains details on how to set up multifactor authentication

Technician Login IP Restrictions

It is possible to restrict Technician logins to specific IP address ranges in the Administration section named Login Security. If you do restrict IP ranges please note that these restrict all Technician logins including the SimpleHelpAdmin user, and that if you wish to log in from a local IP (e.g. 127.0.0.1) or a lan IP you must include these too, otherwise you may be locked out of the server. If your Technicians work from home or at any other location where the connection uses DHCP rather than a static IP, using this feature may lock them out when they are assigned a new IP address.

You can configure Technician Restrictions in the Login Security section of the Administration tab. See our guide for more details.

Logging Failed Login Attempts

The SimpleHelp server produces events every time a technician attempts to log in to the server. The server can be configured to take actions when these events are generated. We suggest configuring SimpleHelp to log these events to file, or to handle them using any other supported action, so that brute force login attempts can be identified and blocked.

Our Server Event Guide details how to set up a listener for particular events, and how to configure the actions to take when the events are produced.

Securing Remote Machines

Remote Access Services will register with the SimpleHelp server using their unique ID. The server and service will then set up a secure communication channel, where all machine information, monitoring data and other communications are securely transferred.

Technicians with a login to the SimpleHelp server can connect to any machines that are visible to their account. In some situations you may wish to take extra precautions to ensure that a malicious user who uses a compromised SimpleHelp account is not able to log in to sensitive machines or services.

Setting Machine Passwords

If you wish to provide an extra level of security for machines that are registering with your SimpleHelp server you can specify a per-machine password in the Remote Access Service configuration. This password must be entered every time a technician attempts to connect to the remote machine. This ensures that even if the server is compromised, a malicious user will not be able to access the services that they do not have a password for.

You can set a machine password in the Remote Access Service configuration. See our Remote Access Guide for more information.

Machine Filters

Machine filters reduce the list of machines that a technician can see or connect to and are a good mechanism for ensuring controlled access to important machines.

Our Filtering Guide contains details about how to set up machine filters.

Advanced SSL Setup and Configuration

By default SimpleHelp will offer maximum compatibility with older browsers and operating systems. You can configure the server to offer increased SSL security at the expense of older browser support. It is important to emphasise that SimpleHelp encrypts all session data independently, so changing these SSL settings will not affect the security of your in-session data.

For SimpleHelp 5.4 and later, see this section of the administration guide about selecting protocols and ciphers

For older versions, you can use the following legacy steps:

Disabling TLS 1.0 and TLS 1.1 (Versions prior to 5.4)

To disable TLS 1.0 and TLS 1.1 edit the following configuration file in your SimpleHelp installation:

configuration/sslconfig/acceptedprotocols

in a text editor of your choice, and set the contents to be:

SSLv2Hello
TLSv1.2

TLS 1.2 is supported by the following browsers: Microsoft Edge, Microsoft Internet Explorer (10 or later), Google Chrome (30 or later), Mozilla Firefox (27 or later) , Apple Safari (7 or later). When SimpleHelp is next restarted the changes will be applied at startup.

TLS 1.3 is supported in SimpleHelp 5.4 and later.

Restricting SSL Ciphers (Versions prior to 5.4)

You can restrict the ciphers that SimpleHelp will offer to SSL connections. Restricting the ciphers may make certain browser and applications incompatible. To alter the cipher set edit the following configuration file in your SimpleHelp installation:

configuration/sslconfig/acceptedciphers

in a text editor of your choice, and set the contents to be:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

These ciphers offer Perfect Forward Secrecy, but they can be restricted further if required. When SimpleHelp is next restarted the changes will be applied at startup.

Setting the Diffie-Helman Key Size

Some SSL test utilities will recommend using Diffie-Hellman key sizes greater than 1024 bits. You can configure SimpleHelp to require larger key sizes by making these changes in your SimpleHelp installation folder. Copy the file:

lib/config.configurable

to:

configuration/config.configurable

There is no need to copy the file if it already exists in the target location. Next, edit the file in a text editor and add the line highlighted below:

[SimpleHelp]
jvmArg=-Xmx403m
jvmArg=-Djdk.tls.ephemeralDHKeySize=2048

When SimpleHelp is next restarted the changes will be applied at startup.

In-Depth Security Explanation

SimpleHelp converges on one mechanism to secure data transferred between technicians and customers or technicians and Remote Access Services. In doing this we focus on one secure implementation that is then used across multiple apps and multiple forms of encapsulation.

SimpleHelp implements a protocol closely based on DTLS using AES-256, RSA-4096, and a combined 256-bit SHA-512/SHA3 (Keccak) authentication hash. Since SimpleHelp always retains control over both ends of the connection (app + server) it does not negotiate these algorithms and thus all sessions and established communications between a Remote Access Service and your server will always use AES-256 and RSA-4096.

Whether you are connected in a session using HTTP, TCP or UDP as an underlying transport or accessing a remote machine's stats or filesystem, all communications are encrypted using this protocol and these mechanisms.

Although SimpleHelp does support and can use SSL, SimpleHelp does not rely on SSL connections to provide security except in the case of browser sessions such as the mobile client (/mobile page on your server) and secure presentations being viewed in a browser. SSL can be configured to be used in a session but this is not necessary for the data transferred to be encrypted and in practice SimpleHelp will be performing a higher level of encryption than the underlying SSL connection. Instead SimpleHelp will always use its DTLS based protocol with its own encryption algorithms (RSA-4096 / AES-256) and will treat the base level connection purely as a transport, much in the same way that SSL will treat TCP/IP as a transport.

As such even when connected to the remote machine over SSL SimpleHelp will still encrypt all information transferred with its standard high security algorithms and will not simply rely on SSL to provide a secure layer. This approach allows SimpleHelp to establish connections via a variety of mechanisms including plain HTTP, TCP, SSL and UDP while retaining high security across both.

Established connections therefore may appear to use plain HTTP or TCP but this is a result of encapsulating the secure DTLS implementation on top of these.