Addition to superbitch.tcl

jestrix · Post by **jestrix** » Tue Feb 12, 2002 12:18 am

I run a botnet of about 30 bots on EFNet and try to keep my channels as secure as possible. One thing I noticed today, was that ops could deOP bots. One of the ops in a channel (+fov for the chan) "accidentally" hit a button for a mass deOP script and started to deOP all of the bots. Luckily in a botnet of 30 this is not a problem (the bots re-op'd the others before the chan could lose ops). However, I thought this to be a security hole - what if some user, whom i previously trusted as a friend/op wanted to takeover a channel? Since I couldn't find any settings in netbots to take care of it (and since i was bored), I created an addition to the superbitch.tcl to take care of this problem.
Before the update, if a user (+fov on the chan) deopped a bot, the following would happen:
[20:49] *** neoshw sets mode: -o HAiKU
[20:49] *** hurts2pee sets mode: +o HAiKU
[20:49] *** l33th4x0r sets mode: +o HAiKU
[20:49] *** TheClap sets mode: +o HAiKU
[20:49] *** alkoholic sets mode: +o HAiKU
etc etc

Now, the following happens:
[21:14] *** jestrix sets mode: -o RumpRangR
[21:14] *** hurts2pee sets mode: -o+o jestrix RumpRangR
[21:14] *** alkoholic sets mode: -o+o jestrix RumpRangR
[21:14] *** CTCPFlood sets mode: -o+o jestrix RumpRangR
and so on...

I made it so that the bot who was deopped would get re-opped immediatly as well as the offender getting deopp'd.

The modified superbitch.tcl (based on the one that came with netbots 4.05) can be found at http://www.jestrix.net/ultrabitch.tcl (code is fully commented)

I take no credit for the code - I simply modified the exisiting script - slennox should be credited for an excellent job

(also, if there was an easier i could have done this, with features already in netbots, please inform me

+revenge +revengebot +bitch -protectops, etc etc, didn't seem to do anything for me)

<edit>damn typos</edit>

[ This Message was edited by: jestrix on 2002-02-12 20:49 ]

Post by **slennox** » Tue Feb 12, 2002 6:21 am

I'd like to add your script tcl archive, however please modify the version as per the guidelines at http://www.egghelp.org/license.shtml section 3b.

Just a couple of comments on things you may have already considered. I noticed there isn't a wasop check on $opped in the -o part of the script. You might want to look into whether this is necessary (might be a good idea anyway for safety). The other thing I noticed is the use of flushmode, which might make the script more effective in responding to a single deop, but less effective for multiple deops.

jestrix · Post by **jestrix** » Tue Feb 12, 2002 11:54 pm

script name changed - sorry about that slennox. New link posted above.

Also added in a wasop check as per your recommendation. As for the flushmode, what I found was that without it, the bot would push multiple modes at a time: ie. Bot sets mode -o+ooo badperson bot1 bot2 bot3

with flushmode, the bot would do:
bot sets mode -o+o badperson bot1
bot sets mode +o bot2
bot sets mode +o bot3

etc etc....

according to the tcl command reference:
flushmode <channel>
forces all previously pushed channel mode changes to go out right now, instead of when the script is done (just for the channel specified)

it was my thinking that the faster the modes went out the better. I didn't notice any time response delay, but I've only tried mass deops by one person. If I am mistaken in thinking that flushmode will help timewise, someone please correct me

[ This Message was edited by: jestrix on 2002-02-12 20:55 ]

[ This Message was edited by: jestrix on 2002-02-13 07:35 ]

Post by **slennox** » Wed Feb 13, 2002 8:56 am

Odd. It seems the opposite of what is supposed to happen (in theory) is occuring in your case.

Presumably, with flushmode pushing all the modes out as soon as each call of the script is done, the modes would go out separately. Without flushmode, the modes would have time to queue up and get sent out in a fewer number of lines. If that isn't happening in practice then somethng strange is going on.

Anyway, I've saved the script for addition in the next tcl archive update.

jestrix · Post by **jestrix** » Wed Feb 13, 2002 10:35 am

errr, after re-reading my post and drinking some coffee, you're entirely correct. I switched my descriptions above:

flushmode sends out numerous mode changes; no flushmode puts the modes out at the same time.

sorry if that confused anyone :/

Yourname · Post by **Yourname** » Mon Feb 18, 2002 10:13 am

Some months back, i had requested someone to post anything about a mass-deop protection standalone script, to which i got no reply.

As this is a netbots integrated script, i hope this same sentinel can be replaced with the current sentinel being used in netbots?.. I mean, i dont need to add any setting to netset.tcl.. do i?.. Or is this supposed to be used as a standalone script?

AND.. this is supposed to be detected on botnets, what if i put this script on just one standalone bot?

Another thing, the same old one, is there ANY such script that can prevent a mass-deop (even the users who dont have a bot record and still were victims of massdeop)..

*Hopefully* someone should've understood what i meant cuz im sure my question(s) are confusing.

_________________
¬¥ourname
Yourname@k.st
http://www.hardfist.com

[ This Message was edited by: Yourname on 2002-02-18 07:17 ]

Petersen · Post by **Petersen** » Mon Feb 18, 2002 10:52 am

massdeop prevention scripts, while somewhat useful, are severely limited in that they're damage limitation scripts (ie, they only come into effect once a mdop has started). If you feel you're in a position where someone would want to mdop a channel of yours, you should look more into preventing ppl getting ops there in the first place. once someone has ops, all the scripts in the world aint gonna help you keep that chan. at a 1:1 bot ratio, a takeover net will always win (and my test show that this can easily be closer to 2 protection to 1 takeover). main reason for this is that the takeover net starts first. depending on server lag, it will probably deop 8-12 of your net before it even reacts.
the point of this post is that if you have a secure net, you shouldn't need any massdeop protection schemes. prevention is better than the cure.
however, probably one of the best ways is a simple combination of revengebot, and protectops, as both are coded in c.

jestrix · Post by **jestrix** » Tue Feb 19, 2002 10:42 pm

Yourname: the script requires no addition to netset.tcl - it simply replaces superbitch.tcl (not sentinel). It could also be used on just one bot; that's your option.

And thank you petersen for pointing out a major footnote to this script:

this script is NOT intended to prevent a channel takeover due to a carefully planned and coordinated takeover by a hostile botnet. It was written to stop an abusive op from causing channel damage. If a channel runs a botnet of only a handful of bots, its entirely probable that one op could get rid of them all - hopefully this will prevent against such attacks.

[ This Message was edited by: jestrix on 2002-02-19 19:43 ]