linux server hacked!!!

Dear Sir/Madam,

Thank you for your comment.
In fact, I am running a server to virtual host some domains.
My server is hacked before, and then, i have used a new harddisk and install
Fedora core2, apache 1.3.33, php4.3.9
and now the hacker seems still try to attack me, and you can see the logs above.

I have some clients using xoops, phpBB, etc, php+MySQL applications.

So I have to solution to prevent it from hacking?
how can I stop it upload a rootshell?

do you know if those plesk, cpanel hosting systems can stop from hacking?
I am really need help for this, otherwise, my small biz may be destoryed, can anyone help?

Thank you.

Dear All,
Thank you for your help.
>If you still have the logs that should be pretty easy to do. On servers that I manage I always configure each site with its own error and access log, partly to make this sort of investigation easier.

How can I identify what pages? I have error_log, and xxx.com-error_log etc..
but which part I should know it is the point of entry?

At the same time, I am trying to add firewall (iptables) that we close unused ports and
only allow to ssh from an IP.
Do you think it is useless? the hacker must need to login and replace our index pages, or he even no need to login ssh?



Thank you.

Stanley

The access log will show what pages have been accessed from what IP and when. You already have the log of the upload of the root kit so correlating those will indicate where to look.

What you attacker appears to have done is to feed bogus GET or POST data to a vulnerable PHP page. That data caused the to misbehave and probably was used to upload a PHP page which the cracker used to upload, unpack and execute the root kit. That's the usual mechanism they use. I can't be certain in this case without doing a forensic analysis on the system (assuming the cracker didn't succeed in erasing the evidence), but it is a likely scenario.

> I am trying to add firewall (iptables) that we close unused ports and
> only allow to ssh from an IP. Do you think it is useless?
It's needed for security purpose. But this doesn't prevent the PHP upload attack
which is your situation now.

Wesly

Dear All,

So I think the most urgent action is to:
 safe mode  = on
register globals = off
file uploads= off

in php.ini, right?
Anything to add?

Thank you.

Stanley

That will help in that it will make it more difficult for a cracker, but won't necessarily prevent a cracker from penetrating the system if there is vulnerable PHP code. Be aware that each of those restrictions is going to break some of your client's PHP code.

Turning off Register Globals helps a bunch, but it will break every PHP code that uses data from a GET or POST unless the page has been specifically code to work in that environment.

When enabling safe mode be sure that you properly define the directory for safe mode code execution.

it seems the hacker can replace our index even which is of owner root.
so it means it can have root access and overwrite/delete all our files?


thank you.

Stanley

oops, forgot to mention that this is not a PHP problem, perl and all other languages have these problems too (PHP makes it just very, very simple to circumvent security;-)

> it seems the hacker can replace our index even which is of owner root
format the disk, or use a new one and reinstall everything from clean media, immediately!

I found the following logs today, what does it mean?

[Fri Dec 17 10:53:03 2004] [error] [client 218.103.125.237] File does not exist: /home/sites/htdocs/wpad.dat
sh: line 1: /usr/bin/sendmail: No such file or directory
sh: line 1: /usr/bin/sendmail: No such file or directory
sh: line 1: /usr/bin/sendmail: No such file or directory
sh: line 1: /usr/bin/sendmail: No such file or directory
[Fri Dec 17 11:08:03 2004] [error] [client 218.103.125.237] File does not exist: /home/sites/htdocs/wpad.dat
sh: line 1: /usr/bin/sendmail: No such file or directory
[Fri Dec 17 11:18:04 2004] [error] [client 81.52.217.8] File does not exist: /home/sites/htdocs/wpad.dat
[Fri Dec 17 11:23:03 2004] [error] [client 218.103.125.237] File does not exist: /home/sites/htdocs/wpad.dat
[Fri Dec 17 11:25:55 2004] [error] [client 81.52.217.8] File does not exist: /home/sites/htdocs/wpad.dat
[Fri Dec 17 11:38:03 2004] [error] [client 218.103.125.237] File does not exist: /home/sites/htdocs/wpad.dat
[Fri Dec 17 11:53:04 2004] [error] [client 218.103.125.237] File does not exist: /home/sites/htdocs/wpad.dat
[Fri Dec 17 12:08:04 2004] [error] [client 218.103.125.237] File does not exist: /home/sites/htdocs/wpad.dat
[Fri Dec 17 12:23:04 2004] [error] [client 218.103.125.237] File does not exist: /home/sites/htdocs/wpad.dat
[Fri Dec 17 12:28:56 2004] [error] [client 202.196.217.35] request failed: URI too long

And what is the following too?

[Fri Dec 17 12:25:26 2004] [notice] SIGHUP received.  Attempting to restart
PHP Warning:  Unknown(): Unable to load dynamic library './php_gd.dll' - ./php_gd.dll: cannot open shared object file: No such file or directory in Unknown on line 0
[Fri Dec 17 12:25:27 2004] [notice] Apache/1.3.33 (Unix) PHP/4.3.9 configured -- resuming normal operations
[Fri Dec 17 12:25:27 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec)
[Fri Dec 17 12:25:27 2004] [notice] Accept mutex: sysvsem (Default: sysvsem)


how to solve it?

Those are the same error message as your original post.
It looks like you didn't take your hacked server off line.

hmm, it does not help much :-(
You have to secure the web application! Data, or more particular: input validation is the keyword here.
Securing php, apache, filesystem or OS itself is just a second, third line of defense. The application is the culprit, always.

Still, most scanners look for software versions, and daemons with security flaws make easier targets worldwide - you don't really have to learn the business logic of the application of the server to which you are hacking.
If your daemons aren't updated, they make good/quick candidates for every port scanner on the net.

This is my opinion, let's see if it solves the problem...

why should I care about the web server type, hunt for specific flaws in there, if I've identified that the web application uses backticks somewhere, or passes each parameter throu to the database server, etc. etc.
Even 101% secure web server does not help, and we all know that security is always <100%

thank you experts.

I have re-installed the server, with a new Hard-disk,
and I have copied all clients application to the new server,
I have installed apache 1.3.33, php 4.3.10,
I have set
safe_mode = On
register_globals = On
file_uploads = Off

is it better to secure the server?

I check apache error log:
[Mon Dec 20 00:16:28 2004] [warn] child process 15289 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15258 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15262 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15263 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15266 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15267 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15269 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15302 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15271 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15272 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15304 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15305 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15306 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15308 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15310 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15311 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15312 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15313 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15314 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15315 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15316 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15317 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15330 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15331 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15336 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15338 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15342 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15388 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15344 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15389 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15391 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15392 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15394 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15395 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15396 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15397 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15398 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15399 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15360 still did not exit, sending a SIGTERM
[Mon Dec 20 00:16:28 2004] [warn] child process 15401 still did not exit, sending a SIGTERM


What is it? is it normal?

Stanley

"register_globals = On" should be "register_globals = Off", which is the default for PhP 4.2 and later.

The errors in the log could be as a result of the changes in the default PHP config. We did say that those changes, while helping with security, will break a lot of PHP code. To find out if that's what's happening here you will need to match up the PID of the failing child with what page it was processing and check that page's code to see if the problem is with one of the changes in the PHP environment.

> is it better to secure the server?
http:#12838251

You must patch your system n with a new kernel of redhat distro.On the firewall,setting the hosts.allow and hosts.deny.edit hosts.deny to ALL:ALL,PARANOID and edit hosts.allow to your client IP and setting www port (80) to your client can access.

Hi,

offer hosting with cpanel and install apf firewall.
Cpanel will fetch automatically reuired patches for your OS
Enable php suexec.

If you have alot of clients, or clients that pays alot of money. You should get yourself a parttime or freelance administrator to help you out with security and basic setup. Seriously sometimes spending some money cost less then investing alot of your time into something.