Nagios Support Forum

Hi,

We have the latest version of XI (5.8.7) with Enterprise license installed at our customer site. It was installed as a virtual appliance a couple of years ago. We went the VA route as we were hoping to cite it being a closed system when security/risk teams scan the host and (inevitably) flag dozens of apparent vulnerabilities. We have also advised the security/risk teams that we risk forfeiting support by upgrading individual components of the VA (ie. PHP, Apache, OpenSSL, etc).

The scanning tool being used only looks at the version of each installed component and then reports the dozens of vulnerabilities (eg. PHP and Apache) in it's database that match that version. The scanner does nothing to validate the vulnerability is exploitable. We've attempted to explain the backporting concept, but the argument is falling on deaf ears. We've actually been asked to have Nagios supply an official document detailing how each listed CVE has been remediated (or is irrelevant) in order to get risk signoff. (If this is possible, great! But I'm assuming it's not).

My question is, how do we balance maintaining official supportability (from Nagios) with the needs of our customer to satisfy the risk team? I know you've posted a KB article on how to update PHP to 7.x, but the question is a bit bigger than that. The scans have flagged OpenSSL, Apache and PHP as being vulnerable so far. What do we risk in upgrading all of these components? Is it likely to cause issues down the track with future XI upgrades?

I apologies that the question is a little open, but I'm assuming I won't the only Nagios customer with similar concerns. If this is something that should be an official support request then please feel free to let me know.

Many thanks in advance for any advice or assistance.

Hello,

Thank you for reaching out -- managing and meeting security requirements can be a time consuming and frustrating process. Let's see if we can define where some of the demarcation points are and what resources are available at those boundaries to make it a little easier to manage.

As you already know our product, like a lot of software on the market, depends upon third party software for our product. To help simplify the management process we've chosen to make our product available on a number of Linux platforms and to keep the management of those third party products primarily within the packaging system of the operating system where we can. From our perspective it is a good way to give our customers the flexibility to use distributions they are comfortable with and/or can be easily integrated into their environment while keeping our development and quality assurance process within a reasonable scope. As a result we generally recommend that people use and stay with the software available via the operating system packaging system, which as you noted often contains backported versions of things like mysql and PHP. This includes the OVA images we use to help customers bootstrap the on boarding process which are usually based upon CentOS. To help simplify things here is our list of what we currently support for OS distributions and major third party packages:

Software: Supported Versions
MySQL: Any (MariaDB or MySQL)
Apache: 2.2, 2.4
PHP: 5.3, 5.4, 5.5, 5.6 | 7.0, 7.1, 7.2 (XI 5.5+) | 7.3 (XI 5.6.8+) | 7.4 (XI 5.7.0+)
OS: CentOS 7, CentOS Stream 8 | RHEL 7, 8 | Ubuntu 16.04, 18.04, 20.04 LTS | Debian 9, 10, 11 64bit only

You can mix and match supported versions of these components, such as using CentOS7 with PHP7.4 where we have knowledge base guides to help resolve some of the compatibility issues. So with that being said let's see if we can address the specifics you highlighted:

First off we're glad to see you're on Nagios XI 5.8.7 and we generally recommend customers stay at the latest version of our products. As you know it does two things: 1) It simplifies our ability to help you troubleshoot issues and upgrade to future versions. 2) It helps to ensure that you have the latest Nagios specific fixes applied including security fixes for our products. You can find a listing of our product security fixes and advisories correlated with the CVE number (when available):

https://www.nagios.com/products/security/

Also here is our changelog for Nagios XI which can help to understand our fixes and some fixes to deal with third party issues:

https://www.nagios.com/downloads/nagios-xi/change-log/

Beyond Nagios XI itself, updating the third party components to acceptable levels will depend upon the Linux distribution you are using, and as mentioned above recent OVA images use a version of CentOS. With that being said there are primarily two routes we would suggest given the limitations of vulnerability scanners and hard security requirements:

1) Update the OS and packaging system and then document the Operating System fixes for the OS; mainly the backported software in the case of CentOS.

For the first option with one of our older OVA images, you will want to check the version of the OS on the image and if it is above CentOS 7 (which it should be if you're running 5.8.7) update it using yum the same way you have been. From there you can take a look at what's been fixed using tools in the packaging system. For example you can use the changelog flags to RPM to get listing of the changes that often includes CVE numbers:

Change PACKAGE to the name of a package like php. Or you could loop around all the packages:
2) The second option would be to migrate to a Linux distribution that will align better with your security team's understanding and/or requirements.

If you choose to go the second option, you can build and install Nagios XI on a supported platform and have it scanned before you license it. That way you can get a look at the security profile before putting in the effort to migrate.

I hope this is useful.

Thanks and Best Regards,
Keith

Hi Keith,

Thank you for the detailed response.

I will work through your suggestions and discuss options with our customer.

Hi silverbenz,

Glad to hear that was useful -- If you have any follow up questions please feel free to start a new thread or open a support ticket for specific issues. We recommend support tickets since we're able to ask and answer security sensitive questions more confidentially.

Have a great rest of your day !!!

Thanks and Best Regards,
Keith