Surviving a security audit with enterprise Linux

Understanding how enterprise Linux distributions handle security updates on a different timescale can ensure that your security audit doesn't result in worse security.

Posted: February 18, 2020 by Scott McBrien (Red Hat)

As a system administrator, you may have already experienced the joy(?) of having your systems audited by a security or risk management professional. Security tools used by auditors generally scan systems and produce a report for the auditor highlighting vulnerabilities found on the scanned system, which the auditor then presents to the team that manages the systems. The expectation is that the administration and management team will resolve the reported vulnerabilities. However, for enterprise Linux distributions, the auditor’s recommended remediations may not be the best choice for the organization to apply.

Getting the information

Starting with an example, many of these auditing tools begin by port scanning a target system and connecting to open ports to gather data about the services being offered by the machine. Here is an example port scan from my own system, generated by the nmap command:

[root@somebox ~]# nmap 10.200.157.174

Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-29 13:40 CET
Nmap scan report for 10.200.157.174
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind

Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds

From this output, you can see that ports 22, 80, and 111 are available for services connecting to this system. A security auditing tool likely then connects to each of these ports to determine what is running on them, or it might use a profiling utility to gather and analyze this data. I will use the telnet command to connect to this machine’s port 80 to determine what is running there:

[root@somebox ~]# telnet 10.200.157.174 80
Trying 10.200.157.174...
Connected to 10.200.157.174.
Escape character is '^]'.
help
HTTP/1.1 400 Bad Request
Date: Wed, 29 Jan 2020 12:46:39 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
Connection closed by foreign host.

After the connection was established, I had to make a request of the service. In this case, I typed the word “help” which, depending on the service, might be a command. For the service running on this system’s port 80, however, help is not an understood command. As a result, an error is produced. In the header, you can see a good bit of information about the system and service. Specifically, the service on this port is Apache version 2.4.6.

Sure enough, if I verify this information by looking at a yum list, Apache version 2.4.6 is the version installed and running on the machine:

[root@somebox ~]# yum list httpd
… output truncated…
Installed Packages
httpd.x86_64 2.4.6-89.el7_6.1      @rhel-x86_64-workstation-7.6

Handling the auditor’s report

This is where things start to get interesting. In my experience, what happens is that the audit report lands on the desk and it says something like:

Detected old version of Apache (2.4.6) which has several vulnerabilities which have been closed in newer versions of Apache.

Recommendation: Install updated version of Apache, 2.4.41, most recent.

At this point, as an enterprise Linux deployment, you should stop. Understand that the auditor’s report is highlighting that, according to the system scan information, this system may have open vulnerabilities. The auditor’s report is correct that installing the most recent Apache version from apache.org would resolve that issue. However, as an enterprise Linux system, these potential vulnerabilities are likely already closed in the version of Apache currently deployed on the system.

Notice that the version on the system is 2.4.6-89.el7_6.1, where 2.4.6 is the actual version number, and the extra version number for this package is 89.el7_6.1. Enterprise Linux distributions often take fixes for issues from newer releases and backport those fixes into an older codebase, then compile an updated version of this older software package. For Red Hat Enterprise Linux, the operating system on my example system, the engineers that manage the Apache package track these applied changes through this extra version number on the rpm package.

Some auditors already know about this, and some tools also account for this type of software management. Sometimes, though, you will work with someone who is using a less sophisticated scanning tool. Not just that, this person might also be unaware that the older version of Apache on this system is the correct version to have installed on this machine, and that the security vulnerabilities that security or risk management people would be concerned with are already closed. And as the system administrator, often it falls to you to explain why your organization should not install the most updated version of this package, counter to the auditor recommendation.

In my experience, one of the best ways to illustrate this point is by looking at the additional data included with your enterprise Linux’s version of this software package. Many enterprise Linux distributions will use features such as the RPM changelog to highlight this data. Here is the information from my example system:

[root@somebox ~]# rpm -q httpd --changelog
* Tue Jun 25 2019 Lubos Uhliarik <> - 2.4.6-89.1
- Resolves: #1719722 - CVE-2018-1312 httpd: Weak Digest auth
nonce generation in mod_auth_digest

… output truncated …

According to the CVE notice linked above, this vulnerability was not fixed in Apache until after 2.4.29. However, you can see in the output of this package’s changelog that a fix for CVE-2018-1312 has been backported and applied to the currently installed codebase, which is based on Apache 2.4.6. This fact means that my example system is not vulnerable to this exploit, despite being an older version of the Apache software.

Why is all of this important? Likely, if you’re using an enterprise Linux distribution, you are doing so because you want to keep changes, potential conflicts, and other software mismatch issues to a minimum. Upgrading Apache, as indicated by the audit recommendation, would be counter to the goal of keeping changes to a minimum. If you are a commercially supported customer, your vendor would probably no longer support Apache-related problems on this machine if you moved to a version that does not ship with their distribution.

Wrapping up

To survive an audit report, like the example above, you have to work with the auditor to make sure they understand how enterprise Linux packages are maintained (that the version displayed on the port may not be the same as the version installed on the system), and that the enterprise Linux packager generally maintains older versions of these packages to account for vulnerabilities that an auditor, computer security professional, or risk management associate might find. Using data like changelog information can help demonstrate this concept of backporting and enterprise Linux package management.

Want to try out Red Hat Enterprise Linux? Download it now for free.