I’ve been seeing those ‘Hacker Safe’ logos on sites for a while now.  As a consumer I’ve always figured that they are kindof a joke, and that sites that display them really aren’t any more secure than any other site.  I’ve recently had some experience with being able to log into a ScanAlert account and seeing what kind of things they actually do.

Overall, they do the basic kinds of things like telling you what ports are open – stuff that the system administrator should already know and would just take a minute with nmap to find out.  They also check the banners for each service to tell you what version you are running.  It produces warning if you are using software that is more than a couple months old. You can alert and give warnings to other people.

What I found the most useful though, was its attempts to look for SQL Injection and XSS vulnerabilities.   From their FAQ:

ScanAlert audits every publicly available part of the domains Web application. This includes all HTTP services, configuration files, and any scripts (CGI, PHP, etc.). ScanAlert submits all database query parameters for vulnerabilities such as SQL injections and cross-site scripting. Since attacks along these vectors vary, ScanAlert must test each query parameter multiple times.

The website that I was looking at had an XSS vulnerability, and it goes into detail about what request parameters were used and everything to create it.   That is pretty useful information to have so that you can look into those pages and get them fixed.  It would take a while for me to go through every page and verify that I’m properly sanitizing user input everywhere.

However, with the site that this was scanning, I’m almost positive that there are really more XSS vulnerabilities than ScanAlert alerted me to.  I basically provided a place to start looking, but is certainly not an exhaustive test.    Moreover, the XSS vulnerabilities were scored only as a ‘Medium Risk’ – A 2 on a scale of 1 to 5 (1 being information disclosure like a robots.txt file, 5 being something really bad like hosting a virus or something).

I’m not sure at what point ScanAlert decides that a vulnerability is bad enough to not display their ‘Hacker Safe’ logo on a site.   Evidently it is higher than a 2 though, because this site still qualified for one.   So, ScanAlert is useful to system administrators and programmers to help identify threats.  It’s only useful though if the website owner actually does something about them.

I had several ‘Medium Risk’ vulnerabilities due to running slightly outdated versions of Apache and PHP.   Both were compiled from source and newer than what was available in the distro’s repositories, so I got them recompiled with the latest stable versions.   I doubt that most sites bother to resolve these issues since it takes a significant amount of work and doesn’t affect the ability to have that all-important ‘Hacker Safe’ banner on your site.

I still have the same opinion of it as a consumer though – basically that the website doesn’t have some blatant vulnerability that is easily exploitable.   There are so many other ways that attackers can gain access to information though, that having a little logo on your site doesn’t instill any confidence in me.

Plesk’s integration with Apache can be quite confusing for those used to manually modifying the Apache configuration files. It isn’t safe to modify most of the files, because Plesk rewrites them whenever a configuration change is made. Here’s a quick overview of how Plesk fits in with Apache:

The main Apache configuration in /etc/httpd/conf/httpd.conf (or /etc/apache2/apache2.conf on Debian/Ubuntu systems) is left unchanged. It includes /etc/httpd/conf.d/* (or /etc/apache2/conf.d/*). Plesk creates a file in that directory where it does most of its global configuration. That file is generally used for system-wide applications like webmail, mailman, etc. This file is overwritten when certain changes are made via Plesk. It also has an “Include” line for each virtual host like this:

Include /var/www/vhosts/mydomain.com/conf/httpd.include

These files contains the VirtualHost configuration for each domain. They also are overwritten whenever certain changes are made via Plesk (and sometimes just at random, it seems). When Plesk is recreating these files, it looks for a corrosponding ‘vhost.conf’ file in the same ‘conf’ directory. If it finds one, then the resulting httpd.include file Include’s that vhost.conf file. in it.

Therefore, if you want to manually make any changes to the Apache configuration for a website, you need to create a vhost.conf file for it, then re-save the domain’s configuration via plesk.

Also, if you’d like to bypass the whole plesk ordeal for a new domain, you can still create the Apache configuration manually in the original /etc/httpd/conf/httpd.conf file (or /etc/apache2/sites-available/* files).