Welcome back, and in this video
of the "Networking Fundamentals" series,
I want to step through the architecture and challenges
of distributed denial of services attacks,
known as DDoS attacks.
Now, we've got a lot to cover, so let's get started.
Distributed denial of service attacks come in any forms,
a few different ways of achieving the same end goal,
which is to overload websites
or other internet-based services.
The idea is to generate some kind of traffic
which competes against legitimate connections
and overloads the hardware
or software providing the service.
Imagine trying to get into an Apple Store
on the day when a new iPhone is released.
How hard is it tog et into the store and get service?
What if you added 100,000 random people
who just want to queue for no reason
and waste the time of the Apple Store staff?
That's the physical equivalent of a DDoS attack.
The challenge when dealing with DDoS attacks come
from the distributed nature of those attacks.
It's hard to identify and block traffic
because there can be millions of IP addresses involved
with larger internet-scale attacks.
Dealing with DDoS attacks requires specific hardware
or software protections.
We won't be covering those in this video.
I'm limiting this to just discussing how DDoS attacks work,
so the architecture of all of the different types
of DDoS attacks.
Now, DDoS attacks themselves generally fit
into one of three categories.
First, application layer attacks, such as HTTP floods.
And these take advantage of the imbalance of processing
between client and server.
It's easy for you to request a webpage,
but it's often very complex for a server
to deliver that same page.
If you multiply that load difference by a billion,
then you can have a potentially devastating attack.
Next, we've got protocol-based attacks, such as SYN floods.
And a SYN flood takes advantage
of the connection-based nature of requests.
Normally, a connection is initiated
via a three-stage handshake
which I detail in a separate video of this series.
Well, SYN floods spoof a source IP address
and initiate the connection attempt with a server.
The server tries to perform step two of the handshake,
but it can't contact the source address
because it's spoofed.
In general, it hangs here waiting for a specified duration,
and this consumes network resources.
And again, if you multiply this effect by a billion,
this can have significant impact
on your ability to provide a service.
Lastly, we have volumetric attacks,
such as DNS amplification.
And this relies on how certain protocols, such as DNS,
only take small amounts of data to make the request,
such as a DNS resolution request, but in response to that,
they can deliver a large amount of data.
So one example is an attack of this nature
might make requests to DNS servers
with a large number of independent requests
where the source address is spoofed
to be the actual IP address of our website.
The DNS servers, potentially hundreds or thousands of them,
respond to what they see as legitimate requests
and overwhelm a service.
DDoS attacks are often orchestrated
by one or a small number of people
who are in control of huge botnets.
And botnets are constructed of machines,
such as your laptop or your desktop, infected with malware.
Most of these attacks come from these botnets,
which are constructed from infected hosts,
and the owners of these hosts don't even realize
that they're part of the attacks.
Now let's look at how these attacks work visually.
But before we do that, it's worth reviewing
what a valid application architecture should look like.
When a website is working as intended,
it looks something like this.
First, we have a number of servers
which provide the website functionality,
in this case, catagram.io.
These servers are normally provisioned
either based on normal load plus a bit of extra as a buffer,
or they're built to auto-scale,
which means adding more servers when load increases
and removing servers as load decreases.
Now, these servers run within a hosting environment
which is connected to the public internet
via a data connection,
which depending on the speed of this connection,
has a limited amount of data that it can transfer
and a limit on the number of connections it can handle.
Then our application has users
who are using a mobile application
to upload their latest cat pictures using TCP port 443.
Now, this is HTTPS,
and these connections move across our data connection
and arrive at the application servers.
Now, under normal circumstances,
the vast majority of these connection will be
from legitimate users of the application.
So this is how it should work.
We have an application.
The servers are sized appropriately.
We have an appropriate data connection.
And our users are accessing the application
using this infrastructure.
Now let's step through what happens
with the various different forms of DDoS attack.
The first type of DDoS attack
is the application layer attack.
Architecturally, behind the scenes,
we have an attacker who is controlling a network
of compromised machines known as a botnet.
This botnet, or more specifically,
the machines which form the botnet,
are distributed geographically.
And in most circumstances,
the real owners of these machines have no knowledge
that they've been compromised.
An application layer DDoS attack,
as I mentioned at the start of this video,
uses the computational imbalance
of client-server communications as an attack method.
It's easy, for instance, for the botnet
to make simple requests to the application, in this case,
a HTTP GET of a page called reallycomplex.php.
The botnet floods hundreds, thousands,
or even tens of thousands of these requests,
each of them directed towards the Catagram servers.
This could mean millions or more
of these really simple requests
which are all requesting our reallycomplex.php page.
The issue is that while making these requests is simple,
responding to these requests
can be computationally expensive,
and this can have disastrous effects on the servers.
It's like throwing hand grenades.
They're easy to throw,
but they're much more difficult to deal with
at the receiving end.
The effect is that our servers
or the data connection won't have the capacity required
to deal with the requests in total.
The fake attack-based requests will prevent
the legitimate requests reaching the servers
in a timely way,
and this can cause performance issues or failures,
essentially a general decrease in service levels.
Now, as I mentioned earlier in this video,
you can't simply block traffic from individual machines
because there can be millions of them.
And the data they're sending can
in many ways look exactly the same as legitimate traffic,
and this is why you have to handle DDoS attacks
in a very specific way.
Now, at this point, let's move on and take a look
at another type of DDoS attack.
This time it's a protocol-based attack.
So with a protocol-based attack,
we follow the same basic architecture,
where a single or a small group
of attackers is controlling a large botnet,
and this botnet is constructed of compromised hosts.
Now, with a protocol attack such as a SYN flood,
essentially what happens is a botnet generates
a huge number of spoofed SYNs.
And SYNs are the initial part
of this three-way connection handshake.
So essentially all of these individual machines attempt
to initiate a connection
with the catagram.io infrastructure,
but, crucially, they're using a spoofed IP address.
Now, under normal circumstances,
if these were real connections,
what should happen is our server infrastructure
would respond back with SYN-ACKs,
which are the second part of the three-way handshake.
Normally, these connection attempts would be
from real IP addresses,
so IP addresses which are expecting
to receive the second part of the three-way handshake.
But because our botnet has initiated these connections
with spoofed IP addresses,
there won't be anything on the receiving end
for our servers to communicate with.
And so in this case,
these requests will simply be ignored.
Because they're being ignored,
it means the connections will stay in this hung state.
The network resources which would otherwise be used
for legitimate connections are waiting
for the second part of the three-way handshake.
And because the botnet is providing millions and millions
of these fake connections,
it can mean that the network resources
are completely consumed with these fake connections,
and that means that our legitimate connections
won't be able to connect into our infrastructure.
Essentially by generating this protocol-based attack,
this SYN flood, we're preventing the network resources
being used for legitimate requests,
and so we're essentially significantly impacting
the network capability of this application infrastructure.
So because this three-way handshake is designed to work
with slower or less reliable connections,
our catagram.io infrastructure will wait.
It will attempt to connect
to these fake source IP addresses.
And while these connections are waiting, waiting
for the second part of the three-way handshake,
these resources can't be used for legitimate connections.
And so if the botnet is large enough,
if it contains a sufficient number of compromised hosts,
then it can, in theory, completely take down the service
provided by the catagram.io infrastructure.
Now let's move on to the third type of attack
which I want to cover in this video,
and that's known as a volumetric
or amplification-based attack.
Now, this type of attack is still orchestrated
by a single person or a small group of people,
but with this type of attack,
the size of the botnet can be much smaller
because an amplification attack exploits
a protocol data imbalance,
so a situation where only a small amount
of data is required to initiate a request,
but the response to that request is much larger.
In this case, our smaller botnet makes a large number
of requests to a large number of DNS servers.
The requests can be made to a large number of DNS servers
and be done frequently
because the amount of data that it takes
to make the request is relatively small.
Now, the botnet will use a spoofed IP address,
and it will use the IP address
of our application infrastructure.
So rather than the DNS servers responding to the botnet,
the DNS servers will all respond to our application servers.
Now, the volume of data in each of those responses
is much larger than the volume of data
making the initial query to DNS.
And because of this the application servers
will be quickly overwhelmed.
This will generally affect the data connection
to our application infrastructure
rather than the application server itself,
and this will mean that legitimate application users
experience degraded levels of performance
because they're competing to use the same total capacity
of the application data connection
with these fake responses coming in
from all of these DNS servers.
So this type of attack does impact our application's ability
to provide service because the amount of data
that our connection provides is consumed,
but it's done so in a way which uses amplification.
So rather than the botnet being required
to consume the same amount of bandwidth
as our application needs to tolerate,
this type of attack can use a tiny amount of bandwidth
to initiate the attack,
but consume a large amount of bandwidth
on the application side.
And this makes this type of attack ideally suited
to take down larger websites or applications.
So these are three different common types of DDoS attacks
which you might come across as a solutions architect,
an engineer, or a developer.
The important thing to understand
about all types of DDoS attack is they can't be combated
with normal network protection.
So because of the distributed nature of the attacks,
it's not practical to implement single IP address blocks.
If you were going to block an entire botnet,
then you would need to block potentially thousands,
tens of thousands, hundreds of thousands,
or even millions of IP addresses.
What's more, if you use a volumetric
or amplification-style attack,
then the actual machines performing the attack
might not even be malicious.
In this case, if you're taking advantage of DNS servers
using a DNS amplification attack,
then these servers, from their perspective,
are doing nothing malicious.
They're just responding to requests.
And so you have to be really careful
that in order to mitigate a DDoS attack,
you're not actually blocking legitimate traffic
or impacting your application's ability
to provide a service.
If you block all DNS servers,
then potentially you can have other issues
with your application.
Now, AWS and other cloud environments
do provide products and services
which are specifically designed
to help you combat DDoS attacks.
And now that you're aware of the architecture
and how these attacks can impact your application,
it's going to be much easier
for you to understand these different products and services.
Now, with that being said,
that's everything that I wanted to cover in this video,
so go ahead and complete the video.
And when you're ready,
I look forward to you joining me in the next.