One of my client's websites came under attack last week. From what I've been able to work out, it appears that they were using a script to bombard the bookings page on an accommodation website. This meant a load of fake bookings and emails generated by the form. I've put a few extra measures in place including a stronger captcha which seems to have stopped the problem.
However, the bandwidth figures for the site have gone through the roof since the attack started and are causing me major problems to keep the site up without running out of what I'm allowed by my hosting account. I'm assuming that their script is still calling the page every 5 mins or so, as the logs showed, and even though they're not causing the same levels of problems as last week, I'd really like to know what I can do to stop them from eating up my bandwidth. There's a lot of photography on the site so any page call is going to use up quite a lot of bandwidth.
I do know that they are changing IP address after every 5 or so calls. There is no sign of them on Analytics so am assuming that they are accessing by script rather than actually visiting the site.
Not 100% my area of expertise and any thoughts or suggestions would be hugely appreciated.
In order to prevent this you need something external to your hoster (or the help of your hoster) to block traffic otherwise you will still get high bills. You can try and limit the amount of resources you send out to those clients but the amount of traffic that goes in mainly depends on them and there is not much you can do from your application or web server.
The way I am used to handling these cases to adding a layer of protection that can filter out automated traffic but allow real humans to visit the site.
As eldad suggests, try to find out which IP addresses are generating this (non-human) traffic, and ask your host to block them.
Alternatively, you could try adding some rules to your .htaccess file to send a 403 (forbidden) error to those ips.
But you'll need to be very sure you're only blocking addresses that are causing bad traffic - that'll be the hard part.
Firstly apologies for the slow reply.
Some very useful suggestions above. Since posting, the problem has not surprisingly continued and I have had to upgrade my hosting account to ensure I have enough bandwidth to keep this and my other sites up.
IP blocking isn't going to work as the error logs I have suggest they only use the same IP about 5 times then move on so they appear to be using proxy servers.
I like the idea of using jquery to add the photos. The other idea I've had is to encrypt some kind of hash key with the current day's date and pop that in some obscurely name session variable. I'd do this on all the legitimate pages of the site but not on the problem page. On that page, I'd check for the legitimate session item and only show the page if that is there and correct. I'm guessing this might mean losing this page from the Google Index but think I'd prefer this than to continue as is.
Any thoughts on this as a possible solution to throw in?
Seems a reasonable idea.
Another option is to consider something like cloudflare, though not sure whether its free level would have sufficient functionality, and I guess having upgraded hosting you'd not want an additional expense.
I've not heard of cloudfare but will have a look into it. Appreciate the feedback. I've also realised I may have missed the most straightforward option. If the hacker has left a script running and might not even be paying much attention now he's had his fun, I'm wondering whether just renaming the page do the job!
More than happy to answer any questions about CloudFlare. If you do decide to try CloudFlare, however, it is very important that you install [mod_cloudflare so original visitor IPs are getting passed back to your server. Since we act as a reverse proxy for sites, our IPs are going to show unless you install this (I'm bringing this up because you most certainly don't want to have any rules blocking requests from our [URL="https://www.cloudflare.com/ips"]CloudFlare IPs](http://www.cloudflare.com/wiki/Log_Files)).