Jump to content

Community Wishlist Survey 2019/Admins and patrollers/Prevent DDoS-style attacks

Add links
From Meta, a Wikimedia project coordination wiki

Prevent DDoS-style attacks

  • Problem: Currently at en.wikipedia, there is a troll that has been running a DDOS-style attack on the various pages that unregistered users frequently go for help (Ref Desks, Teahouse, Help Desk, and related talk pages). Currently the only blunt object we have to stop them is semi-protecting those pages, which is making it VERY difficult for IP-based users (or newly registered users who are not autoconfirmed) to find places to ask for help. The attack consists of spamming vile attacks against registered Wikipedia users, or grotesquely racist comments, or other attacks, hammering the page with edits as fast as every second or two, and jumping from open proxy to open proxy to evade blocking. The attacks start within minutes of the old protection expiring, and continue unabated until protection is returned. It is making the Wikipedia help system essentially unusable.
  • Who would benefit: Admins would have a finer-grade tool to protect pages, by allowing good-faith users to edit while stopping this highly disruptive sort of attack. IP and newly registered users would not be caught up in sanctions not intended for them.
  • Proposed solution: If there was a way to throttle edits to a page in some way, so that the same IP address and/or account would be prevented from multiple, repeat edits it could slow down this virulent attack. They would still be able to jump from open proxy to open proxy, but that takes them a little longer, and it would reduce the speed of the attack to something that hopefully we could manage with blocks and RevDel rather than page protection. What I am looking for here is a way to throttle protection so that the same IP address would have to wait for a non-bot intervening edit before being able to edit again. It wouldn't be needed often, but would come in VERY handy when it is needed.
  • More comments:
  • Phabricator tickets:

Discussion

  • Does {{helpme}} not help with this sort of thing? New contributors could use it quite well until they become autoconfirmed or whatever. Gryllida 22:15, 30 October 2018 (UTC)[reply]
  • Throttle edits to a page in some way, so that the same IP address and/or account would be prevented from multiple, repeat edits This can be accomplished with mw:AbuseFilter. It does not allow you to wait for a non-bot intervening edit before being able to edit again, but I'm confused why that would help. Could you elaborate? MusikAnimal (WMF) (talk) 22:31, 30 October 2018 (UTC)[reply]
    The problem is that someone has found a way to attack Wikipedia and shut down any page they wish using a DDOS-style attack. Currently, they are restricting themselves to areas where IP editors seek help (Help Desk, Teahouse, Ref Desk, ANI occasionally). They also tend to attack the user talk pages of the admins who try to stop them, or other users at will. If you have oversighter or admin privileges, you can pull up the history of this and see a sample of the problem here. If anyone has any idea on a technical fix that would stop this, it would be great. Right now, anyone who does this is able to shut down any page at will, and we really have no defense to it. It's exposed a vulnerability to the entire software, and it would only take one person with the will to do it to, say, expand their scope from a predictable set of project-space pages to instead just start spamming random articles across Wikipedia for hours on end, and they would soak up huge amounts of resources chasing them around, and really, we have no tools to stop them as yet. I'm not really tied to any solution, I made the proposal to get the ball rolling on a discussion, but in the end, it's stopping the problem and not this solution I think we should care about. Maybe I'm over reacting, but I would not want to see this go worst-case scenario, and have the Foundation get caught with their metaphorical pants down. We've got this contained to 1 troll now who is doing it in a limited fashion. This is the sort of thing that, if a bunch of people got bored or had an axe to grind at Wikipedia, could do a lot of damage. If y'all don't see this as a problem, that's fine. It's been annoying as heck at en.wikipedia to deal with on a daily basis, and I don't want to see this trend growing. If anyone has other ideas on technical fixes for this, beyond "end IP-based editing", I'd love to see them. --Jayron32 (talk) 11:50, 31 October 2018 (UTC)[reply]
    @Jayron32: w:Special:AbuseFilter/796? We should not discuss this filter publicly, but it seems to do what you are suggesting. MusikAnimal (WMF) (talk) 16:34, 3 November 2018 (UTC)[reply]
    There are currently 3 abuse filters set to stop this one person. They don't really work, because abuse filters are only set to recognize specific text strings. He's been doing this for years, and knows enough to vary his text strings just enough to make the abuse filters useless. --Jayron32 (talk) 15:06, 5 November 2018 (UTC)[reply]
Maybe adding to abusefilter an option to trigger a captcha, might be helpful? Assuming that attack is bot-based? BWolff (WMF) (talk) 01:51, 5 November 2018 (UTC)[reply]
It may or may not be bot based. I suspect he may be just rapidly doing the edits manually, but it COULD be bot-based as well. Having a CAPTCHA option sounds brilliant, actually. If admins had the ability to set a "CAPTCHA protection" for certain pages, that may slow him down enough for us to minimize damage. It's a small inconvenience for making one edit, but it would slow down the rapid, repeated attacks so we could deal with them. --Jayron32 (talk) 15:06, 5 November 2018 (UTC)[reply]
I would be very interested to see if CAPTCHA protection would solve this problem. I highly doubt this is done manually. They come in more quickly than I can even hit the rollback button, and I have a hard time imagining something that would take less manual time than a single click. GMGtalk 13:25, 7 November 2018 (UTC)[reply]
Adding something like $wgCaptchaTriggersOnProtection['captchaProtection']['edit'] = true; to Extension:ConfirmEdit might be an option. I would actually be interested in the effect of enabling CAPTCHA on pending-changes protected pages more generally. TheDragonFire (talk) 13:36, 7 November 2018 (UTC)[reply]

Even though a Captcha might be an interesting solution, I don't see how a reasonable rate-limit would do anything but slow down those attacks considerably, while being far less invasive for human editors. It would make sense to base this option not only on IPs, which, as already pointed out, could be rotated as a countermeasure, but also on the attacked pagese themselves. As this option does not seem to exist, from what I read here, that might be a worthwhile extension to prevent a predictable serious threat. --Eloquenzministerium (talk) 14:38, 8 November 2018 (UTC)[reply]

  • Alright, so per this comment looks like the edits are definitely automated, which makes me inclined to think a captcha would be the way to go. Also it would be super if we could escalate this in terms of importance given the level of disruption, rather than winding through the whole community wishlist process so we can get something implemented ~sometimes over the next year or so. GMGtalk 14:59, 9 November 2018 (UTC)[reply]
  • Just an update on the need for this; our friend has decided to expand his reach to any random article/talk page/etc. See [1]. Having a solution to stop him beyond "semiprotecting the entire encyclopedia" would be great. --Jayron32 (talk) 15:56, 9 November 2018 (UTC)[reply]
    @Jayron32: Are we asking to impose a CAPTCHA via AbuseFilter? Or is the proposal still centered around a new form of page protection that would throttle edits from the specified user groups? Maybe impose a CAPTCHA once said throttle has been hit? The voting phase goes live this Friday, and I want to make sure we know what we're voting on. Obviously we want to put a stop to the current vandalism spree, but it's worth noting the wishlist defines projects we'll take on in the next calendar year, and not so much for urgent solutions. That said whatever comes out of this will be useful for future vandalism sprees, I'm sure. MusikAnimal (WMF) (talk) 04:32, 14 November 2018 (UTC)[reply]
    On second thought, I think the problem statement is clear. We don't need to worry about the solution just yet. However we might consider is renaming the proposal to something like "Prevent DDoS-style attacks". This will make it more clear what we're voting on, and might increase the chances of getting a lot of support. If I don't hear back about this soon, I'll take the liberty of renaming the proposal. If you later disagree, just ping me :) Ideally we'll have this sorted out before voting starts tomorrow. MusikAnimal (WMF) (talk) 19:29, 15 November 2018 (UTC)[reply]
    I have performed the rename. Hope this is okay! MusikAnimal (WMF) (talk) 16:16, 16 November 2018 (UTC)[reply]
  • Throttling similar edits over several pages are possible. I wrote about it a few years back, but nobody has picked up the idea. Could be because it involves math. — Jeblad 08:50, 18 November 2018 (UTC)[reply]

Shouldn't this proposal be in anti-harrassment category? --Dvorapa (talk) 16:59, 18 November 2018 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Admins_and_patrollers/Prevent_DDoS-style_attacks&oldid=18672394"