Web Hosting Talk







View Full Version : Kill irc bot run by user


jakis
09-21-2001, 01:23 AM
I gave my user telnet access. They're trying to run Bot , irc , eggdrop. I run cron hourly to kill all well-known name like psybnc eggdrop , but today they can just rename it to something else. Is there any better way to prevent user from executing these program ? I've seen some box have a 'cannot execute' shell.( but cgi must be allowed )

davidb
09-21-2001, 01:39 AM
I would recomend to just disable telnet. also if they do it why not delete the account?

jakis
09-21-2001, 01:58 AM
some people need telnet for debugging perl. Disable telnet will make it harder for them to use, but some is cheating. I cannot delete the cheaters because they need to do other telnet stuff, but sometimes they goes over limit. Disable user from executing ./x might be safe from being cracked as well.

spock
09-21-2001, 02:14 AM
You won't be able to fix this with a technical solution. You can disable telnet for specific users or tighten permissions, but in the long run that won't help against users that don't abide by the rules - they can do just about everything with just CGI access (it's just a little bit harder).

The only way to do this is to tell your clients that you won't allow IRC bots (etc) and that you will terminate any accounts that violates your policy. Give them a warning, but do terminate the accounts of repeat offenders.

mikeknoxv
09-21-2001, 07:11 AM
Can't you have a script set in the cron to execute every hour and delete all processes running on your client accounts except for the ones that they will need (essential)?

teck
09-21-2001, 10:28 AM
Try setting up a block of all outgoing connections to port 6667. That's the default port IRCd's run off..

jakis
09-21-2001, 01:29 PM
Thanks for suggestions.

Any action seems to be inefficient. The cheater can just rename pid file , login as another user , change port , upload binary file and rename it to something else like '-' , etc. . any method he could think of .

akashik
09-21-2001, 03:07 PM
Why does this guy still have an account? Sounds to me like he knows he's doing something he shouldn't. If he's still doing it after getting warned, leave a big boot print on his backside and wave him goodbye. I presume there's other accounts on that server? Time to think of their interests I think..

Greg Moore

Domenico
09-21-2001, 03:33 PM
My thoughts exactly. Kick this fool and wave him bye bye.

jakis
09-21-2001, 05:02 PM
Kick the inferior is easy , but beware the fool come back and destroy the assets. Disable telnet is ineffective since everybody can still spawn IRC bot from cgi/php script on their website . Should warning be the best practice when technical solution can't help.

Chicken
09-22-2001, 01:57 PM
Originally posted by jakis
I cannot delete the cheaters because they need to do other telnet stuff, but sometimes they goes over limit.

Once they go over the limit, they are cut off. First, you could step up the security. Some hosts require a photo ID to be faxed for telnet access. Extreme, well a bit, but it might cut down the problem. Make them sign an agreement for telnet access, etc.

From your post, it sounds as if you aren't doing much to prevent it in the first place, and even less once they are found to be doing something you don't want them to do after the fact. This might just be how I read it.

Zeon
09-24-2001, 12:48 AM
Hi,

Did u have tcl install on ur box? From my understanding irc bot needs it to run. :cool:

bteeter
09-26-2001, 08:26 AM
Originally posted by Chicken


Once they go over the limit, they are cut off. First, you could step up the security. Some hosts require a photo ID to be faxed for telnet access. Extreme, well a bit, but it might cut down the problem. Make them sign an agreement for telnet access, etc.

From your post, it sounds as if you aren't doing much to prevent it in the first place, and even less once they are found to be doing something you don't want them to do after the fact. This might just be how I read it.

Here's another idea. Post as part of your user policy and/or SLA that IRC and other chat bot's are allowed but that you will bill $500 per month to any accounts running these types of bots.

That should do wonders to discourage that type of activity. :)

Take care,

Brian

Lmax
09-26-2001, 10:15 AM
I'm a little bit new to Ircbot's. hat's the problem with them. Generate they to much traffic, are they illegal??

jakis
09-26-2001, 10:26 AM
Thanks for comments.

I'm very loose at the beginning since I wish if people can learn things out of the box, then come script kiddies , IRC , sneaker etc. For the time being I'd say better safe than sorry.

slade
09-26-2001, 11:58 AM
Originally posted by jakis
For the time being I'd say better safe than sorry.
Can you elaborate on that?

Are you allowing bots or not?

If you are, leave them alone...

If not, terminate the account. They know they're breaking the rules. But they're doing it anyway. They don't care about you, your other customers, or your server. They're just looking for a place that doesn't care about quality of service delivered to all customers, just themselves.

jakis
09-26-2001, 01:09 PM
The guy emailed me asking if he was allow to run IRC bot , but I replied "no , go to somewhere else and asking for permission there before you launch anything or your account will be terminated". He applied for an account with me later on and start to launch all kinds of bot. But I yet have no written rule about IRC bot. Should I write it first, then remove execute permission from tcl , gcc etc. to prevent future cheater and safe other customers.

spock
09-26-2001, 01:47 PM
Originally posted by jakis
Should I write it first, then remove execute permission from tcl , gcc etc. to prevent future cheater and safe other customers.

If I were one of your (honest) customers, this is where I would scream "Oh no! You mean I won't be able to use gcc to compile my CGI programs?". Think very hard before punishing other customers just because some of them won't follow the rules.

sPoT!
09-27-2001, 03:01 AM
The guy emailed me asking if he was allow to run IRC bot , but I replied "no , go to somewhere else and asking for permission there before you launch anything or your account will be terminated". He applied for an account with me later on and start to launch all kinds of bot.

When I was growing up, no meant no; end of story. You simply didn't press it.

Personally, I would send an email, preferrably quoting the email when you answered his original question about bots, and tell him how it is. A one week notice is enough of an advanced warning... I think it is generous. Also, what kind of account does this guy have? I mean, if it is the $5.95 special, vs. one that actually makes money for you, your losing out. If you told him no, and he is continuing to do so against the policy, he is actually stealing computer resources from you. Don't let one induvidual ruin it for the rest of your clients.

sPoT!

PS I like Chickens' idea combined with bteeter's :D :stickout

jakis
09-27-2001, 04:29 AM
Each account is $2. When a customer signup, he pull in a bunch of customers. When I kick a customer, I lost many prospective customers , since the loser will tell everybody out there that my server did not allow resource consuming. Many innocuous people out there , though their website use very little resources, will go to somewhere else they believe unlimit offer is best suit.

JustinK
09-27-2001, 02:47 PM
It's not just resource consumption though. Those IRC bots can possibly pull in people to try and do DoS attacks on your server(s). You already told him no, and if you don't want this happening then YES get it written down and notify your clients of the changes to your Terms of Service. If he begins telling people on message boards, simply reply explaining that the user was cancelled due to launching irc related bots and programs when he was specifically told before he signed up that he could not do so.

One customer and whoever he tells, vs. your current customers that are at possible risk. And if he gets a DoS attack going on your server and all the other clients leave it's more than just one person complaining about your service. GET RID OF HIM. I'll repeat this again "GET RID OF HIM".

Jm4n
09-27-2001, 07:34 PM
Even worse, IRC bots are commonly used to launch DDoS attacks against *other* machines/networks, and you might have some liability there for allowing it to happen.

End result: if you tell a client something is not allowed and they do it anyway, their account is terminated without warning or refund. That's how I handle these situations, provided the abuse was intentional. Any attempted security breach or abuse is grounds for immediate termination.

If that means his friends leave as well, so be it; they probably aren't the kind of customer you want if they leave for that reason alone.

Chicken
09-27-2001, 08:28 PM
For $2, I wouldn't even think twice about it. Delete user, end of story. Sure, you've lost the potential *other* rule breakers this account *might* bring in, but...

:D

cabalstudios
10-01-2001, 01:04 PM
I used to run a shell server a long time ago, and I remember writing a script that checked the server every 30 minutes, for certain background processes.

I also had a script that ONLY allowed certain users or ALL users to run 1 background process no longer than a specified amount of time, if there was more than one background process or 2 etc, this script would kill the newest process, i'll see if I can dig these scripts out.

If you need em let me know :)

sbrad
10-01-2001, 06:13 PM
Let me tell you what OUR company is *slowly* recovering from.

All of our problems started with irc bots. After eggdrop was installed once, whoever did it the first time must have told his friends, because it was a snowball from there. Pretty soon we had around 10 accounts running bots and launching ddos attacks. At this point we were like the guy running around the Titanic trying to plug the holes. What he SHOULD have been doing was getting as many people into the lifeboats as possible.

After we thought we had plugged all the holes, that made at least one of these guys mad enough to make us the target of a ddos attack. A day or two later, we realized our box had been rooted beyond repair, and Red Hat went bye-bye.

This all started because of some very simple, yet effective, security measures that could have been taken, but weren't. So now, our basic security measures are:

1) Watching who signs up. We watch every credit card number that comes through and make sure it is authorized.

2) TCP Wrappers- This is a big pain, but it is well worth it. No one gets on our server via SSH without their ip in the hosts.allow file.

3) "Know your user"- Yep, we require a drivers license on file before anyone gets shell access. If they don't want to provide this (small percentage, maybe 1%), then we would just rather not have them as a customer. Too big of a risk.

I'm sure I'm missing a few things that Trevor at PowerSurge did, but this is what we can control on our end. And it has been very effective. A smooth running machine makes customers VERY happy. And a happy customer is much easier to deal with than an irate one.
The bottom line is you can do what you want. You're going to anyway. But if I was a customer and found out you were allowing an IRC bot to be run on the server my website was on, I would know instantly what kind of company I was dealing with and RUN away. Our Terms of Service agreement IS our warning, and accounts found running these things are deleted without remorse.

Domenico
10-01-2001, 06:20 PM
I'm interrested ;-)



Originally posted by cabalstudios
I used to run a shell server a long time ago, and I remember writing a script that checked the server every 30 minutes, for certain background processes.

I also had a script that ONLY allowed certain users or ALL users to run 1 background process no longer than a specified amount of time, if there was more than one background process or 2 etc, this script would kill the newest process, i'll see if I can dig these scripts out.

If you need em let me know :)

Domenico
10-01-2001, 06:25 PM
Originally posted by sbrad

2) TCP Wrappers- This is a big pain, but it is well worth it. No one gets on our server via SSH without their ip in the hosts.allow file.


Hmmmm, it would be cool if someone could do something like a pop before smtp thing.

pop3 before ssh? Just some sort of IP verification before a connect is accepted from your IP. It beats editing the host.allow file and is a little bit more flexible.

Oh well, I'm just thinking out loud :confused:

sbrad
10-01-2001, 07:26 PM
Almost forgot. We also disabled root login via SSH. I'm sure that's a no-brainer, but previously we were just logging in as root.