Hello,

I'm a hosting reseller. My hosting provider did shut down the server because it was used by a hacker for DoS attacks. To be more specific, somehow he can upload a script "udp.pl" into the /tmp directory and then execute it through "perl udp.pl". The script "udp.pl" does mass flooding on the IP they specify. The udp.pl code is attached at the bottom.

Has anyone had the same issue? How do they upload the file? I can't find anything in the Apache logs files. That's *very* critical for me because I host about a dozen customers on the server. Please help!

Thanks.

--------------------------------------
#!/usr/bin/perl
#####################################################
# udp flood.
#
# gr33ts: meth, etech, skrilla, datawar, fr3aky, etc.
#
# --/odix
######################################################

use Socket;

$ARGC=@ARGV;

.....
--------------------------------------

please take the code off please please please. i can just imagine how many copy and pastes are being done on it right now. As far as the tmp directory, I believe a NoEXEC directive for the diectory in question in httpd.conf would take care of that. Is /tmp your temp directory for squirrelmail possibly? Are they uploading an attachment? Is allow uploads set to on in php.ini?

linux_terror

Makes sense. Will it affect in any way session vars and/or mysql sock that are besing used in /tmp ?

Well, I too had similar problems today. But does noexec in /tmp helps? Becos the actualy binary is perl (/usr/bin or /usr/local/bin) and it just loads the script from /tmp/. As long as /tmp/upd.pl is readable, perl can execute it. Am I missing something?

Thanks,
Anil

I think everyone is missing the bigger picture here and that is if you're the only one with access to the system and udp.pl shows up in /tmp, then it's very likely that your systems security has been compromised. While removing udp.pl and making /tmp noexec may or may not be helpful, it still doesn't address how udp.pl got there in the first place or identify the level that security has been compromised (have they done a local privilege escalation? Is there a rootkit on the system? Backdoor FTP hosting warez?

If you have multiple users accessing the system and you believe they put it there, check the bash_history files and/or install process accounting.

If you are the only one who should be accessing the system, you need to run through the standard security checklist: download and run chkrootkit or rootkit hunter, check the output of last -i for abnormal login activities. Check the udp.pl file attributes like owner, creation time, access time and use those times as a rough guideline for when access was gained. Then go through the system logs looking for anything abnormal in in or near that time point including kernel panics, application segfaults or errors. Check /etc/passwd for new users and users with UIDs of 0 other than root. Check for the presence of SUID/SGID root files. If you're running a webserver, check for weak CGI scripts and verify that your Apache/PHP/SSL versions are all updated.