My Server (Deb5 and Plesk10) is involved (causing) in brute force attacks
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
MartinM: would you please tar up the /usr/games/go directory and mail them to hangdog if he does not have a problem with that.
Hangdog: would you please forward the other stuff he sent to the group also. If you don't have a problem receiving the other files also forward those as well. There may be some useful info in there to help track this down and maybe something useful for future detection and maybe some info useful for Rkhunter. If you do not feel comfortable receiving the files just say so and I will get in contact with him to forward and see what is going on.
That would be great, but MartinM, please run the below command and post the output first or you will overwrite the last access timestamps.
ls -altuh /usr/games/go/backdor
That will tell if the file was accessed and one possibility of that happening is it was executed. Definitely other ways to tell when the rootkit was installed as well such as reading the setup script and looking at timestamps from new or modified files, but we might as well collect all the evidence we can, while we can.
Goodmorning, I'm back behind the Mac, as you can see
I have made a tar (I hope ) by using this:
Code:
mmn001:/usr# tar cvzf games_go.tgz games
If that's correct, I will send it to hangdog asap.
Underneath are the results (from before making the tar) of the info-requests by OlRoy and slimm609:
Quote:
Originally Posted by OlRoy
That would be great, but MartinM, please run the below command and post the output first or you will overwrite the last access timestamps.
ls -altuh /usr/games/go/backdor
That will tell if the file was accessed and one possibility of that happening is it was executed. Definitely other ways to tell when the rootkit was installed as well such as reading the setup script and looking at timestamps from new or modified files, but we might as well collect all the evidence we can, while we can.
Code:
mmn001:/# ls -altuh /usr/games/go/backdor
total 596K
drwxr-xr-x 2 sw-cp-server 1000 4.0K May 7 09:28 .
drwxr-xr-x 3 root root 4.0K May 7 00:25 ..
-rwxr-xr-x 1 sw-cp-server 1000 25K May 5 01:32 setup
-rwxr-xr-x 1 sw-cp-server 1000 491K May 5 01:32 bin.tgz
-rwxr-xr-x 1 sw-cp-server 1000 442 May 5 01:32 conf.tgz
-rwxr-xr-x 1 sw-cp-server 1000 29K May 5 01:32 lib.tgz
-rwxr-xr-x 1 sw-cp-server 1000 25K May 5 01:32 setup~
mmn001:/#
Quote:
Originally Posted by slimm609
ls -altuhR /usr/games/go to capture all the directories recursively.
Code:
mmn001:/# ls -altuh /usr/games/go/backdor
total 596K
drwxr-xr-x 2 sw-cp-server 1000 4.0K May 7 09:28 .
drwxr-xr-x 3 root root 4.0K May 7 00:25 ..
-rwxr-xr-x 1 sw-cp-server 1000 25K May 5 01:32 setup
-rwxr-xr-x 1 sw-cp-server 1000 491K May 5 01:32 bin.tgz
-rwxr-xr-x 1 sw-cp-server 1000 442 May 5 01:32 conf.tgz
-rwxr-xr-x 1 sw-cp-server 1000 29K May 5 01:32 lib.tgz
-rwxr-xr-x 1 sw-cp-server 1000 25K May 5 01:32 setup~
mmn001:/# ls -altuhR /usr/games/go
/usr/games/go:
total 2.5M
drwxr-xr-x 3 root root 4.0K May 7 09:30 .
drwxr-xr-x 2 sw-cp-server 1000 4.0K May 7 09:28 backdor
drwxr-xr-x 3 root root 4.0K May 7 00:25 ..
-rwxr-xr-x 1 root root 838 May 6 23:48 1
-rwxr-xr-x 1 root root 956 May 6 23:48 10
-rwxr-xr-x 1 root root 782 May 6 23:48 2
-rwxr-xr-x 1 root root 889 May 6 23:48 3
-rwxr-xr-x 1 root root 898 May 6 23:48 4
-rwxr-xr-x 1 root root 836 May 6 23:48 5
-rwxr-xr-x 1 root root 808 May 6 23:48 6
-rwxr-xr-x 1 root root 897 May 6 23:48 7
-rwxr-xr-x 1 root root 846 May 6 23:48 8
-rwxr-xr-x 1 root root 845 May 6 23:48 9
-rwxr-xr-x 1 root root 1.4K May 6 23:48 a
-rwxr-xr-x 1 root root 22K May 6 23:48 common
-rwxr-xr-x 1 root root 265 May 6 23:48 gen-pass.sh
-rwxr-xr-x 1 root root 94 May 6 23:48 go
-rwxr-xr-x 1 root root 1001 May 6 23:48 go.sh
-rw-r--r-- 1 root root 1.1M May 6 23:48 mfu.txt
-rw-r--r-- 1 root root 8.4K May 6 23:48 pass_file
-rwxr-xr-x 1 root root 21K May 6 23:48 pscan2
-rwxr-xr-x 1 root root 6.4K May 6 23:48 scam
-rwxr-xr-x 1 root root 197 May 6 23:48 secure
-rwxr-xr-x 1 root root 444K May 6 23:48 ss
-rwxr-xr-x 1 root root 823K May 6 23:48 ssh-scan
-rw-r--r-- 1 root root 20K May 6 23:48 vuln.txt
/usr/games/go/backdor:
total 596K
drwxr-xr-x 2 sw-cp-server 1000 4.0K May 7 09:30 .
drwxr-xr-x 3 root root 4.0K May 7 09:30 ..
-rwxr-xr-x 1 sw-cp-server 1000 25K May 5 01:32 setup
-rwxr-xr-x 1 sw-cp-server 1000 491K May 5 01:32 bin.tgz
-rwxr-xr-x 1 sw-cp-server 1000 442 May 5 01:32 conf.tgz
-rwxr-xr-x 1 sw-cp-server 1000 29K May 5 01:32 lib.tgz
-rwxr-xr-x 1 sw-cp-server 1000 25K May 5 01:32 setup~
mmn001:/#
Last edited by MartinM; 05-07-2011 at 02:48 AM.
Reason: Addition
The above will apparently give you the Plesk version. It seems you were running FTP, and there was a Plesk/ProFTPD vulnerability here. Again, your logs are going to be your best shot at determining how this happened. Grep your logs for signs of a successful password guessing attack by searching for accepted password for root and also examine the logs for signs Plesk was exploited.
mmn001:/# dpkg -l psa
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==================================-==================================-====================================================================================
ii psa 10.1.1-debian5.0.build1010110120.1 Parallels Panel v10.1.1 core files
mmn001:/#
Afaik I was aware of the ProFTPD vulnerability and patched that the day after the patch was released. This was in Q4 2010.
In regards to the possible cause of this all and the questions about how the intruder entered, it is highly probable that it was simply a brute force on my ssh password.
The server had a complete reinstall 2 months ago and was "delivered" to me with a simple password, 8 positions, 3 letters - 1 number - 1 sign - 3 capitals, which according to KeePass is a 64bit password.
I think it is definitely my own fault that I have not changed that immediately, I only did this after receiving the first report of my server being involved in brute-forcing others. Once I received that report, I changed it to a 200bit password. But I think it is pretty clear to me now that this was too little, too late
Were you getting the Micro Updates for Plesk? Even if you were, you were running a number of other services.
Sounds like a fairly secure password, but I can't say for sure because I don't know how random it is. I don't even know if there was an SSH password guessing attack against your computer, let alone if it was successful. I don't have the logs and any data to go on.
The below should let you check for unauthorized root logins from computers you don't know. You can also pipe it into another grep to filter out IPs you know.
You can find run same kind of grep searches through compressed logs, for example:
Code:
zcat messages.2.gz | grep -P '^Apr\s+28'
These commands mostly just cover SSH. I've written perl scripts to summarize and graph SSH logs, but don't have your logs. It's difficult to teach someone how to do log analysis for the first time with the CLI, when they aren't familiar with the CLI or log analysis.
it is highly probable that it was simply a brute force on my ssh password.
Not to discount your theory about passwords, but OlRoy noticed something that has been bugging me too, namely that the /etc/games/go/backdoor directory and files are owned by sw-cp-server, and not by root. If I understand this user correctly, that is the Plesk user, which raises the possibility that they compromised Plesk to gain access. I'm simply not familiar with Plesk so hopefully someone who is will chime in a bit.
That said, I think the general consensus is that the log files from around April 28th are going to be the next best bet for good information on what happened.
the tar with the complete contents of the directory and the complete log-files are available to Hangdog42 now, he knows where to find them .
I don't mind if he shares them to speed up pinpointing the cause of all this trouble.
Would it be sensible to say that this current server-setup is a no-go for the future and I will need to get a reinstall for sure?
And in that case, since I do have people waiting for me, would downloading everything necessary for restoring their domains be a solution to speed things up in that regard (of course after safeguarding everything else which is needed to track down this attack).
The attacker has had root for some time now and evidence suggests a rootkit was more than likely installed. I'd definitely say you're going need to reinstall, hopefully after someone finds evidence of how the attacker got in.. So sure, you can plan for reinstalling until Hangdog42 or someone can check out the logs you sent him.
In the mean time, if you have the time, you can post the output of:
Code:
ls -altuhR /usr/games
ls -althR /usr/games
ls -altchR /usr/games
You can also check out the contents of /root since the attacker was apparently in that directory at some point and may of created files there. Speaking of which, the below command should help find files changed around April 28th.
The setup script for the rootkit is a gold mine since it will show how it was installed or what it did, and the config file(s) will tell you what the attacker wanted to hide.
Doing the above will most likely just help you figure out what the attacker did. Which can be helpful, but probably won't tell you how they got in. That part will most likely come from log analysis.
Would it be sensible to say that this current server-setup is a no-go for the future and I will need to get a reinstall for sure?
There is no doubt that the intruder gained root and has endeavoured to cover their tracks. I note the "HISTFILE=/dev/null" option in PID 4269 as well as the files in /usr/games/go/backdor which probably contain hacked binaries of system files (although the file dates suggest they are old).
It becomes a judgment call on the skill of the intruder and their intent. You may simply be able to replace any hacked system binaries with known good versions.
I note that there are more exploit modules in the contents of /usr/games/go than were logged in third example here http://blog.macuyiko.com/2011/03/run...ippo-lets.html
This could be interpreted as the intruder having access to recent exploits and so a high level of knowledge.
To be sure, you reinstall. You have no other way of being certain that all traces of the intrusion have been removed.
There is still the question of how your system was exploited. Two obvious options are:
1. Brute force SSH password attack.
2. A ProFTPD exploit, which may explain the curious Plesk username.
You can close the door to the first, but if the second then a reinstall will leave you vulnerable to a repeat incursion.
Not sure why the find command didn't return anything. It works fine for me. Maybe you could try changing the -ctime 10 to -ctime 9 But I would think find would of returned *something* if it was working properly. Someone else might know what is wrong.
The /usr/games/banner is a new file we missed earlier. You can type:
Code:
file /usr/games/banner
If it's a shell script or text file you can post the contents with
Code:
cat /usr/games/banner
You may get lucky and find a file .gz .jpg or some other suspicious file that contained an archive of all the files in the /usr/games directory with this command.
Code:
ls -altuh /usr
If you do, you could google for that file name and who knows, you might find someone else who is dealing with the same attacker(s) on some other forum.
Sometimes you can get an idea for what a program does by its strings. Unfortunately it won't work well if the binary is packed, and sometimes an attacker will insert bogus strings to through off a malware analyst.
Code:
strings -a /usr/games/banner
You could also submit the file to a site like www.virustotal.com, but you'd have to be very careful you don't somehow run the malware.
The above is just a couple of very easy things to do and is a an extremely small part of malware analysis; a field I'm still learning and it's mostly with Windows malware.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.