Scanning of Linux servers

Our Linux Sys Admin made the following statement below. How do you deal with that?

A great majority (discovered vulnerabilities) of these can be immediately crossed off because of [Security Backporting Practice - Red Hat Customer Portal]
Basically, a security scanner wants to see version “1234” but RHEL uses a backported version “123-4”. It’s got all the same security patches but carries a different version number because RHEL (and pretty much everyone else in the enterprise space) backports to keep features stable.

I agree that backporting is a common practice. However, our Red Hat team has never given us that excuse and tends to apply the patches we ask them to patch. The proof would vary by product/vulnerability, but you could reference the Red Hat CVE Database. If you look up the CVE-2014-3670 vulnerability provided in the Red Hat article on backporting, you can see that the vulnerability in PHP 5.3 was addressed in RHSA-2014:1768, although 5.3 went EOL prior to the RHSA being released.

This will take some manual effort, but it can prove whether the patches have been applied. If they have, you can submit exceptions for those vulnerabilities in your console so they are no longer included in metrics and reporting.

Thank you for your input. That is good information.
Your suggestion is something I can live with. Our Linux admin is pretty good with keeping things up to date.

This is more of a manual process than we prefer, but it does help validate what the Linux team is saying. Most of the checks in InsightVM are based purely on OS/product versions, and sometimes it is a little tricky to figure out if systems are actually vulnerable without tracking some of this stuff down. Best of luck!

Hi Andy and Scott,

Backporting is indeed a common practice and one that Rapid7 is well aware of. Typically, these would only show up as false positives during unauthenticated scans (because the Scan Engine doesn’t have access the distribution-specific version from the package manager).

When credentials are configured appropriately, and the template is set to correlate reliable checks with regular checks, then the authenticated checks (which are based on RHSAs or USNs or similar distribution vendor advisories) will override the results from the remote checks that only look at the version in the banner. Note that this override happens on the Security Console, once scan results have been fully integrated.

Hope this is helpful! Scott’s suggestion to look at Red Hat’s CVE pages is a great one when trying to troubleshoot any issues related to this.

All the best,

Thank you for your response. I had always checked the “correlate reliable checks with regular checks” setting since we became a R7 client about 15 months ago.
So, I think I have to dig a bit deeper and challenge our Linux admin a bit on that subject.

Again, thank you Scott and Greg for your input.

We had similar discussions. I had to really make sure they understood that

  1. Vulnerabilities are often discovered before patches are available [they were thinking we were blaming them for not being resolved already when discovered].
  2. Just because a vulnerability is discovered doesn’t mean we expect %100 patching. We realize that in some cases stability and compatibility take precedence. IVM is just to keep visibility on these, even if we never intend to patch, we are not marking them as complete or exclusions…


You made good points.