Comparing QualysGuard PCI to Comodo HackerGuardian

I’m not doing e-commerce transactions, so its not required that I do quarterly external PCI Scan Compliance scans, as dictated by the Security Standards Counsel. But, for the fun of it, I ran an official scan, from two Approved Scanning Vendor (ASV) PCI programs. I am evaluating the QualysGuard PCI On-Demand program for something in my professional life, and using a part of my personal life (my blog), as the test case. This is great, I get to play with a new technology, discover and fix vulnerabilities on my web site, share my experience with you, help others identify and correct these problems on their servers, and get paid for it, all at the same time. Can I get a whoot?

I was shocked at how many problems it found with my web site. In this article, I will expose the report and discuss how I fixed each item, and therefore became PCI scan compliant. Then I will give my review of the QualysGuard PCI program.

Before I remediated any of the problems QualysGuard PCI found, I signed up for Comodo’s HackerGuardian program. I wanted to see if it found the same problems, or yet a different set. I was shocked that Comodo’s HackerGuardian simply gave me a PASSED scoring. More on that later in the article.

For reference, here is copy of the Qualys report. And here is a copy of the Comodo report.

Table Of Contents:

1. Vulnerabilities Found (QualysGuard PCI)
   
   1. File .htaccess Accessible (QualysGuard PCI)
   2. Web Server Uses Plain-Text Form Based Authentication – PCI FAILED – (QualysGuard PCI)
   3. TCP Sequence Number Approximation Based Denial of Service (QualysGuard PCI)
   4. AutoComplete Attribute Not Disabled for Password in Form Based Authentication (QualysGuard PCI)
   5. Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability – PCI FAILED (QualysGuard PCI)
   6. Web Directories Listable Vulnerability (QualysGuard PCI)
   7. SSL Certificate – Signature Verification Failed Vulnerability (QualysGuard PCI)
   8. Web Directories Listable Vulnerability (QualysGuard PCI)
   9. Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability – PCI FAILED – (QualysGuard PCI)
   10. AutoComplete Attribute Not Disabled for Password in Form Based Authentication (QualysGuard PCI)
2. Potential Vulnerabilities (QualysGuard PCI)
   1. OpenSSH Signal Handling Vulnerability (RHSA-2006-0697) – PCI FAILED -(QualysGuard PCI)
   2. Possible Mail Relay – PCI FAILED – (QualysGuard PCI)
3. Information Gathered (QualysGuard PCI)
   1. Host Uptime Based on TCP TimeStamp Option (QualysGuard PCI)
   2. Operating System Detected (QualysGuard PCI)
   3. DNS Host Name (QualysGuard PCI)
   4. Traceroute (QualysGuard PCI)
   5. Open TCP Services List (QualysGuard PCI)
   6. SSL Web Server Version (QualysGuard PCI)
   7. Web Server Version (QualysGuard PCI)
   8. Open UDP Services List (QualysGuard PCI)
   9. Firewall Detected (QualysGuard PCI)
   10. Host Names Found (QualysGuard PCI)
   11. Host Scan Time (QualysGuard PCI)
4. Review of QualysGuard PCI (QualysGuard PCI)
5. Vulnerabilities Found (Comodo HackerGuardian)
6. Review of Comodo HackerGuardian
7. Conclusion

---

QualysGuard PCI Items:

1. Vulnerabilities Found (QualysGuard PCI)

1.1. File .htaccess Accessible (QualysGuard PCI)

THREAT:
.htaccess contains authentication information.
IMPACT:
Unauthorized users can gather authentication information from this file.
SOLUTION:
Change the Apache configuration so the .htaccess file cannot be accessed via the Internet.
RESULTS:
[snipped – don’t want to show my .htaccess file, sorry]

MY COMMENTS:

This is all the information the report gave. It also gave me a dump of my .htaccess file, but didn’t tell me how to fix it. Here’s how I fixed the problem, figured this out on my own accord:

Add this to .htaccess

1. # Disable any public access to any files that start with .ht
2. <FilesMatch “^\.ht”>
3. Order allow,deny
4. Deny from all
5. </FilesMatch>

This fixed it, but I found it important to put it last. The reason is that I have a different FilesMatch section in my .htaccess file that looks for “referrer spam”, does a FilesMatch “(.*)” with a Deny from env=spam_ref, allows everything else. The lesson learned is that apache doesn’t stop on the first FilesMatch it finds, it keeps playing them in order. If you get a deny, then match a later rule that says allow, you’re allowed. So watch out for FilesMatch, have to play them in the right order.

1.2. Web Server Uses Plain-Text Form Based Authentication – PCI FAILED – (QualysGuard PCI)

THREAT:
The Web server uses plain-text form based authentication. A web page exists on the target host which uses an HTML login form. This data is sent
from the client to the server in plain-text.
IMPACT:
An attacker with access to the network traffic to and from the target host may be able to obtain login credentials for other users by sniffing the
network traffic.
SOLUTION:
Please contact the vendor of the hardware/software for a possible fix for the issue. For custom applications, ensure that data sent via HTML login
forms is encrypted before being sent from the client to the host.

MY COMMENTS:

This is my blog (Joomla) administration login page. Rather than taking its advice and contacting Joomla, I used .htaccess to fix the problem. Since the adminstration pages are in a separate directory, I simply dropped a .htaccess file there with this in it:

Force https .htaccess

1. RewriteEngine On
2. RewriteCond %{HTTPS} off
3. RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

1.3. TCP Sequence Number Approximation Based Denial of Service (QualysGuard PCI)

THREAT:
TCP provides stateful communications between hosts on a network. TCP sessions are established by a three-way handshake and use random
32-bit sequence and acknowledgement numbers to ensure the validity of traffic. A vulnerability was reported that may permit TCP sequence
numbers to be more easily approximated by remote attackers. This issue affects products released by multiple vendors.
[snip] IMPACT:
Successful exploitation of this issue could lead to denial of service attacks on the TCP based services of target hosts. Other consequences may also
result, such as man-in-the-middle attacks.
SOLUTION:
Please first check the results section below for the port number on which this vulnerability was detected. If that port number is known to be used for
port-forwarding, then it is the backend host that is really vulnerable.
Various implementations and products including Check Point, Cisco, Cray Inc, Hitachi, Internet Initiative Japan, Inc (IIJ), Juniper Networks, NEC,
Polycom, and Yamaha are currently undergoing review. Contact the vendors to obtain more information about affected products and fixes.

MY COMMENTS:

The workaround to this appears to be at the switch level. It’s my understanding there is nothing I can do on my server to protect against this. I’ll have to run this by my service provider, the network gurus, to see what they have to say about it. I’ll update this comment after I’ve done that. For now, I’m just going to skip this one, it’s not causing PCI compliance failure, anyway.

1.4. AutoComplete Attribute Not Disabled for Password in Form Based Authentication (QualysGuard PCI)

THREAT:
The Web server allows form based authentication without disabling the AutoComplete feature for the password field.
IMPACT:
The passwords entered by one user could be stored by the browser and retrieved for another user using the browser.
SOLUTION:
Contact the vendor to have the AutoComplete attribute disabled for the password field in all forms. The AutoComplete attribute should also be
disabled for the user ID field.

MY COMMENTS:

That’s nice, but I don’t recall off the top of my head how to do that. A quick Google search revealed:

1. <input type=“text” name=“cc” autocomplete=“off” />

Ok, so I’ll pass this along to the Joomla developers, but in the meantime, I want it fixed now. So, I’ll hack it in. A few recursive greps later, I’ve found the INPUT tags the PCI scan was complaining about and added the autocomplete=”off” attributes.

1.5. Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability – PCI FAILED – (QualysGuard PCI)

THREAT:
A Web server was detected that supports the HTTP TRACE method. This method allows debugging and connection trace analysis for connections
from the client to the Web server. Per the HTTP specification, when this method is used, the Web server echoes back the information sent to it by
the client unmodified and unfiltered. Microsoft IIS web server uses an alias TRACK for this method, and is functionally the same.
A vulnerability related to this method was discovered. A malicious, active component in a Web page can send Trace requests to a Web server that
supports this Trace method. Usually, browser security disallows access to Web sites outside of the present site’s domain. Although unlikely and
difficult to achieve, it’s possible, in the presence of other browser vulnerabilities, for the active HTML content to make external requests to arbitrary
Web servers beyond the hosting Web server. Since the chosen Web server then echoes back the client request unfiltered, the response also
includes cookie-based or Web-based (if logged on) authentication credentials that the browser automatically sent to the specified Web application on
the specified Web server.
The significance of the Trace capability in this vulnerability is that the active component in the page visited by the victim user has no direct access to
this authentication information, but gets it after the target Web server echoes it back as its Trace response.
Since this vulnerability exists as a support for a method required by the HTTP protocol specification, most common Web servers are vulnerable.
The exact method(s) supported, Trace and/or Track, and their responses are in the Results section below.
IMPACT:
If this vulnerability is successfully exploited, users of the Web server may lose their authentication credentials for the server and/or for the Web
applications hosted by the server to an attacker. This may be the case even if the Web applications are not vulnerable to cross site scripting attacks
due to input validation errors.
SOLUTION:
Solutions for some of the common Web servers are supplied below. For other Web servers, please check your vendor’s documentation.
Apache: Recent Apache versions have a Rewrite module that allows HTTP requests to be rewritten or handled in a specific way. Compile the
Apache server with the mod_rewrite module. You might need to uncomment the ‘AddModule’ and ‘LoadModule’ directives in the httpd.conf
configuration file. Add the following lines for each virtualhost in your configuration file (Please note that, by default, Rewrite configurations are not
inherited. This means that you need to have Rewrite directives for each virtual host in which you wish to use it):
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* – [F] </IfModule>
With this configuration, Apache catches all TRACE requests, and replies with a page reporting the request as forbidden. None of the original
request’s contents are echoed back.
A slightly tighter fix is to use:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* – [F] </IfModule>
Please note that RewriteEngine can be processor intensive and may impact the web server performance. The trace method can also be controlled
by use of the TraceEnable directive, and track can be controlled through either the Limit or LimitExcept.
In the httpd.conf add or modify:
<Directory>
<limit TRACK>
deny from all
</limit>
…
</Directory>
TraceEnable Off
Microsoft IIS: Microsoft released URLScan, which can be used to screen all incoming requests based on customized rulesets. URLScan can be
used to sanitize or disable the TRACE requests from the clients. Note that IIS aliases ‘TRACK’ to ‘TRACE’. Therefore, if URLScan is used to
specfically block the TRACE method, the TRACK method should also be added to the filter.
URLScan uses the ‘urlscan.ini’ configuration file, usually in \System32\InetSrv\URLScan directory. In that, we have two sections – AllowVerbs and
DenyVerbs. The former is used if the UseAllowVerbs variable is set to 1, else (if its set to 0), the DenyVerbs are used. Clearly, either can be used,
depending on whether we want a Default-Deny-Explicit-Allow or a Default-Allow-Explicit-Deny policy. To disallow TRACE and TRACK methods
through URLScan, first remove ‘TRACK’, ‘TRACE’ methods from the ‘AllowVerbs’ section and add them to the ‘DenyVerbs’ section. With this,
URLScan will disallow all ‘TRACE’ and ‘TRACK’ methods, and generate an error page for all requests using that method. To enable the changes,
restart the ‘World Wide Web Publishing Service’ from the ‘Services’ Control Panel item.
Sun ONE/iPlanet Web Server: Here are the sun recommandations to disable the trace method.
For more details about other web servers : Cert Advisory.

MY COMMENTS:

I’ve heard of this one before! A long while ago also. My apache configuration is from a fresh install of the newest stable version. You’d think Apache would start disabling this by default in the default http.conf file that deploys with the RPM. Or is that up to the operating system vendor to create? Hrm. Oh well, just fixed my httpd.conf file.

1.6. Web Directories Listable Vulnerability (QualysGuard PCI)

THREAT:
The Web server has some listable directories. Very sensitive information can be obtained from directory listings.
IMPACT:
A remote user may exploit this vulnerability to obtain very sensitive information on the host. The information obtained may assist in further attacks
against the host.
SOLUTION:
Disable directory browsing or listing for all directories.
RESULT:
Listable Directories
/src/

MY COMMENTS:

I leave directory listing on purpose. I want to be able to hit my /src/ directory and see the list of files. Ok, for the sake of passing PCI compliance, I’ll turn it off. I simply added a .htaccess file to my /src/ directory:

1. Options -Indexes

1.7. SSL Certificate – Signature Verification Failed Vulnerability (QualysGuard PCI)

THREAT:
An SSL Certificate associates an entity (person, organization, host, etc.) with a Public Key. In an SSL connection, the client authenticates the remote
server using the server’s Certificate and extracts the Public Key in the Certificate to establish the secure connection. The authentication is done by
verifying that the public key in the certificate is signed by a trusted third-party Certificate Authority.
If a client is unable to verify the certificate, it can abort communication or prompt the user to continue the communication without authentication.
IMPACT:
By exploiting this vulnerability, man-in-the-middle attacks in tandem with DNS cache poisoning can occur.
Exception:
If the server communicates only with a restricted set of clients who have the server certificate or the trusted CA certificate, then the server or CA
certificate may not be available publicly, and the scan will be unable to verify the signature.
SOLUTION:
Please install a server certificate signed by a trusted third-party Certificate Authority.
RESULT:
Certificate #0 unable to get local issuer certificate

MY COMMENTS:

I have a signed SSL cert. Granted, I bought it from Go Daddy, Turbo SSL. Go Daddy signs under “Starfield Securre Certification Authority” which isn’t as common of a trusted authority. Major browsers have it, but I’ve found a number of PDA devices that don’t. And apparently, QualysGuard PCI doesn’t have it loaded either. Oh well, I’m not changing.

1.8. Web Directories Listable Vulnerability (QualysGuard PCI)

This is a repeat. I’m getting duplicates, because it’s scanning both my domain and the reverse DNS host name for my ip, ip-68-178-172-38.ip.secureserver.net.

1.9. Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability – PCI FAILED (QualysGuard PCI)

Repeat, due to also scanning ip-68-178-172-38.ip.secureserver.net

1.10. AutoComplete Attribute Not Disabled for Password in Form Based Authentication (QualysGuard PCI)

THREAT:
The Web server allows form based authentication without disabling the AutoComplete feature for the password field.
IMPACT:
The passwords entered by one user could be stored by the browser and retrieved for another user using the browser.
SOLUTION:
Contact the vendor to have the AutoComplete attribute disabled for the password field in all forms. The AutoComplete attribute should also be
disabled for the user ID field.

MY COMMENTS:

Almost thought this was a repeat, but noticed it’s for a different login form when I looked at the RESULT section. This was easy to fix, but I hacked it into my Joomla template. I don’t like hacking my Joomla template or source code, because I loose track of all the changes I’ve done. If I ever want to upgrade Joomla, I’ll have to redo all my hacks. Yuck. So, I’ll tell Joomla about this, hopefully they’ll fix in in their source. Anyway, just had to add another autocomplete=”off” in the right place.

2. Potential Vulnerabilities (QualysGuard PCI)

2.1. OpenSSH Signal Handling Vulnerability (RHSA-2006-0697) – PCI FAILED – (QualysGuard PCI)

THREAT:
A vulnerability in OpenSSH is caused due to a race condition within the signal handling.
IMPACT:
This can be exploited to crash the OpenSSH server and potentially allows the execution of arbitrary code.
SOLUTION:
Red Hat has released security advisory 2006-0697 to address this issue.
A newer updateRHBA-2007-0462 is available which obsoletes RHSA-2006-0697
RESULT:
SSH-2.0-OpenSSH_4.3

MY COMMENTS:

At this time, I am running the most recent versions available for openssh, for CentOS5 (and hence for RHEL5):

1. # rpm -qa | grep -i openssh
2. openssh-4.3p2-24.el5
3. openssh-server-4.3p2-24.el5
4. openssh-clients-4.3p2-24.el5

Why it thinks that 4.3 is vulnerable to RHBA-2007-0462 is beyond me. I should report this to Qualys as a false positive. At least it showed up under Potential Vulnerabilities, as if it wasn’t sure.

There is no way to make ssh not show the version number, short of source code hacking, which I’m not going to do. Client applications rely on the version number to change their behavior accordingly. So, I have no remedy here, except to FILE A FALSE POSITIVE REPORT WITH QUALYS. I’m going to do that, and include the result in my review of the product.

2.2. Possible Mail Relay – PCI FAILED – (QualysGuard PCI)

THREAT:
The Internet Electronic Mail exchange protocol (SMTP) is designed to work with relays. These days, there is less of a need for relaying functions
and, in fact, relaying functions are highly vulnerable to attacks because they allow unauthorized users to connect once to a mail server for a single
message. Then, the relaying server distributes the message to thousands of recipients.
It is possible that mail relaying is allowed by the mail server on the host. More details about the specific relaying addresses that are accepted by the
mail server are given in the Results section. Since a mail server that accepts a relaying address may be configured not to actually deliver the mail to
that address. If this is the case, you may safely ignore this report.
IMPACT:
If mail relaying is indeed allowed, unauthorized Internet users can exploit your Mail server to send anonymous e-mail messages, send massive
advertisement messages to unwilling recipients, consume bandwidth or cause denial of service on your servers.
SOLUTION:
Disallow mail relaying if it is allowed. The mail exchanger will need to be reconfigured accordingly.
RESULT:
HELO qualysguard.com
250 ip-68-178-172-38.ip.secureserver.net
MAIL FROM:<qgmrfrom@ip-68-178-172-38.ip.secureserver.net>
250 ok
RCPT TO:<@qualysguard.com:qgmrtest@ip-68-178-172-38.ip.secureserver.net>
250 ok
DATA
354 go ahead
QG mail relay test # 6
.
250 ok 1206488604 qp 16007

MY COMMENTS:

ip-68-178-172-38.ip.secureserver.net resolves to my server, isn’t it OK THAT IS EXCEPTS MAIL FOR THIS DOMAIN? Try a random domain, it won’t take it! For the sake of passing the PCI scan compliance, I am removing ip-68-178-172-38.ip.secureserver.net from my list of recipient hosts. That should take care of it for the follow up scan.

3. Information Gathered (QualysGuard PCI)

3.1. Host Uptime Based on TCP TimeStamp Option (QualysGuard PCI)

THREAT:
The TCP/IP stack on the host supports the TCP TimeStamp (kind 8) option. Typically the timestamp used is the host’s uptime (since last reboot) in
various units (e.g., one hundredth of second, one tenth of a second, etc.). Based on this, we can obtain the host’s uptime. The result is given in the
Result section below.
Some operating systems (e.g., MacOS, OpenBSD) use a non-zero, probably random, initial value for the timestamp. For these operating systems,
the uptime obtained does not reflect the actual uptime of the host; the former is always larger than the latter.
RESULT:
Based on TCP timestamps obtained via port 22, the host’s uptime is 6 days, 13 hours, and 33 minutes.
The TCP timestamps from the host are in units of 1 milliseconds.

MY COMMENTS:

WOW, this is so cool, haven’t heard of this one before. BUT IT’S NOT RIGHT. My actual uptime is 104 days. Sorry, Qualys, nice try.

3.2. Operating System Detected (QualysGuard PCI)

THREAT:
Several different techniques can be used to identify the operating system (OS) running on a host. A short description of these techniques is provided below. The specific technique used to identify the
OS on this host is included in the RESULTS section of your report.
1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating
system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this
“fingerprinting” technique, the OS version is among those listed below.
Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the
fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the
version of the operating system detected may be that for the firewall instead of for the host being scanned.

RESULT:
Linux 2.4-2.6 TCP/IP Fingerprint U1141:22

MY COMMENTS:

This isn’t my OS, it’s my kernel. Kind of gives away that I’m using Linux, but doesn’t tell you want OS and OS version I’m using. Granted, it’s not safe to announce the kernel, but IT GUESSED WRONG. I am currently running a 2.6 variant, not 2.4. It may be thrown off, because I’m an instance on a Virtuozzo Virtual Dedicated Hosting. Qualys should be alerted to this false detection.

3.3. DNS Host Name (QualysGuard PCI)

THREAT:
The fully qualified domain name of this host, if it was obtained from a DNS server, is displayed in the RESULT section.
RESULT:
IP address Host name
68.178.172.38 ip-68-178-172-38.ip.secureserver.net

MY COMMENTS:

Yeah, so what? Is this actually a threat, or you’re just telling me this as informational only?

3.4. Traceroute (QualysGuard PCI)

THREAT:
Traceroute describes the path in realtime from the scanner to the remote host being contacted. It reports the IP addresses of all the routers in
between.

[snip actual traceroute]

MY COMMENTS:

Ok, obviously this isn’t a “THREAT”. It took me four informational entries to really realize that non of the items in “Informational” are actually a problem. I was thrown by the word THREAT. Must just be embedded in the template. I’d recommend finding a way to change that word in this section, Qualys!

3.5. Open TCP Services List (QualysGuard PCI)

THREAT:
The port scanner enables unauthorized users with the appropriate tools to draw a map of all services on this host that can be accessed from the
Internet. The test was carried out with a “stealth” port scanner so that the server does not log real connections.
IMPACT:
Unauthorized users can exploit this information to test vulnerabilities in each of the open services.

[snip – list of open ports on my server]

MY COMMENTS:

Yes, I know people can port scan me. Do I really need to deploy intrusion detection system to detect and stop port scanners? Its listed in the Informational section, so the answer is maybe. Not high on the priority list, but look into it when you get a chance.

3.6. SSL Web Server Version (QualysGuard PCI)

RESULT:
Server Version Server Banner
Apache 1.3 Apache/2.2.3 (CentOS)

3.7. Web Server Version (QualysGuard PCI)

RESULT:
Server Version Server Banner
Apache 1.3 Apache/2.2.3 (CentOS)

3.8. Open UDP Services List (QualysGuard PCI)

Similar to the TCP list, but this time the UDP list.

3.9. Firewall Detected (QualysGuard PCI)

THREAT:
A packet filtering device protecting this IP was detected. This is likely to be a firewall or a router using access control lists (ACLs).
RESULT:
Some of the ports filtered by the firewall are: 135, 139, 1028, 1080, 3128, 8080

MY COMMENTS:

This is a good thing, right?

3.10. Host Names Found (QualysGuard PCI)

THREAT:
The following host names were discovered for this computer using various methods such as DNS look up, NetBIOS query, and SQL server name
query.
RESULT:
Host Name Source
ip-68-178-172-38.ip.secureserver.net FQDN

MY COMMENTS:

That’s right, I never did supply my domain name, only IP. So, QUALYS NEVER DID DISCOVER modphp.org. I SEE THIS AS A MAJOR FLAW in QualysGuard PCI. I could easily setup my server to respond with a blank dummy page as the default VirtualHost. Since it didn’t find my VirtualHost, it would skip all the web site checks. For example, the plain text form check could not be done, if it could not find the form without the actual hostname. QualysGuard PCI should ask me for a list of hostnames that resolve to the IP.

3.11. Host Scan Time (QualysGuard PCI)

THREAT:
The Host Scan Time is the period of time it takes the scanning engine to perform the vulnerability assessment of a single target host. The Host Scan
Time for this host is reported in the Result section below.
The Host Scan Time does not have a direct correlation to the Duration time as displayed in the Report Summary section of a scan results report. The
Duration is the period of time it takes the service to perform a scan task. The Duration includes the time it takes the service to scan all hosts, which
may involve parallel scanning. It also includes the time it takes for a scanner appliance to pick up the scan task and transfer the results back to the
service’s Secure Operating Center. Further, when a scan task is distributed across multiple scanners, the Duration includes the time it takes to
perform parallel host scanning on all scanners.
RESULT:
Scan duration: 1851 seconds
Start time: Tue, Mar 25 2008, 23:39:34 GMT
End time: Wed, Mar 26 2008, 00:10:25 GMT

MY COMMENTS:

Thanks, it’s nice to know how long it took.

---

4. Review of QualysGuard PCI

The report was very comprehensive, in fact, it reported on a heck of a lot more than is required for PCI compliance. The report clearly marks which items must be fixed to pass PCI compliance, and which are just for your information. I fixed every one I could, re-ran the compliance check, and still didn’t pass, because of a false positive on openssh vulnerability. I reported the false positive, and expect to receive feedback from Qualys within 1-2 business days. I assume they’ll agree with me, and then my report will show I am compliant. I update this report with definite statements after it plays out. Overall, I am very impressed with this product. What I liked is it gave me a full external vulnerability scan against my IP address. I downloaded the PDF report, which was easy to follow, although I could have used the Web UI to navigate through the problems.

I only have a few complaints.

• I was confused by the word THREAT in the Information section on items that were not actually THREATs, but this is an extremely minor template syntax oversight.
• It detected my OS as Linux-2.4.9, which was wrong.
• The Web UI should ask for my hostname(s), in case my web site is not the default VirtualHost.
• The guess at my uptime was way off. It guessed 6 days, I’ve been up 104 days.
• The mail server shouldn’t be marked open relay when it excepts mail for a domain that resolves to the ip of the server. Try sending email to a @qualys.com email, you’ll see it’s not an open relay.
• SSH-2.0-OpenSSH_4.3 is right, more specifically, openssh-4.3p2-24.el5 – this is not vulernable to RHBA-2007-0462 as listed. False positive, boo.
• Some items are a little light on remediation help. They give you a half assed solution, like contact your software vendor and ask them to fix it. This was for non-https login form. See above for my fix, which could be added to your recommendations. May help someone else.
• My SSL cert is signed by “Starfield Secure Certification Authority” -a subsidiary of Go Daddy. All browsers I use don’t complain. You should add it to your list of trusted certs.

And a few thanks:

• Didn’t realize my .htaccess file was public! Thanks for pointing it out.
• I realized my admin login form was available both http and https, but feel better now that it’s only https. Thanks making the point, even though I should have known better.
• TCP Sequence Number Approx – thanks, I wasn’t aware of this before. I’ll ask a few network gurus about this. Even though you supplied a good amount of information, I was still not clear. I think because it’s network level, I’m struggling with it.
• autocomplete=”off” – you know, I just assumed Joomla would take care of that for me. WRONG. It’s interesting that the software vendors are not super in tune with PCI compliance standards. Granted Joomla isn’t an e-commerce package, but there are plugins to make it such. Thanks for pointing this out, I feel better now that I have this in my site.
• Disable TRACE – another one I’ve heard of before, but hadn’t bothered on this server. Thanks for making me!
• I like my web directories listable, it’s convenient for me. But, ok, considered a vulnerability. I still think it’s ok, but only for select directories. It should be off by default, and only turned on in certain places. I am going to convert to this method soon. To be honest, I cheated in this case, and only disabled INDEX in the directory you’re looking in. This is going to be a false negative. At least I pass. Thanks, though.

---

5. Vulnerabilities Found (Comodo HackerGuardian)

Um, none found. I passed. See the report. It’s very bare, just says I pass.

---

6. Review of Comodo HackerGuardian

I was impressed with the level of personal security wrapped around giving me an account. I signed up for the free trial, but had to call and explain my life story to get them to enable it for a scan. They are very careful not to allow you to just scan any IP you want.

I was terribly distressed by the complete lack of detection of any problems on my site. I ran it under the exact same conditions as the QualysGuard PCI scan. I had not fixed any of the problems. When Comodo’s HackerGuardian came back with a “no problems found” report, I realized it’s not doing a comprehensive vulnerability scan. In fact, I’m not sure what it looked for at all.

---

7. Conclusion

I ran the QualysGuard PCI scan first. If found 11 vulnerabilties, 2 possibles and had 11 informational items. QualysGuard PCI made me remediate a few items, and gave me many more to think about. QualysGuard PCI is great, if you want to stay on top of potential vulnerabilities on your site/server. Comodo’s HackerGuardian is great if you want a passing grade, even if you have glaring vulnerabilities. For some people, this is exactly what they want. HackerGuardian costs a heck of a lot less ($80/yr, compared to QualysGuard PCI at $495/yr). Perfect if you want the fastest, cheapest route to compliance, regardless of whether you have anything wrong or not (do you really want to be this guy?). I would worry that Comodo might lose its ASV status, if it doesn’t figure out how to improve its detection methods. QualysGuard PCI will submit your results to qualified banks for you. I believe you can set it up on a schedule, so as long as you pass, Qualys will automatically submit your scan results quarterly. With Comodo HackerGuardian, you must download your results and give to your bank yourself. You have to remember to do this manually every quarter. I’d say it’s worth doing manually for a $400 annual savings, but I cannot recommend Comodo’s HackerGuardian due to its lack of vulnerability detection.

Hands down winner: QualysGuard PCI

Dave K.