Raid Protection

[thebeanogamer]

Is your feature request related to a problem? Please describe.
Gaius has repeatedly failed to detect and block raids, we need to redo this.

Describe the solution you'd like
Detect high rates of joins? This needs suggestions so it doesn't overreact to things like the flood of users we get when Assess opens.

[ZomBMage]

Should be easy enough, autotrigger on a certain number of joins in 30 seconds, then do some funky stuff

[thebeanogamer]

Year 2 particularly, we exceeded that for legit users though. I suppose that's a boundary test...

[thebeanogamer]

I suppose if it was high enough that could work though.

[ZomBMage]

Just make the command enable/disable-able? So if we can preempt lots of users joining at once, like Elite camps, we can just disable it for a time

[thebeanogamer]

:lockdown could also be an option, kill all invites and the permission to generate invites? Then :reopen to generate a new invite and hit the Cloudflare API to update the short URL?

[Bottersnike]

I think bulk invite killing would probably be better on a differently named command. :lockdown would suggest more that new users are locked out of all channels and have no read/write perms anywhere until the server is unlocked again.

[thebeanogamer]

Multiple staff member turnkey perhaps?

[thebeanogamer]

I think bulk invite killing would probably be better on a differently named command. :lockdown would suggest more that new users are locked out of all channels and have no read/write perms anywhere until the server is unlocked again.

Yeah, this is a good point

[Sh3llcod3]

So with some discussion with Picapi he proposes a system that hits these points:

• Some sort of analysis system where new members can be assigned a score and based on that redirected to some captcha, some system to slow them down and verify that they're a legitimate user

• Some sort of system where in case of mass joins, which is detected as suspicious, the system turns off the Dyno join/leave messages

• Some way for Sudos to revoke invites/re enable them

• Auto slowmode/auto kick if high volume of joins detected with DMed message

[JamesVStone]

I have seen some bots that generate a captcha and DM it to the user. You could add a system which you can control :captcha on/off to help prevent raids.

[Sh3llcod3]

This sounds interesting 👀

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[Skiller9090]

Or we could just have a time based system where you do the command:
:userlimit {number}
and it will limit the amount of users per min and this can be changed all year round allowing for influx of large players at access and slow amount during early summer

[RealJammy]

Or even better: add beancon

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[RealJammy]

beano I know you read this please make sure this doesnt close

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[RealJammy]

beanman pls make sure this doesnt stale again uwu

[0xAda]

just run a selfbot on your account that deletes the server if people join too quick

[thebeanogamer]

Thanks Dave

[0xAda]

always happy to help

[JoshHeng]

The way I've implemented it in my bot is that it's triggered after x members join in a minute, after which it just DMs all new users a link to an online captcha and kicks them from the guild. If they complete the online captcha successfully, the bot will generate a one-time invite for them which bypasses the kicking system.

As far as I'm aware this would be the best (but still not ideal) option if we needed this, as:

• Removing all invites could be a pain as they would all have to be regenerated, etc. I know we have the url through Cloudflare, but individual invites are still floating around
• Removing all invites would mean legit users wouldn't be able to join
• Handling the captcha process completely in DMs isn't possible as the bot/user cannot communicate if the user is kicked from the guild. If the user isn't kicked but simply doesn't have access to any channels, I believe they can still see the member list (on a hacked client or something) and mass DM

The downsides to this solution is:

• It wouldn't prevent a human raid as they could just solve the captcha, but it could deter them
• It would require a website to be linked with the bot, which is probably overkill
• Our bot would have to handle welcome/leaving messages because the continuous joining/leaving would spam messages

Basically I don't think there is any optimal solution, it's just finding the least-worst one. It might be best to just leave it completely or find a dedicated bot

[JamesVStone]

Building on @JoshHeng 's ideas. When raid protection is on, new users could muted by default and are DM'd a capcha image (plenty of great libraries to do that) + wait 5 minutes and the muted role is removed. (adjustable)

When I looked at this before, one thing which jumped out is that when multiple instances are running in the k8s cluster there is no way to move state between them. Essentially, we'd need to store state (@thebeanogamer some info on how/where this is run / any ideas for state storage would be great e.g S3 / scratch cloud variables 🤣 )

As for the website concept. Mixing external API from websites isn't always simple: the best way I know of to do that is with a task queue like celery but is terms of setup / dev: infeasible. This would be much easier to do just inside discord.

[JoshHeng]

Building on @JoshHeng 's ideas. When raid protection is on, new users could muted by default and are DM'd a capcha image (plenty of great libraries to do that) + wait 5 minutes and the muted role is removed. (adjustable)

When I looked at this before, one thing which jumped out is that when multiple instances are running in the k8s cluster there is no way to move state between them. Essentially, we'd need to store state (@thebeanogamer some info on how/where this is run / any ideas for state storage would be great e.g S3 / scratch cloud variables 🤣 )

As for the website concept. Mixing external API from websites isn't always simple: the best way I know of to do that is with a task queue like celery but is terms of setup / dev: infeasible. This would be much easier to do just inside discord.

If users are muted by default and not kicked, I think selfbots can still view members and mass DM - idk if this is an issue, or if we are just trying to prevent spam in #general

I don't think we would need multiple instances & clusters given that this is just for a single guild (I'm assuming that's what you mean?) We could probably store a temporary list of captcha users in the bot itself, or persist it in the db we already have (or have a specific role for this and persist captcha users by checking who has the role)

And yeah the website probs isn't a good idea unless we already have one (idk what's happening with the moderation/quote website ideas)

[JamesVStone]

I don't think we would need multiple instances & clusters given that this is just for a single guild (I'm assuming that's what you mean?) We could probably store a temporary list of captcha users in the bot itself, or persist it in the db we already have (or have a specific role for this and persist captcha users by checking who has the role)

Ignore me, didn't see the database. None of that matters if there is persistence, which there is: database. Oops.

[thebeanogamer]

Honestly, we're less bothered about blocking the accounts behind a CAPTCHA, and more so about being able to revoke users ability to create invites and destroying the existing ones. Obviously doing that automatically would be great but it isn't the end of the world if it's manual.

Just turning on and off the permissions for @.everyone to create invites and deleting all the existing ones when a command is run is good enough to get the ball rolling on this.

Also, the DB doesn't presently persist. It will when Skiros' quote revamp is merged, but at the moment we've made a conscious decision to rebuild the dataset every time the bot boots.

[0xAda]

In the 6 months you've spent debating the best way to implement this you could've just deleted the server.

[Lukew11037]

dave has a good point, maybe its time to take his advice.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[thebeanogamer]

Reopened on request from @404dcd

[404dcd]

This issue can now be closed.

[thebeanogamer]

Resolved by #610