WEBVTT - Defense against the Dark DDoS Arts 0:00:04.120 --> 0:00:07.160 Get in touch with technology with tech Stuff from how 0:00:07.200 --> 0:00:13.640 stuff works dot com. Hey there, and welcome to tech Stuff. 0:00:13.720 --> 0:00:17.360 I'm your host, Jonathan Strickland, and I love all things tech, 0:00:17.440 --> 0:00:21.520 and today we're going to continue our discussion about deeds 0:00:21.600 --> 0:00:27.080 attacks distributed denial of service attacks. In the last episode, 0:00:27.080 --> 0:00:30.680 I talked about them from a very high level, right, 0:00:30.680 --> 0:00:32.919 I gave a very high level explanation of what they 0:00:32.960 --> 0:00:34.720 are and how they work. And today we're going to 0:00:34.800 --> 0:00:39.000 get into a little bit more granular specific discussion, though 0:00:39.040 --> 0:00:43.200 not exhaustive, because honestly, to get into a truly exhaustive 0:00:43.200 --> 0:00:49.040 discussion about the DOS attacks requires an incredible amount of groundwork. 0:00:49.120 --> 0:00:51.680 You have delay in order to get the technical understanding, 0:00:51.760 --> 0:00:54.640 and and to be honest, there are certainly elements of 0:00:54.720 --> 0:00:59.560 de DOS attacks, particular implementations that go well beyond my understanding, 0:01:00.040 --> 0:01:03.440 so I don't want to reveal the depth of my 0:01:03.560 --> 0:01:07.199 ignorance too quickly. But first, a distributed denial of service attack, 0:01:07.200 --> 0:01:09.280 in case you don't remember, it's a it's a tough 0:01:09.280 --> 0:01:11.880 thing to defend against. It's because it's really hard to 0:01:11.920 --> 0:01:15.360 tell the difference between legit communication from people who are 0:01:15.400 --> 0:01:19.160 trying to access a an online service, whether it's a 0:01:19.160 --> 0:01:23.680 website or an app or whatever, and an attack it's 0:01:23.720 --> 0:01:27.120 it's hard to tell because the way the Internet works, 0:01:27.600 --> 0:01:30.200 it tries to be agnostic towards the kind of data 0:01:30.240 --> 0:01:33.399 that's going across the system. In many ways, that's a 0:01:33.440 --> 0:01:35.959 great thing, but in other ways it can make it 0:01:36.080 --> 0:01:40.240 very challenging when people are using data itself as a 0:01:40.280 --> 0:01:44.279 way to attack a target. So let's say you've landed 0:01:44.280 --> 0:01:47.520 a job and you are the personal assistant of a 0:01:47.560 --> 0:01:53.360 really powerful, really polarizing entrepreneur. One of your jobs is 0:01:53.400 --> 0:01:57.040 to open this entrepreneurs mail. And whether this is a 0:01:57.400 --> 0:02:01.760 man entrepreneur or a woman entrepreneur, it's your choice. But 0:02:01.840 --> 0:02:04.480 this entrepreneur gets a lot of mail, and you're to 0:02:04.600 --> 0:02:08.800 forward anything important to the entrepreneur, and then you have 0:02:08.840 --> 0:02:13.600 to handle everything else yourself. But this particular entrepreneur has 0:02:13.639 --> 0:02:16.160 ticked off a lot of folks because they're so polarizing, 0:02:16.440 --> 0:02:19.000 and some of those folks have decided that the best 0:02:19.000 --> 0:02:23.520 way to respond is to send hate mail, like a 0:02:23.600 --> 0:02:27.200 lot of hate mail, Like like one person hates this 0:02:27.560 --> 0:02:31.840 entrepreneur so much that not only has this person written 0:02:31.840 --> 0:02:34.920 a letter, but also went out to make hundreds or 0:02:35.040 --> 0:02:38.880 thousands of copies of that hate letter and then mailed 0:02:39.240 --> 0:02:42.320 all of those copies off to the entrepreneur. And your 0:02:42.400 --> 0:02:44.840 job is to go through the mail. So you're spending 0:02:44.880 --> 0:02:48.320 all of your time opening up envelopes and looking to 0:02:48.360 --> 0:02:50.400 see if it's an important piece of mail or if 0:02:50.400 --> 0:02:53.160 it's just another hate mail message. But you're smart, you 0:02:53.160 --> 0:02:55.120 know you catch onto what's going on after you know 0:02:55.560 --> 0:02:58.320 a couple of hours, so you realize, hey, I'll just 0:02:58.360 --> 0:03:01.360 look at the return address because if it's from that person, 0:03:02.040 --> 0:03:04.600 I know it's just hate mail. So I'll just toss 0:03:04.639 --> 0:03:07.640 those letters aside, unopened. I already know what's inside of 0:03:07.639 --> 0:03:10.440 it already. I'll stop wasting time, or at least as 0:03:10.520 --> 0:03:13.760 much time. But then this person who hates your entrepreneur, 0:03:14.639 --> 0:03:18.240 they begin to start sending these letters from different addresses, 0:03:18.760 --> 0:03:21.080 So now you have to start making a list of 0:03:21.120 --> 0:03:23.560 addresses that you should be on the lookout for. It's 0:03:23.600 --> 0:03:26.320 not just this one now, it's a group of them. 0:03:26.360 --> 0:03:29.359 Either this person is traveling around and sending mail, or 0:03:29.520 --> 0:03:32.320 he or she is just making up addresses willy nilly. 0:03:32.360 --> 0:03:35.600 Either way, it's making your job harder. So now you're 0:03:35.600 --> 0:03:37.240 starting to keep a list every time you open a 0:03:37.240 --> 0:03:39.400 piece of mail, you look in, Oh, it's another copy 0:03:39.440 --> 0:03:41.640 that hate letter, but it's a new address. While just 0:03:41.680 --> 0:03:45.200 add it to the list. Then this person goes a 0:03:45.240 --> 0:03:48.320 step further and starts to recruit other people to send 0:03:48.400 --> 0:03:51.680 more copies of the same hate letter to you, and 0:03:51.680 --> 0:03:55.560 they're using other return addresses, and it's different types of 0:03:55.600 --> 0:03:58.440 handwriting too, And now you're back to where you started. 0:03:58.600 --> 0:04:01.080 Every piece of mail comes in, you don't know what's 0:04:01.120 --> 0:04:03.240 inside it until you open it, and you spend that 0:04:03.280 --> 0:04:05.720 time and effort doing it. Now, you could try to 0:04:05.800 --> 0:04:07.920 keep an up to date list of all the bad 0:04:07.960 --> 0:04:11.200 addresses out there, but that could get cumbersome really quickly, 0:04:11.280 --> 0:04:14.120 and eventually that list might be so long that you're 0:04:14.160 --> 0:04:17.880 unable to consult it efficiently. You are spending so much 0:04:17.920 --> 0:04:20.840 time looking to see if a new letter is on 0:04:20.960 --> 0:04:24.119 that list, and if a new return addresses on that list, 0:04:24.600 --> 0:04:26.440 that you're just wasting more time than you would if 0:04:26.480 --> 0:04:29.120 you opened it and looked in it anyway. Or maybe 0:04:29.440 --> 0:04:31.880 some of those same people who have sent you hate 0:04:31.920 --> 0:04:36.080 mail have other messages, really relevant ones that have been 0:04:36.120 --> 0:04:38.560 sent in the mail, or maybe they used an address 0:04:38.560 --> 0:04:43.400 from someone who is a relevant uh communicator, and your 0:04:43.440 --> 0:04:46.280 boss might think it's really important, so you run the 0:04:46.360 --> 0:04:49.520 risk of throwing away a legitimate message while trying to 0:04:49.560 --> 0:04:51.880 get rid of all these fake ones. Well to a 0:04:51.920 --> 0:04:55.640 targeted computer being on the receiving end of ADDOS attack 0:04:55.880 --> 0:04:59.719 is kind of similar to this. An administrator might notice 0:04:59.839 --> 0:05:02.960 the there's an unusual amount of traffic coming from a 0:05:02.960 --> 0:05:07.200 specific IP address, and that that IP address appears to 0:05:07.279 --> 0:05:10.400 be belonging to someone who's trying to bring down the 0:05:10.440 --> 0:05:13.400 computer system, whatever it may be, and so they might 0:05:13.440 --> 0:05:16.680 try and block that specific I P address from being 0:05:16.720 --> 0:05:19.360 able to send messages to the server or the router 0:05:19.560 --> 0:05:23.880 or whatever. But if it's an actual distributed denial of 0:05:23.960 --> 0:05:27.000 service attack, the number of attacking machines could be in 0:05:27.000 --> 0:05:29.800 the hundreds of thousands. So at some point you have 0:05:29.839 --> 0:05:32.680 to worry that you're blocking legitimate traffic, that you're you 0:05:32.720 --> 0:05:35.800 can't block everything, but then you can't be certain that 0:05:35.880 --> 0:05:39.240 every You know that any given IP address isn't a 0:05:39.240 --> 0:05:42.160 compromised one, so you might try to mitigate it by 0:05:42.240 --> 0:05:45.520 rolling out a system whereby legitimate users are identified in 0:05:45.560 --> 0:05:48.880 some way, So instead of trying to identify illegitimate users 0:05:48.920 --> 0:05:51.479 like the ones that are coming from an attacker. You 0:05:52.120 --> 0:05:55.400 roll out some new policy so that anyone who's making 0:05:55.480 --> 0:05:58.960 legitimate use of your service has a particular marker associated 0:05:58.960 --> 0:06:01.600 with them in some way. But then there's the possibility 0:06:01.640 --> 0:06:03.320 that the bad guys figure this out and they just 0:06:03.360 --> 0:06:07.120 disguise their own traffic as legit, which sets you right 0:06:07.120 --> 0:06:09.800 back to square one again. So let's cover some of 0:06:09.800 --> 0:06:12.640 the specific types of de dos attacks out there and 0:06:12.720 --> 0:06:15.840 what they do. First. As I mentioned in the last episode, 0:06:16.080 --> 0:06:19.479 you have volumetric attacks. These are the easiest to understand 0:06:19.520 --> 0:06:22.960 and explain because it's all about overwhelming your target with 0:06:23.080 --> 0:06:27.719 just messages. The target receives so many messages, so much data, 0:06:27.760 --> 0:06:30.080 that it gets bogged down just trying to respond, which 0:06:30.120 --> 0:06:33.200 slows down everything else and can even cause the system crash. 0:06:33.720 --> 0:06:35.840 There are several different ways to do this. I mentioned 0:06:35.839 --> 0:06:38.640 the ping flood in the last episode, but that's really 0:06:38.680 --> 0:06:42.200 just one example. Some attackers might use a clever system 0:06:42.240 --> 0:06:45.880 to not only increase their own effectiveness, but reduce the 0:06:45.960 --> 0:06:49.080 chance that they would be identified or caught. So you 0:06:49.160 --> 0:06:51.360 might remember in that last episode I talked about the 0:06:51.440 --> 0:06:55.039 IP addresses and if there were no way to change 0:06:55.040 --> 0:06:58.440 your IP address, carrying out an attack directly against a 0:06:58.480 --> 0:07:01.960 target would be really dangerous. Like if my IP address 0:07:02.040 --> 0:07:06.080 was was tied directly to my identity all the time, 0:07:06.680 --> 0:07:09.760 then it would be crazy for me to make any 0:07:09.760 --> 0:07:12.720 sort of attack against a prepared target because they would 0:07:12.800 --> 0:07:17.080 know who who came from. But your target uh might 0:07:17.120 --> 0:07:20.080 not be able to identify the attacker because there's a 0:07:20.080 --> 0:07:23.800 technique called i P spoofing that gets around this. So 0:07:24.240 --> 0:07:27.240 in i P spoofing, an attacker impersonates the user of 0:07:27.280 --> 0:07:32.520 another machine by manipulating IP packet headers. Remember, data passes 0:07:32.600 --> 0:07:36.440 over the Internet inside packets bundles of data called packets, 0:07:36.440 --> 0:07:40.280 and each packet has a header that contains meta information, 0:07:40.320 --> 0:07:44.560 including where the data supposedly originated from. So it's sort 0:07:44.560 --> 0:07:47.600 of like writing down someone else's return address on a 0:07:47.680 --> 0:07:49.640 letter before you send it off. When you do i 0:07:49.800 --> 0:07:53.960 P spoofing, you're creating a fake or you're duplicating an 0:07:54.000 --> 0:07:56.800 IP address, whatever, it's not one that belongs to you. 0:07:57.320 --> 0:08:00.680 So someone looks at the incoming IP address, they don't 0:08:00.680 --> 0:08:03.840 know for sure that the computer sending all that traffic 0:08:04.000 --> 0:08:06.840 is the one that's actually identified in that address. Now, 0:08:06.880 --> 0:08:10.239 i P spoofing is relatively simple in the grand scheme 0:08:10.280 --> 0:08:13.120 of things, But clever hackers will even go further. Let's 0:08:13.120 --> 0:08:15.120 say a hacker has managed to get control of a 0:08:15.200 --> 0:08:18.440 large collection of compromise machines, also known as a boton neet. 0:08:18.560 --> 0:08:20.960 The hacker plans to use the botton net to overwhelm 0:08:21.000 --> 0:08:23.840 the target with a direct approach. The target might be 0:08:23.880 --> 0:08:26.240 able to identify some of the machines belonging to this 0:08:26.320 --> 0:08:28.360 boton net, but it would be much more difficult to 0:08:28.480 --> 0:08:31.120 make the leap between the boton net and the hacker 0:08:31.160 --> 0:08:34.040 who's actually pulling the strings. Right, you'd be able to 0:08:34.080 --> 0:08:36.440 see the incoming traffics coming from all these machines, but 0:08:36.440 --> 0:08:39.640 you wouldn't know who's who's actually behind it all. But wait, 0:08:39.760 --> 0:08:42.800 you can get even more clever than that. So imagine 0:08:42.840 --> 0:08:45.439 you have a hacker who has control of a bot net, 0:08:45.760 --> 0:08:48.000 and the hacker wants to send a ton of messages 0:08:48.040 --> 0:08:51.160 to a target web server. But instead of directing all 0:08:51.200 --> 0:08:55.079 those compromise machines in a direct attack, instead of saying army, 0:08:55.280 --> 0:08:59.959 go sick them, the hacker instead has the machines under 0:09:00.160 --> 0:09:04.800 his or her control send messages to uninfected computers that 0:09:04.880 --> 0:09:07.840 are not the target. So these are outside the button net, 0:09:08.000 --> 0:09:11.360 and they also are not your ultimate target. In other words, 0:09:11.840 --> 0:09:16.120 computers that are are just completely innocent, but the messages 0:09:16.160 --> 0:09:19.320 that your button net is sending to these computers have 0:09:19.600 --> 0:09:23.360 a spoofed IP address. Specifically, they have a spoofed IP 0:09:23.440 --> 0:09:25.480 address that make it look like they all come from 0:09:25.520 --> 0:09:30.520 the targeted computer. The innocent computers out there, thinking they 0:09:30.520 --> 0:09:33.960 have just received a message from the target, respond because 0:09:34.040 --> 0:09:36.000 that's the way the internet works. They say, hey, got 0:09:36.080 --> 0:09:38.520 your message, what do you want? And then you have 0:09:38.600 --> 0:09:41.320 this target computer, the one that the hackers wanted to 0:09:41.360 --> 0:09:44.439 take down, starting to get hit by thousands or hundreds 0:09:44.480 --> 0:09:47.240 of thousands of responses to a message it did not 0:09:47.600 --> 0:09:50.440 send out. It's a bunch of people saying, hey, I 0:09:50.480 --> 0:09:52.480 got your I got your text, and you're like, I 0:09:52.480 --> 0:09:54.599 didn't send a text, except you're getting it from a 0:09:54.679 --> 0:09:58.240 hundred thousand people all at once. These innocent computers are 0:09:58.280 --> 0:10:01.600 called reflectors. They are refle electing this message back at 0:10:01.600 --> 0:10:05.240 a target, and this makes finding the responsible hacker even 0:10:05.280 --> 0:10:08.760 more challenging because when you do that first trace of 0:10:08.800 --> 0:10:12.079 the message back to the individual machines, they are all 0:10:12.160 --> 0:10:14.880 uninfected devices. They're not part of that bot net To 0:10:14.920 --> 0:10:17.520 begin with, all they did was respond to a computer 0:10:17.640 --> 0:10:21.400 they thought had messaged them. It's evil, I tells you evil. 0:10:22.400 --> 0:10:26.520 But again, these are all variations on volumetric attacks. There 0:10:26.520 --> 0:10:29.600 are other approaches as well. For example, there are TCP 0:10:29.880 --> 0:10:35.080 state exhaustion attacks. What the what? Well that requires some explanation. 0:10:35.360 --> 0:10:39.760 TCP stands for Transmission Control Protocol, and with the Internet Protocol, 0:10:40.000 --> 0:10:41.920 it is one of the main sets of rules that 0:10:42.000 --> 0:10:46.439 determine how computers communicate across the Internet. Internet protocol is 0:10:46.480 --> 0:10:48.840 all about making sure data gets from one point to 0:10:48.880 --> 0:10:52.640 another in bundles of data packets, and Transmission Control Protocol 0:10:52.679 --> 0:10:55.240 is more about making sure all that data gets reassembled 0:10:55.280 --> 0:10:58.120 properly and that none of it goes missing. So it's 0:10:58.160 --> 0:11:00.520 a set of rules that checks to make sure messages 0:11:00.559 --> 0:11:04.439 being sent across the Internet our whole and properly reassembled. 0:11:05.120 --> 0:11:08.720 During a communication between devices on the Internet, TCP goes 0:11:08.760 --> 0:11:13.719 through numerous states or phases. Elements on networks, such as 0:11:13.840 --> 0:11:16.920 load balancers, which help make sure traffic on the Internet 0:11:17.040 --> 0:11:20.960 is balanced properly. It's it's no one section of the 0:11:21.000 --> 0:11:24.320 network is getting too much traffic and getting congested. It 0:11:24.400 --> 0:11:26.880 helps move some of that traffic around. To keep things 0:11:27.200 --> 0:11:31.800 nice and efficient, have what are called connection state tables, 0:11:31.880 --> 0:11:35.760 and these tables include information about every single connection going 0:11:35.840 --> 0:11:40.000 through that point. Information includes the source address for the connection, 0:11:40.400 --> 0:11:44.240 the port used by that source, the destination address, and 0:11:44.280 --> 0:11:46.680 the port that the destination is using for the and 0:11:46.760 --> 0:11:49.719 also the connection state such as whether it's an established 0:11:49.760 --> 0:11:53.720 connection or not. A TCP state exhaustion attack attempts to 0:11:53.760 --> 0:11:57.040 fill up those tables with garbage traffic in an effort 0:11:57.040 --> 0:12:00.120 to overload the system, whether it might be a firewall 0:12:00.200 --> 0:12:03.040 or a load balancer or some other component. And then 0:12:03.040 --> 0:12:06.640 there are application layer attacks. These are the most complicated 0:12:06.640 --> 0:12:09.320 to explain, and so I'll go into further detail in 0:12:09.400 --> 0:12:12.040 just a moment. But first, how might I take a 0:12:12.160 --> 0:12:23.000 quick break to thank our sponsor. Okay, what is an 0:12:23.040 --> 0:12:27.400 application layer attack? Well, they focus on the application or 0:12:27.600 --> 0:12:30.200 service at layer seven, but that's not really helpful if 0:12:30.240 --> 0:12:32.679 you don't know about layers. So let's talk about that. 0:12:32.960 --> 0:12:35.319 And as I said in the last episode back in November, 0:12:36.280 --> 0:12:38.760 I did an episode title Dip into the Seven Layers 0:12:38.760 --> 0:12:41.960 of the OSI model. The OSI model is a conceptual 0:12:42.120 --> 0:12:45.440 model to help describe the various communications functions in a 0:12:45.480 --> 0:12:48.560 telecommunication system, and it's really just a way for us 0:12:48.600 --> 0:12:51.040 to think about all the different elements that work together 0:12:51.440 --> 0:12:55.079 to allow for the complex communication we can do over networks. 0:12:55.559 --> 0:12:59.360 They do not refer to actual physical layers so much, 0:12:59.760 --> 0:13:03.160 even though each layer serves all layers above it and 0:13:03.360 --> 0:13:06.800 is served by all layers below it. Layer seven is 0:13:06.840 --> 0:13:09.960 the topmost layer, meaning it does not serve any other 0:13:10.080 --> 0:13:12.920 layers because it's at the top of the heat, but 0:13:13.000 --> 0:13:15.559 it is served by all the layers that are underneath. 0:13:15.960 --> 0:13:18.240 So let's go from the bottom and work our way up. 0:13:18.520 --> 0:13:21.079 At layer one, you have the physical layer that consists 0:13:21.080 --> 0:13:25.640 of the actual physical specifications of data connections, whether they're electrical, optical, 0:13:25.760 --> 0:13:29.480 or whatever, and the processes associated with them. Layer two 0:13:29.600 --> 0:13:32.000 is the data link layer, which is a direct link 0:13:32.040 --> 0:13:37.320 between any two nodes, so you've got two computing devices 0:13:37.360 --> 0:13:40.440 on the same network. Layer two is that direct link. 0:13:40.840 --> 0:13:44.040 Layer three is the network layers, so this goes one 0:13:44.080 --> 0:13:47.640 step beyond having a direct link between two computers. This 0:13:47.720 --> 0:13:50.920 includes both the process any functional means to send data 0:13:50.960 --> 0:13:54.920 across two nodes in separate but connected networks. Layer four 0:13:55.000 --> 0:13:58.319 is the transport layer, which allows for the communication between 0:13:58.400 --> 0:14:02.720 processes running on different hosts on different networks, so you 0:14:02.800 --> 0:14:06.800 go from the computers being connected across different networks to 0:14:06.880 --> 0:14:10.760 the processes running on computers being connected through different networks. 0:14:10.760 --> 0:14:13.240 This gets a little confusing because it sounds a bit 0:14:13.320 --> 0:14:15.960 like layer three, but think about Layer three is allowing 0:14:16.000 --> 0:14:18.600 for the connection between the machines, and layer four goes 0:14:18.640 --> 0:14:22.280 a step further and allows actual programs or processes running 0:14:22.320 --> 0:14:25.520 on those machines to communicate with each other. Layer five 0:14:25.760 --> 0:14:29.160 is the session layer that creates the actual communication channels 0:14:29.200 --> 0:14:32.800 between computers, and it's all about actually establishing, maintaining, and 0:14:32.920 --> 0:14:37.520 terminating communication sessions. Layer six is the presentation layer, which 0:14:37.560 --> 0:14:39.800 is kind of like a translator, so it handles stuff 0:14:39.840 --> 0:14:43.640 like encryption and decryption of data being sent or received 0:14:43.680 --> 0:14:46.800 from a network. It's usually part of an operating system. 0:14:47.000 --> 0:14:50.200 And then we get the layer seven, the application layer. Now, 0:14:50.440 --> 0:14:53.040 the name could be a little misleading, as the application 0:14:53.120 --> 0:14:57.520 layer does not actually include the applications themselves. Instead, it 0:14:57.560 --> 0:15:01.000 includes the services that applications can access when they need 0:15:01.040 --> 0:15:04.000 to send data or to receive data from a network. 0:15:04.600 --> 0:15:07.440 Applications can include any kind of software, so a web 0:15:07.480 --> 0:15:10.680 browser is a type of application, but the browser itself 0:15:10.800 --> 0:15:14.120 is not part of layer seven. Instead, the web browser 0:15:14.160 --> 0:15:18.080 taps into these services offered by layer seven whenever it 0:15:18.080 --> 0:15:20.680 needs to communicate with a network, such as when you 0:15:20.760 --> 0:15:23.240 need to click on a link in a web page, 0:15:23.640 --> 0:15:28.160 and that way it sends that message through Layer seven 0:15:28.440 --> 0:15:31.360 further down the stack, so that I can go out 0:15:31.560 --> 0:15:34.680 and actually retrieve the information and come back up and 0:15:34.720 --> 0:15:38.200 then be displayed in your web browser. At this top 0:15:38.280 --> 0:15:41.200 layer of the OSI model you have the processes that 0:15:41.280 --> 0:15:44.800 handle some of the most common Internet requests, such as 0:15:44.960 --> 0:15:48.760 um will HTTP get an h T t P post. 0:15:49.520 --> 0:15:52.800 Get and post are two of the most common commands 0:15:53.120 --> 0:15:56.640 common requests that go across the Internet. So what the 0:15:56.640 --> 0:15:59.000 heck are those? Well? First of all, h T t 0:15:59.120 --> 0:16:03.080 P stands for Hypertext Transfer Protocol. This is the set 0:16:03.120 --> 0:16:06.000 of rules designed to make it possible for client computers 0:16:06.200 --> 0:16:10.720 to communicate with server computers across the Internet. HTTP works 0:16:10.840 --> 0:16:15.080 as a request response protocol, so sticking with web browsers, 0:16:15.320 --> 0:16:17.760 a simple example is when you type in a U 0:16:17.880 --> 0:16:20.440 r L to your web browsers address bar, your web 0:16:20.480 --> 0:16:23.920 browser makes this, takes this information, it interprets it as 0:16:23.920 --> 0:16:27.240 a request, sends that request out to the Internet, which 0:16:27.280 --> 0:16:30.800 relays the request to the appropriate server computer that hosts 0:16:30.840 --> 0:16:33.480 the website you want to see. The server returns a 0:16:33.560 --> 0:16:36.320 response to your web browser, which hopefully contains the web 0:16:36.400 --> 0:16:40.360 page you wanted in the first place. HTTP get is 0:16:40.360 --> 0:16:43.120 pretty much what sounds like. It's a request to get 0:16:43.280 --> 0:16:47.600 data from a specific resource. The get request is used 0:16:47.600 --> 0:16:51.800 to ask for data, but it does not modify data. POST, 0:16:51.880 --> 0:16:55.120 on the other hand, is used to send data to 0:16:55.520 --> 0:16:59.320 a server, typically to update or to create a resource 0:16:59.560 --> 0:17:03.440 on that server. Now, these attacks don't require the same 0:17:03.840 --> 0:17:08.080 bandwidth as a volumetric approach, so remember volumetric is where 0:17:08.080 --> 0:17:12.159 you're trying to get as many different UH in incoming 0:17:12.200 --> 0:17:16.000 messages to flood a a recipient as you possibly can, 0:17:16.040 --> 0:17:19.239 which means you're taking up a lot of bandwidth in 0:17:19.280 --> 0:17:21.520 the In this kind of application layer approach, you don't 0:17:21.560 --> 0:17:23.720 have to do that as much if you're trying to 0:17:23.800 --> 0:17:27.560 overload a specific computer UH. With the application layer, you 0:17:27.600 --> 0:17:31.919 rely less on data being sent from the attacker to 0:17:31.960 --> 0:17:35.080 the target and more about the actual request because the 0:17:35.119 --> 0:17:38.080 target has to do more work with a layer seven 0:17:38.119 --> 0:17:41.200 attack than a network level attack. On network level, we're 0:17:41.240 --> 0:17:44.240 just talking about the underlying infrastructure having to deal with traffic. 0:17:44.760 --> 0:17:47.280 But at the application layer, we're talking about the target 0:17:47.320 --> 0:17:51.199 computer having to actually do something. It has to reference something, 0:17:51.240 --> 0:17:54.400 which is easier to understand if we use a specific example. 0:17:54.480 --> 0:17:56.719 So let's say I want to target a web based 0:17:56.840 --> 0:18:00.400 email service, and so I create an attack that will 0:18:00.400 --> 0:18:03.280 make a relatively small botton net send a series of 0:18:03.359 --> 0:18:06.560 login requests to the to the web mail service. So 0:18:07.040 --> 0:18:10.280 it's as if all these different zombie computers are coming 0:18:10.280 --> 0:18:12.639 to this service and saying, Hey, I've got an email 0:18:12.640 --> 0:18:15.760 account with you, guys, here's my log in, here's my password, 0:18:15.800 --> 0:18:18.200 give me access to that email. Each time the service 0:18:18.240 --> 0:18:21.120 receives one of these requests, it has to reference its 0:18:21.160 --> 0:18:26.320 system to verify the login credentials and either allow access 0:18:26.440 --> 0:18:29.399 or deny the request, probably denying. They're probably sending a 0:18:29.400 --> 0:18:33.080 lot of bogus login requests that this still requires the 0:18:33.160 --> 0:18:37.640 system to reference its database every single time. It has 0:18:37.680 --> 0:18:40.960 to verify whether or not that's a legitimate request to 0:18:41.040 --> 0:18:43.480 get access to email. Then it has to send a 0:18:43.520 --> 0:18:46.520 response to the requesting computer. So think of a time 0:18:46.560 --> 0:18:48.879 when you went to log into a service but you 0:18:49.000 --> 0:18:51.679 typed in the wrong password, and typically you would get 0:18:51.680 --> 0:18:54.000 a message that would say, hey, dude, that's tot's not 0:18:54.080 --> 0:18:56.280 what you set up when you made your account, but 0:18:56.520 --> 0:18:59.399 that requires resources from the server. It actually has to 0:18:59.480 --> 0:19:02.239 reference to log in against its table of data and 0:19:02.240 --> 0:19:05.679 then send that appropriate response. A d DOS attack that 0:19:05.800 --> 0:19:08.679 aims at this layer can quickly overwhelm the target. An 0:19:08.680 --> 0:19:11.399 attacker can use an h T t P flood attack, 0:19:11.960 --> 0:19:15.040 which might seem to be legitimate on the surface, but 0:19:15.080 --> 0:19:18.320 in reality is a botton net attack using HTTP request 0:19:18.440 --> 0:19:22.200 to bog down the target computer and take services offline 0:19:22.359 --> 0:19:25.119 or at the very least slow everything down big time. 0:19:25.560 --> 0:19:28.240 All right, So now let's get into a rundown of 0:19:28.320 --> 0:19:31.600 some specific types of d DOS attacks. Now I'm not 0:19:31.600 --> 0:19:33.240 going to go through all of them because some of 0:19:33.240 --> 0:19:36.199 them require a much more involved explanation of what's going on, 0:19:36.280 --> 0:19:38.720 and we'll get bogged down in some pretty dry material 0:19:38.760 --> 0:19:42.520 about protocols and network architecture. But at layer three, that 0:19:42.600 --> 0:19:45.840 network layer, you've got that ping flood that I mentioned earlier. 0:19:45.840 --> 0:19:49.119 It's also called an ic MP flood attack. That was 0:19:49.160 --> 0:19:51.440 what I talked about in that last episode. And you've 0:19:51.480 --> 0:19:55.240 also got the i P slash i c MP fragmentation 0:19:55.440 --> 0:19:59.240 style of attacks that requires a quick bit of explanation. Now, 0:19:59.240 --> 0:20:01.720 remember when I say we send data over the Internet 0:20:01.800 --> 0:20:04.680 using packets, we bundle it together in packets. Well, you 0:20:04.760 --> 0:20:07.040 might have noticed I did not mention how much data 0:20:07.080 --> 0:20:09.960 a packet can actually hold, which is because different networks 0:20:10.000 --> 0:20:14.080 can handle different sizes of packets. The maximum sized packet 0:20:14.119 --> 0:20:18.040 a particular network can handle is called that network's maximum 0:20:18.080 --> 0:20:23.240 transmission unit, or MTU. If a packet is larger than 0:20:23.320 --> 0:20:26.679 the networks MTU, it has to be broken apart, has 0:20:26.720 --> 0:20:30.920 to be fragmented into smaller bundles of data. But only 0:20:30.960 --> 0:20:33.680 the first fragment of the data packet has the layer 0:20:33.800 --> 0:20:38.359 for information within that packets header. All subsequent fragments, however 0:20:38.400 --> 0:20:41.960 many there may be, could be one of fifty. They 0:20:42.119 --> 0:20:44.640 do not have that information in their headers, and that's 0:20:44.640 --> 0:20:48.240 something an attacker can exploit. In a volumetric attack, there 0:20:48.240 --> 0:20:51.200 are attacks that aim at the fourth layer, that transmission layer. 0:20:51.280 --> 0:20:55.560 For example, there's the User Datagram Protocol flood attack. This 0:20:55.800 --> 0:20:59.080 set of rules allows applications to send messages to a 0:20:59.119 --> 0:21:02.560 networked host on an IP network, and the attacker used 0:21:02.840 --> 0:21:06.760 uses a a spoofed source address to pose as the 0:21:06.800 --> 0:21:12.280 target computers. So the attackers actually using this spoof to 0:21:12.400 --> 0:21:15.720 appear to be the actual target, and then the attacker 0:21:15.840 --> 0:21:18.280 sends out what is called a u d P request 0:21:18.400 --> 0:21:22.920 to a ton of different computers on different random ports. Now, 0:21:22.960 --> 0:21:26.280 those computers received this u DP request, and then they 0:21:26.400 --> 0:21:29.919 look for an application that would be located on the 0:21:29.960 --> 0:21:33.960 respective port that was associated with that request, and most 0:21:33.960 --> 0:21:35.879 of the time there's not gonna be any sort of 0:21:35.920 --> 0:21:39.560 application on that port, and so the computer sends off 0:21:39.600 --> 0:21:43.040 a quick response that essentially says, hey buddy, sorry, but 0:21:43.119 --> 0:21:46.439 there's no application in that port. Better luck next time. Except, 0:21:46.480 --> 0:21:50.080 as I mentioned, the hacker spoofed their address to make 0:21:50.080 --> 0:21:52.520 it look like they were sending this from whatever the 0:21:52.560 --> 0:21:56.320 target computer is, So then the target computer starts getting 0:21:56.320 --> 0:21:59.000 these messages, all these messages saying, hey buddy, I'm sorry, 0:21:59.040 --> 0:22:02.080 but there aren't any applications in that port. Better like 0:22:02.240 --> 0:22:04.600 next time. And if you've ever had your phone number 0:22:04.640 --> 0:22:07.640 spoofed by some jerk and then started to receive angry 0:22:07.640 --> 0:22:10.320 calls as a result, you know what this is like. Now, 0:22:10.359 --> 0:22:12.280 I've never had that happen on my personal number, but 0:22:12.320 --> 0:22:15.000 I actually once worked for a company that had its 0:22:15.040 --> 0:22:18.080 main phone number spoofed by someone who was using a 0:22:18.080 --> 0:22:21.240 fax machine, and this poor woman was getting phone calls 0:22:21.600 --> 0:22:23.359 and she would pick up the phone and it would 0:22:23.359 --> 0:22:25.320 clearly be a fax machine. It would be making that 0:22:25.400 --> 0:22:28.520 terrible fax machine noise. But the telephone number that was 0:22:28.560 --> 0:22:32.280