Skip to main content

As a software publisher, we care about the security of the software we offer and make continuous updates as security vulnerabilities or potential issues are discovered or reported to us via the security@centreon.com address, through our Customer Care service The Guard or here on The Watch. Note that a page describes our security policy and we also have the process to report a vulnerability

 

However, even if your Centreon applications are up-to-date, it is important to follow best practices to keep the Operating Systems on which they run secure, as well as the third-party components running on these systems.

We recommend applying security updates as soon as they are available (and restarting the affected services afterwards; if in doubt, system reboot is also possible).

 

This article is aimed at providing some tips to do so if you are not familiar with Linux systems maintenance.

 

Automatic update tools:

There are tools such as dnf-automatic (for RHEL-like systems) or unattended-upgrades (for Debian) that can apply security updates automatically: 

https://dnf.readthedocs.io/en/latest/automatic.html

https://wiki.debian.org/UnattendedUpgrades

 

Example of a targeted update:

If you are aware of a specific Common Vulnerabilities and Exposures (CVE) and its identifier, it is possible to directly check on your system if it is properly resolved.

 

Here is an example of a process you can use for the CVE-2022-1292 affecting OpenSSL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1292

 

AlmaLinux:

If you are on AlmaLinux 8, a search will take you to this page: https://errata.almalinux.org/8/ALSA-2022-5818.html which references the vulnerability (as it has been fixed upstream by RedHat): https://access.redhat.com/security/cve/CVE-2022-1292.

You can also read the "changelogs" from the system itself, with this command for example: rpm -q -changelog followed by the name of the library or program concerned with a grep on the CVE ID:

 

rpm -q -changelog openssl |grep CVE-2022-1292

- Fix CVE-2022-1292: openssl: c_rehash script allows command injection

 

Debian:

If you are on Debian 11 Bullseye, a search will take you to this page: https://security-tracker.debian.org/tracker/CVE-2022-1292.

From the system, you can search directly in the changelogs with grep, which will confirm that it is properly fixed:

 

zgrep CVE-2022-1292 /usr/share/doc/openssl/changelog.*

/usr/share/doc/openssl/changelog.Debian.gz:    - CVE-2022-1292 (The c_rehash script allows command injection).

/usr/share/doc/openssl/changelog.gz:   CVE-2022-1292, further bugs where the c_rehash script does not

/usr/share/doc/openssl/changelog.gz:   When the CVE-2022-1292 was fixed it was not discovered that there

/usr/share/doc/openssl/changelog.gz:   (CVE-2022-1292)

Hello, thanks.

→ Are there any compatibility to keep between the OS/packages and the centreon packages on a working Server/Poller ?

For exemple, can “dnf update --exclude=centreon*” (update all the packages except centreon ones) have any impact on centreon plugins ?

Will any working Centreon version will be OK with the OS/packages update ?

Or is it mandatory to always update the centreon plugins at the same time “dnf update” ?

 

Thanks

 


instead of “centreon plugins” I meant “centreon packages”


Hello @frantz,

Centreon packages get the recent dependencies they need, but the reverse is not true.

So, it’s rare but possible to encounter issues if the system is up-to-date but the Centreon packages are not. Especially for the centreon-plugins on a poller, which often depend on Perl packages of the system.

Centreon updates can also solve security problems.

I recommend to keep an eye on Release Notes https://docs.centreon.com/docs/releases/centreon-os/ for security concern if you want to decorellate system updates and Centreon updates.


Hello @AltGr 

Thanks for your answer. I was wondering both ways.

 

So If I understand well ? :

→ We must be carefull while upgrading the OS but not the centreon packages “dnf update --exclude=centreon\*” as there may be compatibility issues.

→ Upgrading the centreon packages (but not the OS) with “dnf update centreon\*” should work as dependencies are checked

→ Upgrading both (OS + centreon) with “dnf update” will always work

 

Is that it ?

 

Best regards


Hello @Frantz,

I understand quite the opposite from @AltGr’s answer.

There are more possibilities that older Centreon packages would still work with newer system packages, than a newer Centreon package would work with older system packages.

In a general manner, a distribution tries not to break user applications. But a user application may often require a newer system/library packages.

Concerning Centreon I’m particularly worried about the fact it requires very recent PHP packages, hence PHP packages from the REMI repositories :

1)  REMI repositories do not exist for Debian/Ubuntu, there are some nearly equivalent third-party repository for Debian and its derivatives, but they’re not strictly equivalent.
2) Third-party repositories, as last upstream version of software are less secure and bug-free than software from the stable branch of any mainstream distributions.

3) Sticking to the most common denominator of all the oldest supported distributions would indeed limit the versions available, but I’m pretty sure it would have the great advantage of avoiding fancy, eye-candy and disruptive functionalities to pop in Centreon, which very often only bring more bugs, bloating  and breaking changes than usefulness. Not mentioning the stronger learning curve for potential new contributors.

In my case I’m currently using Centreon 23.10.11 in production, testing the 23.10.14. I will be able to upgrade a development platform in 23.10.15 soon, and looking forward to upgrade the production platform too, as soon as I can. But some company processes can be quite cumbersome in matter of software upgrade politics, sadly.
My (about 12 yo) user experience with Centreon is still made of more cutting edge and highly unfinished new functionalities, which introduce numerous new bugs here and there in the software (sometime even breaking legacy functionalities!), functionalities which are undesired for the most (IMO), than fixes for some annoying and long lasting bugs on the basic, legacy functionalities, which are, in contrary, intensively used, so deeply relied on in our information system.

I’ll be happily surprised if 24.04 and next releases come back to robustness and trustfulness oriented development. Currently I can’t even afford to report all the, sometime blatant, bugs on which I stumble upon on a nearly everyday basis. Furthermore, when I applied myself to did this in the past, it has very few effects.

TMYK

I wish a nice day, and pleasant weekend to everybody.

 


Reply