Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Get in touch with technology with tech Stuff from how
stuff works dot com. Hey there, and welcome to tech Stuff.
I'm your host, Jonathan Strickland, and I love all things tech,
and today we're going to continue our discussion about deeds
attacks distributed denial of service attacks. In the last episode,
(00:27):
I talked about them from a very high level, right,
I gave a very high level explanation of what they
are and how they work. And today we're going to
get into a little bit more granular specific discussion, though
not exhaustive, because honestly, to get into a truly exhaustive
discussion about the DOS attacks requires an incredible amount of groundwork.
(00:49):
You have delay in order to get the technical understanding,
and and to be honest, there are certainly elements of
de DOS attacks, particular implementations that go well beyond my understanding,
so I don't want to reveal the depth of my
ignorance too quickly. But first, a distributed denial of service attack,
in case you don't remember, it's a it's a tough
(01:09):
thing to defend against. It's because it's really hard to
tell the difference between legit communication from people who are
trying to access a an online service, whether it's a
website or an app or whatever, and an attack it's
it's hard to tell because the way the Internet works,
it tries to be agnostic towards the kind of data
(01:30):
that's going across the system. In many ways, that's a
great thing, but in other ways it can make it
very challenging when people are using data itself as a
way to attack a target. So let's say you've landed
a job and you are the personal assistant of a
really powerful, really polarizing entrepreneur. One of your jobs is
(01:53):
to open this entrepreneurs mail. And whether this is a
man entrepreneur or a woman entrepreneur, it's your choice. But
this entrepreneur gets a lot of mail, and you're to
forward anything important to the entrepreneur, and then you have
to handle everything else yourself. But this particular entrepreneur has
(02:13):
ticked off a lot of folks because they're so polarizing,
and some of those folks have decided that the best
way to respond is to send hate mail, like a
lot of hate mail, Like like one person hates this
entrepreneur so much that not only has this person written
a letter, but also went out to make hundreds or
(02:35):
thousands of copies of that hate letter and then mailed
all of those copies off to the entrepreneur. And your
job is to go through the mail. So you're spending
all of your time opening up envelopes and looking to
see if it's an important piece of mail or if
it's just another hate mail message. But you're smart, you
know you catch onto what's going on after you know
(02:55):
a couple of hours, so you realize, hey, I'll just
look at the return address because if it's from that person,
I know it's just hate mail. So I'll just toss
those letters aside, unopened. I already know what's inside of
it already. I'll stop wasting time, or at least as
much time. But then this person who hates your entrepreneur,
they begin to start sending these letters from different addresses,
(03:18):
So now you have to start making a list of
addresses that you should be on the lookout for. It's
not just this one now, it's a group of them.
Either this person is traveling around and sending mail, or
he or she is just making up addresses willy nilly.
Either way, it's making your job harder. So now you're
starting to keep a list every time you open a
piece of mail, you look in, Oh, it's another copy
(03:39):
that hate letter, but it's a new address. While just
add it to the list. Then this person goes a
step further and starts to recruit other people to send
more copies of the same hate letter to you, and
they're using other return addresses, and it's different types of
handwriting too, And now you're back to where you started.
Every piece of mail comes in, you don't know what's
(04:01):
inside it until you open it, and you spend that
time and effort doing it. Now, you could try to
keep an up to date list of all the bad
addresses out there, but that could get cumbersome really quickly,
and eventually that list might be so long that you're
unable to consult it efficiently. You are spending so much
time looking to see if a new letter is on
that list, and if a new return addresses on that list,
(04:24):
that you're just wasting more time than you would if
you opened it and looked in it anyway. Or maybe
some of those same people who have sent you hate
mail have other messages, really relevant ones that have been
sent in the mail, or maybe they used an address
from someone who is a relevant uh communicator, and your
boss might think it's really important, so you run the
(04:46):
risk of throwing away a legitimate message while trying to
get rid of all these fake ones. Well to a
targeted computer being on the receiving end of ADDOS attack
is kind of similar to this. An administrator might notice
the there's an unusual amount of traffic coming from a
specific IP address, and that that IP address appears to
(05:07):
be belonging to someone who's trying to bring down the
computer system, whatever it may be, and so they might
try and block that specific I P address from being
able to send messages to the server or the router
or whatever. But if it's an actual distributed denial of
service attack, the number of attacking machines could be in
the hundreds of thousands. So at some point you have
(05:29):
to worry that you're blocking legitimate traffic, that you're you
can't block everything, but then you can't be certain that
every You know that any given IP address isn't a
compromised one, so you might try to mitigate it by
rolling out a system whereby legitimate users are identified in
some way, So instead of trying to identify illegitimate users
like the ones that are coming from an attacker. You
(05:52):
roll out some new policy so that anyone who's making
legitimate use of your service has a particular marker associated
with them in some way. But then there's the possibility
that the bad guys figure this out and they just
disguise their own traffic as legit, which sets you right
back to square one again. So let's cover some of
the specific types of de dos attacks out there and
(06:12):
what they do. First. As I mentioned in the last episode,
you have volumetric attacks. These are the easiest to understand
and explain because it's all about overwhelming your target with
just messages. The target receives so many messages, so much data,
that it gets bogged down just trying to respond, which
slows down everything else and can even cause the system crash.
(06:33):
There are several different ways to do this. I mentioned
the ping flood in the last episode, but that's really
just one example. Some attackers might use a clever system
to not only increase their own effectiveness, but reduce the
chance that they would be identified or caught. So you
might remember in that last episode I talked about the
IP addresses and if there were no way to change
(06:55):
your IP address, carrying out an attack directly against a
target would be really dangerous. Like if my IP address
was was tied directly to my identity all the time,
then it would be crazy for me to make any
sort of attack against a prepared target because they would
know who who came from. But your target uh might
(07:17):
not be able to identify the attacker because there's a
technique called i P spoofing that gets around this. So
in i P spoofing, an attacker impersonates the user of
another machine by manipulating IP packet headers. Remember, data passes
over the Internet inside packets bundles of data called packets,
and each packet has a header that contains meta information,
(07:40):
including where the data supposedly originated from. So it's sort
of like writing down someone else's return address on a
letter before you send it off. When you do i
P spoofing, you're creating a fake or you're duplicating an
IP address, whatever, it's not one that belongs to you.
So someone looks at the incoming IP address, they don't
(08:00):
know for sure that the computer sending all that traffic
is the one that's actually identified in that address. Now,
i P spoofing is relatively simple in the grand scheme
of things, But clever hackers will even go further. Let's
say a hacker has managed to get control of a
large collection of compromise machines, also known as a boton neet.
The hacker plans to use the botton net to overwhelm
(08:21):
the target with a direct approach. The target might be
able to identify some of the machines belonging to this
boton net, but it would be much more difficult to
make the leap between the boton net and the hacker
who's actually pulling the strings. Right, you'd be able to
see the incoming traffics coming from all these machines, but
you wouldn't know who's who's actually behind it all. But wait,
you can get even more clever than that. So imagine
(08:42):
you have a hacker who has control of a bot net,
and the hacker wants to send a ton of messages
to a target web server. But instead of directing all
those compromise machines in a direct attack, instead of saying army,
go sick them, the hacker instead has the machines under
his or her control send messages to uninfected computers that
(09:04):
are not the target. So these are outside the button net,
and they also are not your ultimate target. In other words,
computers that are are just completely innocent, but the messages
that your button net is sending to these computers have
a spoofed IP address. Specifically, they have a spoofed IP
address that make it look like they all come from
(09:25):
the targeted computer. The innocent computers out there, thinking they
have just received a message from the target, respond because
that's the way the internet works. They say, hey, got
your message, what do you want? And then you have
this target computer, the one that the hackers wanted to
take down, starting to get hit by thousands or hundreds
of thousands of responses to a message it did not
(09:47):
send out. It's a bunch of people saying, hey, I
got your I got your text, and you're like, I
didn't send a text, except you're getting it from a
hundred thousand people all at once. These innocent computers are
called reflectors. They are refle electing this message back at
a target, and this makes finding the responsible hacker even
more challenging because when you do that first trace of
(10:08):
the message back to the individual machines, they are all
uninfected devices. They're not part of that bot net To
begin with, all they did was respond to a computer
they thought had messaged them. It's evil, I tells you evil.
But again, these are all variations on volumetric attacks. There
are other approaches as well. For example, there are TCP
(10:29):
state exhaustion attacks. What the what? Well that requires some explanation.
TCP stands for Transmission Control Protocol, and with the Internet Protocol,
it is one of the main sets of rules that
determine how computers communicate across the Internet. Internet protocol is
all about making sure data gets from one point to
another in bundles of data packets, and Transmission Control Protocol
(10:52):
is more about making sure all that data gets reassembled
properly and that none of it goes missing. So it's
a set of rules that checks to make sure messages
being sent across the Internet our whole and properly reassembled.
During a communication between devices on the Internet, TCP goes
through numerous states or phases. Elements on networks, such as
(11:13):
load balancers, which help make sure traffic on the Internet
is balanced properly. It's it's no one section of the
network is getting too much traffic and getting congested. It
helps move some of that traffic around. To keep things
nice and efficient, have what are called connection state tables,
and these tables include information about every single connection going
(11:35):
through that point. Information includes the source address for the connection,
the port used by that source, the destination address, and
the port that the destination is using for the and
also the connection state such as whether it's an established
connection or not. A TCP state exhaustion attack attempts to
fill up those tables with garbage traffic in an effort
(11:57):
to overload the system, whether it might be a firewall
or a load balancer or some other component. And then
there are application layer attacks. These are the most complicated
to explain, and so I'll go into further detail in
just a moment. But first, how might I take a
quick break to thank our sponsor. Okay, what is an
(12:23):
application layer attack? Well, they focus on the application or
service at layer seven, but that's not really helpful if
you don't know about layers. So let's talk about that.
And as I said in the last episode back in November,
I did an episode title Dip into the Seven Layers
of the OSI model. The OSI model is a conceptual
model to help describe the various communications functions in a
(12:45):
telecommunication system, and it's really just a way for us
to think about all the different elements that work together
to allow for the complex communication we can do over networks.
They do not refer to actual physical layers so much,
even though each layer serves all layers above it and
is served by all layers below it. Layer seven is
(13:06):
the topmost layer, meaning it does not serve any other
layers because it's at the top of the heat, but
it is served by all the layers that are underneath.
So let's go from the bottom and work our way up.
At layer one, you have the physical layer that consists
of the actual physical specifications of data connections, whether they're electrical, optical,
or whatever, and the processes associated with them. Layer two
(13:29):
is the data link layer, which is a direct link
between any two nodes, so you've got two computing devices
on the same network. Layer two is that direct link.
Layer three is the network layers, so this goes one
step beyond having a direct link between two computers. This
includes both the process any functional means to send data
(13:50):
across two nodes in separate but connected networks. Layer four
is the transport layer, which allows for the communication between
processes running on different hosts on different networks, so you
go from the computers being connected across different networks to
the processes running on computers being connected through different networks.
This gets a little confusing because it sounds a bit
(14:13):
like layer three, but think about Layer three is allowing
for the connection between the machines, and layer four goes
a step further and allows actual programs or processes running
on those machines to communicate with each other. Layer five
is the session layer that creates the actual communication channels
between computers, and it's all about actually establishing, maintaining, and
terminating communication sessions. Layer six is the presentation layer, which
(14:37):
is kind of like a translator, so it handles stuff
like encryption and decryption of data being sent or received
from a network. It's usually part of an operating system.
And then we get the layer seven, the application layer. Now,
the name could be a little misleading, as the application
layer does not actually include the applications themselves. Instead, it
includes the services that applications can access when they need
(15:01):
to send data or to receive data from a network.
Applications can include any kind of software, so a web
browser is a type of application, but the browser itself
is not part of layer seven. Instead, the web browser
taps into these services offered by layer seven whenever it
needs to communicate with a network, such as when you
need to click on a link in a web page,
(15:23):
and that way it sends that message through Layer seven
further down the stack, so that I can go out
and actually retrieve the information and come back up and
then be displayed in your web browser. At this top
layer of the OSI model you have the processes that
handle some of the most common Internet requests, such as
(15:44):
um will HTTP get an h T t P post.
Get and post are two of the most common commands
common requests that go across the Internet. So what the
heck are those? Well? First of all, h T t
P stands for Hypertext Transfer Protocol. This is the set
of rules designed to make it possible for client computers
(16:06):
to communicate with server computers across the Internet. HTTP works
as a request response protocol, so sticking with web browsers,
a simple example is when you type in a U
r L to your web browsers address bar, your web
browser makes this, takes this information, it interprets it as
a request, sends that request out to the Internet, which
(16:27):
relays the request to the appropriate server computer that hosts
the website you want to see. The server returns a
response to your web browser, which hopefully contains the web
page you wanted in the first place. HTTP get is
pretty much what sounds like. It's a request to get
data from a specific resource. The get request is used
(16:47):
to ask for data, but it does not modify data. POST,
on the other hand, is used to send data to
a server, typically to update or to create a resource
on that server. Now, these attacks don't require the same
bandwidth as a volumetric approach, so remember volumetric is where
(17:08):
you're trying to get as many different UH in incoming
messages to flood a a recipient as you possibly can,
which means you're taking up a lot of bandwidth in
the In this kind of application layer approach, you don't
have to do that as much if you're trying to
overload a specific computer UH. With the application layer, you
rely less on data being sent from the attacker to
(17:31):
the target and more about the actual request because the
target has to do more work with a layer seven
attack than a network level attack. On network level, we're
just talking about the underlying infrastructure having to deal with traffic.
But at the application layer, we're talking about the target
computer having to actually do something. It has to reference something,
which is easier to understand if we use a specific example.
(17:54):
So let's say I want to target a web based
email service, and so I create an attack that will
make a relatively small botton net send a series of
login requests to the to the web mail service. So
it's as if all these different zombie computers are coming
to this service and saying, Hey, I've got an email
account with you, guys, here's my log in, here's my password,
(18:15):
give me access to that email. Each time the service
receives one of these requests, it has to reference its
system to verify the login credentials and either allow access
or deny the request, probably denying. They're probably sending a
lot of bogus login requests that this still requires the
system to reference its database every single time. It has
(18:37):
to verify whether or not that's a legitimate request to
get access to email. Then it has to send a
response to the requesting computer. So think of a time
when you went to log into a service but you
typed in the wrong password, and typically you would get
a message that would say, hey, dude, that's tot's not
what you set up when you made your account, but
that requires resources from the server. It actually has to
(18:59):
reference to log in against its table of data and
then send that appropriate response. A d DOS attack that
aims at this layer can quickly overwhelm the target. An
attacker can use an h T t P flood attack,
which might seem to be legitimate on the surface, but
in reality is a botton net attack using HTTP request
to bog down the target computer and take services offline
(19:22):
or at the very least slow everything down big time.
All right, So now let's get into a rundown of
some specific types of d DOS attacks. Now I'm not
going to go through all of them because some of
them require a much more involved explanation of what's going on,
and we'll get bogged down in some pretty dry material
about protocols and network architecture. But at layer three, that
(19:42):
network layer, you've got that ping flood that I mentioned earlier.
It's also called an ic MP flood attack. That was
what I talked about in that last episode. And you've
also got the i P slash i c MP fragmentation
style of attacks that requires a quick bit of explanation. Now,
remember when I say we send data over the Internet
using packets, we bundle it together in packets. Well, you
(20:04):
might have noticed I did not mention how much data
a packet can actually hold, which is because different networks
can handle different sizes of packets. The maximum sized packet
a particular network can handle is called that network's maximum
transmission unit, or MTU. If a packet is larger than
the networks MTU, it has to be broken apart, has
(20:26):
to be fragmented into smaller bundles of data. But only
the first fragment of the data packet has the layer
for information within that packets header. All subsequent fragments, however
many there may be, could be one of fifty. They
do not have that information in their headers, and that's
something an attacker can exploit. In a volumetric attack, there
(20:48):
are attacks that aim at the fourth layer, that transmission layer.
For example, there's the User Datagram Protocol flood attack. This
set of rules allows applications to send messages to a
networked host on an IP network, and the attacker used
uses a a spoofed source address to pose as the
target computers. So the attackers actually using this spoof to
(21:12):
appear to be the actual target, and then the attacker
sends out what is called a u d P request
to a ton of different computers on different random ports. Now,
those computers received this u DP request, and then they
look for an application that would be located on the
respective port that was associated with that request, and most
(21:33):
of the time there's not gonna be any sort of
application on that port, and so the computer sends off
a quick response that essentially says, hey buddy, sorry, but
there's no application in that port. Better luck next time. Except,
as I mentioned, the hacker spoofed their address to make
it look like they were sending this from whatever the
target computer is, So then the target computer starts getting
(21:56):
these messages, all these messages saying, hey buddy, I'm sorry,
but there aren't any applications in that port. Better like
next time. And if you've ever had your phone number
spoofed by some jerk and then started to receive angry
calls as a result, you know what this is like. Now,
I've never had that happen on my personal number, but
I actually once worked for a company that had its
main phone number spoofed by someone who was using a
(22:18):
fax machine, and this poor woman was getting phone calls
and she would pick up the phone and it would
clearly be a fax machine. It would be making that
terrible fax machine noise. But the telephone number that was
on her color I D was our telephone number, which
clearly wasn't coming from us. I mean, I was there.
I knew we weren't faxing her. So someone was actually
(22:38):
spoofing our phone number. She was justifiably getting sick and
tired of it, so she would call us and yell
at us, But we weren't actually doing anything. There was
nothing we could do. We there was someone else out
there spoofing our number. Well, hackers do that same thing
on purpose with IP addresses, and in this way you
have all these innocent computers responding to what they interpret
as a legitimate request, flooding target computer with messages. As
(23:01):
a result, there's another attack called the t C P
S Y N flood that's pretty ugly, And this attack,
the hacker engages all of a target servers communication ports
with a communication request that never completes the process to
establish a connection, which means the status is left half open.
So the process is called a handshake, and there should
(23:23):
be a three way handshake between a client and a
server that establishes communications, but this attack stops the handshake
halfway through. So every communication port gets engaged with one
of these requests, but it's never the request is never completed,
so it all gets gummed up with a half finished
handshake process and nothing can go through, Which makes me
(23:45):
think of those phone operators who have a rule that
states they can't be the first person to hang up
on a phone call. So if they call you and
they're following the rules, you can complete a conversation and
then you can just hold them there because they're not
allowed to hang up on you. That'll show them no,
don't do that. Those those folks, they're they're just doing
their job. Any attack that involves a request for a
(24:06):
secure session, such as logging into an account, falls into
the category of an s s L exhaustion attack. This
is one of those that requires the target to do
a lot of work and so it requires less traffic
to actually overtax the target. Or how about a slow
Loris attack named after the animal. This one is also
kind of ingenious. So the attacker sends out an h
(24:28):
T t P request in chunks to a target web server.
Now the server cannot complete this request until it gets
all of the chunks. To protect against this breaking, the
Internet servers have a time out feature, so if they
don't get the next chunk within a set amount of time,
it will time out, and then that that session will
(24:50):
be closed. So the slow Loris attack is a balancing act.
It's all about sending those chunks of an h t
t P request header to a target server, just asked
enough to not trigger the time out request, so as
the server is about to give up, it receives the
next chunk, and then the time out counter resets, and
(25:10):
the attacker aims to come up every communication port on
the server with those style requests, which clogs up the
communication system and prevents legitimate users from accessing the server. Now,
there are tons of other variants, but you get the idea.
All these strategies aim at the same goal, forcing the
target to focus on handling meaningless tasks at the expense
of what it is supposed to be doing. Kind Of
(25:32):
feel the same way with notifications while I'm working, whether
it's emails, Slack, base Camp, instant messages, whatever I feel
they're meant to pull my focus away from what I
should be doing, which we all know is beating tari
at pub G, and I will do it one day
when we come back, we'll talk about some of the
strategies people employ to defend against de dos attacks. So
(25:59):
the first step to defending against an attack is knowing
that an attack is actually happening. This is actually pretty
darn tricky because you have to be able to discern
between what is unusually heavy but legit legitimate traffic and
an outright de dos attack. So an important defense element
is the ability to detect anomalies, so outliers that go
(26:19):
beyond what you would typically see in your network traffic.
To do that, you first have to establish what is
the norm for your network. You have to know what
the baseline is, So you've got to figure out what
was the baseline for bandwidth usage for example, what do
you typically see across your network at different times of
the day, or CPU utilization or things like that. And
(26:41):
once you establish those baselines, then you can keep an
eye out for situations that exceed your baseline activity to
a level that could indicate a potential attack is happening,
and then you can take a closer look. Another step
is monitoring the actual traffic going across the network. Now,
I don't necessarily mean spying on data, although there are
(27:01):
companies that do recommend doing exactly that and taking a
peek inside of packets to make sure that they are legitimate. Um,
I'm a little I'm of a divided mind on that,
because on the one hand, it's a valuable tool if
you want to make sure that traffic is actually legitimate
and not, you know, part of an attack. But on
(27:22):
the other hand, I also don't like the idea of
people peeking into packets because that's not the way the
Internet is supposed to work anyway. The method I'm talking
about here doesn't actually tell you anything that's going on
inside the data packets. Instead, you would be able to
see things in terms like the number of packets traveling
across your network and where those packets originate. So you
(27:45):
would get information from the header of the packets, but
not from the internal part of the packet, so you
would know where the packet was supposed to go, where
it was coming from. And it doesn't give you any
information about what the packets actually represent. It just tells
you which I P addresses are or appear to be
sending information to a server or machine on your network.
(28:08):
If you've detected an abnormality and network traffic, and then
you use a tool like that to see where the
traffic is going, you might be able to suss out
an attempt to create a U d P flood attack,
for example. If you do that, you can take the
next steps to try and stop it. If you determine
that some of that traffic is in fact malicious, you
can set a firewall to block traffic from that I
(28:32):
P address or those addresses if it's a distributed denial
of service attack. So a firewall is a network security system.
It can be hardware, it can be software, but it's
a system that acts like a barrier between a network
and the larger internet, or a machine and a network.
It's named that because it's like a fire a physical firewall,
(28:54):
something that can hold up if there's a fire on
the other side of the wall, it's not going to
come through, right, same sort of idea. All traffic has
to pass through the firewall, and the firewall follows a
predetermined set of security rules, so you can actually adjust
those rules. You can change what the rules are, so
maybe you're an administrator for say a company network, and
(29:17):
you've identified a website that hosts malicious software. You know
this site has got some bad juju on it. You
don't want any employees to go to that site and
potentially infect their machines, which could then possibly spread malicious
code to everyone else on your network. So you set
a rule in your firewall and it blocks any computer
(29:37):
on the company network from being able to contact that
specific websites server. If you were to try to go there,
you would get an error message. You could do the
same thing but in reverse, by denying any incoming traffic
from a specific I P address, saying all right, well,
if you get anything from this address, block it. Of course,
if you're wrong about the nature of the traffic, you
(29:59):
could be blocked and innocent person's communications with your server.
They're also network infrastructure tools called intrusion prevention or intrusion
detection systems, which are really more about trying to detect
hackers that are trying to get unauthorized access to your systems,
but they can sometimes set up alerts that will let
(30:19):
you know that something hinky is going on in general,
and you can take a quick closer look and see
if maybe that's an indicator of Adidas attack. They also
can create a lot of false positives, however, so it's
not like it's a a full proof way of detecting
this uh. So it's just one more tool in the
toolbox for people who are trying to protect their networks.
(30:41):
There's also a method called reverse path forwarding sometimes that
can help out. The process involves verifying the incoming packets
are coming from legit IP addresses, because if a hacker
is spoofing addresses, they might not be careful enough to
make sure they're spoofing a legitimate IP address, right They
could be spoofing and the IP address that's in those
(31:03):
data packets actually doesn't connect to any real device that
is connected to the Internet. And if that's the case,
if you do this reverse path forwarding approach, and you determine, hey,
these messages are supposedly coming from this I P address,
but that IP address is not actually in use right now,
that tells me that these are not legitimate packets. This
(31:24):
is uh an attack that has a spoofed IP address
attached to it, So then you could discard those packets. Essentially,
you tell your firewall, hey, get rid of anything that's
coming from this address because that's not legit. Another strategy
is just compartmentalization, in which a company will make certain
that valuable services exist on separate servers, possibly on separate
(31:47):
but connected networks, and that way, if one service or
network is targeted in particular, the other ones could remain
viable while security teams work to mitigate the effects of
the attack. That doesn't prevent attack from happening, but it
helps limit their effect on an overall system. So again,
let's say that there's uh, let's let's use Google as
(32:07):
an example. Let's say that there's an attack on Google
Mail Gmail, and that attack is hitting Gmail servers really hard. Well,
Google could have those compartmentalized, so it's not affecting other
Google services. Like you would go to the web search
and everything's fine. You can't tell that Google the Gmail
(32:27):
is down or maybe there are other elements that are
also working just fine. It's just Gmail is being affected.
That's through compartmentalization. And again it doesn't stop an attack,
it just reduces how much damage an attack can do.
And then there are content delivery networks or c d ns.
These are not on their own an anti d DOS measure,
(32:53):
but they can help. Uh. These are distributed servers that
respond to requests from clients based upon a graphic location
of that client. This is more helpful if I use
an example. So let's say I'm a business owner and
I launch a new website. And when I first started out,
my website is housed on servers that I have in
my garage, right like, this is just a startup company.
(33:16):
It's something I wanted to do in my spare time.
But it catches on and my site people find it
amazing and they love it, and more and more users
start to visit the site. So I need to scale up.
My little server just can't handle this traffic. So soon
I'm leasing server space from large data centers. And because
folks are really wanting to use my services and they're
(33:37):
all across the United States, I choose to go with
a provider that has data centers and a few different
strategic locations around the country, And that way, my customers
can end up connecting to a server that's geographically close
to them, probably through some sort of automated feature in
my web service, so the user doesn't even have to
think about this. There they don't see it. They just
(33:57):
know that the web page is loading nice and fast
because the system is making sure they're connecting to the
instance of my website that's closest to them. But then
I scale up again and now it's time to go global,
and at this stage I need a content delivery network.
This is a larger company that can host my service
across the globe. And essentially the content delivery network just
(34:20):
makes a copy of my website to sit on one
or more servers in every single data center has a
deal with around the globe. Now, no matter where you are,
when you pull up my website, there's not a super
long delay while it connects to the server and pulls
that information back and loads it in your browser, unless,
of course, the data transfer speeds in the area you
are in are terrible, which that is a different matter. Now,
(34:43):
because c d ends are global in nature, and because
of the way that they approach this, they can actually
absorb a lot of traffic and they can balance the
load as well. So if one geographic area is being
hit really hard, the c d N could potentially redirect
quests to less traffic servers. So while the most convenient
(35:04):
server might normally be in your home city. If that
particular site is being hit by a di DOS attack,
the c d N could route your request to a
different server in a nearby city, and it might take
a little longer than it normally would, but it will work,
Whereas if you try to connect to the server you
usually connect to, it might not work because it's being attacked.
(35:27):
So cd ns do not stop attacks. They don't prevent attacks,
they just soak up the damage. They're kind of a
bullet sponge. So it's really not much of a stop
gap because we keep seeing di dos attacks increase in
the amount of data that they're throwing at their targets.
So if you're getting to this point where you're getting
(35:47):
exponentially larger amounts of data being shot at targets, eventually
you're gonna hit a point where, even if you're huge,
you're still gonna feel it. So it's not really a
solution so much as it it's just a way to
put off how badly dedest attacks are going to affect you.
(36:10):
And again, there are all sorts of people who use them.
There are activists, there are criminals who are trying to
extort money from potential targets, and there are people who
are doing it just for the lulls, so it's tough.
Because the tools are easy to get hold of, it's
relatively easy to attack using these approaches, but it's really
hard to defend against it. So it's one of those
(36:32):
things where it's a it's a disproportionate amount of work.
The attacker doesn't have to do very much work, and
the defender has to do a ton of work. So
even when you're successful in defending, you're still using a
lot of resources to do it well. That wraps up
these discussions about distributed denial of service attacks and what
they are and why they're so infuriating and why it's
(36:53):
important to know about them. If you guys have suggestions
for future episodes of tech Stuff, send me an email.
The address for the show is tech Stuff at how
stuff works dot com, or drop me a line on
Facebook or Twitter to handle it. Both of those is
text Stuff h s W. Make sure you follow us
on Instagram and I'll talk to you again really soon
(37:20):
for more on this and thousands of other topics. Because
it how stuff Works dot Com