This plugin provides several features that channel ops will find useful. Non-op users may also find some value in the features, such as clone reporting and protection from join/part floods (by ignoring the flooders).
One of the features is auto-unban. When active, any ban you place on a channel will be undone after the delay set with the /aub command. When an auto-unban is scheduled, it is displayed in the channel window with a #nn delayed-command sequence number. If you want the ban to remain in effect, you can type /delay #nn cancel. You must have the hipDelayedCommands plugin active to use the auto-unban.
Another feature is automatic clone detection and reporting, with optional kickban. You can control the number of clones you'll tolerate before kickbanning them, and can also set address masks from which you'll tolerate any number of clones.
For years there has been an ongoing "arms race" in which the writers of scripts and channelbots develop more effective protections against floods, and writers of flood scripts/bots/programs find ways to counter those defenses. The advantage lies with the flooder, because a defense against flooding has to walk a fine line between protecting a channel and its users while not over-reacting and accidentally kicking or locking out innocent channel users. A defense script is also at a disadvantage because it can only react to a problem once the flood is well underway, and then it is at the mercy of the inherent lag between linked IRC servers.
HipScript now attempts to protect users (even non-op users) from clone and join floods, by ignoring almost everything the flooders are doing. One of the biggest problems with a join flood is that there is so much going on in the channel window that ircle begins to fall further and further behind, making the script's reactions even slower. HipScript now combats that problem by attempting to ignore virtually everything the flooders are doing while at the same time trying to still display normal channel conversation by the non-lame users.
Once HipScript detects that a given IP address or hostname is a flooder (detected either by the number of clones or the number of joins from that IP in a short time), it then ignores everything it can from that IP/hostname. This means that it doesn't display join/part/signoff messages, public channel text, messages, notices, or CTCPs. If you have your Userlist window open, you may see a lot of strange activity in that window, users coming and going quickly and so on, without any corresponding activity in the main channel window. This is normal, it's just HipScript trying to protect you from being lagged by Ircle's relatively slow window text drawing and scrolling. If this is happening, closing your Userlist window may help even more, as it removes the burden of redrawing it so quickly.
If you are an op, there are some recent improvements in how HipScript attempts to protect your channel from the flood...
In the past, once HipScript detected that a given IP/hostname was a flooder, it would try to kick any user from that IP/host joining the channel. In practice, it turns out that this would often slow down Ircle and HipScript even more, because the most common form of flooding is to join, sometimes dropping some text into the channel or sending a CTCP or msg to the channel, then part or signoff right away. By time the kick commands HipScript sent made it to the server, the target of the kick was gone and then the server sends back an error message, lagging your connection even more. Now when clones are detected HipScript will kick all the clones at once (when the limit is exceeded) and then mark that IP/host as a known flooder. When the detection is based on the number of joins (rather than on the clone limit) the IP/host is just added to the known flooders list. In either case, a ban is set immediately to try to keep new flooders out, but it often takes the server a while to process that ban and get it distrubuted to all linked servers. When new users on the known-flooders list join the channel, they are not kicked immediately. Instead, their nick is placed on a "pending kicks" list. That list is allowed to grow to 10 entries before anything happens. Once there are 10 nicks on the pending kick list, every time a new nick is added, the oldest nick on the list is checked. If that oldest nick is still in the channel, that's when a kick command is sent. The point of this is that if the flooders are joining and leaving quickly by themselves HipScript never sends in any needless kick commands. If the flooders aren't leaving by themselves, then they kicked pretty quickly anyway. Once the flood seems to have stopped (10 seconds after any new flooders join), the remaining 10 nicks on the pending-kick list are kicked if they're still in the channel at that time.
HipScript also now has an option to try to deal with floods that come from more than one IP or hostname at a time. When a flood from a given IP or hostname is first detected, a ban is placed immediately to try to keep that flooder out. If a flood from a different IP or hostname is then detected within 60 seconds, HipScript will try to set channel mode options to keep flooders out (assuming you've specified what modes to use for that, see the /joinfloodmodes command). After the flood has died down, HipScript will reset the channel modes to their normal settings.
Despite these improvements, HipScript can't completely prevent clone and join floods, for a variety of reasons. The primary reason is because IRC servers are linked into a distributed network and there is always some lag between the servers. When HipScript sends a ban or mode-change command to the server, it has to be forwarded to all linked servers, and that takes some time. If the flooders are using a server that's lagged 2 seconds from the server you're on, then it will take at least 2 seconds for the ban command to reach that other server. In 2 seconds, a flood program can easily do 200 join/parts. All those join/part events are going to be delivered to Ircle no matter what -- in other words, that much of the flood has already happened and all you can do is roll up your pant-legs and watch it cruise by. HipScript tries to make this better by not displaying all the events, but remember that other non-HipScript users in the channel are going to see the whole mess. Some of them are probably going to be knocked offline by it.
HipScript can also be fooled by certain types of floods that use many IP addresses. If the flooder has many IP addresses available to it (I've seen floods come from more than 50 different IPs at once), and if the flooder has designed his attack to join one nick from each of those IP addresses at a time, then that doesn't look like a flood to HipScript. Eventually, those 50 flooding users part, then 50 more join. Then they part, and 50 more join. Now it's starting to look like a flood attack to HipScript, and it starts getting dealt with using bans and channel modes, but 150 or more join/part events have already happened.
You might ask "Why doesn't HipScript just consider any large number of joins from different addresses in a short time to be a flood?" Well, maybe in your channel that would be a sure sign of a flood, but there are channels which routinely have large numbers of joins in a short time just as part of their normal operations. (Personally, I don't know why people hang out in channels like that, but I can't write a script that kicks innocent users without pissing off the ops of that kind of channel.) Netsplits can also cause problems along these lines; when a netsplit mends in a big channel, you can easily have 100 joins or more in 2 seconds, all of them innocent non-flooding users.
I'm not giving up on dealing with these floods from many IP addresses. Like I said at the beginning of this rambling diatribe, it's an arms race. Right now, I'm a bit behind in the race based on some floods I've seen recently. I continue to research ways to better protect your channels without impacting your normal operations and innocent users. Future HipScript releases will almost certainly have more flood protections in them as I continue to learn more about how the flooders are attacking.
/aub
/aub Off
/aub quiet | -quiet
/aub wildcards | notwildcards
/aub hh:mm:ss
This command changes or displays the default auto-unban time. With no parameters, it displays the current auto-unban time.
If the parameter is "Off", the auto-unban feature is disabled and any subsequent bans will not schedule a delayed unban automatically. This is the initial default until you configure a value.
If the parameter is a time (as described under the /delay command), then subsequent bans will schedule a delayed unban to run after the specified time.
The quiet | -quiet option turns on/off the display of the automatically generated /delay commands that do the unbanning.
The notwildcards option suppresses auto-unbans for any ban having wildcards in the hostname part. This works well in conjunction with the /reban command -- first you kickban someone by specific hostname, then they ban evade, you end up kicking them again and doing a /reban. The wildcarded bans set by the /reban do not get an unban scheduled for them.
/autokick
/autokick mask kick msg
/autokick -mask or -number
/autokick [on | off]
This command creates, deletes, or displays entries on your personal auto-kick list. Auto-kicks are similar to kicks set by Ircle's Friends list, except that you can have a custom kick message for each lamer on the list.
Used with no parameters, this command lists all the auto-kick entries.
Used with a mask and optional custom kick msg, this command creates a new autokick entry. The name mask can be any part of nick!user@host, with wildcards allowed. For any part you leave out, wildcards are supplied by the script. (EG, just "Joe" turns into "Joe!*@*"). If you don't supply a custom kick message, the rather dull default message, "Auto-kick" is used.
Used with -mask or -number, this command deletes the specified entry.
When a user matching an entry on the list joins any channel in which you have op privs, that user is banned and then kicked using the message set up with the mask.
By default the ban is placed as *!*@current.host.info so that the user can't just switch nicks and reenter. If the first 3 characters of the kickmsg string are an NUH ban mode as described for the /bannick command, the ban is placed using that type of wildcard, and the rest of the words are used as the kickmsg.
If you use /autokick off, all autokick processing is temporarily disabled, until you do /autokick on. This setting is not saved in the prefs, since it's useful mostly to temporarily disable autokicks while you're guest-opping in someone else's channel or something.
/bannick nickname NUH
This command bans a user based on nickname. The values of the characters in the NUH positions control masking on the ban. NUH stands for Nick, User, Host; the character in each position controls how the banmask is built, as follows:
* - Puts a literal '*' in that position
V - Puts the value of the nick, username, or hostname in that position
W - Wildcard-masks the nick, username, or hostname in that position
D - Wildcard-masks the entire domain, valid only in the hostname position
Thus, given a user joe!joeblow@ppp12.isp.com, a /bannick joe *VW would create a banmask of *!joeblow@ppp*.isp.com.
You can use this command to ban a user who isn't in the channel you enter the command into. It attempts to look up the user@host info for the given nickname via the server command /userhost, and place the ban based on that.
All of HipScript's internal bans (for floodkicks, autokicks, etc) use this command to construct the banmask, usually with an NUH mask of **V. All bans placed by this command will ban both the hostname and IP number if "/iphostban on" is in effect.
This command will be most useful if it's covered with an alias. Something like:
/alias kbn /bannick $1 *WW\n/kick $channel $1 $2-
This would ban the user (with wildcarded username and hostname) and kick them with the message that follows their nickname on the /kbn command you enter.
As a rule, if you don't use a * in the username position, you should use W rather than V. This will cover non-idented users that have a ~ at the start of their username.
HipScript's style of wildcarding a hostname replaces all sequences of adjacent digits with a *. This is usually preferable to just using *.last.nodes, because many ISPs have geographic info in their hostnames (EG, den-co12.ppp2.isp.com becomes den-co*.ppp*.isp.com), and it's better to ban just Denver users than all users from that ISP regardless of location. In a few cases, this doesn't work well; AOL always makes a good example of things that don't work well: their hostnames are of the form ###-###-###-###.aol.com, which makes the mask effectively *.aol.com. Oh well.
/clonelimit nn [kick message words]
This command sets the limit on how many clones (users from the same address) you'll tolerate in the channel. It also controls clone detection in general. If the clone limit is set to any number higher than 50, clone checking is completely disabled. For numbers lower than 50, clones are detected and reported as they join a channel you're in, and if you have ops privs in that channel, clones are kickbanned when the limit is exceed.
A clonelimit of 1 means you'll tolerate an original copy of a user plus one clone of that user. A clonelimit of 0 is allowed, and means you won't tolerate clones at all.
When the limit is reached, a warning is sent to the clone that no more will be tolerated (unless disabled by the /clonewarn command); if exceeded, all the copies of that address are kickbanned (if you're an op on the channel). When the clonelimit is zero, no warnings are sent, (because it would be obnoxious to warn everyone who joins that they can't have clones), but the kick will still happen if a clone joins.
The initial clonelimit is 99 by default, so clones won't get detected or kicked until you set a more reasonable limit (2 or 3 is usually good for kicking, 20 is good for detection-only).
Clone checking is also automatically disabled if there are more than 200 users in the channel. The more users there are in the channel the more CPU cycles the clone checking uses up, and 200 is the point at which even fast modern processors start to bog down doing the check for every joiner, especially because channels that large tend to have a lot of join/parts.
/cloneokay addressmask
/cloneokay -addressmask
This command sets an address mask from which you'll tolerate any number of clones. To remove an address, use -address. To show the current list, don't supply any parm. Note that this must be just the host or IP part of the address, no nick or user@.
There are also two special entries you can add to your cloneokay list, "+o" and "+v". These indicate that clones of opped or voiced users should be ignored.
/clonewarn [on | off]
This command sets whether to send a warning to someone when they've reached their clone limit.
/iphostban [on | off]
This command controls the HipScript feature which automatically bans both the hostname and IP number for bans placed by internal script features and the /bannick command.
When set on (the default), it automatically does a /dns lookup for any hostname or IP number you ban, and sets the corresponding ban on the other form of the address. For example, if you do a /bannick Joe **W and Joe's hostname is ppp12-isp.com and IP address 192.100.10.38, it will ban ppp*.isp.com and 192.100.10.*. The ban on the form of the name the user is currently logged on as is placed immediately, and the ban on the other form of the name is placed with the /dns results are available.
Using the "/autodns all" or "/autodns silent" setting can vastly speed the placing of the alternate-form ban, because it'll be highly likely that the alternate form of the address will be in your machine's local DNS cache from when they joined.
Using iphostban isn't as good an idea as it used to be. Modern IRC servers now do their own host/IP mapping (to some degree anyway) so this command mostly just makes the banlist twice as big as it should be.
/joinflood limit [kick message words]
This command sets the limit and kick message used for protecting against join/part floods. If a user (detected by host, not nickname) joins and parts a channel more times than the limit without allowing at least 20 seconds to elapse between any pair of join events, the user is kickbanned. Don't set this too low, or netsplits will cause spurious kickbans. Something in the range of 5-12 should be a good value.
Set the limit to a number higher than 50 to disable detection and kickban on join/part floods.
20 seconds was chosen as the limit because if the join/parts are happening slower than that, you'll be able to manually select the user and kickban them.
This command now also helps protect non-op users from floods, by detecting flooders and ignoring everything they do.
/joinfloodmodes "+setmodes" "-resetmodes"
This command is used to set/reset channel modes to help deal with a flood from multiple IP addresses. A favorite trick of flooders these days is to use anything from 5 to 100 different IP addresses or hostnames for flooding. This can quickly fill up a banlist, and bans are an "after the fact" reaction to the flooders anyway; it's preferable to keep the flooders out in the first place.
The quotes are required around the parameters if there are any spaces in the modes.
When an op uses this command to specify channel modes to set during a flood, HipScript's reaction to floods changes slightly. When the first flooder is detected (through either the cloneflood limit or the joinflood limit) that flooder is kickbanned as usual. If a second flooder with a different IP or hostname is detected within 60 seconds of the first, HipScript will send a /mode command for the channel to turn on the "setmodes" specified by this command. The modes stay in effect until 10 seconds passes with no newly-detected flooders, then HipScript sends a mode command using the "resetmodes".
In general, "setmodes" should be a combination of modes that helps keep flooders out of the channel and quiet if they do get in, and "resetmodes" should undo the changes. A common technique that many scripts use is to set a channel to "+im" (invite-only and moderated). The +i keeps new flooders out, and the +m keeps them from flooding the channel with text. In this case, the resetmodes would be "-im".
I recommend that instead of +i to keep new flooders out, you use "+k FloodStop"; that is, make your setmodes "+mk FloodStop" and your resetmodes "-mk". Why? Becase using a channel key instead of invite-only will ensure that you don't get locked out of the channel yourself. Sometimes a flooder does such a good job that you actually end up losing your connection to the server during the flood. There's nothing more frustrating than being unable to get back into your channel when you reconnect, which is what will happen if the channel is +i. (Sure, you may be able to invite yourself back in using Chanserv or a channelbot. But what if they're lagged?) If you set a channel key and then lose your connection, you can still get back in by providing that key on your join command (eg, /join #macintosh FloodStop).
/nickflood limit [kick message words]
This command sets the limit and kick message used for protecting against nick-change floods. If a user changes nicknames more times than the limit without allowing at least 20 seconds to elapse between any pair of changes events, the user is kickbanned from all channels you have ops in that the user is also in. Something in the range of 7-12 should be a good value.
Set the limit to a number higher than 50 to disable detection and kickban on nick-change floods.
20 seconds was chosen as the limit because if the changes are happening slower than that, you'll be able to manually select the user and kickban them.
/matchkick nick[!user@host] NUH kickmsg
This command will kick multiple users matching a nick!user@host, all with the same kickmsg.
If just a nickname is given, that person's user@host is looked up, then a ban is set according to the NUH ban modes, and also any other users in the channel matching the ban are also kicked. If a full nick!user@host is given (containing wildcards or not), the NUH is used to convert it to a possibly-wildcarded ban, and all matching users are kicked.
The first 3 characters of the kickmsg string are an NUH ban mode as described for the /bannick command. Each user is banned using that type of wildcard, and the rest of the words are used as the kickmsg.
/multikick [match] [NUH] kickmsg
This command will kick multiple selected users, all with the same kickmsg.
This can be very useful together with the /alias and /button commands. If auto-whois shows you a series of people joining and all of them are opped in the channel #PC4LIFE, you can pretty much predict that lameness is imminent. As each joins, you can cmd-click to add them to a set of selected users in the userlist window. At the first sign of lameness from any of them, you can clean up the whole mess with one command (or the click of one button if you've used /button to set up some /multikick commands with canned kickmsgs).
If the word "match" follows the command (but precedes the NUH banmask) the operation becomes more complex. It proceeds through the list of each selected user, and for each user places a ban using the NUH mask (including wildcards). It then matches that mask against the entire userlist for the channel and kicks anyone who matches. For example, if you had a user selected whose info is Joe!lamer@some.isp.com and you do "/multikick match **D Lamers be gone", then every user currently in the channel who matches *!*@*.isp.com would be kicked. This can be handy for removing spambots working in pairs.
By default the users are kicked but not banned. If the first 3 characters of the kickmsg string are an NUH ban mode as described for the /bannick command, each is banned is using that type of wildcard, and the rest of the words are used as the kickmsg.
/reban [mine] [ W | D | NUH]
This command will "widen" the last ban placed by anyone in the channel, by changing it to a ban that includes wildcards. If you specify the word "mine" it will widen the last ban you placed, rather than the last ban anybody placed.
By default, or if you add the W option, a standard HipScript "smart wildcard" banmask is used (numbers replaced with wildcards) to wildcard the hostname. If you use the D option, a domain-ban is used. You may also specify all 3 characters of the NUH mask, as described under the bannick command.
Note that "/reban mine" may not work well if you have the /iphostban option turned on.
For dalnet users, /cloneokay *dal.net is a good mask to use; it prevents kicking folks who are using the dalnet telnet client.
To automatically unban users 30 minutes after they're banned, use:
/aub 30:00
The minimum unban delay is 5 seconds (because the delayed commands plugin only checks for pending commands once every 5 seconds).
You must use a colon (:) to separate the hours, minutes, and seconds, even if the country you live in (and AppleScript dialect you use) typically uses a dot (.) to separate time components. Sorry, it's an AppleScript limitation that would take tons of special code to try and fix.
A delay of 30 to 60 minutes works pretty well for all but the most brain-dead lamers you ban.