Bezos DDoS'd: Amazon Web Services' DNS systems knackered by hours-long cyber-attack Parts of Amazon Web Services were effectively shoved off the internet today – at times breaking some customers' websites – after the cloud giant came under attack. Unlucky netizens were intermittently unable to reach sites and other online services relying on the internet goliath's technology as a result of the ongoing outage …
DNSSEC is NOT the problem in fact its some of the answer...
when talking about reflection-amplification DDoS attacks, we need to look at the real culprits:
o Systems generating traffic with spoofed IP addresses and networks allowing such traffic. This is, in fact, a root cause of reflection attacks, although the one that is nearly impossible to track back currently. Many such systems together can be operated as a botnet.
o Reflectors and Amplifiers: remote applications that will respond to requests coming from compromised hosts. These responses will be directed at the target specified by the spoofed source IP address in the requests.
basically AWS need RPKI and DNSSEC implemented NOW but so much for the marketing dept taking that onboard... we need someone who cares and has the technical ability to actually champion it...
Switching to TCP would fix the spoofing issue. Amplification is still an issue but at least we'd get some real IP addresses out of it to track down the botnets, making every attacking host reveal itself.
DNSSEC would be nice, but that fixes a different problem and I think I prefer DNS over TCP - or rather TLS, which is an easier thing to do.
There was a reference to DNS caching in the article, though I took it out as it was potentially confusing: a reader privately pointed out to me that the TTL of .amazonaws.com domains is in the order of a few seconds, much shorter than I assumed. Next time I'll check the TTL...
So if you are caching the queries somewhere, great, but ensure they are cached for a while and not dumped within a minute.
C.
Edit: I've added some brief advice to the update in case it's needed by anyone in future.
the TTL of .amazonaws.com domains is in the order of a few seconds
You can override the minimum TTL in many DNS servers. A few will continue to serve up expired data from the cache if it can't reach the live server, or will cache everything to disk where you could do lookups or rig up a local authority to serve it up until things get resolved.
> basically AWS need RPKI and DNSSEC implemented NOW but so much for the marketing dept taking that onboard... we need someone who cares and has the technical ability to actually champion it...
DNSSEC has nothing to do with this.
For RPKI to help here, it would require the entire internet to support and enforce RPKI, so I don't know whose marketing dept you are talking about ...
DNSSEC (or rather AWS bodging their mitigations) did cause additional problems for ISPs' validating resolvers.
It would not have prevented the DDoS.
Some very creative types seeing just what it takes to do damage to AWS. This could just be an opening salvo before they make these attacks wider reaching.
It could also be they're seeing if/how it affected certain clients like cloudflare.
Feels like a probing attack to me.
I am not saying that the US participated in this DDoS but that The US DOD just chose (Thursday) Azure after a review of the original Amazon award supposedly initiated by the white house.
The idea of a state level actor affecting what we assume is the most durable and reliable Cloud service peopled by world class experts, does make one wonder about what the heck is going on, and if a Trump 'friend' is amplifying the big man's malevolent wishes for Bezos.
Yeah more of this stuff coming I'm afraid.
Well that explains why the light on my connected to the internet smart socket* has been flashing randomly today. But that was happening on Saturday night and parts of Sunday too. Has this attack been going on for longer?
*Yes I know but it's only being used to turn on a small LED lamp. And half the time I use the button on the device itself. Look just stop judging me.
Storage dependent on a high-level protocol to function? That's just asking for trouble... Well, so is relying on DNS TTL-abuse to do the work of redirecting clients when a storage endpoint moves rather than doing the work of writing the protocol to handle that sort of thing properly.
By properly, I mean something like the client connects to a 'storage Director" service, sets up a persistent connection and requests the location of a specific storage bucket along with a flag of "Inform me if the location of this bucket changes". That way the client isn't hitting the server every few second to re-resolve the bucket's location. At the very least, a DNS outage would only cause failure of any new client connecting to the director system, but already connected clients wouldn't have a problem.
> By properly, I mean something like the client connects to a 'storage Director" service, sets up a persistent connection and requests the location of a specific storage bucket along with a flag of "Inform me if the location of this bucket changes".
And when your "storage Director" service is taking millions of TPS, how do you scale it?
When it is taking millions of concurrent TCP connections, how do you scale up to handle more connections (taking into account that you only have ~64k TCP ports available per IP address)?
Noticable uptick in tcp syn attacks recently and this one seems cleverer than most as its very low level from a wide range of (probably fake) ip addresses. So only 10-20 from each ip in an hour but from a large number of ip addresses from different subnets. Unless you are monitoring the number of connections in a TCP_SYN state you probably won't even notice it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
