Should I be worry about thoses security holes from Apache, PHP and SSL

Support
1

After scanning for PCI compliance most of problem coming from Apache, PHP and SSL, and most of them could be resolve by update of those.

Basically I have 2 questions
1’ Should I considering those 200 potentiels holes of security ?
2’ It is possible to update them without breaking Nethserver, and if yes, how to ?

Screen Shot 2015-09-15 at 16.png755×700 72 KB

thanks for your time and your opinion

2

this image is useless…

we need to know exactly which kind of bug/vulnerabilities we’re taliking about.
I’d add that if tests are done against version number, they are not real…
RH (and so CentOS) backports security bugfixing to their packages…
in another words, PHP5.3 you’re running on NS is not a “real” php 5.3

3

Thank Stefano, it what I understood by reading your post : Best Way of Updating PHP... or not
but I wasn’t sure

Also I could put the CVE list, put it’s truly long just to name a few

PHP : CVE-2006-7243, CVE-2010-2094, CVE-2010-2950, CVE-2010-3436, CVE-2010-3709, CVE-2010-3710, CVE-2010-3870, CVE-2010-4150, CVE-2010-4156, CVE-2010-4409, CVE-2010-4645, CVE-2010-4697, CVE-2010-4698, CVE-2010-4699, CVE-2010-4700, CVE-2011-0421, CVE-2011-0708, CVE-2011-1092, CVE-2011-1148, CVE-2011-1153, CVE-2011-1464, CVE-2011-1466, CVE-2011-1467, CVE-2011-1468, CVE-2011-1469, CVE-2011-1470, CVE-2011-1657, CVE-2011-1938, CVE-2011-2202, CVE-2011-2483, CVE-2011-3182, CVE-2011-3267, CVE-2011-3268, CVE-2011-3379, CVE-2011-4566, CVE-2011-4885, CVE-2012-0057, CVE-2012-0781, CVE-2012-0788, CVE-2012-0789, CVE-2012-1823, CVE-2012-2143, CVE-2012-2311, CVE-2012-2335, CVE-2012-2336, CVE-2012-2386, CVE-2012-2688, CVE-2012-3365, CVE-2012-3450, CVE-2012-6113, CVE-2012-1823, CVE-2013-1635, CVE-2013-1643, CVE-2013-4113, CVE-2013-6712, CVE-2014-0207, CVE-2014-0237, CVE-2014-0238, CVE-2014-3515, CVE-2014-3981, CVE-2014-4049

SSL : CVE-2007-1858, CVE-2013-4353, CVE-2013-6449, CVE-2013-6450, CVE-2014-0076, CVE-2014-0160, CVE-2010-5298, CVE-2014-0195, CVE-2014-0198, CVE-2014-0221, CVE-2014-0224, CVE-2014-3470, CVE-2015-0292, CVE-2014-3505, CVE-2014-3506, CVE-2014-3507, CVE-2014-3508, CVE-2014-3509, CVE-2014-3510, CVE-2014-3511, CVE-2014-3512, CVE-2014-3513, CVE-2014-3566, CVE-2014-3567, CVE-2014-3568, CVE-2014-5139, CVE-2010-5298

APACHE : CVE-2003-1567, CVE-2004-2320, CVE-2009-3560, CVE-2009-3720, CVE-2010-0386, CVE-2010-1452, CVE-2010-1623, CVE-2010-2068, CVE-2011-3368, CVE-2011-3607, CVE-2011-4317, CVE-2012-0021, CVE-2012-0031, CVE-2012-0053, CVE-2012-0883, CVE-2012-2687, CVE-2012-4557, CVE-2013-1862, CVE-2013-1896, CVE-2013-5704, CVE-2014-0118, CVE-2014-0226, CVE-2014-0231

RC4 : CVE-2013-2566, CVE-2015-2808

4

You sound like you’re opening up a world of hurt here for yourself.
Even that snapshot you posted says there are only 80 ‘holes’, whatever that means.

fwiw, I would hazard a guess that you can throw out 30 to 50 of those 80 simply by tightening up your ssl conf to have your server not offer up insecure ciphers on all the various services it serves.

Here’s an example of a scan against a plain mail and web nethserver showing what I mean, from, I’ll point out, a scanner that’s not built to stress fud as the basis for selling fix it services.

vulnscanexample.png901×669 63.6 KB

5

Here is the summary.
Now, I’ll point out, the worst ‘vuln’, is that xss issue, but it counts for two because it’s on http and https, so that one fix.
Also, this scan. as is obvious, is from internal, most of those services aren’t available externally, this nethserver is behind a gateway and it’s not on an open dmz, oh and even better, I haven’t even gotten around to installing the firewall module.
Now I will point out that this scan, as you can see, did not hit port 980… did yours?
Do you see what I’m getting at?

vulnscanexample2.png916×772 107 KB

6

take a look here:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6113

as I told you, all packages coming from RH/CentOS are patched

7

Hi Stefano and others;

Correcting me if i’m wrong
NethServer use CentOS repo which are base on RedHat.
So if you update your NethServer and RedHat patch the security issue https://rhn.redhat.com/errata/rhel-server-6-errata-security.html your server is safe.

So, we don’t need to be worry, and annoying NethServer community, about the security. If we want to discuss about security issue, we should communicate with CentOS community.

So for now, the only issue, I think, might be regulate by NethServer Community is the weakness of the SSL by using RC4, which if i’m following well, will be resolve into 6.7

I hope this post will help others to understand like it help me!

8

Yes this is the real truth! :wink:
We should make a FAQ with this! Do you wanna try helped by @zamboni?

9

Generally speaking, any security weakness caused by a specific configuration should be investigated: what configuration does NethServer make use of? Is it secure?

So we are at the state-of-art about code because of upstream updates, but we need to review our configuration choices.

Also we have to take care about some packages coming from third-party repositories (EPEL, RepoForge, and so on…), and hosted on NethServer repositories. They must be followed carefully!

Have a look at them:

http://mirror.nethserver.org/nethserver/6.7/base/x86_64/Packages/

3 Likes