Website compromises - what's happening?

Published: 2009-08-18
Last Updated: 2009-08-18 15:20:57 UTC
by Deborah Hale (Version: 1)
6 comment(s)

Recently there seems to have been a lot of activity with websites getting hacked.  Folks are getting really frustrated and are looking for answers to what is causing the problems and what they can do to protect their sites from compromise.

Unfortunately I am not a web development expert.  We do have Handlers that are...  I just don't happen to be one of them.  My expertise with websites is hosting them and protecting the servers that we host our customers sites on.  I monitor activity on our servers and check log files daily for any unusual activity or attempts to hack our customers sites or attempts to hack into our servers.  The last few weeks we have had an increase in the attempts to access our servers (brute force).  As soon as these attempts are flagged they are added to the blocklist for our network.  It is incredible to me how many IP's I have had blocklisted (blocked) in a short amount of time.  

We had two customers domains get wacked.  In both cases the index.html file was replaced with a modified file that contained a hidden link to .ru websites.  In both cases these "alterations" were found to be the result of a Gumblar type infection on the customers PC that is used to do the upload of the website to our server.  It appears in both cases that it was a Gumblar type infection, however instead of the typical Gumblar that we saw back in the May 2009 timeframe - the domains involved were a couple of .ru domains.  Perhaps just shifting resources a little or perhaps a new strain of an old bad guy. In investigating the infection in the two domains involved, I came across a really good article explaining what Gumblar was all about.

The initial infections were both discovered over the weekend so I was unable to contact the customers immediately to let them know what was going on.  In both cases I disabled the index.html files and changed the passwords on the ftp accounts on the domains.  In both cases for several days afterwords I saw many attempts to login to the ftp accounts with incorrect passwords from multiple China IP addresses.  

This was an interesting exercise in web security for me.  My assumption was that the server itself was lacking in security.  I therefore worked very hard after taking this position to make sure that our webhosting servers were secured to the best of my ability and I aggressively monitor these servers to make sure that they continue to be secure.  Now I know, no matter how secure your hosting company tries to make your domains it may be your own internal lack of security practices that are putting your domains in jeopardy.

So my question to our readers is:

What are you doing to protect your webpages? 

We have had novice webpage developers in the past ask us what they can do to protect the security of their webpage.  Unfortunately we see that anyone now can create a webpage.  It doesn't take any special education or skills to create a webpage as we have witnessed by looking at the social networking sites. In these sites anyone (maybe even a monkey)  can create their own webpages. ( We have seen how secure that is). So what are your recommendations?

I would like to hear from you.  Please let me know if I can include your information in the diary. I will publish a list of the good tips that I get from you our readers.


Deb Hale Long Lines, LLC

6 comment(s)


I host 30 domains on my server and all sites run with RavenNuke protected by NukeSentinel. Have not had a successful attack in over two years now. Every day there are dozens of attempts but no success.
FTP-based defacements have been discussed in quite some detail over at the cPanel forums, and it would seem that the consensus suggestions are:

1) Move to enforced FTPS or FTPES. Several hosts who have made this change report that they have had no further defacements.

2) Start piping all FTP uploads through ClamAV or similar. I have found that often if a page has been defaced, a quick "clamdscan *" in the directory reports that the files are infected from the URL which has been injected (depending on ClamAV config and definitions), so why not scan them as they are uploaded? Obviously as this can be CPU-intensive feasibility has to be assessed on an individual basis, however it works well for us. There are several guides out there on how to configure popular FTP servers with an AV engine.
Dasient just released a new free web-monitoring tool that scans your website and checks if it is infected. If it is, it blocks it to protect the end-user. It might be worth to give it a try.
We run suphp along with suhosin and mod-security. Along with tight directory permissions, this helps quite a bit.

Lately some AVs seem to have problem detecting all obfuscated iframe virus attacks.
Re Dasient product mentioned by styx, the blacklist monitoring is free, the malware scan is $49 a month up to 1000 pages (presumably per scan), anything above 1000 you have to get a quote.
Re Dasient I need to add that the blacklist monitoring and malware scanning are both described as public beta whereas the next level up, quarantining, is limited private beta and no pricing details are provided.

Diary Archives