----- Original Message ----- From: "Carlo Wood" <[EMAIL PROTECTED]> To: "Isomer" <[EMAIL PROTECTED]> Cc: "Dani?l Boeije" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, August 18, 2002 8:55 AM Subject: Re: [Coder-Com] Modes for (by example) botservice(s)
> On Mon, Aug 19, 2002 at 12:14:50AM +1200, Isomer wrote: > > What would you suggest? Perhaps some examples? > > Being able to ban bots from channels. > Only allowing bots to message people who are on the same channel > (disable PRIVMSG thus, only allowing CPRIVMSG). This is a well intentioned but still, bad idea with currently existing bot codebases. It prevents bots from sending any messages at all unless opped or voiced on a channel, which while it fights spam and other abuses, can be a serious problem because a fair number of bots need to msg another bot (such as X) to get their ops in the first place. The only way around that if such a restriction were imposed, would be to force people to set an autoop script on the bot that doesn't require the bot to authenticate itself, which is a really bad security risk for channels (even the old X which had your specific hostmask wouldn't autoop you unless you were logged in ... for good reason). A solution might be to restrict PRIVMSG to +k clients only, so that bots can msg X without CPRIVMSG, but nobody else. Actually, this makes me think that maybe CPRIVMSG should be changed to allow a +k target to be messaged regardless of the sender's op/voice status; this seems like less coding work and CPU usage than adding the checks to PRIVMSG. (Unless this has already been done; I haven't really been keeping all that much track of the features in the most recent betas ...) > Put a much tighter restriction on (joining/)parting channels, > for example a maximum of one PART per 20 minutes. Good idea as long as the restriction is placed on PART. (JOIN would be a bad idea, as a takeover artist could easily kick a bot and put it out of action for 20 min; *not* good) > Not allowing bots to talk to channels at all unless they are +o or +v. A decent idea. > Keeping a counter per human of the number of times they > are msg-ed by a (different) bot per second; if someone is > messaged by -say- 10 different bots within 10 seconds then > report all bots that msg this target to (a channel with) IRC opers > (botnet detection). Reporting to all opers creates a lot of noise; reporting to a channel requires hard coded channel names, hardly a good idea (ircnet ircd uses hardcoded channel names for a few things, but then, ircnet ircd is hardly an example of good ircd code :) Reporting to services (+k clients) could work. An appropriately designed service could then forward the messages to a channel set in its configuration. Since most floodnets use CTCP (and most non-flood bots that use CTCP extensively tend to be warez/mp3 kiddie xdcc bots anyway), checking solely for excessive CTCP might work. This could lead to CPU usage issues though, having to check messages at the character level. > Disconnect bots that are idling when a server is full and > a human wants to connect. Has to be done delicately. As another member mentioned, it is possible then to DoS legitimate bots by connecting too many drones, rather too easily. A better solution may be to disconnect a bot on attempting to connect, but this is not particularly feasible if bots must log in to a service to receive their status. Better might be to, upon a bot acquiring its flag, checking to see if the server is more than a certain amount full, and if it is, disconnecting the (almost certainly newly connecting) bot, rather than disconnecting existing clients which is, as mentioned, rather thorny. -- Amarande
