WEBVTT 1 00:00.000 --> 00:04.340 One of the really beautiful things about security in the world of NSX is that 2 00:04.340 --> 00:05.360 we have a concept 3 00:05.360 --> 00:07.760 called micro segmentation. 4 00:07.760 --> 00:11.330 So to really appreciate that, let's talk about in the old days, let's go back 5 00:11.330 --> 00:12.920 20 or 30 years 6 00:12.920 --> 00:16.520 and take a look at how we did controlling of traffic on a network back in the 7 00:16.520 --> 00:17.520 early days. 8 00:17.520 --> 00:20.640 So back in the early days, let's imagine we have a router, we couldn't call 9 00:20.640 --> 00:21.080 that router 10 00:21.080 --> 00:24.520 one, and we have a network over here, let's call that the 10-10 network. 11 00:24.520 --> 00:27.870 And then over here on the right, we have the 10-20 network, and then we have 12 00:27.870 --> 00:28.560 some servers 13 00:28.560 --> 00:32.800 and printers and other devices connected respectively to those networks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 13 00:28.560 --> 00:32.800 and printers and other devices connected respectively to those networks. 14 00:32.800 --> 00:39.050 So perhaps this device right here is at 10.20.0.100, and instead of here is at 15 00:39.050 --> 00:41.800 10.20.0.101. 16 00:41.800 --> 00:45.160 And over here, this device is at 10.10.0. 17 00:45.160 --> 00:47.160 Let's go ahead and use 90. 18 00:47.160 --> 00:50.240 And this device right here, let's say it's at 10.10.0.91. 19 00:50.240 --> 00:51.240 All right, fantastic. 20 00:51.240 --> 00:54.830 And then for default gateway services, let's imagine this router is at dot one 21 00:54.830 --> 00:55.680 on the 10-10 22 00:55.680 --> 01:01.060 network and over here on the 10-20 network that is dot one over here with 10-20 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:55.680 --> 01:01.060 network and over here on the 10-20 network that is dot one over here with 10-20 23 01:01.060 --> 01:01.560 .1. 24 01:01.560 --> 01:04.870 And then based on the IP configuration of these devices, they would be using 25 01:04.870 --> 01:05.280 dot one 26 01:05.280 --> 01:07.680 on their respective networks as their default gateway. 27 01:07.680 --> 01:10.770 And then router one, of course, can have connectivity to additional networks, 28 01:10.770 --> 01:11.080 which we'll 29 01:11.080 --> 01:12.560 just represent as a cloud. 30 01:12.560 --> 01:15.570 And let's further more imagine that over here, this group of computers in this 31 01:15.570 --> 01:16.000 network 32 01:16.000 --> 01:19.200 segment, that's the human resources department. 33 01:19.200 --> 01:22.920 And over here on the right hand side on the 10-20 network, let's imagine that's 34 01:22.920 --> 01:23.680 the engineering 35 01:23.680 --> 01:24.680 group. 36 01:24.680 --> 01:27.560 So I wanted to set up controls to control what traffic is allowed. 37 01:27.560 --> 01:31.580 For example, between 10-10 over here and 10-20-0 over here, what we would do in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 37 01:27.560 --> 01:31.580 For example, between 10-10 over here and 10-20-0 over here, what we would do in 38 01:31.580 --> 01:32.520 the old days 39 01:32.520 --> 01:34.880 is we would set up controls at this router. 40 01:34.880 --> 01:38.990 So we could put in access control list at these interfaces that specify, "Hey, 41 01:38.990 --> 01:39.400 I want 42 01:39.400 --> 01:43.600 to permit or deny this certain type of traffic based on IP address or the layer 43 01:43.600 --> 01:44.560 for protocol, 44 01:44.560 --> 01:48.790 et cetera, going between 10-10 and 10-20 and the pass that was implemented with 45 01:48.790 --> 01:49.080 access 46 01:49.080 --> 01:50.080 control list. 47 01:50.080 --> 01:53.440 And with stateful filtering, it can go ahead and based on our rules allow 48 01:53.440 --> 01:53.920 initial 49 01:53.920 --> 01:57.560 flows of traffic and then dynamically remember those states and allow the reply 50 01:57.560 --> 01:58.120 traffic to 51 01:58.120 --> 01:59.120 come back." 52 01:59.120 --> 02:02.780 So many of the routers and most of the firewalls today are capable of doing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 01:59.120 --> 02:02.780 So many of the routers and most of the firewalls today are capable of doing 53 02:02.780 --> 02:04.280 stateful filtering, 54 02:04.280 --> 02:07.160 where they allow initial flows of traffic and remember that session and allow 55 02:07.160 --> 02:07.640 the reply 56 02:07.640 --> 02:08.640 traffic to come back. 57 02:08.640 --> 02:12.040 However, I've got a question and a problem to present and that's this. 58 02:12.040 --> 02:15.040 What if we want to control what traffic is allowed between this host? 59 02:15.040 --> 02:18.000 We'll call it host A and this host, host B. 60 02:18.000 --> 02:21.360 Now if they are the same local area network and they're not going through the 61 02:21.360 --> 02:22.600 router interfaces 62 02:22.600 --> 02:25.600 or if this was a firewall, they're not going through the firewall interfaces, 63 02:25.600 --> 02:26.040 how do we 64 02:26.040 --> 02:29.760 control what traffic is allowed between host A and host B? 65 02:29.760 --> 02:33.690 And the answer in the old world was if this was a VLAN, we could set up layer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 02:29.760 --> 02:33.690 And the answer in the old world was if this was a VLAN, we could set up layer 66 02:33.690 --> 02:34.520 two security 67 02:34.520 --> 02:37.960 and implement that but that was really, really tedious to do manually. 68 02:37.960 --> 02:42.110 However, in the world of NSX, if these are two VMs and they're both right here, 69 02:42.110 --> 02:43.240 for example, 70 02:43.240 --> 02:47.160 on segment 10, we can set up a distributed firewall and that distributed 71 02:47.160 --> 02:47.960 firewall, think 72 02:47.960 --> 02:52.480 of it like a firewall with a set of rules that hovers over the entire network. 73 02:52.480 --> 02:55.460 So with the distributed firewall, we could say, for example, as part of our 74 02:55.460 --> 02:55.880 rules, that 75 02:55.880 --> 02:58.990 hey, we don't want to allow, let's say, certain types of traffic, let's say a 76 02:58.990 --> 02:59.320 ping 77 02:59.320 --> 03:04.080 request or any ICMP traffic between host A here and host B. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 02:59.320 --> 03:04.080 request or any ICMP traffic between host A here and host B. 78 03:04.080 --> 03:07.560 So if we set up that distributed firewall rule, it doesn't matter if these 79 03:07.560 --> 03:08.240 devices A 80 03:08.240 --> 03:12.430 and B are on the same local segment or if we move one to another segment, that 81 03:12.430 --> 03:13.000 distributed 82 03:13.000 --> 03:16.440 firewall rule is going to be implemented regardless of where that machine goes. 83 03:16.440 --> 03:19.400 Now if we had to do those rules for every single machine to every other 84 03:19.400 --> 03:20.280 possible virtual 85 03:20.280 --> 03:22.520 machine, that would be very tedious as well. 86 03:22.520 --> 03:25.600 So we're also going to leverage the concept of groups. 87 03:25.600 --> 03:29.120 And as an example of that, we could create a group called users. 88 03:29.120 --> 03:32.380 And this user's group could represent a group of VMs that are acting as clients WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 88 03:29.120 --> 03:32.380 And this user's group could represent a group of VMs that are acting as clients 89 03:32.380 --> 03:32.600 . 90 03:32.600 --> 03:35.840 So maybe for this user's group, and then we go ahead and color code these. 91 03:35.840 --> 03:39.680 So for the user's group, we'll go ahead and use this orange color right there. 92 03:39.680 --> 03:45.600 And let's go ahead and put this VM and that VM and that VM and that VM, we'll 93 03:45.600 --> 03:45.840 put them 94 03:45.840 --> 03:48.520 all inside of this group called users. 95 03:48.520 --> 03:50.680 And then we can create another group called servers. 96 03:50.680 --> 03:54.030 And just for this example right here, let's just imagine this web server here 97 03:54.030 --> 03:54.480 and also 98 03:54.480 --> 03:57.320 this database server here are going to be part of that group. 99 03:57.320 --> 04:00.310 And then as part of our configuration for the security policy rules as part of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 03:57.320 --> 04:00.310 And then as part of our configuration for the security policy rules as part of 100 04:00.310 --> 04:00.920 our distributed 101 04:00.920 --> 04:06.250 firewall, we can specify exactly what is allowed between, for example, objects 102 04:06.250 --> 04:07.040 or in this case, 103 04:07.040 --> 04:10.830 VMs that are in the user's group, if they're connecting to or interacting with 104 04:10.830 --> 04:11.320 the servers 105 04:11.320 --> 04:12.320 group. 106 04:12.320 --> 04:15.040 So let me clean up a little bit of this as we continue our discussion here. 107 04:15.040 --> 04:18.920 So as part of our rules, let's go ahead and use ICMP as an example. 108 04:18.920 --> 04:25.120 We can say no, ICMP from the user's security group, if it is trying to access 109 04:25.120 --> 04:26.280 any objects 110 04:26.280 --> 04:29.280 or VMs here as part of the server's security group. 111 04:29.280 --> 04:32.210 And then the cool thing is this, once we implement that, this VM right here on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 111 04:29.280 --> 04:32.210 And then the cool thing is this, once we implement that, this VM right here on 112 04:32.210 --> 04:33.160 the same local 113 04:33.160 --> 04:37.080 network segment as the web server, if we had that rule in place, there'd be no 114 04:37.080 --> 04:37.840 permissions 115 04:37.840 --> 04:41.910 for any kind of ICMP traffic that was initiated from this VM trying to go to 116 04:41.910 --> 04:42.800 the web server 117 04:42.800 --> 04:46.290 because in our security policy rules, we're specifying that that is not allowed 118 04:46.290 --> 04:46.360 . 119 04:46.360 --> 04:49.430 Now another great question I'd like to chat with you about is regarding, okay, 120 04:49.430 --> 04:50.000 how exactly 121 04:50.000 --> 04:51.520 do we get these VMs? 122 04:51.520 --> 04:54.910 For example, these four VMs in orange here, how do we get them included as part 123 04:54.910 --> 04:55.320 of this 124 04:55.320 --> 04:56.320 user's security group? 125 04:56.320 --> 05:00.760 Now, one way is we can just manually go select them and add them or we could go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 125 04:56.320 --> 05:00.760 Now, one way is we can just manually go select them and add them or we could go 126 05:00.760 --> 05:01.400 ahead and 127 05:01.400 --> 05:03.200 create a dynamic group. 128 05:03.200 --> 05:07.030 So for a dynamic group, we can specify if a VM matches these criteria, for 129 05:07.030 --> 05:07.720 example, this 130 05:07.720 --> 05:12.760 OS or that IP address, then go ahead and include them as part of the group. 131 05:12.760 --> 05:17.040 Now, one of those options we conclude as a criteria for a group membership is 132 05:17.040 --> 05:17.800 the concept 133 05:17.800 --> 05:19.240 of a tag. 134 05:19.240 --> 05:22.570 So for example, in NSX, we could go ahead and create a tag called user, and I 135 05:22.570 --> 05:23.000 'll go ahead 136 05:23.000 --> 05:26.680 and call it user tag here, and we create another tag called server tag. 137 05:26.680 --> 05:30.200 And we associate that user tag with these four VMs right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 05:26.680 --> 05:30.200 And we associate that user tag with these four VMs right here. 138 05:30.200 --> 05:33.620 And if we have a group that's looking for any VMs that have that tag, that'll 139 05:33.620 --> 05:34.280 dynamically 140 05:34.280 --> 05:37.520 make any of those four VMs that have that tag a member of that group. 141 05:37.520 --> 05:40.890 And we can do a similar concept for the servers to make them a member of the 142 05:40.890 --> 05:41.720 servers group. 143 05:41.720 --> 05:44.920 We either manually add them individually or we could look for some 144 05:44.920 --> 05:45.960 characteristic, including 145 05:45.960 --> 05:47.520 the use of a tag. 146 05:47.520 --> 05:51.140 So for these servers, if we specify these two servers that they had this tag 147 05:51.140 --> 05:51.880 called server 148 05:51.880 --> 05:54.400 tag, and then we create a group called servers. 149 05:54.400 --> 05:57.920 And as part of the dynamic membership of that group, if you have the tag called 150 05:57.920 --> 05:58.240 server 151 05:58.240 --> 05:59.840 tag, you're a member of that group. 152 05:59.840 --> 06:05.080 And that way we can very easily on the fly, manipulate the tags associated with WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 05:59.840 --> 06:05.080 And that way we can very easily on the fly, manipulate the tags associated with 153 06:05.080 --> 06:05.600 the VMs. 154 06:05.600 --> 06:08.240 And as a result, they would then be included as part of the respective security 155 06:08.240 --> 06:08.600 group. 156 06:08.600 --> 06:13.010 And then also as a byproduct of that, if we have our distributed firewall rules 157 06:13.010 --> 06:13.120 that 158 06:13.120 --> 06:17.080 are permitting or denying certain types of traffic flow, we're now able to 159 06:17.080 --> 06:17.800 control all 160 06:17.800 --> 06:21.390 the traffic that flows between any of our VMs in our environment based on our 161 06:21.390 --> 06:21.960 security 162 06:21.960 --> 06:22.960 policy rules. 163 06:22.960 --> 06:25.770 Also, another really cool thing about a distributed firewall is that very 164 06:25.770 --> 06:27.560 similar to the concept 165 06:27.560 --> 06:31.940 of routing where a host transport node will make all the routing decisions WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 165 06:27.560 --> 06:31.940 of routing where a host transport node will make all the routing decisions 166 06:31.940 --> 06:32.600 early and 167 06:32.600 --> 06:34.840 then forward it to the final destination. 168 06:34.840 --> 06:37.240 The same thing is true for our distributed firewall rules. 169 06:37.240 --> 06:40.610 For example, if this little VM right here, which is running on host A, is 170 06:40.610 --> 06:41.160 trying to send 171 06:41.160 --> 06:44.650 traffic that's going either to another VM on the local segment or needs to be 172 06:44.650 --> 06:45.040 routed 173 06:45.040 --> 06:48.980 through the NSX routed environment, either way, host A because it has a copy of 174 06:48.980 --> 06:49.400 not only 175 06:49.400 --> 06:52.800 the distributed router, but also all the rules included as part of our 176 06:52.800 --> 06:53.880 distributed firewall 177 06:53.880 --> 06:54.880 rules. 178 06:54.880 --> 06:58.130 If there's a deny that says, hey, that traffic is not allowed, it's the ESXi 179 06:58.130 --> 06:58.800 host transport 180 06:58.800 --> 07:01.970 node where that VM lives that's going to identify, hey, that's not allowed and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 180 06:58.800 --> 07:01.970 node where that VM lives that's going to identify, hey, that's not allowed and 181 07:01.970 --> 07:02.760 kill it right 182 07:02.760 --> 07:03.760 near the source. 183 07:03.760 --> 07:06.670 So for this VM here, this part of the users group, if it was trying to connect 184 07:06.670 --> 07:07.200 down to 185 07:07.200 --> 07:10.570 this database server here, which is part of the servers group, where this VM 186 07:10.570 --> 07:11.360 here, VMA 187 07:11.360 --> 07:15.400 is running on host A and the database VM is running on host B, if that traffic 188 07:15.400 --> 07:15.880 from this 189 07:15.880 --> 07:21.120 VM to that server is not allowed, it's ESXi A, that host transport node that 190 07:21.120 --> 07:21.760 has all that 191 07:21.760 --> 07:24.270 information about the distributed firewall rules that's going to go ahead and 192 07:24.270 --> 07:24.720 say, whoa, 193 07:24.720 --> 07:27.520 that traffic is not allowed and deny it right there. 194 07:27.520 --> 07:31.460 Didn't have to wait until it gets all the way over to ESXi B for ESXi B to make WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 194 07:27.520 --> 07:31.460 Didn't have to wait until it gets all the way over to ESXi B for ESXi B to make 195 07:31.460 --> 07:32.360 the decision. 196 07:32.360 --> 07:36.990 ESXi A can enforce those rules immediately, drop the traffic and the host ESXi 197 07:36.990 --> 07:37.480 B would 198 07:37.480 --> 07:40.780 never have to make that decision because the traffic was never sent over there 199 07:40.780 --> 07:41.200 in the first 200 07:41.200 --> 07:42.200 place. 201 07:42.200 --> 07:45.370 So again, just like routing, the security policy rules as part of a distributed 202 07:45.370 --> 07:45.840 firewall 203 07:45.840 --> 07:48.840 are processed as close to the source as possible. 204 07:48.840 --> 07:51.640 So let me clean some of this up and let's talk about one other concept 205 07:51.640 --> 07:52.720 regarding distributed 206 07:52.720 --> 07:53.720 firewalls. 207 07:53.720 --> 07:55.720 And the concept I'd like to share with you is the order. 208 07:55.720 --> 07:59.390 Let's imagine we have several rules in place that are either going to permit or 209 07:59.390 --> 08:00.720 deny traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 209 07:59.390 --> 08:00.720 deny traffic. 210 08:00.720 --> 08:02.200 How exactly are those processed? 211 08:02.200 --> 08:05.920 And the answer is they are going to be processed in, first of all, a set of 212 08:05.920 --> 08:06.840 categories. 213 08:06.840 --> 08:09.280 So those categories go left to right. 214 08:09.280 --> 08:12.960 So I'm going to call this category one, two, three, and four, and five. 215 08:12.960 --> 08:14.640 They have some names as we'll see in the interface. 216 08:14.640 --> 08:17.200 And again, those are processed from left to right. 217 08:17.200 --> 08:20.620 And within each of those categories, there could be one or more policies which 218 08:20.620 --> 08:21.240 also include 219 08:21.240 --> 08:24.440 rules that are permitting or denying traffic based on a match. 220 08:24.440 --> 08:27.400 So let's imagine here in category one, we have a couple rules. 221 08:27.400 --> 08:29.560 Let's call it rule A and B. 222 08:29.560 --> 08:32.160 And then over here in category two, we have rules C. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 222 08:29.560 --> 08:32.160 And then over here in category two, we have rules C. 223 08:32.160 --> 08:37.130 And D and E. And then category three, we have F and G and H and I, each of 224 08:37.130 --> 08:38.520 those representing 225 08:38.520 --> 08:39.520 rules. 226 08:39.520 --> 08:44.030 And then over here in category four, B, J and K and L. And then category five, 227 08:44.030 --> 08:44.940 it's M and 228 08:44.940 --> 08:47.320 N and O and P and Q. 229 08:47.320 --> 08:48.320 And those could go on. 230 08:48.320 --> 08:51.710 And again, each of those represents the individual rules as part of our 231 08:51.710 --> 08:52.760 security policy. 232 08:52.760 --> 08:56.030 So as far as how these are processed looking for a match, we're going to start 233 08:56.030 --> 08:56.380 on the 234 08:56.380 --> 08:59.850 left with the first category and then go through everything in that first 235 08:59.850 --> 09:00.680 category and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 235 08:59.850 --> 09:00.680 category and then 236 09:00.680 --> 09:04.020 go to category two, then we'll check all the rules in that category and then go 237 09:04.020 --> 09:04.600 to category 238 09:04.600 --> 09:06.080 three, check all those rules. 239 09:06.080 --> 09:08.920 So let's imagine we have traffic that's flowing through the network or wants to 240 09:08.920 --> 09:09.400 flow through 241 09:09.400 --> 09:13.750 the network inside of NSX and for the criteria for the matching, there's 242 09:13.750 --> 09:15.160 nothing specifically 243 09:15.160 --> 09:19.000 matching in category one, there's no specific rules as part of category two. 244 09:19.000 --> 09:22.560 But let's imagine that we have a rule H here in category three. 245 09:22.560 --> 09:23.720 And so there's a match. 246 09:23.720 --> 09:27.080 And as a result, it's going to go ahead and do what that rule says. 247 09:27.080 --> 09:30.530 And the options that we can specify for a rule that's being matched is we can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 247 09:27.080 --> 09:30.530 And the options that we can specify for a rule that's being matched is we can 248 09:30.530 --> 09:31.240 go ahead and 249 09:31.240 --> 09:32.240 allow that traffic. 250 09:32.240 --> 09:35.040 We can go ahead and drop that traffic or we can reject that traffic. 251 09:35.040 --> 09:37.520 So allow simply says, permit the traffic to go. 252 09:37.520 --> 09:40.120 A drop says, go ahead and drop the traffic. 253 09:40.120 --> 09:41.120 Don't let it continue. 254 09:41.120 --> 09:44.640 However, don't bother telling anybody else that you drop the traffic. 255 09:44.640 --> 09:48.100 So if this client, for example, right here was trying to connect to this server 256 09:48.100 --> 09:48.720 down here, 257 09:48.720 --> 09:52.500 maybe it was a TCP session that was being attempted by this VM and it was being 258 09:52.500 --> 09:52.920 denied 259 09:52.920 --> 09:53.920 here. 260 09:53.920 --> 09:56.990 So if the rules being matched and the action was dropped, this client would not 261 09:56.990 --> 09:57.760 get a TCP 262 09:57.760 --> 10:01.930 reset or any other indication that it was being rejected by the network or by WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 262 09:57.760 --> 10:01.930 reset or any other indication that it was being rejected by the network or by 263 10:01.930 --> 10:02.800 the server. 264 10:02.800 --> 10:05.120 So we have dropped as the action for a matched rule. 265 10:05.120 --> 10:08.630 This VM would simply, if it matched that rule, simply think, wow, the service 266 10:08.630 --> 10:09.320 isn't working 267 10:09.320 --> 10:10.800 and it would simply timeout. 268 10:10.800 --> 10:14.580 On the other hand, if we said reject as opposed to drop for the action on that 269 10:14.580 --> 10:16.080 matched H rule, 270 10:16.080 --> 10:20.310 in that case, if this VM initiated or tried to initiate a TCP session down to 271 10:20.310 --> 10:21.120 the server, 272 10:21.120 --> 10:24.160 the response coming back would be a TCP reset. 273 10:24.160 --> 10:26.280 Effectively, information is saying, you know what? 274 10:26.280 --> 10:27.280 This isn't going to happen. 275 10:27.280 --> 10:28.280 It's not going to work. 276 10:28.280 --> 10:31.960 At which point, this VM right here would know because it's got feedback from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 276 10:28.280 --> 10:31.960 At which point, this VM right here would know because it's got feedback from 277 10:31.960 --> 10:32.680 the network 278 10:32.680 --> 10:34.320 that that session is not allowed. 279 10:34.320 --> 10:37.250 And as a result, instead of waiting, for example, for several seconds to 280 10:37.250 --> 10:37.840 timeout, it 281 10:37.840 --> 10:40.320 would know immediately that session is not allowed. 282 10:40.320 --> 10:43.640 So from a security perspective, why would we use one over the other? 283 10:43.640 --> 10:47.080 Well, if we use a drop and somebody's trying to attack us or scan our network 284 10:47.080 --> 10:47.640 and figure 285 10:47.640 --> 10:50.880 out what's available, if we do a drop, we're not giving back to the particular 286 10:50.880 --> 10:51.080 network, 287 10:51.080 --> 10:53.880 potential attacker, any additional information. 288 10:53.880 --> 10:57.400 Where if we say reject as our action for that rule, then an attacker is going 289 10:57.400 --> 10:58.120 to get a response 290 10:58.120 --> 10:59.120 back. 291 10:59.120 --> 11:01.650 And then based on that response, the attacker has just a teeny bit more WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 291 10:59.120 --> 11:01.650 And then based on that response, the attacker has just a teeny bit more 292 11:01.650 --> 11:02.600 information regarding 293 11:02.600 --> 11:04.960 what's allowed or not allowed on our network. 294 11:04.960 --> 11:08.460 Also I'd like to point out something right here as the very last rule in the 295 11:08.460 --> 11:09.080 very last 296 11:09.080 --> 11:10.200 category. 297 11:10.200 --> 11:15.160 And that rule, by default, is permitting all IP traffic at layer three. 298 11:15.160 --> 11:16.160 So here's what that means. 299 11:16.160 --> 11:21.260 If we don't have any specific rules earlier in our security policies that are 300 11:21.260 --> 11:21.680 denying 301 11:21.680 --> 11:25.110 or matching on traffic, everything at the end of the day, if it's not matched 302 11:25.110 --> 11:25.600 earlier, 303 11:25.600 --> 11:27.680 is going to match on this rule right here. 304 11:27.680 --> 11:31.980 And that default action is allow, meaning all the traffic is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 304 11:27.680 --> 11:31.980 And that default action is allow, meaning all the traffic is going to be 305 11:31.980 --> 11:33.880 allowed by default. 306 11:33.880 --> 11:37.690 Now that may seem like a foreign concept of a default allow at the end of our 307 11:37.690 --> 11:38.280 security 308 11:38.280 --> 11:39.280 policy. 309 11:39.280 --> 11:42.990 However, just imagine if the default behavior they set up as part of the 310 11:42.990 --> 11:43.920 security policy 311 11:43.920 --> 11:47.360 rules was to drop or reject traffic. 312 11:47.360 --> 11:51.110 That means that pretty much no traffic would flow whatsoever in our networked 313 11:51.110 --> 11:51.840 environment 314 11:51.840 --> 11:54.320 unless it was permitted explicitly earlier. 315 11:54.320 --> 11:57.950 Now it might be a good goal to get to a point where we add on an additional 316 11:57.950 --> 11:58.640 rule and we 317 11:58.640 --> 12:00.480 say we want to drop everything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 317 11:58.640 --> 12:00.480 say we want to drop everything. 318 12:00.480 --> 12:04.450 But that would be after we have explicitly set up our rules to permit the 319 12:04.450 --> 12:05.280 traffic that 320 12:05.280 --> 12:06.720 we want on our network. 321 12:06.720 --> 12:11.200 So just be aware that by default, there is a default allow action at the end of 322 12:11.200 --> 12:11.480 the 323 12:11.480 --> 12:14.080 distributed firewall policy security rules. 324 12:14.080 --> 12:17.170 And again, if we don't have traffic that's matched earlier in the policy, it's 325 12:17.170 --> 12:17.440 going to 326 12:17.440 --> 12:19.960 hit that allow rule by default. 327 12:19.960 --> 12:23.210 So now that we've taken a big picture look at the concept of a distributed 328 12:23.210 --> 12:23.920 firewall that 329 12:23.920 --> 12:28.080 provides us the ability at a very granular level to control what traffic flows 330 12:28.080 --> 12:29.120 are allowed. 331 12:29.120 --> 12:33.490 In the next video, let's pause for a moment and create a specific game plan WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 331 12:29.120 --> 12:33.490 In the next video, let's pause for a moment and create a specific game plan 332 12:33.490 --> 12:34.160 that we can 333 12:34.160 --> 12:37.160 put together, implement, and verify. 334 12:37.160 --> 12:39.480 So I'll see you in the next video for that game plan.