Virtual Appliance Hardening

The Threat Command virtual appliance is a secure, closed appliance: both the OS (Ubuntu 20.04 LTS) and the application are maintained solely by Rapid7. In addition, Rapid7 performs server hardening to ensure that it complies with security requirements.

This document describes the Threat Command virtual appliance hardening measures that are in place.

Note: The user is expected to ensure that the virtual appliance is running at the latest version. Updating the version is described in this document.

General

The Threat Command virtual appliance runs inside a single Docker container. That Docker execution unit resides within its own siloed environment, which significantly reduces the surface of vulnerability exploitation.

From a security point of view, Docker ensures that applications that are running on containers are completely segregated and isolated from each other, granting complete control over traffic flow and management. No Docker container can look into processes running inside another container. From an architectural point of view, each container gets its own set of resources ranging from processing to network stacks.

Docker security

Docker utilizes several layers of security mechanisms, including kernel namespaces and Control Groups. These layers provide each running container with a private running environment, in which one cannot see nor affect other processes in the host or in other containers. Kernel namespaces and Control Groups are features of the Linux kernel.

Kernel namespaces also provide a method for the containers to isolate their network stack. Each container runs with a private network stack, having a virtual network interface, and therefore can’t access sockets or interfaces of the host or other containers. From a network architecture point of view, all containers on a given Docker host are sitting on bridge interfaces. This means that they are just like physical machines connected through a common Ethernet switch.

Kernel namespace code has been exercised and scrutinized on many production systems and the design and the implementation are quite mature.

Control Groups are another key component of Linux containers. They provide many useful metrics, and they also help ensure that each container gets its fair share of memory, CPU, disk I/O, and, more importantly, that a single container cannot bring the system down by exhausting one of those resources.

Control Groups also play a role in preventing one container from accessing or affecting the data and processes of another container, they are essential to fend off some denial-of-service attacks. They are particularly important on multi-tenant platforms, like public and private PaaS, to guarantee a consistent uptime (and performance) even when some applications start to misbehave. Control Groups code is also very mature.

Monitoring

The Threat Command virtual appliance is constantly monitored by Rapid7 engineers to track and dramatically reduce any synchronization and connectivity issues.

Telemetry, application, microservice level, and infrastructure logs are sent periodically to Rapid7 servers.

Penetration testing

Code penetration tests are performed bi-annually by a third-party, certified vendor to ensure security compliance. The penetration tests are greyhat-based; the assessors are given platform credentials, and they operate without restriction.

If a vulnerability is found that warrants immediate action, all affected customers are notified immediately, and an update is deployed within 72 hours. In less severe cases, patches are deployed in a future version, depending on the severity.

Virtual appliance update

Regular updates are communicated through the virtual appliance platform as a pop-up when the admin user logs in to the dashboard. When the user approves the popup message, the virtual appliance begins the update process immediately. The user can also check for updates from within the virtual appliance web user interface. Updates with critical security fixes are also communicated via email and phone.

OVA maintenance

The OVA is updated whenever there's a security fix relating to the underlying OS. Differences may exist in the operating system APT packages version from previous releases. The OVA is rebuilt and replaced in the cloud.

When the admin user logs in to the dashboard, a pop-up informs them of the new version. Updates can also be performed manually from the appliance.

An SHA-1 hash is supplied with the OVA. The user should always validate the file hash before installing the OVA. Hash values are found on the platform, right beside the download link for the OVA file.
To calculate the hash of the downloaded appliance, run: sha1sum [appliance_path]

If a critical vulnerability is found, users are given prior notice and a call for action. Forced update is not done automatically.

NOTE: Existing appliance users do not need to download the new OVA, as security updates will reach them as well.

Operating system

The virtual appliance is based on Ubuntu v20.04. The image is updated with newer packages using the Ubuntu Advanced Packaging Tool (APT). APT commands are logged in the /var/log/dpkg.log log file. Updates to the operating system are supplied via the virtual appliance task system. When the OVA is updated, the latest security packages are installed. There are no separate partitions.

The appliance polls for new IOCs every minute, and it sends logs (telemetry, application, microservice level, and infrastructure) to the SaaS platform every two hours.

Communication between the appliance and the SaaS platform is through verified SSL. The API routes on the SaaS platform also undergo security checks before every version is deployed. All communication to the SaaS platform is protected by Cloudflare. This provides web application firewall capabilities to every request made to the platform, including all the communication endpoints between the virtual appliance and the SaaS platform.

The following security measures are also enforced:

• IP address forwarding and send packet redirects are disabled.
• The available service list is very lean. All services that are not required for the platform are removed.
• IPv6 service is disabled.
• iptables firewall configuration allows communication only with the specific services that are explicitly allowed. ICMP echo request (ping) is allowed to enable connectivity checks.
• The latest available packages with the latest security updates are used.
• /etc/motd (message of the day service) is disabled and replaced with a Rapid7 greeting message.
• SYN cookies are turned on by default. This is done so that when the system is overwhelmed by new network connections, SYN cookie use is activated, which helps mitigate a SYN-flood attack.
• Address Space Layout Randomization (ASLR) is implemented by the kernel and the ELF loader by randomizing the location of memory allocations (stack, heap, shared libraries, etc). This makes memory addresses harder to predict when an attacker is attempting a memory-corruption exploit. The virtual appliance has ASLR enabled, by default, and the randomize_va_space sysctl value isset to 2, the safest configuration, as it also randomizes data segments.

The following list shows kernel protections that are part of the Ubuntu 20.04 LTS

• server: 0-address protection

• /dev/mem protection

• /dev/kmem disabled

• Block module loading

• Read-only data sections

• Stack protector

• Module RO/NX

• Kernel Address Display Restriction

• Kernel Address Space Layout Randomisation

• Blacklist Rare Protocols

• Syscall Filtering

• dmesg restrictions

• Block kexec

• UEFI Secure Boot (amd64)

For more information, see: https://wiki.ubuntu.com/Security/Features

Root account

The root account is disabled; there is no option to connect to the appliance as a root user.

Administrative account

Only one administrative account is supplied with the appliance.

The admin user has sudo permissions, which prevents privilege escalation. The default password is admin, and the user must change this password on initial login.

Shell and console access

You can access the virtual appliance shell using console or SSH. The SSH server is supplied with the default port (22) enabled. This port can be changed in the OpenSSH configuration.

Networking

The virtual appliance includes a firewall service.

The following ports are the only ones that are open for inbound connections:

These default ports cannot be changed.

Services and Security Measures

Every release cycle, all services are updated to their latest version, after being checked for security compliance. Service logs are collected and sent to Threat Command for automatic monitoring.

UI security

The user interface is built on a Python HTTP server platform.

SSL communication is with a self-signed certificate. Because the appliance resides in a customer domain, and it will be given an unknown IP address or hostname, no vendor can sign a valid SSL certificate for it. If customers wish to work with a valid SSL certificate for the appliance web user interface, they can install a company trusted CA-signed certificate on the appliance.

This should not be confused with the signed SSL communication that the appliance performs with Threat Command.

The password is user-configured.

Cloud connectivity SSL

All cloud communication and pull packages are encrypted using SSL with a valid certificate. The certificate is determined by the service with which the virtual appliance is communicating. For example, Cloudflare-signed for the *.intsights.com domain, and Google-signed for the Google managed services.

Docker login

Login is performed securely, over SSL, with a Google-provided API key.

Security measures per service

The following table depicts specific security measures that were taken, for each service: