Cant Stop Udp.pl Flood Script!

[bsasninja]

Someone is uploading a udp flooder to tmp folder, called udp.pl (is a common kiddie script)

This is my ps aux at the moment the script was running:

sh -c cd /tmp;perl udp.pl 201.9.15.245 0 999 1> /tmp/phpshellu
nobody 28569 33.4 0.0 6800 1800 ? R Sep06 184:55 perl udp.pl 201.9.15.245 0 999
nobody 28636 0.0 0.0 5240 1140 ? S Sep06 0:00 sh -c cd /tmp;perl udp.pl 201.9.15.147 0 999 1> /tmp/phpshellt
nobody 28637 34.2 0.0 7096 1800 ? R Sep06 189:08 perl udp.pl 201.9.15.147 0 999
nobody 29072 0.0 1.3 38396 28980 ? S 00:00 0:30 /usr/local/apache/bin/httpd -DSSL
nobody 29477 0.0 0.0 5792 1136 ? S 00:06 0:00 sh -c cd /tmp;perl udp.pl 201.14.107.237 0 999 1> /tmp/phpshel
nobody 29478 32.7 0.0 6612 1804 ? R 00:06 177:14 perl udp.pl 201.14.107.237 0 999
nobody 29629 0.0 1.4 38668 29172 ? S 00:09 0:26 /usr/local/apache/bin/httpd -DSSL
nobody 29967 0.0 0.0 4316 1140 ? S 00:14 0:00 sh -c cd /tmp;perl udp.pl 201.10.171.250 0 999 1> /tmp/phpshel
nobody 29968 31.7 0.0 6100 1804 ? R 00:14 169:22 perl udp.pl 201.10.171.250 0 999
nobody 30251 0.0 0.0 5080 1140 ? S 00:17 0:00 sh -c cd /tmp;perl udp.pl 201.14.107.237 0 999 1> /tmp/phpshel
nobody 30252 32.3 0.0 6652 1804 ? R 00:17 171:28 perl udp.pl 201.14.107.237 0 999
nobody 3449 0.0 1.4 39828 30412 ? S 01:31 0:25 /usr/local/apache/bin/httpd -DSSL
nobody 3686 0.0 0.0 4424 1136 ? S 01:35 0:00 sh -c cd /tmp;perl udp.pl 201.67.80.19 0 999 1> /tmp/phpshellI
nobody 3687 30.8 0.0 6856 1800 ? R 01:35 139:39 perl udp.pl 201.67.80.19 0 999
nobody 15870 0.0 0.0 5292 1140 ? S 06:05 0:00 sh -c cd /tmp;perl udp.pl 201.24.11.19 0 999 1> /tmp/phpshell2
nobody 15871 26.9 0.0 6028 1804 ? R 06:05 49:16 perl udp.pl 201.24.11.19 0 999

I have securetmp, modsecurity. Dont want to run phpsuexec cause some sites will mess up.

Is there a way to stop running "sh -c" command, through mod_security?

Please help will be appreciated.

Thank you

 

[bmcpanel]

I have securetmp, modsecurity. Dont want to run phpsuexec cause some sites will mess up.


Thank you

My suggestion is to get past your adversity to phpsuexec if you want to avoid these problems. Once you get through the pain of the switch, and you educate your customers, you will not have future problems.

 

[chirpy]

Using mod_security in this case isn't really the solution, that is for you to trawl through your servers domlogs and find out which PHP script is being exploited.

 

[bsasninja]

I did a search at domlogs but I didnt find anything

tryed "grep -r udp.pl /etc/httpd/domlogs/*"
tryed "grep -r wget /etc/httpd/domlogs/*"

tryed tryed "grep -r XXX.XXX.XXX.XXX /etc/httpd/domlogs/*" where xxx is the ip numbers that appeared at top.

(have to use -r cause if I use only grep I would get too many arguments error)

Which will be the worst scenario if I turn on phpsuexec?

 

[bsasninja]

hi again

is there a way to secure the sh command in linux.

Chmoding /bin/sh to 000 what kind of problem may lead in normal use? This could prevent from running scripts at tmp ??

Of course when I do updates should be at 755 to work correctly.

Thanks!

 

[jugo]

First off...

Install ELS to lock down your common executables like WGET, etc. That will also secure your /tmp, /var/tmp and /dev/shm directories... you can get it from http://www.servermonkeys.com/els.php

 

[NightStorm]

Which will be the worst scenario if I turn on phpsuexec?

All htaccess files that have php flags in them will cause the site to error out.
All directories with higher levels than 755 (basically, any 777 directory or file) will cause a 500 script error. 755 is sufficient for writing with phpSuExec, as the php process runs under the same username as the owner of the file/folder.
Honestly, that's the only problems I ran into when I enabled phpSuExec. Everything else was extremely minor, and easily fixed in the period of a few seconds.
I very highly suggest that you go through with this. Send a message out to all customers that it is happening, and direct them on how to fix any problems that they may experience. Essentially, show them what problems will come up, and tell them how to fix it themselves. Once phpSuExec is enabled, even if someone manages to upload a pl exploit script to /tmp again, you'll be able to tell just from the ownership, what domain that file came from.
As far as the script itself, you should follow the advice of the others here... and run a search on php exploit... likely you're running something like phpBB on your server, and someone is using a bug in it to upload files. Check your php.ini and make sure that you have some disable_funtions in place to help slow down the upload process (shell_exec and such).
The forum is loaded with information on how to combat and fix this. Just make sure that they do not have any root level access, or you're looking at a wipe.

 

[Modchips(Pablo)]

Hi take a look to this. i saw some process using the same behavior

the flaw was Tufat Flashchat ..

http://forums.cpanel.net/member.php?find=lastposter&t=57343

 

[bsasninja]

ok

i will try it firts on a test server.

By the way chmoding sh command to 000 avoid this from happening. Do you know if it breaks fantastico setups or removes, cpanel backups?

I would set it up back to normal permissions if I need to make some sysupdate or cpanel update.

Could be possible this??

Thansk

 

[bsasninja]

hi

does anybody tried chmoding sh to 000 sometime?¿

 

[randomuser]

A. Don't chmod /bin/sh to 000 unless you want to break a lot of things, whether you have noticed anything broken or not.

B. There is no such thing as "secure /tmp", "securing /tmp", or anything else that refers to security and a directory that anyone can write to. If an unauthorized person can write to /tmp, it is no longer secure, nor was it to begin with. "Securing /tmp" is a huge misnomer that leads people into a false sense of security. Having /tmp mounted nosuid,nodev,noexec is better than nothing, but in the end, it's trivially bypassable. Nothing secure about it by any stretch. Nothing.

C. Hire an admin, ASAP. You desperately need one.