They then use their street cred to get paid by less scrupulous actors to attack their rivals. Sometimes the people paying are governments, sometimes just shady companies. For example last year there was a lot of crypto companies attacking each other's websites.
Most of the people who do this have a lot of technical skill but not a lot of opportunity to get paid for it based on where they live or the circumstances of their upbringing.
Now we need the SEO content side: "How we hit Google with 398M RPS".
"... you can do this manually, but our product makes it as easy as a sign up and API call. Talk to us about pricing. [Python API example].
What I'm not sure of is why Google published this. I can't figure out what their strategy is here. We never published about the attacks we absorbed because we didn't want them to know our capabilities.
Unless this is marketing for Google Cloud?
If you read the article, there are plenty of marketing remarks in there to get you to use Google Cloud
That seems likely here if they're claiming this is the largest DDOS ever.
Besides publicity, there is also link to a list of advisories that may be of interest to other cloud operators and users.
We? Netflix or Reddit? I know for a fact that Amazon doesn't.
At eBay/PayPal we filed patents on our DDOS shield, since it was as far as we knew the first one to exist, but that was about the only public information on it.
At reddit and Netflix we didn't actually have to deal with it because AWS just absorbed (or mitigated) it before it ever hit us. We only had to deal with L7 attacks, which we had shields in place for.
As for why to write about it, it's a new type of attack that resulted in almost an order of magnitude increase in attack size. That's interesting and newsworthy by itself, and publishing a concrete number gives people an idea of the size of the problem and the trendlines.
This is also something that needed a CVE, so it was going to be very public anyway. If nothing is written about it, at a minimum Cloud customers will be flooding their support reps with questions about whether the vulnerability applies to them.
Pretty clever
How is this an advantage? Can someone explain please?
You could add some smarts to the server or reverse proxy that delays starting work in case a cancellation request quickly arrives. This is probably part of the mitigation work they refer to in the article.
They point out in the article that it's a better practice to immediately limit stream creation when you detect abuse - not wait for a round trip to complete first. I'm sure there's a good reason for the original guidelines; I'm just trying to get it and haven't found anything clarifying through Google. Was it specified before the rise of modern attacks?
After all you could say any client ignoring a GOAWAY is either bugged or malicious but certainly not until you get confirmation they go it.
Here with the "attack", it's simply exploiting the ability of HTTP/2 to compress requests and reduce them to just a few bytes, meaning that within a few kilobytes of data you can easily have hundreds of requests. Again this is not new and was already being discussed in 2012 about SPDY's use of zlib to compress requests.
The extra stuff that seems to have made this attack "new" for such service providers is that attackers took care of closing their requests so as not to have to wait for a response and be able to fill the wire with a flow of request. Again this has been known from the inception of HTTP/2 and routinely met by those dealing with proxies which timeout and send headers followed by rst_stream.
Here it makes noise because new records were broken, and likely because the stacks in place were not properly designed so they omitted to check for the real number of streams and only focused on the protocol validity...
LOL. No there are plenty of legitimate enterprises as well as opportunity to immigrate. Especially in tech. These guys are just criminals.
I know people who can't relocate because of communication issues and/or cultural differences.
No they aren't criminals, but they are definitely underpaid compared to those who managed to relocate.
Blaming it on the people that knock them off will not make improve the situation.
The hard part (and it truly is hard!) is convincing a few companies to do this. It risks user complaints in the short term, to solve a problem that may not be very acute for the largest companies (who can simply absorb these attacks).
(No I don’t expect any response but I am just leaving this thought for those who stumble on this thread in the future).
ISPs do this literally all the time. They sell services that do this.
not necessarily true
Shout out to Dutch ISP XS4ALL who was (is?) very very strict and active in this space.
Also, sounds illegal.
Step 2: Execute DDoS
Step 3: Prove to others you are responsible by using private key
(the /s is just on the "oh wait" part, not the whole post)
It's not obvious what's the value of having the largest ineffective attack.
One gets you more money in the short term. The other one gets you more street cred - which gets you more money in the long term.
If they're advanced, they are doing it to test capabilities and responses. The Taliban used to pay kids to light off firecrackers outside base to check defensive TTPs. It also had the effect of desensitizing the sound of gunfire.
Really good adversaries know how to accomplish the latter while appearing as the former.
Bring back CotDC, MoD, even lulzsec. I miss the days of the internet being the open seas and everyone having their own fun on it, user beware.
With the Mirai botnet, some of the creators had a DDOS mitigation company as well: they'd sell one party the weapon, and sell another party the defense against that weapon.
Sometimes it's for the street cred, or the lulz, or just the challenge of building a botnet.
Seen it happen with big DDoS on clients. Furaffinity, one of the larger furry webistes, and a constant drama magnet, was a client at a former job. They got DDoS'd hard, and in between scripted DDoS hits they slammed the hell out of their web applications to get vulns and do credential stuffing.
As in blast em, lighten it up just enough to get a ssh or nmap through a few times, blast em again, and repeat until they got in.
Is also why you want out-of-band solution that doesn't touch your infra much.
I've heard this before, but I still don't understand what purpose the DDoS serves here. Distraction, so the actual attack drowns in the noise?
Also the participants are sometimes innocently recruited victims for the attack. I blame app insecure defaults.
The trend since 2015 is to get worst as you will see in the bottom layer of this graph: https://www.digitalattackmap.com/
> Who has an incentive to carry out these DDos attacks?
Did you read the comment I was replying to?
Sitting at the end of whatever network, you will not be able to do anything against a sufficient volume attack.
If you analyze the situation from the perspective of "Who benefits from it?", then the answer is clearly: Google benefits from it (they are so good, they can mitigate gigantic DDoS attacks). So, I don't think it's that crazy to think this is all a publicity stunt .
"With or without patches, organizations would need to make significant infrastructure investments to keep services running in the face of attacks of any moderate size and larger. Instead of bearing that expense themselves, organizations running services on Google Cloud can take advantage of our investment in capacity at global scale in our Cross-Cloud Network to deliver and protect their applications."
I'm pretty sure someone will find a way to take down GOOG/AWS/Azure/etc through a DDoS so large nothing will work for anyone.