help needed in finding IRC bot

[nobaloney]

We've got a client with a probable IRC bot installed through some kind of CMS hole.

We can't find it.

Currently we've got it turned off but it may come back; it has before.

top output:

18728 apache    25   0  7748 2944 1140 S 99.4  0.1  20:39.66 perl

but ps waux | grep 18728 shows:

apache   18728  7.4  0.0   7748  2944 ?        R    02:33  37:47 /sbin/syslogd

and ps waux | grep syslog doesn't show the real syslogd process, though it appears to be running; logging is happening.

We found a suspicious perl script in /tmp: pred.txt. I moved it and chmodded it 000.

Kill the running process and it comes back.

Some Googling shows it to be something extremely similar to the first bot described here (linuxmadhatter.co.za).

Turning off perl doesn't keep it from coming back when killed.

I finally got it to stop coming back:

I killed the process. Then I shut down the script running with the pid of syslogd. Then I tried using service syslog restart to restart the syslog daemon, but it failed. So I started it manually from the command line:

syslogd -m 0

and now it doesn't appear to have come back.

But we really need to find it. If you have any ideas, please post. If you have experience in finding this kind of bot and want to offer your services, please respond.

Thanks.

Jeff

 

[SeLLeRoNe]

Are you using mod_ruid with apache? Cause, something like that appeared many time ago (always a perl script in /tmp from a non-updated cms with 777 permission on an upload/tmp directory)

When i had this problem i had no suphp or mod_ruid so i founded all the 777 permission directory and manged to view (that was a lot of time) all website that was using the 777 permission and compare their cms version with the latest one.

Exactly i dont remember how did i found the hacked site but i can give you the command ive used to find all the 777 permission:

find /home -perm 0777

Probably you already knew but, well, i think that any help (doesnt matter how basic or stupid can be) is an help

Ive asked about mod_ruid or suphp cause the perl file maybe should have the user hacked as owner (am i wrong?)

Is the /tmp mounted with noexec,nosuid?
Had you linked /var/tmp to point to /tmp?

Hope those should help in some way.

Regards

 

[nobaloney]

Are you using mod_ruid with apache? Cause, something like that appeared many time ago (always a perl script in /tmp from a non-updated cms with 777 permission on an upload/tmp directory)

No mod_ruid on this server; no mod_suphp. Runs as mod_php.

When i had this problem i had no suphp or mod_ruid so i founded all the 777 permission directory and manged to view (that was a lot of time) all website that was using the 777 permission and compare their cms version with the latest one.

Tons of directories with 777 permissions. I'll pass the info on to the client.

Exactly i dont remember how did i found the hacked site but i can give you the command ive used to find all the 777 permission:

find /home -perm 0777

Probably you already knew but, well, i think that any help (doesnt matter how basic or stupid can be) is an help

All helps.

Ive asked about mod_ruid or suphp cause the perl file maybe should have the user hacked as owner (am i wrong?)

It should. But since machine runs mod_php, all are owned by apache.

Is the /tmp mounted with noexec,nosuid?
Had you linked /var/tmp to point to /tmp?

Old machine. /tmp is not in it's own partition.

Hope those should help in some way.

You've been very helpful. I'm going to be in touch with the client. He's mentioned he's willing to go to a more modern server. Perhaps it's time. Otherwise we can switch to mod_ruid and create file to use for /tmp.

Thanks.

Jeff

 

[SeLLeRoNe]

No problem man, you helped me so many times

I suggest you to put mod_ruid, very simple to do and mount /tmp in a separate partition and link /var/tmp into there.

This for sure will prevent those kind of situation.

You are in the same condition i was in that time and have all file owned by apache make the understanding very hard.

Regards

 

[nobaloney]

Agreed. We need client approval. Do you know of easy way to convert 0777 to more secure setting?

Jeff

 

[SeLLeRoNe]

From the mod_ruid2 how too here:
http://www.directadmin.com/forum/showthread.php?t=37467&highlight=mod_ruid

I use this for reset all permission in a good condition:

cd /usr/local/directadmin/scripts && ./set_permissions.sh user_homes
find /home/*/domains/*/public_html -type d -print0 | xargs -0 chmod 711
find /home/*/domains/*/public_html -type f -print0 | xargs -0 chmod 644
find /home/*/domains/*/public_html -type f -name '*.cgi*' -exec chmod 755 {} \;
find /home/*/domains/*/public_html -type f -name '*.pl*' -exec chmod 755 {} \;
find /home/*/domains/*/public_html -type f -name '*.pm*' -exec chmod 755 {} \;
cd /usr/local/directadmin/data/users && for i in `ls`; do { chown -R $i:$i /home/$i/domains/*/public_html;}; done;

Regards

 

[interfasys]

Be very careful with a script like the above (permissions), it will break most CMS and permissions are DA settings dependant.

 

[nobaloney]

Thanks to both of you. I'll direct the client to this thread.

Jeff