10-19-2010, 10:00 PM
I recently had a site hacked with a .js file injected into the code. I removed the offending code but now the website opens sooo slowly. If the apache server is restarted the website opens perfectly but after a few hours it returns to being veeerrrrrrrrrry slow again. I did a reverse dns lookup and the other sites on the server don't suffer this speed issue suggesting its not a DoS attack. Any ideas of how I get my site working fast again. It's a CMS built using expressionengine.
First port of call is to take a look at the logs (in particular the error logs) and see if they shed any light on the issue. The injection of a rogue .js file (presumably through some XSS attack) would effect only client side and should not slow the server down par se. On the other hand, a large number of requests for it that don't close the connection may do just that.
It may be that you are a victim of a simple reflected attack where miscreants have steered traffic to your site looking for that xss .js file (look in the (error) logs for anything calling <whateva>.js and now getting a 404 not found to confirm this scenario)
OR..... Perhaps you have a rogue shell on the box, which can be a real PITA. On the plus side, any 'hacker' who has infiltrated your site and made it noticeably slow has done a very bad job which, one would hope, would be pretty straightforward to resolve.
I'd probably make a note of the time when it is notably slow and look through the access and error logs paying attention to that time slot. A common trick is to put a backdoor or shell on the box by replacing a relatively unvisited file such as some trivial 'about' or language/notes file.
Apache - despite its stability - is easy to hang if an instance gets too many requests that don't close. There is a common attack against Apache servers called 'slow loris' that makes use of this fact and can, quite literally, take a server down with very little bandwidth. If you have a reasonable number of requests for a missing file that don't close the connection, you can get a similar issue in some circumstances and I'd not be surprised to see a slowing on that particular fork/instance of Apache running the given virtual host.
After all that long winded guff the keys to this are logs, logs and logs as your starter for ten. Pay attention to requests for what is *not* there or should not be being called with frequency + blocks of repeat IP addresses over and over that don't seem to fit with the normal 'flow' of a visitor.
10-20-2010, 10:13 PM
Thanks very much for taking the time to give such a comprehensive answer. I will look thru the logs and see whats up.
Thanks again. Much appreciated! :)