Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
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?
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).
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.
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.
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.
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.
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.
