Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


I just got hacked! The hacker injected code into my website files on my server.

Server: Debian Lenny, Apache 2.2, PHP 5.2, MySQL 5


Apparently my question wasn't deemed good enhough for some so I will try again. I apologize if I appear to be a total noob.

What have I done so far:

  • used chkrootkit, rkhunter - no problems detected
  • Bad PHP files with permission 777 was targeted, and they are being fixed.

As for the other thread about hacked server I read it. Unfortunately it doesn't quite help me answer this question:

But here is one thing that I need some help to understand. I got some files/directories that have 755 permission but the owner is www-data:www-data. Some of these files has ben compromised too. My naive thought was that set the owner and permissions like that prevented direct upload/altering files by hackers but allowing users to upload files via a script protected by a password (.htpasswd outside of web root)

Do you know what I need to do instead?

share|improve this question
Have a look at the excellent answers to this question. – Iain Mar 28 '11 at 10:21
Posting a bit of JavaScript is of absolutely no value. How about posting something relevant, such as what you have checked so far, what you've found in the logs, etc., etc., etc. – John Gardeniers Mar 28 '11 at 11:18
I hope you're not the sysadmin of the recently compromised – Tom O'Connor Mar 28 '11 at 12:32
up vote 3 down vote accepted

If you're interested in analyzing what happened, you take the server off the network and make a forensic image of the drive volume to a separate, preferably external hard disk. Then you wipe the drive and restore from a known good backup.

If you don't have a known-good backup, you recreate it from scratch.

Then you apply all updates and security fixes. Then you work on setting up a file monitoring program that works like Tripwire, where your files are checksummed and you store the check files on a separate disc/disk for comparison.

Then you can try to figure out how the attacker got in. Weak passwords? Unnecessary services? SQL injection? Plug the holes. Update your file monitor.

Set up logging to a separate machine so logs are copied and can be compared for tampering-checking.

You cannot trust a machine once it has been compromised. You have no guarantee that the binaries aren't hiding things that are running in the background. You need to take it offline and restore from a pre-compromised state and bring it up to a point where you fix the holes or at least have it create a trail to follow if it's compromised, but you cannot trust system binaries in the system if the attacker may have gained root access.

share|improve this answer
+1, Nuke it from orbit and restore from backup. – Chris S Mar 28 '11 at 12:35
I get it. Re-install. But still... What is the proper way to secure directories where users uploads files. Assuming that the script is secure, would chown www-data:www-data + 755 permission be good enhough? If I don't find the problem I will get the problem again. – Cudos Mar 28 '11 at 12:56
@Cudos if you want permission level "jailing" you will need to look at mod_suexec or suPHP (switches to the owner of the file for execution) you can then look at using Folder perms 700 and php perms 600, HOWEVER I must stress this will only jail the application within it's own folder if server wide permissions are correct, and will not defend against an in application vulnerability. – Oneiroi Mar 28 '11 at 13:12

Unfortunately, even if you manage to find the offending IP address, this is very unlikely to lead you to the attacker. The attack will almost certainly have come from another compromised machine.

Your machine could feasibly have been hacked by any of the open services on your machine. Start by checking the services that have listening ports open. e.g.:

  1. FTP
  2. SSH
  3. Apache itself
  4. MySQL?

Check the logs of each of these services to see if there's anything unusual there.

In my experience, the vast majority of these hacks are facilitated by:

  1. FTP credentials compromised - often via a trojan on a client machine that has access. - either by key-logging, or compromising a password cache.
  2. Old version of a popular PHP script that is insecure, coupled with loose file permissions for the user context of the website.
share|improve this answer
I think the question relates more to how the attacker got access, not from where or who he is. This is much more important because you have to fix the hole that allowed the access in the first place. – Sven Mar 28 '11 at 10:19
Fair enough - the question's possibly slightly ambiguous, but I see what you mean on a re-read. I've added extra info. – Steve Mayne Mar 28 '11 at 10:21

I'm a fan of AIDE but that's not going to help after the fact unfortunately.

Apache error.logs are a good place to start.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.