SimpleHelp Security Guide

SimpleHelp may be simple to use, but we do not 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.

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, accessing a remote machine's files, or viewing CPU usage charts via the Access tab. SimpleHelp encryption is always applied, and the encryption process is independent of the type of connection 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 sent to the server. Services will only re-register with, and upload data to, a SimpleHelp server that is recognised. A service recognises a SimpleHelp server because a secure server ID is fetched on first registration. If a new server appears with a different server ID, services will stop registering with that server until the expected server ID is reinstated.

Security Best Practices

By default your SimpleHelp server secures and encrypts all connections and sensitive data, however there are additional security measures we recommend for every deployment.

We recommend the following steps:

• Run the built-in Security Audit and address any serious issues or recommendations.
• Disable or remove the SimpleHelpAdmin user. If this user is required, set a secure password, such as a long passphrase, and require multifactor authentication.
• Set up multifactor authentication for all technician groups. See our Authentication Guide for details.
• Configure password strength, failed login restrictions, technician authorisation for new devices, and login IP restrictions.
• Restrict technician permissions so that each group has only the capabilities it needs.
• Review Toolbox, API token and Cyana permissions carefully because these features can run tools, scripts, commands, or other actions on remote machines.
• Configure a valid SSL certificate, redirect HTTP to HTTPS where appropriate, and use the recommended SSL protocols and ciphers.
• Configure the server firewall to block incoming connections on ports other than the SimpleHelp server's configured ports, which default to 80 and 443.
• Keep secure backups of the SimpleHelp configuration folder, especially the server ID and any custom encryption key files.

Security Audit

SimpleHelp includes a built-in server security audit. Open the Administration tab, select Server Health, then run Perform a Server Security Check.

The security audit checks the server configuration for common hardening issues, including:

• missing, self-signed or expiring SSL certificates;
• the legacy SimpleHelpAdmin account still being enabled;
• technician groups without multifactor authentication;
• technician groups without session or Technician Console inactivity timeouts;
• non-administrator groups that can manage Server Events;
• technician accounts that have not logged in recently;
• weak or unset minimum password strength;
• missing administrator, technician or API IP restrictions;
• missing failed login restrictions;
• API tokens that exist without API IP restrictions;
• missing Server Event notifications for failed logins and new API tokens;
• weak SSL protocols or ciphers.

The server also performs a recurring security audit and can notify administrators when serious issues or recommendations are detected. Treat serious audit entries as items to resolve immediately, and review recommendations during regular server maintenance.

Firewalls and NAT Devices

It is important that the SimpleHelp server is 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 limit attacks on the server itself.

UDP Security

There is no additional security risk to enabling UDP incoming connections. SimpleHelp uses TCP, including straight TCP and HTTP/S, as well as UDP, but it does not rely on the transport to provide encryption. SimpleHelp encrypts all data sent in a session, as well as data sent when machines register with the SimpleHelp server. This is the same encryption whether the connection 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 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 Let's 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 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 the 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, and will not process many typical web requests that can cause security issues. For example, the SimpleHelp web server will not process CGI, PHP, Perl, 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 relevant because the script is assuming the SimpleHelp server is a Tomcat or IIS based general web server. These scripts may also report missing HTTP headers. If you wish to add HTTP headers to your SimpleHelp server web requests 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 provide security benefits, but they should be evaluated with your SimpleHelp integration to ensure the SimpleHelp server is still accessible via your support site:

The legacy X-XSS-Protection header is no longer recommended for modern browsers. If a penetration test specifically requests it, evaluate whether it is required for the browsers you support before adding it.

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, and limits the impact of a compromised account.

MFA and Auth Services

We suggest configuring app-based multifactor authentication for the SimpleHelpAdmin user in v5.5 and earlier, and for all technicians. This ensures that even if a 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. It also covers OpenID Connect, Entra ID, LDAP, Active Directory and RADIUS authentication services. If your external authentication service already requires multifactor authentication, you may choose to avoid duplicating that requirement inside SimpleHelp, but you should still ensure that only appropriate users can authenticate into SimpleHelp.

When using group-authenticated logins, use authentication filters to limit which users from your directory or identity provider are allowed to become SimpleHelp technicians. See the Authentication Filtering Guide for details.

Password and Login Rules

Configure the minimum password strength for local SimpleHelp technician accounts. Avoid weak or reused passwords, and force a password change when credentials do not meet your policy.

You should also configure failed login restrictions. SimpleHelp can block repeated failed login attempts by account or by IP address, reducing the risk of brute-force attacks.

New Device Authorisation

Technician authorisation can require logins from new devices to be authorised before the Technician Console is allowed to continue. Authorisation can be performed by a server administrator or by email to the technician's account address. This is useful when technician credentials are valid but the login is occurring from a device that has not been seen before.

Login IP Restrictions

It is possible to restrict logins to specific IP address ranges in the Administration section named Login Security. SimpleHelp supports separate network restrictions for:

• Technicians;
• Server Administrators;
• Remote Work users;
• API requests.

If you restrict IP ranges, include any local IP addresses or LAN ranges that administrators may need, such as 127.0.0.1, ::1, or your internal network ranges. Otherwise you may lock yourself out of the server. If your technicians work from home or from other locations 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.

Network restrictions can use a single IP address, a wildcard pattern such as 192.168.1.*, or CIDR notation such as 192.168.0.0/24.

You can configure these restrictions in the Login Security section of the Administration tab. See the Login Security section in the Administrator Guide for more details.

Session and Console Timeouts

Technician groups can be configured with inactivity timeouts for remote sessions and for the Technician Console. We recommend setting timeouts for every technician group so that unattended consoles and stale sessions do not remain active indefinitely.

Login Event Logging

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, email administrators, or handle them using another supported action, so that brute-force login attempts can be identified and blocked.

You should also create a Server Event notification for new API tokens. API token creation is a sensitive administrative action and should be visible to server administrators.

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.

Least Privilege

Technician Group permissions determine what technicians can see and do. Apply least privilege: each group should only be able to use the features required for its role.

Pay particular attention to permissions that allow technicians to:

• administer the server;
• manage technician accounts or technician groups;
• start Remote Support or Remote Access sessions;
• control sessions without requesting permission;
• use file transfer, diagnostics, port forwarding or app tunnels;
• install or manage Remote Access Services;
• manage monitoring, monitoring alerts or Server Events;
• view or manage session recordings and history;
• manage tags or assign tags to machines;
• manage, import or run Toolbox tools;
• use Cyana or grant Cyana access to files, commands, screenshots or session control.

The Security Audit will flag non-administrator technician groups that can manage Server Events, because Server Events can automate powerful actions.

Securing API Tokens

The SimpleHelp API allows third-party software and scripts to perform API requests against the SimpleHelp server. API tokens should be treated like privileged credentials.

When creating or reviewing API tokens:

• give each token a clear description so that its purpose and owner are known;
• enable only the permissions the integration requires;
• avoid granting server configuration, technician, group, machine modification, history or Toolbox execution permissions unless the integration genuinely needs them;
• configure API IP restrictions so tokens can only be used from expected networks;
• remove unused tokens;
• configure a Server Event notification when a new API token is created.

API tokens can be permitted to list toolboxes and run toolboxes on remote machines. These permissions should be granted with particular care, because they allow automation outside the Technician Console.

Securing Remote Machines

Remote Access Services register with the SimpleHelp server using their unique ID. The server and service 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 connect to sensitive machines or services.

Review New Service Installations

If unrecognised Remote Access Services appearing in the Access tab is a concern, enable Review New Service Installations. New services will be placed in an Awaiting Approval group until reviewed and approved. Services awaiting approval cannot be connected to until a technician with the appropriate permission approves them.

This is recommended for deployments where Remote Access Services should only appear after an administrator or trusted technician has verified that the service is part of the intended deployment.

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 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.

Service Blocking and Clean-up

Remote Access Services that should no longer appear can be forgotten or blocked. You can also configure SimpleHelp to automatically forget services that have been offline for a specified duration. Regular clean-up reduces confusion and makes unexpected or unauthorised services easier to spot.

Server ID and Authenticity

SimpleHelp applications and Remote Access Services use the SimpleHelp server ID to verify server authenticity. If the server ID changes unexpectedly, applications may refuse to communicate with the server because this can indicate that a different server is answering at the expected address.

Keep a secure backup of your SimpleHelp configuration folder, and especially configuration/serverkeys.dat. See Server ID and Authenticity for details.

Toolbox and Script Execution Security

Toolbox tools can run commands and scripts on remote machines, include resource files, download resources before execution, and run in different contexts depending on the tool configuration. Treat Toolbox content like operational code.

We recommend:

• restricting who can manage tools and toolboxes;
• restricting who can import tools and shared toolboxes;
• restricting who can run tools from the Access tab or inside sessions;
• reviewing imported or shared toolboxes before running them;
• documenting the purpose, owner and expected behaviour of powerful tools;
• avoiding embedded secrets in scripts or command lines;
• removing temporary resources after a tool run where possible;
• reviewing tool run history when investigating unexpected machine activity.

For more information, see the Toolbox Guide and the Toolbox Scripting API Guide.

Cyana and AI Security

Cyana is SimpleHelp's integrated AI assistant. If Cyana is enabled, it should be governed by the same least privilege principles as other administrative tooling.

Cyana can be controlled at the server level in Server Features and at the Technician Group level using group permissions. Depending on configuration, Cyana permissions can allow technicians to:

• use web research;
• view machine details and metrics;
• view screenshots;
• read files and folders;
• modify files and folders;
• run commands and scripts;
• manage processes and services;
• view or assign machine tags;
• control in-session mouse and keyboard input.

Review these permissions carefully before enabling Cyana for a technician group. The ability to run commands, modify files or control a session can have the same impact as giving a technician those capabilities directly.

When configuring AI endpoints, protect API keys, review endpoint URLs, and consider what data may be sent to the configured provider. Technician-specific Cyana context is included with every Cyana Command request from that technician, so avoid adding secrets or sensitive customer data to that context.

Cyana's auto-approve settings can allow actions to be performed without explicit approval for each tool call. Only use auto-approve for trusted workflows and narrow scopes. Auto-approve can include actions such as reading files, modifying files, running commands, executing scripts, managing processes or services, and accessing screenshots.

Data at Rest and Custom Key Encryption

SimpleHelp uses internal private keys to encrypt data stored by the SimpleHelp server. For additional protection you can configure SimpleHelp to use a custom encryption key specific to your SimpleHelp server installation.

If you use custom key encryption, keep an immediate secure backup of the key file and password. If the password or key backup is lost, encrypted data cannot be recovered. See Custom Key Encryption for setup details and warnings.

Advanced SSL Setup and Configuration

By default SimpleHelp balances security with compatibility for 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.

Protocols and Ciphers

For SimpleHelp 5.4 and later, configure SSL protocols and ciphers from the Administration tab rather than editing files manually. See Configuring HTTPS / SSL Access in the Administrator Guide.

Use the Use Recommended option in the SSL protocols and ciphers dialogue unless you have a specific compatibility requirement. The current recommended protocol set is:

TLSv1.2
TLSv1.3

We recommend disabling:

• SSLv2Hello;
• TLSv1;
• TLSv1.1.

The recommended cipher set is based on the server's available ciphers and SimpleHelp's cipher security metadata. Where supported by the Java runtime, the preferred ciphers are:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Avoid enabling weak or legacy cipher families unless you have a documented compatibility requirement. This includes CBC mode suites, RSA key exchange suites, anonymous suites, export suites, RC4, 3DES, and DHE or DSS suites. If you temporarily enable weaker ciphers for compatibility, document the reason and remove them as soon as possible.

The Security Audit will flag weak protocols and ciphers and can take you directly to the SSL configuration dialogue.

Legacy SSL Configuration

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

Disabling TLS 1.0 and TLS 1.1

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

configuration/sslconfig/acceptedprotocols

Set the contents to:

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, and 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

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

configuration/sslconfig/acceptedciphers

For older installations that support these ciphers, use the ECDHE AES-GCM ciphers below as the preferred manual list:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

These ciphers provide Perfect Forward Secrecy and avoid the older CBC, DHE, RSA key exchange, RC4 and 3DES suites that are now commonly flagged by SSL scanners. When SimpleHelp is next restarted the changes will be applied at startup.

Setting the Diffie-Hellman Key Size

The recommended cipher set avoids DHE ciphers. If you must enable DHE ciphers for legacy compatibility, some SSL test utilities may 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 and server, it does not negotiate these algorithms. 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, available at /mobile 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. In practice SimpleHelp performs application-level encryption above the underlying SSL connection. Instead SimpleHelp will always use its DTLS based protocol with its own encryption algorithms, RSA-4096 and AES-256, and will treat the base level connection purely as a transport, much in the same way that SSL treats 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 all of them.

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.