Hello all,
I was wondering if the IVM appliances can be self-maintained as in patching the OS / software?
I’m getting ‘advised’ to review the appliances as they are the most outdated, unpatched systems in several areas of our environment.
If not, are newer releases of the appliances released by Rapid7 that are patched up to date?
Thanks in advance!
Good point. When you say IVM appliance, is this the security console, scan engine, or something else? Also, what specifically are you noticing is outdated and unpatched, i.e., PostgreSQL, etc.? I can take a look at our systems here to compare and perhaps to look at potential vulnerabilities that may impact us as well.
This would be the IVM scan engines. There’s really no single product/service that is majorly reporting out of date. Every vuln states it’s RedHat then lists a specific service such as openssl, python, expat, bind, microcode_ctl, nss, libxml2, open-vm-tools, zlib, openldap - for examples.
I believe I understand now, but please confirm with me. It sounds like you are scanning the IVM scan engine, and the vulnerability report states the scan engine is out-of-date on several packages, is that correct?
Correct!
Okay, so there could be a few things at play here. When InsightVM scans a Linux system it grabs the package version and cross-references that package version against its own vulnerability database or NIST NVD. If the version number matches an older/vulnerable release, you get a security finding after the scan finishes. However, many older versions of Linux—especially those that are still under support—backport security fixes into the package while retaining the original version number of that package at the time the server was built.
A good way to validate this is to review the list of security findings against that scan engine and the CVE’s that it believes are present. Then navigate to your scan engine (via ssh) and take note of what the current package version is and when it was installed. You can then search online to see if the vendor/package offers a changelog to review what CVEs were patched.
I haven’t encountered this yet for a RHEL system, but this happens frequently with Ubuntu systems. You can validate these changes on Ubuntu via “apt-cache policy openssl” and “apt-get changelog openssl” using OpenSSL as the target package. On Ubuntu, this will show the installed package version and changelog notes which many times include the security fixes that were patched. You can then determine whether to add an exclusion into the IVM dashboard so that future findings do not appear.
Hopefully this helps to point you in the right direction. If you have any other questions send it here.
Thank you, and with your statement However, many older versions of Linux—especially those that are still under support—backport security fixes into the package while retaining the original version number of that package at the time the server was built.
Would re-building the IVM scanner engine include latest versions and exclude the ‘backport’ fixes? Meaning, would the old, vulnerable versions be gone?
In my environment, that did not fix the issue. Rather, this seems to be common amongst vulnerability scanners and packages that backport security fixes. The best method that worked for me was reviewing the vulnerability output in IVM and then researching the packages and release notes on the Linux systems that show as being impacted. Peering into the packages release notes/changelog will usually tell you if they bundled a security fix into that package despite the version appearing old.