Centos as a production server

[nexussentry]

I am new to linux and Open Source. Just would like to know, is CentOS good enough to use as a production environment or should only be used as a lab or test environement?

[pjwelsh]

Centos represents almost 6% of the top 10,000 websites and 7.3% overall (source: http://w3techs.com/technologies/breakdo ... os/ranking), for example. That's a very big number for a free OS. To me it's very clear CentOS is production worthy. The bigger issue may be are you ready for Linux? Sadly, "new-to-linux" and "production-worthy" do not generally go hand-n-hand. As with any production server OS (ALL OF THEM), each has a steep technical learning curve to get "right".
pjwelsh

[nexussentry]

Thank you very much for your insight. I know that I have a journey ahead of me, just wanted to make sure CentOS is not like Fedora. I found that most of the authors of the books I read did not recommend Fedora for a production environment. But I found no comments on CentOS. I do realize that Linux requires a good set of skills. Appreciate your observations and the facts you presented.

[ScutMonkey]

CentOS is Red Hat Linux. The ONLY difference is the name and lack of support, so asking if it's production worthy is like asking if Red Hat is production worthy which it obviously is. The reason to go with Red Hat instead is support. If you can afford a support contract and you are not an expert (like me) then go RH and get the support for when you need it. There is so much behind the wall which makes it worth it.

[raetrace]

Yeah, a bit late but I just wanted to get this out there for those who don't already know.

CentOS is great for a production environment, so long as you don't have to work with any government compliance or regulatory agency such as HIPAA, SOX, NERC, PCI DSS, etc.

If you do have to meet a government compliance or other regulatory agency, avoid CentOS for production as it will just create more work for you. Specifically if you have to meet a compliance concerning security patch analysis and reporting.

See viewtopic.php?t=30967#p144571 for more information on the topic. Look at the second post by TrevorH.

But in a nutshell, CentOS does not contain any security information in the CentOS repository. So whenever you try to use the 'yum --security check-update' or 'yum list-security' it will always return 0 even though there may actually be hundreds of security patches for CentOS (EPEL and other 3rd party repositories might actually show security patches, but none of the CentOS repos will... period).

I've spent quite a bit of time researching this topic and people have been asking for the CentOS repos to contain security patch info for several years now but nothing has came of it as of yet. There is a script out there that will take the security info from the CentOS mailing list and build the appropriate repomd.xml and corresponding updateinfo.xml.gz file but the information contained is very limited and basic. I have to meet NERC CIP requirements and the script just wasn't good enough. Maybe someone else can link it here, but I gave up on it two weeks ago and deleted the links from my favorites.

If you need as much information as you can get for reporting on security patches to meet compliance, stick with RedHat.

[TrevorH]

Well, regardless of the fact that yum-plugin-security does not work, the advice for CentOS is to run yum update and get ALL updates. We do not test individual updates so you cannot cherrypick one update without applying all others anyway. The rpm changelog still contains the CVE numbers that are fixed and all updates that are released for RHEL are rebuilt and released for CentOS too.

Just because yum-plugin-security does not work does not mean you cannot be secure and prove it.

[raetrace]

Sorry TrevorH, I guess I should have been more clear. Please don't get me wrong, I love CentOS and use it in areas where I don't have to meet some kind of regulatory compliance requiring patch assessments.

Yes, you can prove the system to be secure by stating and showing a NERC CIP auditor that you are fully patched and up to date. However, this alone isn't enough for NERC CIP compliance (and I'm not sure this would necessarily be enough for other compliance standards such as PCI DSS).

The problem comes from identifying, assessing, and documenting the "security" patches each month (which an auditor will want to see). NERC CIP-007 Requirement 2.2 requires us to evaluate and assess security related patches and document them. In order to document needed security patches, we first need to identify them. Something easily done within most other modern Unix/Linux distros, but not CentOS. It gets even more complex if there is a reason why a patch can't be installed (for example a recent kernal update with security fixes broke one of our applications) at which point we need a mitigation plan providing detailed reasons and instructions for the mitigation.

So far I've only been able to find two methods of getting the security patch information (and if someone has a better solution already, I would love to hear it as I would love to use CentOS in my NERC CIP environments). The first is to manually monitor the CentOS patch mailing list and compare the patch release information with your installed packages on CentOS (yes, a lot of work). Second is to semi-automate it using the script I mentioned in an earlier post. The script requires you to setup your own CentOS repository (not a big deal). However, it really only identifies which patches are security related, but doesn't provide you with the details of the security patch itself. You still have to go read the mailing list to get the specifics of the security patch (ie. what the patch is fixing exactly, known problems, etc.).

This need for automating as much information on security patches as much as possible hasn't been lost on RedHat, Debian, Ubuntu, and others because they specifically added the ability to list security only patches and details within the OS themselves. I hate to say it, but as more and more businesses come under more and more cyber-specific regulations I fear CentOS will be pushed further out. At least until "yum updateinfo list sec" actually returns results in CentOS.

[hunter86_bg]

Am in confusion, or all this security information is publicly available on Red Hat's website ?

[Boyd.ako]

Sorry TrevorH, I guess I should have been more clear. Please don't get me wrong, I love CentOS and use it in areas where I don't have to meet some kind of regulatory compliance requiring patch assessments.

Yes, you can prove the system to be secure by stating and showing a NERC CIP auditor that you are fully patched and up to date. However, this alone isn't enough for NERC CIP compliance (and I'm not sure this would necessarily be enough for other compliance standards such as PCI DSS).

The problem comes from identifying, assessing, and documenting the "security" patches each month (which an auditor will want to see). NERC CIP-007 Requirement 2.2 requires us to evaluate and assess security related patches and document them. In order to document needed security patches, we first need to identify them. Something easily done within most other modern Unix/Linux distros, but not CentOS. It gets even more complex if there is a reason why a patch can't be installed (for example a recent kernal update with security fixes broke one of our applications) at which point we need a mitigation plan providing detailed reasons and instructions for the mitigation.

So far I've only been able to find two methods of getting the security patch information (and if someone has a better solution already, I would love to hear it as I would love to use CentOS in my NERC CIP environments). The first is to manually monitor the CentOS patch mailing list and compare the patch release information with your installed packages on CentOS (yes, a lot of work). Second is to semi-automate it using the script I mentioned in an earlier post. The script requires you to setup your own CentOS repository (not a big deal). However, it really only identifies which patches are security related, but doesn't provide you with the details of the security patch itself. You still have to go read the mailing list to get the specifics of the security patch (ie. what the patch is fixing exactly, known problems, etc.).

This need for automating as much information on security patches as much as possible hasn't been lost on RedHat, Debian, Ubuntu, and others because they specifically added the ability to list security only patches and details within the OS themselves. I hate to say it, but as more and more businesses come under more and more cyber-specific regulations I fear CentOS will be pushed further out. At least until "yum updateinfo list sec" actually returns results in CentOS.

In short, Linux is Linux as ice cream is ice cream. The real differences between the distros is package management and how fast the distro gets updates. Redhat gets paid to be up-to-date as much as possible. So patching compliance is in the bag with them. The Redhat Open Source off-shoot is Fedora which pretty much receives the update first after Redhat patches, tests, and releases it. Fedora is pretty much Redhat minus the proprietary support crap.

As for auditors, 999% of the time they really don't know what they're looking at other than numbers. I work on Redhat professionally and you'd be surprised to hear that the "vendor" hasn't supplied a compliant update "yet" as an acceptable mitigation.

To be honest with you. It looks like you should do some studying for the CISSP in regards to compliance guidelines, layered security, and mitigation methods and what not. An OS doesn't need to be 100% rock solid in security. If it did they wouldn't be running Microsoft every where. That's where layered security and mitigation comes in.

Also the Redhat cyber-sec method is meh... They're renowned for creating their own CVE numbers that don't relate to the industry CVE numbers like mitre and NIST.

So, is CentOS an acceptable Production server? Yes. The only reason companies pay for Redhat is for what the CISSP refers to as "Risk Transfer" via support contracts.

[TrevorH]

Fedora is pretty much Redhat minus the proprietary support crap.

No, you have this round the wrong way. Fedora is the bleeding edge distro where new shiny stuff is introduced to see how bad it is. Redhat then take a Fedora release and hack on it for about a year to produce a stable RHEL major version. Fedora has a 13 month security update cycle which means you have to update to the latest Fedora every 13 months or get no updates. RHEL is a sort of distant cousin to Fedora - Fedora being the one that's always in trouble and the rest of the members of the family look on with bemused tolerance and hope it grows up sometime before it gets into real trouble

CentOS is RHEL without the support. It's built from the exact same source - modified only when there are RH trademarks etc that need to be removed.