Server Compromised (Httpd Dies and an IRC perl script is started)
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Server Compromised (Httpd Dies and an IRC perl script is started)
Here is the just of it:
My server (for serving Web and Email) to a number of clients has been compromised by some Perl script.
It is not a root hack as far as I can tell as it starts at RANDOM times. It doesn't start at boot time and the files are all owned by apache.
Basically, in my error logs I can see that a download is initiated to download the perl script from some other compromised server.
The hack then stops Apache and starts itself (for some reason occupying port 80 as Apache cannot then be restarted until the script is killed)
This script appears to be connecting to an IRC server and joining a room called #perl2, which I have joined and find 400 odd invisible users in a channel with one operator - perhaps the attacker)
The perl script appears to be launching itself at random times. When I kill it I can start apache again and everything is fine for a few hours until it happens again.
The perl script is initiated with the fake name of httpds.
SIDE QUESTION: What is the ps command to see the FULL PATH of where this perl script is and from what directory it is being called?
Contents of this script is as follows:
# ! / usr/ bin/ perl
use IO::Socket;
srand;
my $bPs = 'httpds';
#my $aMaster = 'Clx';
my $aHost = 'white@abuse.gov';
my $sServer = 's.bl4cklist.net';
my $sPort = '10001';
my $sTimeOut = '300';
my $bChan = '#perl2';
Problem :
Running programs named Perl with Heavy CPU usage, with the ownership of user apache.
We found the problem on Fedora 3 and Fedora 6.
In our case, it was the result of a Trojan activity.
Quick Solution
Check the cron jobs of user apache
crontab -u apache -e
*/1 * * * * perl /tmp/.tmp/tmpfile
delete the cronjob entry.
Also delete the file /tmp/.tmp/tmpfile
also added "apache" to the file /etc/cron.deny
There are probably a couple of steps to take immediately. First, isolate this machine from the Internet. If you can't pull the network cable then you should enable your firewall so that only SSH is allowed and only then from an IP address you trust. You then need to give us a more detailed description of your rig, in particular you need to give us the distro you're using, the version of Apache and what sort of sites it is hosting (name and version). By chance do you have something like Aide, Tripwire or Samhain installed?
I would then spend some quality time with your log files looking for things that could indicate when the compromise occurred. Furthermore a good idea would be to work through the CERT checklist.
Basically, the way this forum operates is to try and get you to detail the facts of the situation. That allows you to determine what happened and when so when you do get to the point where you should start remedying the situation, you'll have a good idea of how to prevent this one from happening again.
As an aside, these situation typically attract a lot of "You need to do foo, then bar" which frequently have no bearing on the situation. The only way we can accurately identify how this happened is if you can provide us with the facts. The script you posted is interesting, but a symptom of a larger problem.
It's a Quad Core Xeon Machine with 4GB RAM and 2 x 250GB Sata drives in no RAID. The server is hooked up to my hosts network via 1000mbit ethernet. Now that was probably not what you were looking for :P so....
The box hosts various web and mail services for a bunch of end users. In addition, we also offer ShoutCast hosting services so there are a few daemons running there too. We offer the DirectAdmin control panel (I dont like control panels, but DA really seems to leave your config files in the most understandable and structured out of all of the CP's we tried.
It's running CentOS 5 32bit and the other versions as follows:
Apache: 2.2.14
Perl: 5.8.8
SpamAssassin: 3.2.5
Exim 4.69 (as I recall)
OpenSSL: Updated to latest stable as of today
OpenSSH: Updated to latest stable as of today
I hope that I am not leaving out anything important?
The box hosts various web and mail services for a bunch of end users.
This raises a bunch of questions you'll need to look into. First off, does the existence of these end users mean that you can't isolate the box from the internet? Second, do you have an idea of what web services are being run by the end users. Those can introduce a wide variety of exploitable avenues, particularly if any of them are PHP applications. Do you have control over the mail servers?
Quote:
It's running CentOS 5 32bit
Can you say anything about the state of patching or the procedures for keeping the box current? You say your OpenSSH and SSL are the latest stable "as of today". Does that mean these were updated after the intrusion?
As I said before, some quality time with the logs is probably important. You said that you were alerted to this via the error logs. If you can find out how far back these downloads go, that would give you a rough idea of when the server was compromised and you use that as a guide for looking in system logs.
As Hangdog said if you can disconnect it from the network please do so. If you cannot then enable the firewall for everything that you can. Also from looking at the script. If you have to leave it online one thing you may want to do is create an empty lock file to keep if from running as you run through the cert guide.
If you read through the script you find this line
Code:
open(LOCK, '>/tmp/sess_f6wtx4es3wedxwa213s1x1ws1e32sx1') or die;
so if we create a file in tmp with the sess_***** then it should stop it from running again.
touch /tmp/sess_f6wtx4es3wedxwa213s1x1ws1e32sx1
and put an immutable flag on it so it can not be deleted without some knowledge first
chattr +i /tmp/sess_f6wtx4es3wedxwa213s1x1ws1e32sx1
** This is only if you can not take it offline and must leave it online.
The bad thing about apache is the fact that if the permissions on the directory are wrong for the config file is setup with some relaxed security options then it is fully capable of running scripts like perl without a vulnerability being present on the system.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.