On Thu, Aug 23, 2018 at 3:57 PM, Jimmy Hess <mysidia@gmail.com> wrote: <snip> Is there something unique about what is happening in the flood events that
prevents perpetrators working around delay timers and message-specific rules?
No, we always consider new features to help us make DALnet better.
Many of these such as Join_Connect_Time would surely have a large negative impact on legitimate users and "normal operation" greatly while active.
I disagree, only channels who want to use this feature will enable it and those channels probably already using the +MR channel modes.
I'm sure we could look at features of Text messages besides "Is it CTCP or not?" and "Is it Notice or not?" --- I would assume if CTCPs and Norices are blocked; the abusers don't stop flooding attacks: they just pivot to a different kind of disruptive message; Probably something dense in control characters ---- detectable If a dynamic message classification scheme could be implemented.
This is true, however, one of our goals is to minimize the effect floods have on clients and this will surely help.
Are those creating the flood attacks using registered nicknames?
Not at this time.
Perhaps some extensions above +r to "Increase the threshold of identification" As in extended User Flags as in SVSXUF <username> :REGISTERED:<Timestamp of nick registration> SVSXCF <channel> EXEMPT_REGISTERED_BEFORE:<N> <- Exempt nicknames identified/registered before the given Timestamp or identified to a nick registered for a given number of days SVSXUF <username> :IDENTIFIED_2FA <- User Logged into NickServ in a manner requiring Two-Factor Authentication such as OATH-TOTP or E-mailed one time password, suggesting this is not a stolen nick account SVSXCF <channel> EXEMPT_IDENTIFIED_2FA
Something like that can added at a later stage if/when we'll see floods with registered nicks.
It seems like having the extended channel flags is an improvement over re-using simple cmodes, but still inadequately expressive,
I'm sure our servers can handle it... :) so far as enabling channel managers to easily adapt quickly as abusers
adapt, without further Ircd changes every time abusers change their behavior. Ideally there would be a mechanism to create parseable rules with test conditions such as pattern matches boolean logic, arithmetic, relational expressions, bitwise tests, and boolean combinations on tests for any attribute that Ircd or Services knows related to the Sending user/their relationship to channels. To form Join/Message conditions or..
* Have a custom "Ad-Hoc challenge" or "Captcha" prompt start coming up for users joining a "Channel Under Attack" or "Controlled user Join Mode"
* Chanops can set a timestamp XYZ the Attack began defaulting to now and "Timeout" (number of seconds/mins/hours to apply)
* Open join condition: Logical expression users joining can meet to skip Join Control: such as Nickserv users registered 24 hours before attack started at XYZ timestamp or connected to IRC before XYZ - <delta>.
* Some form of Challenge/Custom CAPTCHA definition such as:
Channel X option challenge_header :Please be advised, you need to answer the following challenge to join this channel: Channel X option challenge_prescript :var a = Math.round(Math.random()*5); var b = Math.round(Math.random()*5) Channel X option challenge_prompt : response.add("What is " + a.toString() + " plus " + b.toString() + " ?") Channel X option challenge_answer : challenge.addAnswer("My answer is " + (a+b).toString()) Channel X option challenge_footer :To complete the challenge, within 1 minute: please type /join ${channel.name} :My answer is <ANSWER>
Those are great ideas but we save them for a later stage (via services logic rather than the IRCd). <snip>
Require by rule Bots which automatically send any automatic messages, respond to any remote control commands, or automatically Join/Part any channel for any reason to declare themselves:
I see your point but It's unlikely we'll require users to register their bots (in any way) as this will surely make people's life harder. Thanks for the feedback! -Kobi.