Why is anyone using S3 when Cloudflare R2 is free?
The AWS S3 Denial of Wallet Amplification Attack
51–60 of 97 posts
Re: The AWS S3 Denial of Wallet Amplification Attack
#52At least 500-600 words weren't needed and just added noise to the article, making it harder to read.
Re: The AWS S3 Denial of Wallet Amplification Attack
#53Re: The AWS S3 Denial of Wallet Amplification Attack
#54"Denial of Wallet" seems a misnomer--it makes it sound like source of payment is being blocked. They should really use the same term cellular systems have been for decades to describe this kind of threat, namely an "overbilling attack".
Re: The AWS S3 Denial of Wallet Amplification Attack
#55Earlier quoted context omitted.
As it should be, but recently on HN it was posted that AWS will charge you for any unauthorized PUT request to your S3 buckets. Meaning even 4xx errors will rack up a charge. So your S3 bucket names must be hidden passphrases now that stand between an attacker and your budget.
In all fairness, systems administrators have always had to pay for unauthorized requests and systems to mitigate the risk The new thing is hyperscalers have so much capacity you can get flooded by these long before the service degrades or goes offline
Cloud computing charges you by the request/byte/cpu cycle. Servers do not have this issue.
Also, is it simply not possible to rate limit this on a per IP basis? Make client only able to do X requests per second from each unique IP/network flow.
Re: The AWS S3 Denial of Wallet Amplification Attack
#56Earlier quoted context omitted.
Sorry for not having this made clearer (we'll fix this part of the post): the gotcha is not that AWS does not honor range requests, it's that canceling those will still add the full range of bytes to your egress bill (and this can add up quickly) although no bytes (or much fewer) have been transferred.
On the other hand you did ask for them so what does it mean “canceling”? Just playing devil’s advocate that they did likely start getting the data for you and that takes resources. Otherwise they would be open to a DOS attack that initiates many requests and then cancels them.
On top of this, S3 already bills (separately) for any request against a bucket (see the other current issue with the invalid PUT requests against a secured bucket, which still got billed to the bucket owner; https://news.ycombinator.com/item?id=40203126). So I'd say both the requests and the cancellations were already paid for; the surprise was the 'egress' cost on top, of data that was not actually leaving the AWS network.
Still, you are right that this still consumes some additional AWS resources, and it is probably a non-trivial issue to fix in the 'billing system'.
Re: The AWS S3 Denial of Wallet Amplification Attack
#57Earlier quoted context omitted.
So I guess the attack of the OP is a case AWS calculate price based on the unbounded request header and not on the actual egress
More or less. The article quotes AWS as saying the following: > Amazon S3 attempts to stop the streaming of data, but it does not happen instantaneously. ...which doesn't really explain it. It shouldn't send more than a TCP window after the connection is closed, and TCP windows are at most 1 GiB [1], usually much less, so this completely fails to explain the article's observed 3 TB sent vs 130 TB billed. The article…
S3 is a block storage, so retrieving an object for such a high availability and high perf service means it tries to pull some X block of data and cache it before sending through the socket.
That X block of data is out of internal S3 storage, just not sent through the bigger Internet egress subsystem.
So technically aws may argue this is egress for s3, just not for aws
Re: The AWS S3 Denial of Wallet Amplification Attack
#58Re: The AWS S3 Denial of Wallet Amplification Attack
#59Earlier quoted context omitted.
More or less. The article quotes AWS as saying the following: > Amazon S3 attempts to stop the streaming of data, but it does not happen instantaneously. ...which doesn't really explain it. It shouldn't send more than a TCP window after the connection is closed, and TCP windows are at most 1 GiB [1], usually much less, so this completely fails to explain the article's observed 3 TB sent vs 130 TB billed. The article…
this can be explained that this may be not egress out of AWS, but egress out of S3 system itself. S3 is a block storage, so retrieving an object for such a high availability and high perf service means it tries to pull some X block of data and cache it before sending through the socket. That X block of data is out of internal S3 storage, just not sent through the bigger Internet egress subsystem. So technically aws m…
Re: The AWS S3 Denial of Wallet Amplification Attack
#60Earlier quoted context omitted.
A "AI Generated" label would be nice, here.
These AI accusations are becoming a tired trope. What, exactly, about the article gives you the impression that it was generated by an LLM?