unprivileged user binding to port 80

[nobaloney]

I've tried googling for this but nothing I've found helps me with finding out how it might have been done.

One of my clients finds he can't restart apache because something else is bound to port 80. It's something different almost every time.

We fixed the problem for him by finding a reseller who, if we suspended that reseller, httpd could be restarted.

Now I'm waiting for the client to tell me what he or his reseller finds.

But my question here is: How is this possible?

How could a php-based attack bind anything to port 80?

Any ideas?

Jeff

 

[localhost]

Yes it's possible.
There are PHP scripts which are always opening them-selves, PHP Shells.
Apache can't kill the PHP process due Timeout and the Apache is killing himself but the PHP process linked with Apache still remains as alone process. So when you try to restart the Apache you have Apache already running.

To fix you need to modify the init script to killall all processes.

 

[SeLLeRoNe]

i had same problem with some perl based scripts that was going to execute file in /tmp (and some times in hideddn user's owned directory).

Probably with mod_ruid or suphp this wouldn't happend but im not totally sure.

A good way should be look for which software is binding port 80 and analyze for find where is located and how has been possible (usually a bug in some cms with permission 777)

Regards

 

[localhost]

i had same problem with some perl based scripts that was going to execute file in /tmp (and some times in hideddn user's owned directory).

Probably with mod_ruid or suphp this wouldn't happend but im not totally sure.

A good way should be look for which software is binding port 80 and analyze for find where is located and how has been possible (usually a bug in some cms with permission 777)

Regards

When you will look at port bindings you will see only Apache, even if it is not running. So you can only find out which script is keeping the process alive by strace it.

 

[nobaloney]

In the case in question, the program running had the name of a random real program (a different one every time), which would not normally bind to any port. So I'm not sure how to automate killing it, or even figure out what it really was. Any more ideas?

Thanks.

Jeff

 

[localhost]

In the case in question, the program running had the name of a random real program (a different one every time), which would not normally bind to any port. So I'm not sure how to automate killing it, or even figure out what it really was. Any more ideas?

Thanks.

Jeff

This is really easy.

netstat -tanp | grep :80 | awk '{print $7}' | awk -F/ '{ print $1}' | grep -E '[[:digit:]]' | 
uniq

You should add this to your init script this will kill all bastards.

 

[zEitEr]

Or with lsof:

lsof -i:80 | grep -v PID | awk '{print $2}' | xargs ps -fp | grep -v PID

or simple:

lsof -i:80 | grep -v PID | awk '{print $2}'

 

[localhost]

lsof is not present on all Linux distributions by default.
I made something according to LPI recommendations.

 

[nobaloney]

Thanks, gents. I'll give it a try when it next comes up (I still haven't heard from the client again). I'm not sure it will work in this case; it appears that even if we found and killed the bastard process, a new one immediately started.

But now I know a lot more about how to go about this and that's a good thing.

Should we just put it into the restart?

Jeff

 

[localhost]

Thanks, gents. I'll give it a try when it next comes up (I still haven't heard from the client again). I'm not sure it will work in this case; it appears that even if we found and killed the bastard process, a new one immediately started.

But now I know a lot more about how to go about this and that's a good thing.

Should we just put it into the restart?

Jeff

Yes.

You should add something like

for i in `netstat -tanp | grep :80 | awk '{print $7}' | awk -F/ '{ print $1}' | grep -E '[[:digit:]]' | 
uniq`
do
kill -9 $i
done