Live data from Hacker News

Malicious attack on Wikipedia – what we know and what we’re doing

wikimediafoundation.org

181–190 of 320 posts

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#181

Earlier quoted context omitted.

You'll also have to prove the IOT device DDoSing from my IP isn't a rogue device. I swear it's not mine.

If someone hacks my WPA password and torrents child porn from my IP I am liable (in Germany) - no need to prove it was me or my device.

Not so simple: https://ipkitten.blogspot.com/2016/09/breaking-cjeu-says-tha...

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#182

Earlier quoted context omitted.

After working with a few large corporations and their DDoS protection solutions, I did not have a good experience with Verisign, and they were not able to handle attacks or get things working. However, I have great experiences with Akamai and Cloudflare. I trust the people at Wikimedia will choose wisely. I would I have learned that Verisign has one of the worst BGP mitigation/scraping solutions out there. There are…

Any serious mitigation solution must be BGP based, not proxy. Besides its technical merits and convenience, it also minimizes the risk of a benevolent controller (e.g. Matthew Prince of Cloudflare) ruining your company, because it becomes your upstream provider only during the attacks. Otherwise the GRE tunnels are not in use. The IP addresses are still yours always. We used Verisign for mitigation of a 44Gbps volume…

A proxy is a perfectly acceptable “serious” solution for this type of problem, as well as nearly all of the rest. Wikipedia is not the kind of website that would warrant being removed from Cloudflare. What’s wrong with having an upstream provider for caching close to the user and other features when you’re not under attack?

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#183
post #168

Earlier quoted context omitted.

If you consider the amount of money they are burning in comparison to 5 years ago, are the results really that impressing? See https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2...

I found this updated version: https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C... Their expenses have doubled in less than 5 years... Even if their ratio Expenses / Assets has now decreased compared to 3-5 years ago (but stalls now), it means that their goal of financial independence is still very far away and they still rely heavily on a huge amount of donations.

I buy that yes it takes time to be financially independent of donations while offering a global information service for free.

But that essay is clearly pure hyperbole. The expenses aren’t exponential, they’ve been roughly linear for a decade. Notice how the word exponential was removed in the second version. The graph is showing increasing savings along with increasing growth, and the expenses appear to have slowed slightly in the last five years compared to the five prior years. It’s completely failing to demonstrate the stated claim of runaway spending, the numbers practically prove the opposite.

Plus it’s not outlining what the money is used for, so there’s no concept of efficiency here, no reason to doubt that increased service came with increased expenses. There’s zero meat in this argument.

Whatever; last year’s total expenses seems very small to me compared to web sites of similar size; there are startups smaller than Wikipedia’s team that have raised more money than Wikipedia’s yearly expenses without managing to deliver anything. Wikipedia’s value to the world is currently larger than it’s expenses, IMO, and I think it’s impressive what this non-profit has done.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#184
post #84

On a side note, I was surprised to learn, that Wikipedia does not have a proper status page. status.wikimedia.org redirects to grafana dashboard and it too was down yesterday.

Issue tracked at https://phabricator.wikimedia.org/T22079

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#185
post #160
post #138

Earlier quoted context omitted.

If you are not a political undesirable, it does help, though. I think Wikipedia is fine in this regard, not something to shun of for a big corp.

Wikipedia is blocked in China. It's politically undesirable for 1/8 of the human population...

I think undesirable here describes something like white nationalists. They have a problem getting web hosting.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#186
post #20

Apparently this group is behind it. Also attacked WoW and twitch servers.. https://twitter.com/ukdrillas

Part of the liability should be shared with the people owning the compromised machines these crazies are using for their attacks, otherwise attacks like these will never stop as long as enough free “ammunition” is being left around by incompetent people who can’t be bothered to secure & monitor their systems properly. Edit: in reply to some of the (valid) counter-arguments, I'd like to say that there are indeed many…

I proposed regulation as interim step in the past. Here's a reprint of it:

A combo of per-customer authentication at packet-level, DDOS monitoring, and rate limiting (or termination) of specific connection upon DDOS or malicious activity. That by itself would stop a lot of these right at the Tier 3 ISP level. Trickle those suckers down to dialup speeds with a notice telling them their computer is being used in a crime with a link to helpful ways on dealing with it (or support number).

Far as design, they could put cheap knockoff of an INFOSEC guard in their modems with CPU’s resistant to code injection. Include accelerators for networking functions and/or some DDOS detection (esp low-layer flooding) right at that device.

https://en.wikipedia.org/wiki/Guard_(information_security)

Old one from high-assurance field, albeit with medium rating, that did what I’m describing in an Ethernet, card computer:

https://web.archive.org/web/20040623100328/http://www.crypte...

Modern implementation could probably be done in a cheap clone and security-enhanced mod of this product:

https://www.cavium.com/OCTEON-II_CN68XX.html

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#187

Earlier quoted context omitted.

No offense taken, I don’t work on the product side of things there. Also, with the caveat that I don’t know enough about the implementation details of the product at Reddit: I’d argue that Reddit’s workload is more write heavy that Wikipedia’s workload, which makes caching and scaling a bit harder for Reddit, relatively speaking.

OTOH, shouldn't it be easier to scale Reddit horizontally by sharding the subreddits into separate DBs?

Certainly not trivially - the subreddits are not wholly independent entities. User accounts are shared between them, for instance, and every post a user makes is (searchably) linked to their account, regardless of which subreddit they posted it in. Users can also send each other private messages, and this does not take place in the context of any particular subreddit.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#188

Earlier quoted context omitted.

After working with a few large corporations and their DDoS protection solutions, I did not have a good experience with Verisign, and they were not able to handle attacks or get things working. However, I have great experiences with Akamai and Cloudflare. I trust the people at Wikimedia will choose wisely. I would I have learned that Verisign has one of the worst BGP mitigation/scraping solutions out there. There are…

Any serious mitigation solution must be BGP based, not proxy. Besides its technical merits and convenience, it also minimizes the risk of a benevolent controller (e.g. Matthew Prince of Cloudflare) ruining your company, because it becomes your upstream provider only during the attacks. Otherwise the GRE tunnels are not in use. The IP addresses are still yours always. We used Verisign for mitigation of a 44Gbps volume…

You appear to be extremely mad Cloudflare stopped proxying a website that encouraged large gun massacres.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#189

Earlier quoted context omitted.

In order for wikipedia's anyone can edit to work, its really important that when someone makes a bad edit to a popular article that it can be removed immediately. This is important both to get things fixed quickly and to make it less of a juicy target so less people vandalize (no fun to vandalize if it doesnt stay up). I suspect latency in the minutes for cache updates would be unaceptable to wikipedia users

Power users use very different workflows than read-only users. You can serve pages from a 30-minute-old cache to the 99.9% of passive readers and it doesn't hurt that much. Editors use "Recent Changes" to monitor edits, and that's much easier to render in real time because the audience is comparatively minuscule.

Yes but if someone replaces the picture on the trump article with goatse, and non power users get this version for 30 minutes until the cache clears - they are going to be pretty pissed and start yelling to power users & just generally cause a PR disaster.

Additionally if vandals know their vandalism will stay for 30 min, they are much more likely to do it, which is a vicious cycle

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#190
post #138

Earlier quoted context omitted.

If you are not a political undesirable, it does help, though. I think Wikipedia is fine in this regard, not something to shun of for a big corp.

I think it’s somewhat misleading to refer to those who support genocide and child abuse as simply “political undesirables.”

Genocide has been and still is a political tool. It is extreme, but ultimately something that people consider and carry out as part of political processes, not a special category of its own. And realpolitik is to continue dealing with countries that practice genocide. Consider Burma or China.

Cloudflare simply has the luxury of choosing which politically disagreeable parties they do not want to associate with because they are insignificant customers.

Pretending that this is not due to differences in politics and moral judgment is semantic smoke and mirrors.

Anyway, the point is that they are not a neutral carrier/providers. Unlike banks or telecoms which are required by regulation to accept any legal business. CF styles itself as neutral infrastructure, until they decide they are not.

The risk of getting deplatformed due to someone's moral judgment is quite real, even for an entity such as Wikipedia. For example they were blocked in the UK because the Virgin Killer album cover landed it on a block list used by major ISP.

Post reply on HN