View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002127 | unreal | ircd | public | 2004-10-16 03:42 | 2006-01-19 10:33 |
| Reporter | Zell | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.1 | ||||
| Summary | 0002127: Invite-Flood Protection | ||||
| Description | Though we have all sorts of protection for floods, we don't really have a solid one for Invite-Flooding clientside. A bot can join up say 6 rooms and flood out users with /invite user #chan Could we, say, add a UMode for blocking invites? And send an error message along with that, so it will flood the bot with errors, instead of the user with invites. | ||||
| Additional Information | If needed, I can begin research on adding this [and paste code I develop so that you Coders [codemastr/syzop] can "fix" it into UnrealIRCd-acceptable code. I propose to use Usermode +Z, unless you have a different one in mind. | ||||
| Attached Files | noinvite.txt (968 bytes) | ||||
| 3rd party modules | |||||
|
|
Of course, if you're really paranoid: set { modes-on-join "+V"; restrict-channelmodes "V"; }; Problem solved :P . Until they get smart, register the channel, and mlock -V :-/ . Only problem is, invite involves more than just sending a nice message to the client. It also involves several state changes, such as marking the user as allowed to banwalk or keywalk, for example. If the ircd where to reject sending the invite, would it also reject setting this information? In any case, I wouldn't mind seeing something similar DCC Allow, or hybrid's +g, for this perhaps. For example: /umode +Z /invallow +#Channel1 +#Channel2 -#Channel3 etc That way I can still get the invites for the channels I want invites from, without having to temporarily open myself to being flooded by spammers. |
|
|
doesnt SILENCE stop invites? or is that only for priv msgs / notices, if not i would say rather than make up extra umodes etc just readjust the silence list to handle the invites as well, seems most logical (?) |
|
|
Most clients have such an ignore system already. I see no reason to add this. All it will do is, as with the last flood-stopping suggestion, require me to store an invite counter in every single user causing more memory to be used when 99% of users won't use this feature. |
|
|
Well, the idea is, floods ignored by the client can still be destructive (eg, I might be ignoring the invites, but that's not stopping someone from filling up my sendq with them). Floods stemmed by the server are less so. Anyway, I don't think the idea is to have flood control (though that could be useful) calculated by the server, but to have a mode to server-side block invites altogether, and possibly make exceptions for certain channels. Though I think White_Magic may have the right idea here to just tweak SILENCE to ignore invites. If I'm blocking privmsg/etc from someone, why do I want invites from that person? You are right that there are a few clients (namely major ones like mIRC and Klient) that have a more advanced ignore system than unreal's SILENCE, but if a client could take advantage of SILENCE instead of doing ignores on its own (and thus still be open to being sendq'd or something)... I imagine flooders would be noticably less successful. |
|
|
You're right, sendq is an issue. However, Unreal already rate limits the text sent by clients so as long as the server provides a reasonably sized sendq, that will never happen. Also, Unreal supports recvq limiting which will prevent the flooder from sending too many invites to begin with. |
|
|
Well, my thought to coding it, is if the destination user is +Z (or whatever mode would be chosen), then the command would be rejected automatically without setting flags [as aquanight pointed out] - the effect would be similar to the +K and +V chanmodes which deny the command if a certain condition exists. I know my network and White_Magic's network would most likely lock +Z to the modes-on-connect because they are prone to a lot of flooders and I'm sure they'd enjoy the new protex. Shouldnt be too hard to code, ive already started working on it. |
|
|
[quote]You're right, sendq is an issue. However, Unreal already rate limits the text sent by clients so as long as the server provides a reasonably sized sendq, that will never happen. Also, Unreal supports recvq limiting which will prevent the flooder from sending too many invites to begin with.[/quote] That might work for a small flood, but when it's a really serious flood (maybe 500 or so bots involved?), I don't think recvq is going to matter. Mind, if someone's going to sic 500 floodbots on you, you've probably got worse things to worry about than a nice little ERROR :Closing link yournick[blarp.blah] (Max SendQ). But that shouldn't stop us from providing methods to protect users from those who have nothing better to do than just make everyone else's lives miserable. *edit* Anyway, I'm not so sure about sending an error message really... I guess it would make sense, most everything else does... edited on: 2004-10-16 16:54 |
|
|
Completed Work on Usermode +Z (Deny Invite). I'm attaching a text file with the list of the modifications. I suppose you could remove the error message from it, but that would be against the RFC wouldnt it? Unreal Coders: feel free to modify the code I gave if necessary. mIRC Debug Output of an Invite (with the given code): <- :SkyNet.Zell.Net 989 Zell :Cannot invite Auron to channel #Services - User is blocking Invites (+Z) |
|
|
i still recon, the silence list should be tweaked for this, or, the silence list should become extended.. something like this? -> /msg irc silence *!*@* <--- stops the mask + everything they do or -> /msg irc silence +n *!*@* <-- stops all notices -> /msg irc silence +c *!*@* <--- stops all channel notices -> /msg irc silence +i *!*@* <--- Stops all invites bearing in mind that +V users get them convertd into privmsgs im sure it would still be possible to stop those priv msgs. |
|
|
Webbies arent the only ones on the net, though, their population is nearing that of fire ants. UnrealIRCd Team:: If you could examine the code I posted and tell me if its acceptable as a modification to the Source. If not, I could adjust it if needed, or you guys could (since you probably know more about it than me lol...). I get no bugs here running it on U-3.2.1(*nix), U-3.2.1(Win32), and U-3.2.1b(Win32). The code mods listed are for U-3.2.1 though they can be easily incorporated into 3.2.1b |
|
|
I don't see any code... |
|
|
eh... oh sh*t!! when i attached i must not have hit 'upload'.. f*ck! and i already erased the changes file -_- looks like i gotta rebuild it grrr ---Added the file now edited on: 2004-10-20 15:49 |
|
|
Coders: Prior to releasing 3.2.4, this may be a nice feature to add. Please consider adding this feature. If at this time you do not find interest in the issue, you may close the bugnote. -Z |
|
|
Hm, I don't think we should add this. Btw, Zell, for what it's worth.. this can be implemented excelent in a module :P. Just a PERM module, add a umode, commandoverride "INVITE", check the target user based on parv[1].. etc. Very small module :). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-10-16 03:42 | Zell | New Issue | |
| 2004-10-16 05:42 | aquanight | Note Added: 0008015 | |
| 2004-10-16 14:44 | White_Magic | Note Added: 0008016 | |
| 2004-10-16 15:46 |
|
Note Added: 0008018 | |
| 2004-10-16 15:58 | aquanight | Note Added: 0008019 | |
| 2004-10-16 16:03 |
|
Note Added: 0008020 | |
| 2004-10-16 16:08 | Zell | Note Added: 0008021 | |
| 2004-10-16 16:51 | aquanight | Note Added: 0008022 | |
| 2004-10-16 16:54 | aquanight | Note Edited: 0008022 | |
| 2004-10-16 21:12 | Zell | Note Added: 0008024 | |
| 2004-10-17 14:36 | White_Magic | Note Added: 0008032 | |
| 2004-10-18 21:36 | Zell | Note Added: 0008038 | |
| 2004-10-18 22:52 | aquanight | Note Added: 0008039 | |
| 2004-10-20 15:37 | Zell | Note Added: 0008053 | |
| 2004-10-20 15:49 | Zell | Note Edited: 0008053 | |
| 2004-10-20 15:49 | Zell | File Added: noinvite.txt | |
| 2006-01-16 23:59 | Zell | Note Added: 0010975 | |
| 2006-01-19 10:33 | syzop | Status | new => closed |
| 2006-01-19 10:33 | syzop | Note Added: 0010980 | |
| 2006-01-19 10:33 | syzop | Resolution | open => no change required |
