View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002786 | unreal | ircd | public | 2006-02-01 08:43 | 2015-10-30 12:42 |
| Reporter | White_Magic | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.1 | ||||
| Summary | 0002786: Spamfilter VS Server Commands | ||||
| Description | many nets use neostats, and its ablity to kill/*line ANYONE who joins a particaluar room, while we have blocked the room name being typed via the spamfilter , users are managing to set +L #room2 and then forcing the limit to be 1, they join another room and claim flood! in #room2 and anyone who joins #room2 is diverted to the room that will get u killed or auto *lined on join - this INCLUDES ircop - I remember the report aout the aliases for services, is it possible a special target can be added to make it also check all commands to the server, like /mode this was discovered on 3.2.1 but i presum as theres no word on the filter checking server commands that it wont stop them doing this on the 3.2.3RC3/4 clients. *This note is marked private as i feel others users should not be allowed to see this trick, as it will get any ircop *lined* | ||||
| Additional Information | Secureserv doesnt sit in the room, so adding modes like +i or *!*@* ban wont stop them from joining, as there is nothiong to hold the modes or ban. | ||||
| 3rd party modules | |||||
|
|
I think a +L blacklist was suggested before (sounds basically what you want). Btw, a services module (for example) could actually fix things for you as well, as soon as it would see a +L with the "bad channelname", it could unset the -L and/or take other actions :p. (just an interim suggestion) |
|
|
yeah well its ircqnet thats having this problem the most, cu has had it once, but we stopped using the channel feature of secureserv :D and since ircqnet only update to stable releases im kinda hoping a filter or some kinda anti-trick bug is added so when they take 3.2.4 release it`ll stop it from happening. and the admins there are, well u know, maybe a blacklist would be easier indeed, depends how many commands they can use to take advantage of such a system |
|
|
oh, well it certainly won't be in 3.2.4. That one is going to be released on Friday ;p. This problem can be solved at multiple levels, a services module (but yeah this needs coding), an irc module (also needs coding, should also run at all servers instead of only services), or.. well.. hmm.. You could disable +L of course (set { restrict-channelmodes "L"; };).. depends on how bad the problem is [tradeoff] :). *edit* btw they could still set +L via chanserv mlock, unless your services has some way to stop that too */edit* |
|
|
nah the build and version of ircservices is nearly as old as the network itself, so they dont have that, and yes they could use the mlock L trick ircservices-4.5.45 services.icq.com build #2, compiled Tue Dec 16 04:26:56 EST 2003 i ws just thinking thou while cooking, another reason why i think this good to implent: -- Bots are often made to join certain channels on connect, a filter target like this would esstinally take them out as soon as they connected becuz they`d run the /join command, hits the filter and bye bye. this is safer as well for ircops, it allows them to join and part the room freely as they`d be exempt from the filter, and of course, anyone who know the bots were going there would be removed as well for typing the room name. Other commands i had in thought it would be good for, is /Knock /invite /privmsg and /notice - if its possible to filter out who / which room it was going to use as the target, it would be able to remove them rather than " reject them " - however its seems very weak. just a thought or two thou *edit added in the services build and version reply lol * |
|
|
Bump. Still an issue? |
|
|
it always will be untill a +L blacklist is made on the servers side to be honest. ircqnet use +L all the time to keep their public channels under a sensible limit so only a blacklist would be suitable for them. |
|
|
Not anymore as neostats has been dumped and no longer used (for our networks anyway) but im pretty sure this problem will always exist as long as there is some kind of " kill/ban on join #channel " function, i dont believe anymore it is a unreal error either. unless an idea similiar to http://bugs.unrealircd.org/view.php?id=3055 is used, if the server knows #channel is gonna be on kill, restrain +L #name from being set, not sure the impact of that would be thou. |
|
|
I think a quick fix for this is to check to see if the person setting +L is at least a chanop in the target channel. This will stop the +L forwarding to a "jail" channel as normal chanops wont have access. IE: bored user knows that #spammer1 is "jailed" so to get a good laugh they set their channel +lL 1 #spammer1 An Alternate idea is to have a new chanmode that would disallow said channel from being a target of +L. This would be less limiting and likely less resource intensive due to the few number of checks. IRCops can then immune official and jail channels. UPDATE: Not sure if this possibility exists, but if it does, it might also be a good idea to insure that channels can't be looped. IE: set #chan1 +L #chan2, set #chan2 +L #chan1. |
|
|
Hmm. I don't think this is particularly useful. If you decide to kill any user joining a room, you are taking quite a risk. So yeah if someone decides to forward another channel to that one... :) As said, if you don't like +L, then you can decide not to load the module for it. Much easier in UnrealIRCd 4 too. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-02-01 08:43 | White_Magic | New Issue | |
| 2006-02-01 10:58 | syzop | Note Added: 0011108 | |
| 2006-02-01 11:12 | White_Magic | Note Added: 0011109 | |
| 2006-02-01 15:28 | syzop | Note Added: 0011111 | |
| 2006-02-01 15:29 | syzop | Note Edited: 0011111 | |
| 2006-02-08 10:13 | White_Magic | Note Added: 0011182 | |
| 2006-02-08 10:17 | White_Magic | Note Edited: 0011182 | |
| 2007-04-27 05:38 |
|
View Status | private => public |
| 2007-04-27 05:39 |
|
Note Added: 0013827 | |
| 2007-04-27 05:39 |
|
Status | new => feedback |
| 2008-08-05 21:13 | White_Magic | Note Added: 0015338 | |
| 2011-04-09 16:52 | White_Magic | Note Added: 0016642 | |
| 2011-04-10 05:41 | katsklaw | Note Added: 0016645 | |
| 2011-04-10 05:42 | katsklaw | Note Edited: 0016645 | |
| 2011-04-10 20:44 | katsklaw | Note Edited: 0016645 | |
| 2015-10-30 12:41 | syzop | Note Added: 0018836 | |
| 2015-10-30 12:41 | syzop | Status | feedback => closed |
| 2015-10-30 12:42 | syzop | Assigned To | => syzop |
| 2015-10-30 12:42 | syzop | Resolution | open => no change required |
| 2015-10-30 12:42 | syzop | Note Edited: 0018836 |
