Interpreting security scan reports for your server

Application security scans are a great way to review and improve the security of customer-facing applications. Often, these security scans also perform basic infrastructure checks that routinely generate large amounts of false positives or misleading results.

This article is a summary of the most common "security issues" reported to us, and will provide you with the information you need to analyze the report you've received.

Prefacing the summary, we want to make you aware of our article about Security recommendations for your Managed Server.

Ubuntu software versions and patching philosophy

Nine uses Ubuntu LTS versions (Long Term Support), which are released every two years.

With the release of each version, a major version for each particular software is chosen by Canonical. Over the lifespan of each LTS version, these major versions won't change. To ensure the LTS releases remain safe from critical security issues, Canonical is actively backporting security patches for critical parts of the operating system and software stack.

Therefore, while versions may appear to be outdated and potentially vulnerable, they're perfectly safe to use and security issues have been addressed by backported patches from newer releases.

A prime example of this is OpenSSH. On Ubuntu Focal, the OpenSSH version appears to be 8.2p1, when connecting to the server:

Remote protocol version 2.0, remote software version OpenSSH_8.2p1

However, at the time of writing this article (July 2024), the detailed package information is as follows:

apt-cache policy openssh-server
openssh-server:
  Installed: 1:8.2p1-4ubuntu0.11

The installed version 8.2p1-4ubuntu0.11 reflects the patch level (0.11) of the OpenSSH server package and illustrates the philosophy with which Canonical backports security updates. The patch level is deliberately not shown in the connection information above.

SSH

OpenSSH is the standard for establishing remote shell connections to servers. This makes OpenSSH a potential target for attacks, requiring a strict security approach in its development. When it comes to this aspect of security, the OpenSSH developers have done exemplary work.

OpenSSH is one of the most secure software in the world. Its defense-in-depth design and code are a model and an inspiration, and we thank OpenSSH's developers for their exemplary work.

These are the words of experts of Qualys, a company well established in the IT security scene with a record of hundreds of security issues found in various software projects over the years.

However, no software is free of bugs or issues.

Critical security vulnerabilities in OpenSSH have been extremely rare. In addition, the developers have been excellent at triaging and responding to issues that were found.

Following is a summary of fixed or disputed issues that we regularly see in security reports:

CVE	Affected OpenSSH version	Affected Ubuntu versions	Note
CVE-2016-20012	< 8.7	All before Jammy	Disputed issue, ignored on upstream. For more information, please refer to the Github discussion.
CVE-2020-14145	< 8.4	All before Jammy	Only affects the client integration. Fix possibly breaking RFC's. Ignored on upstream.
CVE-2020-15778	< 8.3	All before Jammy	Only affects authenticated users, see detailed information.
CVE-2021-28041	< 8.2	Focal	False positive, fixed in 8.2p1-4ubuntu0.2
CVE-2021-36368	< 8.9	All before Jammy	Disputed issue, ignored on upstream. Only applicable to FIDO authentication mechanism (not used at Nine).
CVE-2023-38408	< 9.3p2	All	False positive, fixed in: Xenial: 7.2p2-4ubuntu2.10+esm3 Bionic: 7.6p1-4ubuntu0.7+esm1 Focal: 8.2p1-4ubuntu0.8 Jammy: 8.9p1-3ubuntu0.3 Noble: 9.3p1-1ubuntu2
CVE-2023-48795	< 9.6	All	False positive, fixed in: Xenial: 7.2p2-4ubuntu2.10+esm Bionic: 7.6p1-4ubuntu0.7+esm3 Focal: 8.2p1-4ubuntu0.10 Jammy: 8.9p1-3ubuntu0.5 Noble: 9.6p1-3ubuntu1
CVE-2023-51384	8.9 - 9.6	Jammy, Noble	Only affects the ssh-agent
CVE-2023-51385	< 9.6	All	False positive, fixed in: Xenial: 7.2p2-4ubuntu2.10+esm5 Bionic: 7.6p1-4ubuntu0.7+esm3 Focal: 8.2p1-4ubuntu0.11 Jammy: 8.9p1-3ubuntu0.6 Noble: 9.6p1-3ubuntu1
CVE-2024-6387	8.5 - 9.6	Jammy, Noble	False positive, fixed in: Jammy: 8.9p1-3ubuntu0.10 Noble: 9.6p1-3ubuntu13.3

It is worth noting that security reports play a "guessing game" when it comes to OpenSSH. By design, OpenSSH presents a version number during the connection handshake to allow negotiation of connection parameters between client and server.

The version number shown during the connection handshake does not indicate the patch level of the service.

Nine actively monitors security issues and triages them in a timely manner.

TLS

Ciphers

TLS ciphers define the cryptographic algorithm that is used to establish a TLS connection. Client and server negotiate a cipher during the connection's handshake. When client and server don't support a mutual cipher combination, connections can't be established.

To support a broad range of clients without sacrificing security, Nine supports a few ciphers for backwards compatibility that are recommended by the Mozilla Foundation. These ciphers are a compromise between security and compatibility, with the goal of achieving high overall ratings on the well known Qualys SSL check.

If you only want to support the most modern ciphers and client compatibility isn't a concern for you, we're happy to adjust the ciphers offered by the server to your demand.

Default Vhost and Server Name Indication (SNI)

All Nine managed environments have a so called "default vhost" configured. This vhost is used by the webserver if an access can't be assigned to a specific vhost, for example when the IP address of the server is requested directly in the browser. In this case, a simple "No website configured" message is shown.

This ensures that search engines do not inadvertently crawl and index customer content under a Nine controlled URL.

The default vhost is also served if a client does not support SNI. Otherwise, the first customer vhost (in alphabetical order) would be delivered instead, likely serving unwanted content to the end user.

Self signed TLS certificates

The default vhost is also accessible via https. Nine creates a self-signed certificate for this purpose, with the same goals in mind mentioned above.

If a customer vhost does not already use a TLS certificate, the self-signed certificate will be used when accessing that vhost using the https protocol.

This can be easily avoided by creating a Let's Encrypt certificate for that vhost with our nine-manage-vhosts integration.

In case you're using our Managed Service FTPAdmin, you might see a reference in a security report that the FTP service is using a self signed certificate as well. This is intended to support FTP(E)S connections.

If required, a certificate from a recognized certificate authority can be integrated for the FTP service.

FTP

The existence of an FTP server is often cited as a problem in security reports. We couldn't agree more! The FTP protocol dates back to 1972, with a more "modern" RFC replacing the original in 1985.

Unless your application or use case is strictly dependent on FTP, we strongly recommend that you use only SFTP, which can easily replace most use cases for FTP.

We're more than happy to deactivate the FTP protocol. This does not have any implication on the SFTP integration of FTPAdmin.

HTTP Header

From time to time, security scans report missing HTTP headers. We agree that certain HTTP headers can increase the security and recommend setting these headers within the scope of the application, either via .htaccess or within the code / application itself.

Our article about security recommendations mentions a few headers, that might be worth looking at.