Johnny Hughes wrote:

Bob Boilard wrote:

...

Hello all,

I love CentOS, but I am seriously regretting selecting Centos 4.4 for my production hosting servers. The current situation with CentOS 4.4 and being stuck at Apache 2.0.52 is a huge problem because of the new requirements for the Credit Card industry PCI scan. Apache 2.0.52 does not pass PCI compliance scans. which means no ecommerce on any of these servers - MAJOR ISSUE. So my question to the community is: when are new Apache RPM's going to be released or at minimum a backported version that plugs these security holes so we can pass PCI scans. Apache 2.0.52 has some major issues that need to be dealt with?

I am almost positive that this issue is one of the scan software using version numbers and not understanding that RHEL backports fixes.

It is probably just looking at version numbers and not vulnerabilities.

I can not imagine a REAL scanner that will not pass RHEL-4 in it's scans.

There are not any unpatched holes on the latest httpd in centos as all security issues are backported.

I know that there are millions of ISPs using CentOS-4 for e-commerce everyday.

...

Help us out here. I know I am not the only one in this situation. every hosting company that uses Ensim Pro X is just where I am. Any insight or better yet a solution to this would be great.

I would suggest that you ask the scanning agency to specify why they do not understand the RHEL backports ... unless there are REALLY unpatched issues.

I do want to point out that you need to be running the latest httpd and php and mysql (or other things) from CentOS-4.6 and not CentOS-4.4 ... and I do not run any Ensim software, so I am not sure what it does to the system files ... here are the latest versions that are released:

httpd 2.0.52-38.ent.centos4 mysql 4.1.20-3.RHEL4.1.el4_6 php 4.3.9-3.22.9

If you have versions that are older than that, there are probably security issues. If you have those, then I think the scanner is incorrect ... please verify that you have that (or better) on your centos-4 install.

Ross S. W. Walker wrote:

Johnny Hughes wrote:

...

Bob Boilard wrote:

...

Hello all,

I love CentOS, but I am seriously regretting selecting

Centos 4.4 for my

...

production hosting servers. The current situation with

CentOS 4.4 and being

...

stuck at Apache 2.0.52 is a huge problem because of the new

requirements for

...

the Credit Card industry PCI scan. Apache 2.0.52 does not pass PCI compliance scans. which means no ecommerce on any of these

servers - MAJOR

...

ISSUE. So my question to the community is: when are new

Apache RPM's going

...

to be released or at minimum a backported version that

plugs these security

...

holes so we can pass PCI scans. Apache 2.0.52 has some

major issues that

...

need to be dealt with?

I am almost positive that this issue is one of the scan software using version numbers and not understanding that RHEL backports fixes.

It is a big fear of mine that this may become more and more of an issue when government agencies start setting stricter and stricter software compliance guidelines.

The agencies don't know what security backports vendor XYZ has implemented and frankly they don't care. All they have is a list of minimum version numbers that software must be at in order for it to be deemed "compliant".

I think we will start seeing this in the PCI and HIPA compliance regulations first, but I wouldn't be surprised if it leaks out into GLBA and other regulations over time.

I think it will be these compliance issues that may force upstream to change their strategy otherwise I can see this being a roadblock to RHEL/CentOS adoption in these industries in the future.

-Ross

OR force the scanner people to support backports.

There are already Nessus templates that support CentOS/RHEL scanning for PCI compliance.

Being that RHEL is 85% (ish) of the paid enterprise server market and EAL certified and running on many government sites already, I would imagine that the scanners will be the things to change.

I could be wrong ... that HAS happened before :-) ... but that is my take.

nate wrote:

Ross S. W. Walker wrote:

...

The agencies don't know what security backports vendor XYZ has implemented and frankly they don't care. All they have is a list of minimum version numbers that software must be at in order for it to be deemed "compliant".

So check the actual version number of the package. Using a remote network software scanner to detect security problems based on banner strings provided by the network software is nothing more than a false sense of security.

I'm not worried about myself. In a regulated environment the agencies do not trust corporations will honestly test their controls, so they have outside auditing firms and agencies test them for you and it is often these outside firms or agencies that take unreasonable or uneducated stances and often times there is very little you can do. When the FDIC says jump your correct response should be "How high?".

...

I think we will start seeing this in the PCI and HIPA compliance regulations first, but I wouldn't be surprised if it leaks out into GLBA and other regulations over time.

The scanning vendors will be forced to fix their products. It's perfectly acceptable, and preferred behavior to backport patches. Just look at the recent Samba thread here for a good reason why backporting is good. I'd be mightily pissed if RHEL or CentOS switched a version out from under me which caused breakage. I honestly cannot believe that RHEL did that for Samba. If anything introduce a new ALTERNATE package that has the incompatible changes in it and allow users to choose between that one and the original for their systems. That's just me though. Fortunately I don't really use Samba.

I agree whole heartily. It would go a long way though if Redhat provided independent certification of their products under these compliance banners.

Does anybody know if such a thing exists now?

That way with the certification in hand and proof that the servers are kept up to date one can keep the auditors at bay.

...

I think it will be these compliance issues that may force upstream to change their strategy otherwise I can see this being a roadblock to RHEL/CentOS adoption in these industries in the future.

I highly doubt it. It'll be the scanning companies that will have to change. RHEL/CentOS are not the only ones that backport fixes. Really they need to have a database of package names and versions, and a set of scripts to run on the various servers to compare the versions with their "approved" list. After all it's not easy to remotely determine the kernel version.

You know that is if the auditing firms and agencies actually use scanning software, or if they ask for a package listing and go through that list by hand.

We are talking about the US government here.

Network scanning is OK for some things, especially if you are attempting the actual security vulnerability rather than just assuming it has or does not have it based on the version.

Take Oracle for example, pretty expensive piece of software. Lots of security holes in it. I'm not a DBA so I looked up how to find what patches are installed, and as far as I can tell you cannot determine those patches remotely, you need to run a command on the local host.

My production oracle servers(10.2.0.3) currently have 34 patches installed. And the version string did not change.

Installed Top-level Products (3):

Oracle Database 10g 10.2.0.1.0 Oracle Database 10g Release 2 Patch Set 1 10.2.0.2.0 Oracle Database 10g Release 2 Patch Set 2 10.2.0.3.0 There are 3 products installed in this Oracle Home.

Interim patches (34) : [..] (snip)

And guess what? all 34 patches are security related. I have 8 more patches to get installed soon as well.

Yes of course the software needs to be kept up to date that goes without saying. One can only hope that with a certificate from Redhat that they keep software up to date with security fixes within a reasonable time frame by backporting them can be had.

Then there is the whole convincing these firms and agencies that since CentOS is a duplication of Redhat's system it is therefore certified by the laws of transitivity, but who knows if they will buy it...

-Ross

______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.

nate wrote:

Ross S. W. Walker wrote:

...

Then there is the whole convincing these firms and agencies that since CentOS is a duplication of Redhat's system it is therefore certified by the laws of transitivity, but who knows if they will buy it...

Well I wouldn't be surprised if a agency/certification thing would not support you under CentOS if they support RHEL. It would be sad but not completely crazy.

Those firms and agencies are likely more strict on what they support than software/hardware vendors. And there's quite a few software and hardware vendors that don't support CentOS but do support RHEL.

I suppose it mostly comes down to the organization behind it and the relationships Red Hat in this case has with those companies in order to help track/escalate problems/fixes/etc easier then organizations like CentOS that are less formal. And yes I believe if a bug is found in CentOS it's almost certain to appear in RHEL, but without reproduction under RHEL the vendor is unlikely to approach Red Hat and say you have a bug in your product even though I was using CentOS.

True. Maybe if CentOS gets enough publicity and a tremendous user base (not that it doesn't now) it would be too much of a force to just disregard as "unsupported", but who knows, time tells all.

Oh and BTW I believe it is CentOS' user base that discovers the majority of the edge case bugs in RHEL as I believe the user base to be more diverse in the hardware they run it on. The majority of hardware RHEL is run on is HP or Dell, so RHEL actually benefits in the long run with CentOS being around.

-Ross

______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.

Scott Silva wrote:

on 2/13/2008 7:44 AM nate spake the following:

...

Ross S. W. Walker wrote:

...

The agencies don't know what security backports vendor XYZ has implemented and frankly they don't care. All they have is a list of minimum version numbers that software must be at in order for it to be deemed "compliant".

So check the actual version number of the package. Using a remote network software scanner to detect security problems based on banner strings provided by the network software is nothing more than a false sense of security.

...

I think we will start seeing this in the PCI and HIPA compliance regulations first, but I wouldn't be surprised if it leaks out into GLBA and other regulations over time.

The scanning vendors will be forced to fix their products. It's perfectly acceptable, and preferred behavior to backport patches. Just look at the recent Samba thread here for a good reason why backporting is good. I'd be mightily pissed if RHEL or CentOS switched a version out from under me which caused breakage. I honestly cannot believe that RHEL did that for Samba. If anything introduce a new ALTERNATE package that has the incompatible changes in it and allow users to choose between that one and the original for their systems. That's just me though. Fortunately I don't really use Samba.

Wasn't the samba issue something that was fairly critical, but just couldn't be backported?

Yeah, it was a decision whether to keep samba at the same version but with Windows 2003/Vista incompatibilities or to up the version knowing it can break customers setups.

Difficult decision, but every now and then all vendors have to make at least 1 controversial decision. Besides what good is a Windows compatibility layer that isn't compatible with the latest version of Windows?

-Ross

______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.

Tony Placilla aplacilla@jhu.edu Sr. UNIX Systems Administrator The Sheridan Libraries Johns Hopkins University

...

...

On Wed, Feb 13, 2008 at 10:01 AM, in message

E2BB8074E5500C42984D980D4BD78EF901FAFEF4@MFG-NYC-EXCH2.mfg.prv, "Ross S. W. Walker" rwalker@medallion.com wrote:

Johnny Hughes wrote:

...

Bob Boilard wrote:

...

Hello all,

I love CentOS, but I am seriously regretting selecting

Centos 4.4 for my

...

production hosting servers. The current situation with

CentOS 4.4 and being

...

stuck at Apache 2.0.52 is a huge problem because of the new

requirements for

...

the Credit Card industry PCI scan. Apache 2.0.52 does not pass PCI compliance scans. which means no ecommerce on any of these

servers - MAJOR

...

ISSUE. So my question to the community is: when are new

Apache RPM's going

...

to be released or at minimum a backported version that

plugs these security

...

holes so we can pass PCI scans. Apache 2.0.52 has some

major issues that

...

need to be dealt with?

I am almost positive that this issue is one of the scan software using version numbers and not understanding that RHEL backports fixes.

It is a big fear of mine that this may become more and more of an issue when government agencies start setting stricter and stricter software compliance guidelines.

The agencies don't know what security backports vendor XYZ has implemented and frankly they don't care. All they have is a list of minimum version numbers that software must be at in order for it to be deemed "compliant".

I think we will start seeing this in the PCI and HIPA compliance regulations first, but I wouldn't be surprised if it leaks out into GLBA and other regulations over time.

I think it will be these compliance issues that may force upstream to change their strategy otherwise I can see this being a roadblock to RHEL/CentOS adoption in these industries in the future.

-Ross

In a previous life I did PCI compliance for the company I worked for & I ran into this quite often. The scanners would only report on versions & we'd get "out of compliance" which caused no end of hand-wringing from the higher-ups.

However, the certifying parties we used had an appeals process & I could almost always boilerplate the output of rpm -q --changelog httpd |grep -i cve

and send them proof of the backported fixes. They would then remove the "compliance failure"

Obviously IANAL & things could change with PCI certification vendors & such, but this might be worth investigating