1 00:00:00,240 --> 00:00:01,140 In this lesson, 2 00:00:01,140 --> 00:00:03,090 we're going to discuss a network-based attack 3 00:00:03,090 --> 00:00:05,580 that you may come across while working in the field. 4 00:00:05,580 --> 00:00:08,970 This is known as a denial of service or DoS attack. 5 00:00:08,970 --> 00:00:10,500 Now, a denial of service occurs 6 00:00:10,500 --> 00:00:13,350 when one machine is continually flooding a victim 7 00:00:13,350 --> 00:00:15,030 with requests for services. 8 00:00:15,030 --> 00:00:17,550 That victim system simply won't be able to keep up, 9 00:00:17,550 --> 00:00:20,280 and so it'll run out of memory and eventually crash. 10 00:00:20,280 --> 00:00:22,740 For example, if I have a workstation that begins to send 11 00:00:22,740 --> 00:00:25,830 10 or 20 or 30 different packets of information at once 12 00:00:25,830 --> 00:00:27,360 to a low-powered server, 13 00:00:27,360 --> 00:00:29,610 that server may be able to crash 14 00:00:29,610 --> 00:00:31,980 because it won't be able to handle all those requests. 15 00:00:31,980 --> 00:00:33,330 Now, this was a big problem 16 00:00:33,330 --> 00:00:36,180 when we were dealing with networks 10 or 20 or 30 years ago. 17 00:00:36,180 --> 00:00:37,620 But since that time, 18 00:00:37,620 --> 00:00:40,140 computers and servers have gotten much faster, 19 00:00:40,140 --> 00:00:42,660 and so it is now very difficult for one computer 20 00:00:42,660 --> 00:00:45,150 to cause a denial of service all by itself 21 00:00:45,150 --> 00:00:47,550 by being able to send enough traffic to a server. 22 00:00:47,550 --> 00:00:49,770 But it is important to understand this concept 23 00:00:49,770 --> 00:00:51,330 from a historical perspective 24 00:00:51,330 --> 00:00:54,240 because what is old tends to become new again over time 25 00:00:54,240 --> 00:00:55,410 when it comes to network attacks 26 00:00:55,410 --> 00:00:57,000 and protecting ourselves from them. 27 00:00:57,000 --> 00:00:59,760 To achieve a denial of service attack with a single machine, 28 00:00:59,760 --> 00:01:02,490 attackers are going to use either a TCP SYN Flood, 29 00:01:02,490 --> 00:01:04,440 or an ICMP flood. 30 00:01:04,440 --> 00:01:06,660 A TCP SYN Flood is a specific type 31 00:01:06,660 --> 00:01:08,070 of denial of service attack 32 00:01:08,070 --> 00:01:09,600 that occurs when an attacker initiates 33 00:01:09,600 --> 00:01:11,250 multiple TCP sessions, 34 00:01:11,250 --> 00:01:13,680 but they never complete those sessions. 35 00:01:13,680 --> 00:01:16,590 So remember, TCP operates by conducting 36 00:01:16,590 --> 00:01:19,440 a three-way handshake to establish communication. 37 00:01:19,440 --> 00:01:21,720 This happens by the requester first setting a packet 38 00:01:21,720 --> 00:01:23,280 with the SYN flag set. 39 00:01:23,280 --> 00:01:25,170 Then the server sends back a packet 40 00:01:25,170 --> 00:01:27,420 with both the SYN and the ACK flag set. 41 00:01:27,420 --> 00:01:30,180 And finally, that server sits there and waits for the client 42 00:01:30,180 --> 00:01:33,630 to send back a final packet with just the ACK flag set, 43 00:01:33,630 --> 00:01:35,520 and this will complete the handshake. 44 00:01:35,520 --> 00:01:37,920 Well, in A TCP SYN Flood attack, 45 00:01:37,920 --> 00:01:40,230 the attacker sends a bunch of requests to the server 46 00:01:40,230 --> 00:01:41,700 to establish those connections 47 00:01:41,700 --> 00:01:43,890 by sending out the first part of the handshake. 48 00:01:43,890 --> 00:01:46,830 Those packets will just have the SYN flag set. 49 00:01:46,830 --> 00:01:49,950 The server will then respond and reserve some resources, 50 00:01:49,950 --> 00:01:52,950 like network capacity or memory, for each of the requests, 51 00:01:52,950 --> 00:01:54,660 and it sends back the packet 52 00:01:54,660 --> 00:01:57,630 that has SYN and ACK flags both being set. 53 00:01:57,630 --> 00:01:58,620 Now, up to this point, 54 00:01:58,620 --> 00:02:01,740 everything is operating like a normal TCP handshake, right? 55 00:02:01,740 --> 00:02:03,870 But instead of the attacker acknowledging 56 00:02:03,870 --> 00:02:05,310 that SYN-ACK packet, 57 00:02:05,310 --> 00:02:07,200 they're not going to send back an ACK packet. 58 00:02:07,200 --> 00:02:09,240 Instead, they're just going to ignore it. 59 00:02:09,240 --> 00:02:12,210 And so we end up with a bunch of these half-open connections 60 00:02:12,210 --> 00:02:14,340 that are consuming resources on the server. 61 00:02:14,340 --> 00:02:16,500 If you have too many of these half-open connections, 62 00:02:16,500 --> 00:02:17,940 you could overwhelm the server, 63 00:02:17,940 --> 00:02:19,650 and therefore, you could crash it 64 00:02:19,650 --> 00:02:22,110 through this process of resource exhaustion. 65 00:02:22,110 --> 00:02:23,700 To execute this type of an attack, 66 00:02:23,700 --> 00:02:26,100 the attacker is usually going to spoof their source IP 67 00:02:26,100 --> 00:02:28,290 when conducting their three-way handshake. 68 00:02:28,290 --> 00:02:30,780 This way, when they send the SYN packet over, 69 00:02:30,780 --> 00:02:34,050 the server will respond with the SYN-ACK to a spoofed IP. 70 00:02:34,050 --> 00:02:35,820 and that person isn't expecting it, 71 00:02:35,820 --> 00:02:37,530 and therefore, they're not going to answer it, 72 00:02:37,530 --> 00:02:39,330 and they're just going to drop that packet. 73 00:02:39,330 --> 00:02:41,190 This leaves the connection half open 74 00:02:41,190 --> 00:02:42,540 for the default length of time 75 00:02:42,540 --> 00:02:44,580 until the server closes that connection. 76 00:02:44,580 --> 00:02:46,860 Normally, this will be around three minutes. 77 00:02:46,860 --> 00:02:48,900 So, in that three-minute period, 78 00:02:48,900 --> 00:02:51,480 you can get a lot of these half-open connections. 79 00:02:51,480 --> 00:02:52,860 And if you get too many of them, 80 00:02:52,860 --> 00:02:55,500 it will be resource exhaustion on that server 81 00:02:55,500 --> 00:02:57,240 that could cause it to crash. 82 00:02:57,240 --> 00:02:58,860 You could see an example of that here 83 00:02:58,860 --> 00:03:01,320 with four different spoof IPs being sent to the server 84 00:03:01,320 --> 00:03:02,460 by the attacker. 85 00:03:02,460 --> 00:03:05,610 Now, when the server sends back its responses to those IPs, 86 00:03:05,610 --> 00:03:07,470 which never respond because they weren't starting 87 00:03:07,470 --> 00:03:09,060 a three-way handshake after all, 88 00:03:09,060 --> 00:03:11,010 that server is now just going to sit there 89 00:03:11,010 --> 00:03:13,710 and wait with a bunch of half-open connections. 90 00:03:13,710 --> 00:03:15,120 To help you remember this concept, 91 00:03:15,120 --> 00:03:17,880 I think there's a good analogy that I can give you here. 92 00:03:17,880 --> 00:03:19,320 Let's pretend that you have some kids, 93 00:03:19,320 --> 00:03:20,153 and if you have kids, 94 00:03:20,153 --> 00:03:21,930 you're probably going to relate well to this. 95 00:03:21,930 --> 00:03:23,700 Now, when my kids were really little, 96 00:03:23,700 --> 00:03:25,800 my wife would sometimes get really stressed out 97 00:03:25,800 --> 00:03:27,300 and overwhelmed by them. 98 00:03:27,300 --> 00:03:28,740 This would occur because both kids 99 00:03:28,740 --> 00:03:31,080 would try to get her attention at one time. 100 00:03:31,080 --> 00:03:33,667 For example, my two kids would go running over her and go, 101 00:03:33,667 --> 00:03:35,737 "Hey, mommy, mommy, mommy, I have a question." 102 00:03:35,737 --> 00:03:37,507 "Mommy, mommy, mommy, I want a snack." 103 00:03:37,507 --> 00:03:40,020 "Mommy, mommy, mommy," and things like that. 104 00:03:40,020 --> 00:03:42,030 Now, if one of the kids did this to mom, 105 00:03:42,030 --> 00:03:42,863 mom could handle it. 106 00:03:42,863 --> 00:03:44,880 She can take care of one kid with no issues. 107 00:03:44,880 --> 00:03:46,680 But if both of them did at the same time, 108 00:03:46,680 --> 00:03:49,290 she would have to balance her efforts between the two kids. 109 00:03:49,290 --> 00:03:51,150 And so if my kids had a few friends over, 110 00:03:51,150 --> 00:03:52,530 and now we have five or six kids 111 00:03:52,530 --> 00:03:54,720 who are asking for mom's attention all at once, 112 00:03:54,720 --> 00:03:57,690 she could quickly become overwhelmed and crash. 113 00:03:57,690 --> 00:03:59,850 And that is using the terminology of an overloaded server, 114 00:03:59,850 --> 00:04:01,170 but you get the idea. 115 00:04:01,170 --> 00:04:03,300 Basically, she could become exhausted 116 00:04:03,300 --> 00:04:04,680 and she wouldn't be able to function anymore 117 00:04:04,680 --> 00:04:06,510 and answer all their queries. 118 00:04:06,510 --> 00:04:09,060 This is basically a denial of service. 119 00:04:09,060 --> 00:04:11,310 Now, another form of denial of service attack we have 120 00:04:11,310 --> 00:04:12,930 is known as a Smurf attack. 121 00:04:12,930 --> 00:04:14,910 And again, this is an older type of attack. 122 00:04:14,910 --> 00:04:17,070 It's known as an ICMP flood. 123 00:04:17,070 --> 00:04:18,870 This occurs against the victim's server 124 00:04:18,870 --> 00:04:22,200 by using ICMP traffic instead of TCP traffic. 125 00:04:22,200 --> 00:04:24,990 An ICMP flood occurs when an attacker sends a ping 126 00:04:24,990 --> 00:04:28,290 to a subnet broadcast address with the source IP spoofed, 127 00:04:28,290 --> 00:04:30,480 and that source IP is now going to be showing 128 00:04:30,480 --> 00:04:32,040 as the victimized server. 129 00:04:32,040 --> 00:04:34,440 By doing this, all the devices on that subnet 130 00:04:34,440 --> 00:04:36,240 are going to respond back to the server, 131 00:04:36,240 --> 00:04:38,820 and this can start using up all their processing power, 132 00:04:38,820 --> 00:04:40,470 their memory, and their bandwidth, 133 00:04:40,470 --> 00:04:42,270 and this could lead to resource exhaustion 134 00:04:42,270 --> 00:04:44,310 and, again, a possible server crash. 135 00:04:44,310 --> 00:04:47,040 In this example, an attacker spoofs their source address 136 00:04:47,040 --> 00:04:48,930 and pretends that they are the server. 137 00:04:48,930 --> 00:04:51,270 Now, this attacker sends out a single packet 138 00:04:51,270 --> 00:04:56,040 to the subnet broadcast address of 192.168.1.255, 139 00:04:56,040 --> 00:04:59,703 and it says, "Hey, I'm the server at 10.1.1.2." 140 00:04:59,703 --> 00:05:02,880 Now, in response to this, all the clients in the broadcast, 141 00:05:02,880 --> 00:05:04,710 in this example, a class C subnet 142 00:05:04,710 --> 00:05:06,840 with up to 254 clients on it, 143 00:05:06,840 --> 00:05:09,360 will start sending back a response to that server 144 00:05:09,360 --> 00:05:11,820 since they all saw the source IP of this request 145 00:05:11,820 --> 00:05:14,310 as that of the server and not the attacker. 146 00:05:14,310 --> 00:05:17,010 This essentially is going to amplify the denial of service 147 00:05:17,010 --> 00:05:18,210 against the server 148 00:05:18,210 --> 00:05:20,610 because the attacker can now speed up this process 149 00:05:20,610 --> 00:05:23,040 even more by sending out more of these requests. 150 00:05:23,040 --> 00:05:25,290 They can send the same type of requests over and over 151 00:05:25,290 --> 00:05:26,760 to multiple different subnets, 152 00:05:26,760 --> 00:05:28,740 and they can use different broadcast addresses 153 00:05:28,740 --> 00:05:30,810 to get all these things amplified back towards 154 00:05:30,810 --> 00:05:32,100 that first victim. 155 00:05:32,100 --> 00:05:33,960 Now, because of this threat of a denial of service 156 00:05:33,960 --> 00:05:36,510 using ICMP traffic, which is the same traffic 157 00:05:36,510 --> 00:05:37,950 that's used by the ping tool, 158 00:05:37,950 --> 00:05:40,230 a lot of networks will block providing responses 159 00:05:40,230 --> 00:05:42,840 to ping requests and instead, they'll just drop 160 00:05:42,840 --> 00:05:44,370 or ignore these requests. 161 00:05:44,370 --> 00:05:47,160 For this reason, ICMP floods are not as common 162 00:05:47,160 --> 00:05:48,090 as they used to be. 163 00:05:48,090 --> 00:05:50,070 But if you misconfigured your network, 164 00:05:50,070 --> 00:05:52,110 it still could be a viable attack method 165 00:05:52,110 --> 00:05:54,180 for an attacker to use on your network. 166 00:05:54,180 --> 00:05:57,000 All right, let's take this concept of a denial of service 167 00:05:57,000 --> 00:05:59,940 one step further and add more attacking machines 168 00:05:59,940 --> 00:06:02,400 that are focused on overwhelming a single server 169 00:06:02,400 --> 00:06:03,720 all at the same time. 170 00:06:03,720 --> 00:06:06,180 This is known as a distributed denial of service 171 00:06:06,180 --> 00:06:08,100 or DDoS attack. 172 00:06:08,100 --> 00:06:10,350 Now, in a distributed denial of service attack, 173 00:06:10,350 --> 00:06:14,190 the attacker will use 100, 1,000 or even 100,000 computers 174 00:06:14,190 --> 00:06:17,970 all at the same time asking for access to a single server. 175 00:06:17,970 --> 00:06:20,250 This way, they can consume up all of that server's 176 00:06:20,250 --> 00:06:22,680 processing, memory and bandwidth resources, 177 00:06:22,680 --> 00:06:26,310 leading to that server exhaustion and a server crash. 178 00:06:26,310 --> 00:06:29,190 Now, often, these machines can become part of the attack 179 00:06:29,190 --> 00:06:31,080 and they won't even know they're part of that attack 180 00:06:31,080 --> 00:06:33,360 because they are essentially part of a botnet 181 00:06:33,360 --> 00:06:35,610 and they're now being controlled as a zombie. 182 00:06:35,610 --> 00:06:38,490 A botnet is simply a collection of compromised computers 183 00:06:38,490 --> 00:06:40,890 under the control of a single master node. 184 00:06:40,890 --> 00:06:42,120 A zombie, on the other hand, 185 00:06:42,120 --> 00:06:45,120 is any one of these individually compromised computers. 186 00:06:45,120 --> 00:06:47,190 Once a device becomes part of a botnet, 187 00:06:47,190 --> 00:06:49,350 it can be controlled by a master node 188 00:06:49,350 --> 00:06:52,080 as a C2 or command and control server. 189 00:06:52,080 --> 00:06:54,060 An attacker who controls a C2 server 190 00:06:54,060 --> 00:06:55,830 will also control all the zombies 191 00:06:55,830 --> 00:06:57,870 that operate as part of this botnet. 192 00:06:57,870 --> 00:06:59,970 This isn't just a single computer anymore, 193 00:06:59,970 --> 00:07:02,790 but instead it could be hundreds of thousands of machines, 194 00:07:02,790 --> 00:07:04,560 all with the ability to be coordinated 195 00:07:04,560 --> 00:07:06,720 into attacking a single target. 196 00:07:06,720 --> 00:07:08,460 So when the attacker wants to launch 197 00:07:08,460 --> 00:07:11,040 a distributed denial of service attack against a website, 198 00:07:11,040 --> 00:07:12,360 like the Wall Street Journal, 199 00:07:12,360 --> 00:07:13,380 they simply send a command 200 00:07:13,380 --> 00:07:15,600 from their computer to the C2 server, 201 00:07:15,600 --> 00:07:18,450 and then the C2 server will then relay that command 202 00:07:18,450 --> 00:07:21,570 down to some or all of the zombies under its control. 203 00:07:21,570 --> 00:07:23,820 This allows them to conduct a massive attack 204 00:07:23,820 --> 00:07:26,280 that can even take down some really large websites 205 00:07:26,280 --> 00:07:27,900 if they have enough zombies. 206 00:07:27,900 --> 00:07:29,460 Now, the challenge for an attacker here 207 00:07:29,460 --> 00:07:32,190 is that as more and more organizations move to the cloud, 208 00:07:32,190 --> 00:07:35,280 it becomes harder and harder to overwhelm their servers. 209 00:07:35,280 --> 00:07:38,010 After all, if you're using elastic cloud servers, 210 00:07:38,010 --> 00:07:39,720 you can simply horizontally scale out 211 00:07:39,720 --> 00:07:41,610 to answer up for all this new demand 212 00:07:41,610 --> 00:07:44,010 that's being sent to you from all these different zombies 213 00:07:44,010 --> 00:07:46,200 during a distributed denial service attack. 214 00:07:46,200 --> 00:07:48,480 But that doesn't mean you shouldn't try to prevent 215 00:07:48,480 --> 00:07:50,250 these types of distributed denial of service attacks 216 00:07:50,250 --> 00:07:51,210 from happening. 217 00:07:51,210 --> 00:07:53,220 After all, with cloud-based resources, 218 00:07:53,220 --> 00:07:55,110 you're still paying for all that compute 219 00:07:55,110 --> 00:07:57,180 and bandwidth resources that are being used 220 00:07:57,180 --> 00:07:59,520 to answer up for all these attacking requests. 221 00:07:59,520 --> 00:08:02,850 So even if you can withstand the attack and outlast it 222 00:08:02,850 --> 00:08:05,220 by horizontally scaling out on your servers, 223 00:08:05,220 --> 00:08:07,890 it could result in a huge bill at the end of the month, 224 00:08:07,890 --> 00:08:08,940 and none of that bandwidth 225 00:08:08,940 --> 00:08:10,770 was actually doing anything useful for you 226 00:08:10,770 --> 00:08:13,410 because it wasn't from legitimate customers or users. 227 00:08:13,410 --> 00:08:15,360 It was just from people who were attacking you 228 00:08:15,360 --> 00:08:16,910 and you're still paying for it.