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