Nonsense! He isn't running Windows Server if you haven't noticed yet.

lexthoonen, if you can trace every wrong-doing that happened on your server and rule out all entry points, you don't need to reinstall. Even if you reinstall, what hopes do you have that reinstalling will prevent future break-ins?

Here's a tip: test your server's security by using a penetration test tool like Screamix. There are dozen tools out there which I'm sure are no more better or slightly better than the other. Running a server is not a simple thing so get to work .

Good luck.

Re-installation after a breach is always the best route no matter WHAT OS you are running. The fact that it's a Linux box rather than a Windows box is really meaningless once it's been breached.

Do you have hashes of every file on the box so you can verify they are all the correct files ? if not I don't see how you can be 100% certain the system is clean. if you were running tripwire, AIDE or something similar you would be able to tell exactly what files, if any, have been altered. if not you are really just guessing.

When it comes to a server being breached you have no way of telling what has been changed. They could change system binaries such as ps so that when you run it you can't see other processes they have running hidden on the server. Nothing like trying to track down a breach using tools that have been tampered with.

I'm sorry but telling someone to not bother reloading a server that has been breached, is not only bad advice, but bad security practice imho.

better u scan your server with the help of a nessus scanner and identify the vulnerabilities.

You probably should make an image of the system to preserve the evidence. Then reinstall. In the very least, make a copy of the log files, config files and code. There may be clues you won't find at first.

I'm not an expert however, but a little voice keeps saying "remote file inclusion".

Audit the php code that use include statements.

Even if remote file inclusion isn't possible, what about local file inclusion?
The cracker could have used local file inclusion to read files such as /etc/passwd for example to learn usernames, which would make a brute force attack easier.

Also read the security section of the MySQL manual.

You can use Google code search to locate vulnerabilities in the cms scripts.

Good Luck!

Unless you've done the work necessary to figure out if they got root access (or not) this could just be putting a small speedbump in their way. That's the problem with security breaches, unless you have the system set up beforehand to identify changed files (something like Aide or Samhain) you're doing a lot of guesswork as to what has, or has not, been changed. And one of the issues with being cracked is that the crackers will replace basic system binaries with new ones that don't show what they are truly up to. You've certainly found something. The question is, did you find EVERYTHING. If you haven't, then you still have a compromised machine and now the crackers know they've been spotted.

At very least, you're looking at a full system re-install as other have suggested.

Tbh, it's easier to find tampering when it comes to stuff like this in Windows, although Windows should be reloaded also.

Farslayer speaks the truth...

I agree that reinstalls should happen after a system compromise, but only AFTER it is understood how the mahcine got compromised in the first place. I've seen several people reinstall only to immediately get compromised again. Sometimes its an app that they repeatedly install that's the culprit. Other times it is something the admin did that caused the hole.

Reinstalls aren't the solution. It is only the way to start from scratch after a root cause has been discovered, though.

I'm sorry that I don't completely agree with that. IMHO, reinstalling a security breached server is not the first thing to do on the way of reinstalling security. It should be the last thing to do if you don't succeed. That's why you keep backups and run instrusion detection systems. Alas, his case could be more serious.

Let me preface this with saying, I do not consider myself a security expert in any way.

Yes you keep backups of your data, but I don't know many people that back up entire systems. At least not if you manage more than one system. The cost of housing all this data would be unneeded. Not to mention, lets hope your backups haven't been compromised.

IDS's aren't as great as some people think. They are good, and important; but that being said, they are not the be all end all. If binary's have been recompiled to phone home, in a certain way, most IDS implementations won't alert you. Now if your machine was then trying to attack/scan other nodes, this is where IDS's come into play.

So yes, reloading the OS is the last thing you do, after you have discovered the break in, fixed said break in, and have documented it so it doesn't happen again. THEN we reload the OS.

Well I haven't had (more) trouble sofar, but how does one, well, I in this case, really find out about the break in. I mean, I'm not a security expert (one might have guessed ), nor a linux expert. I'm certainly not a hacker (although I've learned some cheap tricks these days).

To *really* find the break in actually means breaking in myself on the same spot just to prove it was there, doesn't it?

As shown earlier in this thread, they don't really log on, it seems they've done all via the php scripts they've somehow managed to upload. But with the c99and r57 scripts they can tell a lot about a system and users. Not everything though, luckily. The rights they get are apache rights.

I don't understand. How big can a dedicated server be when it comes to the binaries it runs, ie., excluding custom content?

It hardly goes beyond 500MB for a simple server, or 1-2GB for something gradually more complex.

Is that too much data to backup? Is it? Even if you keep compressed backups? Really?

That said. I'm leaving this thread.

In short, no. To find out how they broke in, you need to do the analytical work. In my first post I linked to the CERT checklist. I suggested that because it is a good place to start, particularly if you don't know where to start.

I think a better statement is that the rights they started with were apache rights. Unless you've done more than you're posting, you don't know if they ever managed to escalate to root or not. Have you checked any system binaries to see if they've been compromised? I'm certainly no security expert but what I have learned from following a number of threads here is that there is no substitute for facts. And unfortunately in this thread there are precious few of those.