Defense against the Dark DDoS Arts - podcast episode cover

Defense against the Dark DDoS Arts

Jun 26, 201838 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

We take a closer look at different DDoS strategies as well as how cyber security experts try to handle attacks. Is there anything you can do to help limit DDoS attacks?

Learn more about your ad-choices at https://www.iheartpodcastnetwork.com

See omnystudio.com/listener for privacy information.

Transcript

Speaker 1

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, 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. 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 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

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 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 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 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 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, 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 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 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, 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 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 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 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 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 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. 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 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 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, 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 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

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 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 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 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 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 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 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 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 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

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 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 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 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 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 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

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 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 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 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, 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 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

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 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 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 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 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. 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,

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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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.

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 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, 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 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 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 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 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. 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 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 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 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 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 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, 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. 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 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 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 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, 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

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. 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 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.

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 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 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 for more on this and thousands of other topics. Because it how stuff Works dot Com

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android