Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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!
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?
Makes sense. Will it affect in any way session vars and/or mysql sock that are besing used in /tmp ?
Originally posted by linux_terror 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?
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?
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.
Last edited by Capt_Caveman; 12-15-2004 at 10:23 AM.