Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 3 subscribers
  • Views 9378 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Vulnerability scans

BarryG
Hi, our company has a 3rd party do vulnerability scans for as as part of our PCI compliance.

This is not critical, but the following items are on the firewall's external IP are in the report each time. Note this is the actual firewall, we are NOT doing NAT.

1. SSL Anonymous Diffie-Hellman Ciphers
recommendation: configure server to only allow higher-grade SSL

2. SSL Weak Encryption Algorithms
recommendation: configure server to only allow higher-grade SSL

3. HTTP TRACE method enabled
recommendation: disable trace method

I realize the impact of these issues is probably very low.

Thanks,
Barry


This thread was automatically locked due to age.
Parents
  • 0
    I'd appreciate it if someone from Astaro would acknowledge my message; otherwise I'll probably need to open a ticket.

    Thanks,
    Barry
  • 0 in reply to BarryG
    Hey Barry, since you're my customer, would you like me to go ahead and open the case for you?
  • 0 in reply to BrucekConvergent
    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
  • 0 in reply to BarryG
    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)
  • 0 in reply to RDL
    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
  • 0 in reply to BarryG
    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.
  • 0 in reply to RDL
    Yeah we use Trustkeeper as well. Pretty overpriced.
  • 0 in reply to ReD-MaN
    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
  • 0 in reply to BarryG
    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.
  • 0 in reply to BrucekConvergent
    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.
  • 0 in reply to BarryG
    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
  • 0 in reply to BarryG
    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
Reply Children
No Data