Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

wikimediafoundation.org

Post reply on HN
Print view View original

221–230 of 320 posts

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

#221

Post by Gibbon1 »

jolmg wrote: post #220
betaby wrote: post #147

Earlier quoted context omitted.

Liability boundary is an important question. There is no simple answer. Couple of years back owner of the abandoned building was declared liable of the death of the kid who entered to the fenced building despite all the signs no trespassing and so on. Neither your example nor mine negates that there should liability for various voluntarily and involuntarily acts, own or third party.

> Couple of years back owner of the abandoned building was declared liable of the death of the kid who entered to the fenced building despite all the signs no trespassing and so on. Honestly, that doesn't sound right. I hope I'm misjudging because of lack of details.

In the the US the term is attractive nuisance. It's not a new thing either, case law in the US dates back to the 1870's.

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

#222

Post by chillydawg »

blauditore wrote: post #137
chillydawg wrote: post #47

Earlier quoted context omitted.

It's because they're just serving a big site, not running the world's most sophisticated surveillance and ad serving machine. Serving giant websites isn't all that hard if you're just spewing out SQL queries into html templates. It all scales in all directions with a properly thought through architecture.

> Serving giant websites isn't all that hard if you're just spewing out SQL queries into html templates. It all scales in all directions with a properly thought through architecture. No. 1. Your comment makes it sound like Wikipedia is just, or mostly, serving read-only content, which is far from true. Yes, static read-only content is significantly easier to serve than dynamic, editable one, but Wikipedia is the latt…

I have, actually, worked on very large and interactive websites at the very core. Notably: betfair.com which has a very busy API and website and used to be something like a 1:10 write:read ratio with multiple clusters and layers of fancy caching to keep it all coherent down to millisecond scales.

Wikipedia does not need to be globally consistent like Betfair does and the ratio of writes to reads is nothing like 10%, I'd guess at one write per million reads or less. There are several pretty obvious ways to architect a site like Wikipedia for effectively unlimited scalability. The main trick is that it doesn't matter if a page is slightly stale and you can queue edits in the backend for quite some time (many seconds) without severely harming end users. Given those constraints it really isn't rocket science given the plethora of amazing tools we have to hand.

What I'm NOT saying is that I could build it in a weekend. It would clearly require a few teams of skilled engineers to put it all together and, crucially, operate it. My initial comment was in the context of Wikipedia having 100 engineers, and I think it's reasonable to say that a team that size is easily capable of such a feat.

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

#223

Post by dangxiaopin »

OBLIQUE_PILLAR wrote: post #188
dangxiaopin wrote: post #148

Earlier quoted context omitted.

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.

The originalcontent was posted on IG. 8ch took the reposts down when it became known that it was connected to the real shooting. Watch the video with the 8ch founder explaining (unless YouTube took it down too). Matt was preparing for the IPO.

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

#224

Post by viraptor »

whitexn--g28h wrote: post #135
alexeldeib wrote: post #125

Earlier quoted context omitted.

Does this actually answer the question? If there's a node online that means I can reach the content, but would it help with DDOS? Not so sure.

A popular IPFS file might be available on thousands of nodes similar to how popular torrents have thousands of seeders. DDoS attack against thousands of servers across multiple countries and networks would be nearly impossible to perform.

It depends on the kind of node storing the data and how many there are. It's likely easier to DDoS 100 people on DSL than a single Wikimedia endpoint.

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

#225

Post by SahAssar »

snazz wrote: post #182
dangxiaopin wrote: post #148

Earlier quoted context omitted.

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?

> What’s wrong with having an upstream provider for caching close to the user and other features when you’re not under attack?

The problem is that you are basically mitm:ed all the time.

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

#226

Post by inimino »

WhitneyLand wrote: post #202
braythwayt wrote: post #50

Earlier quoted context omitted.

Please be careful of logical tautologies: "It all scales in all directions with a properly thought through architecture" sounds dangerously like, "Programming isn't that hard if you just do it right."

>>"Programming isn't that hard if you just do it right." Is this like saying, programming isn't hard if you choose easy enough problems to solve? Or should we ask for a link to see a demo of an AGI implementation? I guess math is not hard either if you're "doing is right", as long as it's all arithmetic... >>That's not a tautology. I would agree tautology is not the best description, probably fallacy would do fine.

> Is this like saying, programming isn't hard if you choose easy enough problems to solve?

No, this is saying that things don't have to be as hard as we make them. You don't need more than a hundred people to run a top-ten website, and that shouldn't be surprising. It is surprising only because we are so good at making things overcomplicated.

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

#228

Post by kminehart »

k5hp wrote: post #191
Theboda wrote: post #20

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

How can it be that a single group can take down Wikipedia? The internet is broken.

It's a bit sad. With a bit of money and some connections, you have access to a botnet large enough to cause some serious downtime.

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

#229

Post by lima »

dangxiaopin wrote: post #120
judge2020 wrote: post #6

Someone claimed the attack on twitter with some details (DDoS) - and proved it later by stopping the attack for x minutes then restarting it at a specific time. https://twitter.com/fs0c131y/status/1170093562878472194?s=20 - the attacker also went on to DDoS the twitch ingest servers (not twitch.tv itself) knocking some big streamers offline.

It looks like a volumetric attack from this tweet. Wikipedia needs to use Verisign BGP mitigation. They create GRE tunnels to your routers and are capable of handling 2Tbps. During an attack, you make a BGP announcement and the traffic goes via Verisign scrubbing/tunnels. No application changes are required, no Matthew Prince selectively and benevolently enforcing CF neutrality. It's used by large banks.

There's plenty of specialized providers which provide this service, Verisign is one of many.

The issue with on-demand BGP mitigation is that an attacker can do short attacks on and off over a long period of time. Each time the mitigation kicks in, BGP propagation takes at least ~1 minute and will cause some downtime. Proper protection is always-on without requiring redirection.

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

#230

Post by ngcc_hk »

eloff wrote: post #178
yorwba wrote: post #176

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Great_Cannon

What a world we live in... Government sponsored DDoS.

What a world live in if you are the 1.x million in som northern part of china. The 1.x billion if live inside Great Wall. The 7m if you are in Hong Kong or 2x million if you are in Taiwan.

You live in a world where a totalitarian communist state is welcomed and controlled a significant portion of the world economy. Even speak in internet summit.

Welcome to the brave new internet and international world of china.

Post reply on HN