System security - best practice

  • 17 minute read
Prev Next

Appgate SDP appliances are secure by design including some of the additional hardening steps detailed in the Security Technical Implementation Guide (STIG) for Ubuntu developed by the Defense Information System Agency (DISA). There are a number of steps that you can take to further improve the system security. One or more of these actions can be implemented as they are all independent of one another. This section looks at the security of the Appgate SDP Collective and its related configurations; it does NOT cover more general ways to improve overall security in respect of networks and protected resources accessed through Appgate SDP.

Appgate SDP system hardening steps

1. Proxy Protocol

The System TLS Connection can be configured to use the “Proxy Protocol”. When this option is enabled Client connections will be accepted that use EITHER the special SPA key OR Proxy Protocol. It is therefore very important to limit the allowed sources for new connections (from the Proxy only).

As well as circumventing SPA users connecting directly can spoof their clientSrcIP by crafting a Proxy Protocol packet comprising the spoofed IP address.

So:

  • Set Allow Sources only from the Proxy itself

    NOTE

    By default Allow Sources has two configurations: 0.0.0.0/0 and ::/0 so don’t forget to either edit both or delete these, otherwise any additions will be overridden.

2. Device Registration

Appgate SDP has the ability to limit (new) device connections to the system. New device registration can be restricted firstly by quantity (per user) and then by the optional use of MFA. A new device registration is defined as the first time the Appgate SDP system has seen that specific combination of a user and a device.

By using Prevent new devices registrations that exceed this per user limit, devices can be limited to say one or two per user. After all the devices you require are registered, new device registrations can be blocked completely by setting the limit to zero or one (does not affect existing devices). When a new device needs to be added, existing devices can simply be removed from the list of registered devices.

After the per user limit is checked, then MFA at Sign-in can be used to further restrict new device registrations. Not required (Automatically register all devices), Once (MFA required to register all new devices) or Always (MFA required at every sign in) can be selected. For more information please refer to MFA.

So:

3. Using IP addresses not hostnames

A Gateway's or Connector's hostname does not require to be published outside of the system itself (even to users). So if IP addresses rather than hostnames are used then there would be no (external) DNS records for these appliances either. With the addition of SPA (especially in UDP-TCP) mode - it becomes almost impossible to find these appliances. This makes it very hard to mount any form of attack and can provide very effective DDOS attack mitigation with new (hidden) Gateways spinning up and users failing over to them automatically.

So:

4. SSH credentials

If a new appliance is set up from the command line, then the first Controller will be seeded with a CZ user password for SSH access to the appliance. (This will not be the case for Cloud instances which require PKI authentication.) Strong passwords are fine to use, but public key authentication is almost always stronger. The SSH authentication should be changed to public key for the first Controller.

First generate your SSH key pair.

Adding keys

To add this SSH key (for the cz user) on an appliance. From the command line on the first Controller do one of the following:

sudo cz-config user --authorized-keys "KEY" where KEY is your ssh key pasted between the "" (e.g. "ssh-rsa AABBCCDD......")
sudo cz-config user --authorized-keys-file FILE where FILE is the path to your ssh key.

The above cz-config commands will overwrite any current keys. If you are trying to ADD another key, then instead you must:

  1. Copy the file /home/cz/.ssh/authorized_keys to somewhere else such as temp/new_keys.

  2. Edit the new file to add the new key and save.
    NOTE: There must be ONLY ONE KEY PER LINE.

  3. Do the following: sudo cz-config user --authorized-keys-file FILE

Your SSH key(s) for the 'cz' user can now be used.

Pinning keys

To pin the key(s), preventing the cloud provider from overriding them do the following:

sudo cz-config user --pin {true,false}

Defaults to false.

Then from the admin UI go to System > Appliances > Networking > Advanced mode find the SSH Server section and disable <Password Authentication>.

There is an anti-bot feature which prevents the guessing/trying of countless passwords. The trigger point where this cuts in can be configured - refer to Advanced > SSH command line administration

5. SSH server access (default Port 22)

Allowing SSH access to the appliances from the internet is not recommended. SSH access should be limited to an internal or a management network.

There are three ways of doing this:

NOTE

The default allows two sources 0.0.0.0/0 and ::/0, so don’t forget to either edit both or delete these, otherwise any additions will be overridden.

For systems that can be accessed through an Appgate SDP Gateway, security can be further improved by using the Appgate SDP Client and then provide access via the tunneled interface (port 443) using Entitlement to port 22 on the internal interface of the appliance:

  • Add one or more appliance access for port 22 to the administrator Policy which already contains the admin roles.

6. MFA for Admins

The Appgate SDP system allows MFA to be mandated for administrators. This can be linked to a specific MFA provider which might be different from the one used by normal users.

See the Enable Admin MFA section.

NOTE

The default has Admin MA disabled. When enabling, do not forget to exclude the API User(s) if you are using APIs to manage the Controller.

7. Admin roles

The Appgate SDP system has a powerful role based delegated administration system built in. The type of privilege (e.g. read), the target (e.g. Entitlements) and the scope (e.g. tagged with) can be set per Role. Roles can be assigned with the same level of granularity as for Entitlements (in Policies).

So:

8. Admin rights

In Policies, it is possible to set up assignment criteria to limit when the specified Admin roles are applied (just like user Entitlements). When setting up the criteria there are a rich set of options available apart from just using directory group mapping that would typically be put in place. These can include: IP based criteria - e.g. to only allow internal IPs, time based criteria – e.g. to only allow working hours, geoIP based criteria – e.g. to only allow access from certain locations.

So:

9. Admin Token expiration

When an admin signs in to the admin UI, they have the option to select the Keep me signed in until the token expires checkbox. This is a powerful features, since the tokens are all that is required to sign back in to the admin UI. If there is a cached valid token on a machine, this will survive a reboot and allow access to the admin UI immediately when the browser is re-launched.

Shows the Keep me signed in option selected.

The cached token is removed when the user sign-out of the admin UI. Any remaining token(s) will also expire, even if the user does not sign-out.  

So to prevent unauthorized users gaining access to the admin UI:

  • Only tick “Keep me signed in until the token expires” on secure computers.

  • Always sign out of the admin UI using sign out at the top right of the admin UI.

  • Set the Administration Token Expiration time to an appropriate value that balances the needs of your admins with any shorter expiration time that security best practice demands (default is 24h).

10. Admin/API TLS Connection (default Port 8443)

Port 8443 is used for admin users (and API calls) but this only applies to Controllers and the LogServer. While it is possible to allow admin access from the internet, this port is not protected by SPA, so we strongly recommend against this configuration. Access should be limited to an internal or a management network.

There are three ways of doing this:

  • Configure your external firewall rules (or Cloud provider network security group)  to allow port 8443 access from only the internal network.

  • Set Allow Sources: for the internal network - in this example eth1.

List of allowed sources with corresponding network interface cards and IP addresses.

NOTE

The default allows two sources 0.0.0.0/0 and ::/0. Don’t forget to either edit both or delete these, otherwise any additions will be overridden.

  • Provision access to the admin UI through an Appgate SDP Gateway. By using the Appgate SDP Client, access can be granted the internal IP address of the of the Controller/LogServer via the Gateway's tunneled interface (port 443). Create a Controller/LogServer access Entitlement using their internal IP addresses on port 8443 and add it to the administrator Policy.

11. Admin/API TLS Connection HTTPS certificate

Admin/API access is via the Unique Admin Hostname. This uses the self-signed root certificate which means there will be an 'unsafe' warning shown (the browser does not trust the certificate). To avoid the admin having to approve this certificate, an externally signed certificate can be used. This requires a PKCS#12 file containing a certificate (for the Unique Admin Hostname) signed by a trusted CA and the private key is required to terminate the admin/API HTTPS connection.

When adding a new (trusted) certificate, it will associate to port defined in the Admin/API TLS Connection only. This will remove the untrusted warning in the browser and remove any possibility of man-in-the-middle attacks happening. It also makes it easier to set up API calls to the Controller using TLS.

So:

12. Use of SPA

Client and peer connectivity depends on sending a special Single Packet Authorization (SPA) packet up front.

By default the Appgate SDP system uses SPA for all communications from the Client to Controllers and Gateways and between peers using TCP SPA mode. SPA is more effective when using UDP-TCP SPA mode.

So:

  • Enable UDP-TCP SPA

    NOTE

    UDP traffic on ports 53 and 443 must be allowed to appliances for UDP-TCP SPA to work reliably.

    NOTE

    Users might occasionally struggle to connect in certain locations with very strict outbound UDP firewall rules. To mitigate this mode also comes with SPA overrides which can be configured if required.

13. System TLS connection (using SPA)

Clients and other appliances (for peer-to-peer communication) within the Collective need to be able to connect to the System TLS Connection (default port 443) on the appliances. This port is already protected by SPA so is designed to be exposed to the Internet. There may be some very specific situations where the use case is very constrained in which case the System TLS Connection security can be further improved by only allowing access from specific networks. Examples of this might be: where you allow access from your wired network but not from Wi-Fi; or you only allow internal access but want to prevent connections from the internal NATed IP of the firewall.  For full details please refer to the network configuration.

So:

  • Configure your Cloud providers network security group / external firewall rules to only allow port 443 access from a defined subnet

  • Set Allow Sources in System TLS Connection from a defined subnet

    NOTE

    The default allows two sources 0.0.0.0/0 and ::/0, so don’t forget to either edit both or delete these, otherwise any additions will overridden.

14. Client inactivity timeout

Desktop clients will be signed out automatically when the user or network has been inactive for the timeout period.

This feature is designed mainly to drop the open tunnels to the Gateways and prevent any background traffic being sent from unattended machines. It is not designed as a user security feature since the Client typically signs in automatically. However, when used with a suitable remedy action it will require a user interaction when the Client re-connects.

So:  

15. Access to other services

For each appliance, as well as enabling & restricting sources for the SSH service (covered in 5), you can add Allowed Sources for Ping and once enabled restrict the Allowed Sources for SNMP, Healthcheck (port 5555) and Prometheus (port 5556). Access to all these services should also be limited to only those hosts needing access to these services.

So:

16. Site access

is also possible to limit the extent of a user’s network access when a new Appliance is configured. Instead of adding a very open address range or just a network interface, specific Allow Destinations can be defined for the Gateway. This setting works in series with any Entitlement-based access rights that a user is granted. So, should a delegated administrator make a mistake in an Entitlement then the traffic might still be blocked by this Allow Destinations rule.

So:

Configuration settings for Allow Destinations with network address, netmask length, and interface input.

NOTE

By default, nothing is set for Allow Destinations, so no packets will be allowed through until something is configured.

17. Use of mTLS

All internal communications within an Appgate SDP Collective uses mTLS. However the Controller in particular, may interface with numerous external systems. Wherever possible mTLS should be used for these communications.

So:

18. Securing NTP

The system is very reliant on NTP to ensure the integrity of the security mechanisms used such as SPA and TLS. The default NTP server configuration uses unauthenticated public Ubuntu NTP servers which means it would be possible to intercept and modify the NTP replies.

So:

  • The default NTP servers should be deleted and alternative NTP servers added. These should ideally be private NTP servers located on a protected network. If this is not possible then the new servers should be 'secured' by selecting the Symmetric NTP key type and then adding the related Keyno and Key.

Configuration settings for an NTP server including hostname and key options.

19. Avoid the use of appliance customizations

Appliance customizations allow the execution of arbitrary code with root privileges. When a new appliance seed file is saved in the admin UI, the use of customizations will be set to disabled. If this facility is not required it should never be enabled.

It can also be disabled/enabled from the command line at any time:

20. Client auto-update service

The auto-update service runs on the client machine and increases the attack surface of the Clients. If you're not using this Appgate SDP feature to deploy upgrades across your user-base, you should disable this service.

So:

21. Client device claim scripts

Device claim scripts run as user service so increases the attack surface of the Clients. If you're not using this Appgate SDP feature to harvest additional Claims, you should disable this service.

So:

There is a device claim which can be used to check if they are disabled.

22. Client security

We recommend that Clients are installed via enterprise device management system (Intune, Jamf, SCCM, ...) and that the Appgate SDP Client profile is pushed as part of the install parameters. In order to make sure the Client is always running with this default configuration we also recommend you set a device policy that prohibits configuration changes to the following Client functions.

  • Autostart

  • Add and Remove Profiles

  • Keep me signed In

  • Browser/Certificate Auto Sign in

  • Suspend

  • Sign Out

  • Quit

23. Portal appliance

The Portal is an edge device with a Portal Hostname that is very likely to have a public DNS record. This means that HTTPS (port 443) will be open to the Internet; as will any Listening Port(s) which will be forwarded via the Gateways to the (protected) hosts. Neither of these are protected by SPA which means that the appliance is more vulnerable than other appliances in the Collective. Care must be taken as a compromised appliance could provide data to an attacker or act as a jump server.

So:

  • Limit access to the Portal appliance by:

    • setting inbound firewall rules for port 443 and any listening ports only.

    • setting Allow Sources in HTTPS Settings using Address and Netmask Length and/or Network Interface.
      By default, Allow Sources has 2 configurations: 0.0.0.0/0 and ::/0. Don’t forget to delete both of these.  

    • locating it in a DMZ away from other systems.

  • Use a unique SPA key for the Portal's Client Profile (to limit the consequences of the SPA keys loss).

  • Don't use wildcard certificates (and private keys) for the Proxied Entitlement Certificates (PKCS #12) - instead upload one or more certificates specific to each (protected) host.

24. STIG

The STIG guide for Ubuntu includes numerous small (and not so small) steps, each helping to further harden the appliance. Several of these steps have been baked into the appliance as standard. However a number have been made optional because they can have a negative effect on either the user experience or on the system performance. Unless you understand the STIG requirements and need to use some of these optional steps for compliance reasons we recommend leaving the system as is.

So:

  • SSH to each relevant appliance and run man cz-stig. This lists all the optional STIG steps that can be configured/enabled.

Conclusion

If you combine the all the built-in appliance hardening done by AppGate even before an appliance is commissioned with these best practice steps, then the Appgate SDP system presents a formidable security posture.

  • The system would for the most part lie hidden on the internet with only minimal DNS records and exposed ports. Except for the Portal, the only type of access allowed from the internet would be SPA initiated traffic, encrypted with the strongest TLS ciphers - ECDHE-RSA-AES256-GCM-SHA384. Only ‘known’ (on-boarded) devices would be authenticated, so even if usernames and passwords were compromised, access would not be granted.

  • Any admin access would be from a limited range of internal networks or separate management networks. Admins would require multi-factor authentication and even when authenticated, would only be given roles with very limited rights. All actions performed by an administrator would be recorded in the audit logs.

  • SSH access would be from a limited range of internal networks or separate management networks. It would require the use of strong public key based authentication and use brute force blocking to prevent the keys being guessed. Only aes256-ctr, aes192-ctr, aes128-ctr ciphers are supported. Any established SSH connection drops automatically after a short period of inactivity.

  • Client access can also be restricted: on the way in, from defined subnet(s); and on to the (protected) hosts by defining allowed subnet(s).

Related articles