2

I have a clean, stock CentOS 7 installed and now (after a security scan) want to update packages to fix known security issues (they all have CVE numbers and some are already some time old).

Somehow, CentOS 7 does not really care about these security issues (a big problem is also PHP, which is stuck at 5.4, without any good way to upgrade).

How should I handle security issues on CentOS, other than a simple yum update?

  • 1
    Centos and RHEL are designed for stability and stodgyness over bleeding edge packages. They do backport after extensive testing, but keep roughly the same major versions over a decade. PHP being an older version is entirely by design I suspect. – Journeyman Geek Oct 16 '15 at 6:55
  • CentOS 7 is perfectly fine and many of the items you believe are “unlatched” are back ported. Meaning, while you might have older versions of items like PHP, the CentOS team does back port the necessary patches to make CentOS 7 as stable and secure on all levels as newer releases of packaged software. Also as a web developer, I definitely do not want to be on the “cutting edge” of a new version of PHP. I like to keep things as stable on a known, supported version. And PHP 5.4 is perfectly fine. Many sites still use PHP 5.3 (back ported) for the same reasons. – Giacomo1968 Oct 16 '15 at 6:57
  • @JakeGould thanks. The scan is complaining about the PHP version, but it is possible the actual threat has been fixed? Is there any way to make sure that the issue is fixed? – Bart Friederichs Oct 16 '15 at 7:09
  • @BartFriederichs I posted a detailed answer where I explain my feelings on this stuff and security scans from my years of experience. The long and short of it? I’m sure your CentOS 7 setup is solid. But the security scan is a bit off if it is telling you to update PHP. In fact it should have warned you your version of PHP was being exposed to begin with. Servers should never expose version details to the world. Follow my tips on how you can do some basic server hardening and try that security scan again. I bet the results will be much better. – Giacomo1968 Oct 16 '15 at 7:35
4

You state this:

I have a clean, stock CentOS 7 installed and now (after a security scan) want to update packages to fix known security issues (they all have CVE numbers and some are already some time old).

Don’t panic! Your CentOS 7 install is fine.

The reality is CentOS 7 is perfectly fine and many of the items you believe are “unpatched” are backported. Meaning, while you might have older major versions of items like PHP, the CentOS team does backport the necessary patches to make packages in CentOS 7 as stable and secure on all levels as newer releases of packaged software.

Also as a web developer, I definitely do not want to be on the “cutting edge” of a new version of PHP. I like to keep things as stable on a known, supported version. And PHP 5.4 is perfectly fine. Many sites still use PHP 5.3 (back ported) for the same reasons. Jumping up to a major version in PHP things will break more things than it will ever “secure” your installation more.

The “iffy” nature of website security scans.

But you also mention a “security scan.” What do you mean by “security scan?” Some web-based security scanning tools just list all the flaws it can find and will spit out panicky generic alerts. Many of these just panicky alerts are just based on major versions like PHP 5.4 being shown and not much else.

And the reason those website scans react like that is to create FUD (fear uncertainty and doubt) in those who use them so the sponsors of such a service can—for example—sell a panicked user some online service or consultancy related product. Many of those scans are useful to a degree, but you should take them with a strong grain of salt and should always research the claims further if something concerns you.

The larger issue—if you ask me—is somehow your server is exposing the exact PHP version to the world. And that is not a CentOS issue. That is a server hardening issue. Meaning well protected servers never reveal the exact version of core software being used to prevent anyone from thinking any flaws exist.

My advice? If you have done a yum update and it says you are all up to date, you are all up to date. But like I said, server hardening is a 100% different issue that canned security scans never seem to address. But this is how you can deal with this PHP specific issue. And the process is pretty easy.

Hardening PHP by disabling expose_php.

First, find your PHP config file (php.ini) and open it up like this; this example is using nano and a path for the file on Ubuntu but the concept is the same:

sudo nano /etc/php5/apache2/php.ini

Now do a search in that file for the line that configures expose_php. Looking at the official PHP documentation, expose_php is described as follows:

Exposes to the world that PHP is installed on the server, which includes the PHP version within the HTTP header (e.g., X-Powered-By: PHP/5.3.7).

So knowing that I bet that security scan just saw the X-Powered-By header and reacted. But anyone doing real security administration can tell you the issue is not the version number itself but the fact that the header is exposed at all. So just change that expose_php value as follows:

expose_php = Off

And then restart Apache and try that security scan again. Heck you can even check the headers for your server from the command line using curl like this:

curl -I example.com

The returned headers should now not contain any PHP version number info.

Harden Apache while you are at it.

As long as security is a concern, I would recommend hardening Apache as well while you are at it. Just open up this Apache config file; again based on Ubuntu but find the equivalent in CentOS:

sudo nano /etc/apache2/conf.d/security

Then locate ServerTokens and set to “production” like this:

ServerTokens Prod

After that, locate ServerSignature and disable it:

ServerSignature Off

Finally, locate TraceEnable and disable that as well:

TraceEnable Off

Restart Apache and check the headers—or security scan the server—again. You should now be in better shape.

The basic concept of these simple hardening ideas is a website that is setup with a default config that exposes internals to the world sends a message to malware bots that one, the server is in a default state and two, the server is running “older” software. Thus an un-hardened server like that would be a nice target for an attack. By obfuscating details in returned headers you make your server a less desirable target since there is no way for a script to tell what you might be vulnerable to.

0

What makes you think that CentOS don't care about those security issues? Redhat (and thus CentOS) backport changes so its entirely probable they have backported known security issues for your problems.

As far as PHP goes, you can add the Webtactic Repo to get PHP5.6.

  • The "not caring" part was a little bit a rant, because I couldn't get good info on these matters. – Bart Friederichs Oct 16 '15 at 8:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.