Solved Updating Debian Packages on Self-hosted 3CX Server

[ksure]

Hi,

I have inherited a self-hosted 3CX server running Debian 10, and am having issues updating some packages to the latest versions. I am going through a CyberEssentials Plus audit and the Nessus scan has picked up the below:

• Upgrade the openssl packages. For the stable distribution (bullseye), this problem has been fixed in version 1.1.1n-0+deb11u2.
• Upgrade the openldap packages. For the stable distribution (bullseye), this problem has been fixed in version 2.4.57+dfsg-3+deb11u1.
• Upgrade the postgresql-11 packages.

3CX is fully up-to-date according to the web portal, on the server the packages are reporting as below.

• Openssl reports - openssl is already the newest version (1.1.1n-0+deb10u1).
• Postgresql-11 reports - postgresql-11 is already the newest version (11.14-0+deb10u1).
• Open ldap reports an error, but I don't think it is actually installed - slapd: Installed: (none) Candidate: (none) Version table:

My Linux knowledge/experience is quite limited, but would a potential resolution be to add a new repo and get the packages from there? If so, is it possible this could break the 3CX system in anyway (I imagine it probably is). Are there any better ways to do this?

Thanks

 

[Saqqara]

Check out information in Introductions - https://www.3cx.com/docs/manual/installing-debian-linux-pbx/

The only supported way of keeping your system supported by 3cx is to enable auto updates, which installs Debian updates along with 3cx updates

 

[cobaltit]

So 3CX is running Debian 10 and your notes are listing the versions for bullseye which is Debian 11. It may not be reading the system properly. But as @Saqqara mentioned, 3CX only supports installation from the 3CX ISO and then having auto-updates enabled which takes care of the Debian updates.

 

[ksure]

Thanks for your responses.

So 3CX is running Debian 10 and your notes are listing the versions for bullseye which is Debian 11. It may not be reading the system properly. But as @Saqqara mentioned, 3CX only supports installation from the 3CX ISO and then having auto-updates enabled which takes care of the Debian updates.

I believe the scan is reporting the correct OS from the system, in the report it states Linux Kernel 4.19.0-18-amd64 on Debian 10.12.

Our Cyber Essentials Plus auditor has advised that we will only pass the cert if the packages are updated. From this is it safe to assume those with self hosted 3CX servers running the latest version (v18, Debian 10) are not able to get Cyber Essentials Plus certified? It would be interesting to hear from anyone who has the same config and has managed to get Cyber Essentials Plus certified.

Also, just to confirm - Debian 10.12 is the latest version for the 3CX provided ISO? And if the update page shows as below then there are no updates available for the OS?

 

[cobaltit]

Updates in the management console only show 3CX related updates. OS updates will never show there, and manually checking for updates only updates 3CX. The only supported method by 3CX is to have auto-updates turned on and then to let it update the OS.

For your Cyber Essentials Plus certification, does 3CX have to pass regardless of where it's at? For compliance purposes it's often easier to move things that don't pass outside of the protected environment into a DMZ or it's own VLAN. Is that an option for you?

 

[ksure]

Updates in the management console only show 3CX related updates. OS updates will never show there, and manually checking for updates only updates 3CX. The only supported method by 3CX is to have auto-updates turned on and then to let it update the OS.

For your Cyber Essentials Plus certification, does 3CX have to pass regardless of where it's at? For compliance purposes it's often easier to move things that don't pass outside of the protected environment into a DMZ or it's own VLAN. Is that an option for you?

As far as I have been advised the 3CX system has to be fully up-to-date with the relevant packages regardless of where it sits. I am currently querying this with them though, as I find it hard to believe they haven't seen a similar situation before (especially with the prevalence of 3CX)!

Thanks for your help.

 

[JohnS_3CX]

There must be something wrong with the tool that generated this. Its reporting updates for Debian Bullseye, when your system is running Debian Buster.

Blindly installing the latest linux dependencies especially if you have limited knowledge on the subject could be quite catastrophic to your deployment so this is a double edged sword.

 

[ksure]

There must be something wrong with the tool that generated this. Its reporting updates for Debian Bullseye, when your system is running Debian Buster.

Blindly installing the latest linux dependencies especially if you have limited knowledge on the subject could be quite catastrophic to your deployment so this is a double edged sword.

Good point, I imagine their argument will be to upgrade to Bullseye but since Buster is still in support this shouldn't be a requirement. I will see what they come back with.

I am thinking the best option, providing they don't agree with the above, may be for me to migrate 3CX from Linux to Windows. As far as I am aware the differences are minimal, and should be able to more easily (at least with my lack of experience in Linux) make it compliant for this cert.

 

[JohnS_3CX]

I'm just speculating here, but if the tool is generically listing packages, and then comparing their current version to the latest published version, then the results you see will not make much sense in the world of Linux. On linux, the latest version of a package is not automatically considered the greatest version that you should absolutely have.

We check the packages before releasing them on our repo because in the past people have manually updated packages blindly using 3rd party tools, only to discover that something in the updated dependency changed sufficiently to bring down their system, forcing them to re-deploy from scratch (keep your 3CX backups current!).

Also, the packages available on Debian 11 should not automatically be assumed to also exist for Debian 10. Generally speaking, scanning tools can generate false positives in a paranoid "better safe than sorry" fashion, but ultimately a knowledgeable human should be performing a vulnerability assessment after they run a scanning tool, to actually verify the results and see if they represent real vulnerabilities. Otherwise the results can be meaningless and it would cause me to question the value of the certification at the end of the day if it's just a blind pass or fail..

Windows might indeed be easier to pass because the dependencies are built into the system and do not appear as separate packages, give it a go and see what you get, but keep in mind that this would not guarantee safety: good security practices can still mitigate attacks, even if you were running vulnerable packages.

https://www.3cx.com/blog/unified-communications/dont-be-that-guy-vol-1/
https://www.3cx.com/blog/unified-communications/dont-be-that-guy-vol-2/
https://www.3cx.com/blog/unified-communications/dont-be-that-guy-vol-3/
https://www.3cx.com/blog/unified-communications/dont-be-that-guy-vol-4/

 

[SteveITS]

results you see will not make much sense

I've had similar issues with scanners that check Red Hat/CentOS servers. Red Hat doesn't update version numbers so scanners blindly flag the file. That's unrelated to Debian of course, but my point is one should not blindly trust such scanners.

 

[ksure]

Thanks for all your help, we were re-certified today!

In the end the assessor accepted evidence (in the form of screenshots) showing our packages were of the latest version and the OS was still supported.