Vulnerability scans

I'd appreciate it if someone from Astaro would acknowledge my message; otherwise I'll probably need to open a ticket.

Thanks,
Barry

Hey Barry, since you're my customer, would you like me to go ahead and open the case for you?

Sure Bruce, that'd be great.

As I said, these aren't (currently) critical as far as PCI goes, but they do keep changing the standards, and cleaning this up would make less work for us on our quarterly audits.

Thanks!
Barry

Who do you all recommend and any experiences good or bad with these services for Vulnerability Scans and PCI Compliance?
Thank you all in advance.

8 - Astaro 220's 7.104 and 7.201 (testing)

My employer has contracted with Ambiron, now known as TrustWave. Their scan product is TrustKeeper.
Ambiron was purchased by IBM about a year ago.

However, I can't recommend them; they're consulting is extremely expensive and only includes 1 3-hour call per quarter, and the scans are about $600 each (+ the retainer), and the scan reports do not include vital details such as the exact URL for a XSS vulnerability, etc.

Nessus would be fine, and I'm pretty sure TrustKeeper's product is based on Nessus, but they've over-customized the reports (omitting critical information).

Anyways, for most PCI levels, you have to have a 3rd party doing some of the scans, and they have to be PCI certified... I wish there was someone I could truly recommend.
The OWASP mailing lists might be a good place to inquire further.

Barry

I'll let you know in the coming months if I find someone worth a hoot that doesn't think the world revolves around their report findings, and charges like they own the world.  haha  Thanks Barry.

Yeah we use Trustkeeper as well. Pretty overpriced.

Bruce kindly opened a ticket with Astaro...

A. They may not fix this in 6.x... understandable. I've done some research on this for our other servers; it may be possible to 'hack' it though by adding:
SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL
To the global section of the httpd.conf

B. They think some of the issues don't exist in v7, and will look into the others soon.
If anyone has seen these alerts with v7, please respond here.


Thanks,
Barry

Just a reminder guys; while I think the entry that Barry G. mentions here may work in Version 6, but do remember this may void your support and / or "kill" the box.  I'll be keeping up with this issue myself, there are some pen tests that we run against the box, I'll check to see if we have some that look at this "HTTP Trace" method.

Just a reminder guys; while I think the entry that Barry G. mentions here may work in Version 6, but do remember this may void your support and / or "kill" the box.  I'll be keeping up with this issue myself, there are some pen tests that we run against the box, I'll check to see if we have some that look at this "HTTP Trace" method.

FWIW, I now have stronger evidence that TrustKeeper is using Nessus, or a custom-licensed version of Nessus; the wording in their reports is _extremely_ similar to the Nessus alerts.

I've 'hacked' our ASL 6.3 installation to disable SSLv2 etc.

Disclaimer: As always, any changes via the shell may void your Astaro support!
If you make a mistake, it could kill webmin (and any portals, if v6 has any), so make sure you backup the files to be changed first!

reference: http://adamyoung.net/Disable-SSLv2-System-Wide
Note you need the first Apache line, even if you put in the second. I put both in.


Hack:
0. Make sure you have a current Astaro backup!

1. backup /etc/httpd.conf-default

2. add 2 lines and a comment to /etc/httpd.conf-default (near the top):
# Basic stuff

# 2008-07-14 - PCI compliance - (http://adamyoung.net/Disable-SSLv2-System-Wide)
SSLProtocol ALL -SSLv2
SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL


3. make the same change to /etc/httpd.conf
(I couldn't figure out how to force the default to get copied)

4. restart webmin:
/etc/init.d/httpd restart

5. make sure webmin is working in your browser

6. test that SSLv2 is disabled. You can do this on Astaro (IF you allow webmin connections from ANY or from localhost), or from another box with openssl installed:
openssl s_client -ssl2 -connect fw.example.net:443

The result should be an error, e.g.
CONNECTED(00000003)
32124:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:


If anything goes wrong, undo the changes and restart httpd again.

I've done this on 6.311, and it worked fine for me. We'll be having another TrustKeeper scan tonight; I'll try to report on the results.

I haven't tried this on v7, but note that:
a. Astaro is now looking into this issue for v7 (CaseID 00071816), and some of these 'vulnerabilities' may not exist in v7 anyways. They did say however that people making this a 'feature request' would push it through faster.

b. v7 has the webmin, end user portal, ..., so there may be more than 1 httpd.conf; I'm not sure.


Barry

BTW, above post doesn't cover the HTTP TRACE method issue.

As there is not a simple way (mod_rewrite isn't simple) to disable this in the version of Apache on ASL 6.3, I'm not going to try to mess with it.

reference:
http://www.ducea.com/2007/10/22/apache-tips-disable-the-http-trace-method/

My 7.2x box seems to already have TRACE disabled in
/var/sec/chroot-httpd/etc/httpd/httpd.conf
This is good.

Barry