AllProtection.tcl (Stable: v4.8 / Beta: v4.9b4)

Post by **slennox** » Fri Jun 10, 2005 2:16 am

Detecting "drone nicks" is an academic pursuit. If you're interested in practical flood protection, I'd suggest not spending too much time on it. It may be effective initially after a lot of effort on implementation, but with far less effort, flooders will respond by altering their nick generators to use more vowels or dictionary words.

The end result will be a small victory for the flooders. Currently, "drone nicks" have the unintended benefit of being distinguishable from regular users, which can simplify the job of IRC and channel operators. That will disappear.

Post by **Sir_Fz** » Fri Jun 10, 2005 11:35 am

sKy wrote:My only suggestion:
If there are other scirpts which provides publik commands (!help or whatever), the bind pub will not trigger your bind pubm against channel/repeatingflood.
Maybe you can find a way to let each bind pub trigger you bind pubm too?

Anyway, really great script. You have done a good work.

Well, I'm sure that the person who has access to public commands must have atleast a +f or +mo flags. Note that allfloodprotection exempts +f and +mo users, also voices and ops.

Alchera wrote:I am guessing the aim is to detect and ban consonant nicks

Looking at my translated proc, it doesn't only ban consonant nicks... It first checks if the nick has no vowels (except for y) if it does, then it checks if other characters are in the nick. Note that there are a few checks on the nick and ident (i.e. is alpha, lowercase, length...etc) before checking for vowels, characters...etc

slennox wrote:The end result will be a small victory for the flooders. Currently, "drone nicks" have the unintended benefit of being distinguishable from regular users, which can simplify the job of IRC and channel operators. That will disappear.

I agree with this. Currently nosense:kick pretty much works for me as my bot is oped in a channel where alot of "such" nicks join, but it may not work if other types of nicks is used... so you're right, in the end there can be found a way through it.

awyeah · Post by **awyeah** » Fri Jun 10, 2005 2:11 pm

What is 'is alpha' for string match? I read the manual but I was unable to understand the meaning.

demond · Post by **demond** » Fri Jun 10, 2005 2:17 pm

alphanumeric, [a-zA-Z0-9], i.e. letter or digit

Post by **Sir_Fz** » Fri Jun 10, 2005 7:44 pm

demond wrote:alphanumeric, [a-zA-Z0-9], i.e. letter or digit

Actually, it's letters only [A-z].

demond · Post by **demond** » Fri Jun 10, 2005 7:52 pm

right, the one I meant is actually alnum

^DooM^ · Post by **^DooM^** » Sun Jun 12, 2005 6:22 pm

Hey FZ. I have the script running now and all seems to be working as expected. I shall log status for a while see if any errors pop up. Thanks for adding those suggestions. I can remove 4 seperate scripts now

Post by **Sir_Fz** » Mon Jun 13, 2005 4:42 am

^DooM^ wrote:Hey FZ. I have the script running now and all seems to be working as expected. I shall log status for a while see if any errors pop up. Thanks for adding those suggestions. I can remove 4 seperate scripts now

Cool

lets see if there're no problems from now till next week (as I haven't found any myself and there were no new bug reports) I'll release the complete (non-beta) script with some improvements to the code and a new requested feature. Thanx for your help.

Post by **Sir_Fz** » Tue Jun 14, 2005 5:53 pm

Version 3.8b releasd. I've made alot of changes to the code, bug fixes and added 2 new features. Hopefuly, this will be the last BETA version, and after fixing all bugs (if any) in this version I'll release the complete bugfree version, unless something happens

I hope all errors/bugs would be reported and not just wait for someone else to report them, don't bargain on that

Thank you.

Pixelz · Post by **Pixelz** » Wed Jun 15, 2005 10:02 am

While I haven't acually used your script I did read through this thread and had a quick look at the code. I applaud your initiative to create a sentinel replacement, even if that wasn't your initial intent. Anyway, if you want feature suggestions, here's a few from me.

I'm a big fan of dynamic settings, so I'd suggest adding some of those. If nothing else, channel flags for settings like textl(chans). A few others might be useful to have dynamic aswell but this type of setting is the most obvious one.

Another thing you might want to consider is some type of roles system for a botnet running this script. For instance, one bot could be assigned to the more trivial aspects of flood protection such as control codes, swearing and capslock, while others could concentrate on more critical things.

Post by **Sir_Fz** » Wed Jun 15, 2005 2:12 pm

I didn't use dynamic settings because there would be a lot of settings to add in allfloodprotection's case, so I find it better to leave all configurations in the script. As for the botnet suggestion, why not add the script on different bots and configure it as you want on each bot

Pixelz · Post by **Pixelz** » Sat Jun 18, 2005 5:26 am

The only setting that would be critical to have dynamic is which channels should have what flood protections. It's fine to edit the tcl each time you add and remove channels as long as someone who acually have access to the shell is doing the adding. While there are indeed alot of settings, you wouldn't acually want to change most of them very often. You would however perhaps want capslock kick in big public channels but not in small private ones. Another aspect of this is that it's just not practical to edit files once you reach a certain number of bots in your net.

As for botnet support, you really would have to use different configurations on different bots with this script as it stands now. Especially if you want to use the warn function, or you could end up with your entire net warning people at the same time. Simply creating a function that figures out what each bot should do when they link would really improve the usability of this script.

demond · Post by **demond** » Sat Jun 18, 2005 11:35 am

I agree with Pixelz, a general channel-oriented script should have all of its settings as setudef's - the user shouldn't be bothered to edit the script itself

Post by **Sir_Fz** » Sat Jun 18, 2005 12:07 pm

I'm not sure about that, it's still alot of udefs. for example if we use setudef flag, there would be about 20 flags for flood type on each channel, and if I use setudef str then I can add 1 flag and like 20 strings into it which would be a better idea but still alot of options in it. So IMO it's best as it is.

As for the botnet idea, well it'll need some time for coding and debugging which I'm not so enthusiastic in doing at the time especialy that my focus right now is to release the complete bug free script which is on the verge of being done. But, I'll keep the idea in mind for the near future (hopefully).

I had been thinking of releasing two versions of the script, like 1 which supports kills/klines and one that doesn't so other users won't have to put up with extra codes.

awyeah · Post by **awyeah** » Sat Jun 18, 2005 12:10 pm

Releasing one for botnet is more complicated and messy. Why can't 1 bot do the same work, which several bots would do!

Kills and klines in my idea woudn't be so necessary, only if the bot is opered up on a small network, plus different IRCd's have different umodes and services to check for all these certain types of floods and etc.

Just focus on improving the code, making it smaller and more effective.