Security scan on server failed

[veronicabend]

Hi to all!

A site hosted at our server got a security scan by Security Metrics run and the scan showed some fails. If anyone could help me understand better what these fails mean, I would be very grateful!

Some of the things they spotted are cpanel ports, which they say should be closed if not needed. Well they are needed so out of the question. Those comments didn't have a risk value associated to them.

They're saying we should turn off ping requests or install a firewall, that server should not answer ping requests.

Anyway, these are the issues I am more interested in getting help with:

1) The remote host is using the Apache mod_frontpage module. mod_frontpage older than 1.6.1 is vulnerable to a buffer overflow which may allow an attacker to gain root access. *** Since SMetrics was not able to remotely determine the version *** of mod_frontage you are running, you are advised to manually *** check which version you are running as this might be a false *** positive. If you want the remote server to be remotely secure, we advise you do not use this module at all. Solution: Disable this module Risk Factor: High

All I could find out about the server front page extensions is this:

Apache/1.3.36 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.2 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.27 OpenSSL/0.9.7a

It says FrontPage 5.0.2.2635 . They're mentioning mod_frontpage 1.6.1 . Numbers look so different that I am not sure this is referring to the same thing. Could anyone give me a hint about this? Thanks!

2) The remote host is using a version of OpenSSL which is older than 0.9.6j or 0.9.7b This version is vulnerable to a timing based attack which may allow an attacker to guess the content of fixed data blocks and may eventually be able to guess the value of the private RSA key of the server. An attacker may use this implementation flaw to sniff the data going to this host and decrypt some parts of it, as well as impersonate your server and perform man in the middle attacks. *** SMetrics solely relied on the banner of the remote host *** to issue this warning See also : http://www.openssl.org/news/secadv_20030219.txt
http://lasecwww.epfl.ch/memo_ssl.shtml http://eprint.iacr.org/2003/052/ Solution: Upgrade to version 0.9.6j (0.9.7b) or newer Risk Factor: Medium

From the code I posted above, we have OpenSSL 0.9.7a .
I don't know why this one should be outdated, cPanel takes care of updates. Any ideas? I don't think upgrading manually myself would be a good idea. Would it affect cpanel? Will cpanel revert the change?

3) Synopsis : The remote service encrypts traffic using a protocol with known weaknesses.
Description : The remote service accepts connections encrypted using SSL 2.0, which
reportedly suffers from several cryptographic flaws and has been deprecated for several years. An attacker may be able to exploit these issues to conduct man-in-the-middle attacks or decrypt communications between the affected service and clients. See also :
http://www.schneier.com/paper-ssl.pdf Solution: Consult the application's documentation to
disable SSL 2.0 and use SSL 3.0 or TLS 1.0 instead.

How do I know which version of SSL is enabled? How can this be upgraded? Is it set at cPanel?

Thank you very much for any help!!!

Veronica

[byronm]

Hate to rehash an old thread but we're working on PCI audits and the openssl issue is the last one i have lingering but it looks like the only way to get it fixed is to upgrade to Centos 5 as the buildapache stuff automatically pulls down an RPM for openssl even if you roll/build your own later version..

anyway to have the build apache stuff use the latest version without re-installing the rpm?

[serversphere]

Most of the time, especially with RH/Centos boxes, these updates are rolled in without a version increase. So you will see version 1.0.22 (for example - relating to nothing specific) when the author may be calling the latest 1.0.46. RH (and subsequently Centos) are patching the version they have rather than using the brand new version.

So you should check with your OS provider. You might find you are building your own latest version and overwriting the already patched version supplied by your provider.

[byronm]

Centos 5 includes the "fixed" openssl, centos 4.4 includes the "broken" one. Security providers are simply using the apache version info to pull this information and it does me no good if centos/redhat are not increasing the version to reflect the patch level when you rely on a 3rd party to validate compliance if you know what i mean.

PCI compliance is a major thing - payment card industry will sue everyonce out of existance if fraud happens and your credit card/authorization chain isn't compliant.

Attempting a cpanel 5 upgrade on a test server just to see if this will finally push us over the compliance issue.

Remember folks, if you accept credit cards or even Paypal web payments pro you MUST get PCI compliant and fax in a copy of your compliance report or else you can get in deep dooo doo

[byronm]

Centos 5 got me up on a decent version of OpenSSL however the audit reports still want anything higher than 0.9.8d but b will pass the major audits finally (PCI audit)

hope to see cpanel push out a contrib rpm or see if redhat will roll an update

[smdstudios]

So you should check with your OS provider. You might find you are building your own latest version and overwriting the already patched version supplied by your provider.

I think we have this problem with our server. The sever techs fix the issues but when a update comes up for Cpanel the issues come back. Is there a way around this?