And welcome back. Now that we've applied some basic policy, I wanted to step through some of the advanced profiles, the security profiles that we offer within multi cloud defense. What's really quick level set though.00:06And just take a look at our policy. We had previously created a grouped policy.00:20And as part of this group policy, we actually added one rule that is an allow log rule. We are running a Forb proxy on port 04:43 and we're allowing selective sources within our AWS environment right now.00:25To be able to get out to the internet. And we did test, we validated that it's working, we're basing everything off of instance tags rather than CIDR. So right now the workload that we have is able to access the internet.00:40On 04:43. But what if we wanted to further limit that access? Maybe to specific website domains or specific URLs? How can we accomplish that within multi cloud defense? Well, we do offer a couple different profiles that might be able to help us here. And if I take a look under policies.00:55And under this profile section, you can see the different profiles that are available to us. Now, some of these are gonna be available for ingress only, some of them are gonna be able.01:15Accessible or utilizable for egress only some, you know, between both. But what I want to take a look at and actually if we click into this egress rule that we have here and click oh this is the source destination. Let's go back to rule sets.01:27If we take a look at our rule, and I say edit here, we can see for this specific egress rule forward proxy I have the ability to do IPS IDS, anti malware, data loss prevention, URL filtering, FQDN filtering, malicious IP, and AI guardrails.01:43We could definitely have a video about all of these, but I just wanna cover a little, little bit of advanced policy using URL and FQDN filtering as our examples today because those are two fairly low hanging fruits that a lot of customers typically choose to pick off. So let's say this host is able to get out to the internet, but we.02:04We want to restrict where.02:24A user might be able to go. So we might want to employ something like FQDN filtering where we look at the HTTP host header or the host header within the SNI to identify the domain that that packet is headed towards. We can look up the documentation, so for.02:27I go to documentation here.02:47Under the profiles for security and gateway, we'll expand that, we look at security profiles. So let's 1st take a look at this FQDN filter profile. So they do list out that, hey, it evaluates the FQDN associated with traffic and applies an action to either allow or deny that traffic.02:50So.03:10The caveats to this has to be in forwarding or forward proxy mode, so like the reverse proxy using our ingress gateway, this isn't applicable, and it must be TLS encrypted or contained and containing FQDN in the SNI field of the TLS hello header. It can also be evaluated.03:11Using the HTTP host headers so for the unencrypted traffic. So we will take a look at FQDN, and I typically use fairly simplistic examples. So if we look, you know, for a lot of customers, they might use GitHub repository, so GitHub might be a domain that they either want to allow.03:30Or deny. We're gonna use that as our example today.03:50And just to kind of showcase what we can and can't do, we'll say, hey, we want to deny, so I typically urge customers if they're gonna go into the URL filtering or or FQDN filtering kind of domain to move into more of a blacklist rather than like a whitelisting philosophy, because if you get into whitelist, there's a lot of.03:54Nuances on websites where they make call outs to other websites and they just don't act appropriate.04:14So it's easier in a lot of cases to specifically go out and deny the categories or the websites that you don't want people or users or systems accessing rather than trying to list all the ones that you do. So, what we'll do is we'll say, hey, for now, just as an example, we want to.04:18Disallow access to GitHub.com. So how would we go about that? The 1st thing we would do is we would go to policies and we would go off to FQDN filtering. There are two different spots for FQDN and this confuses a lot of customers. There's the FQDN that's under the security policy section. This is for the.04:37Matching, so this would be like an F FQDN matching criteria. We're not gonna use this for the profile section.04:57We'll talk about this in another video in a little bit more detail. So we're gonna use FQDN filtering profiles. I'm gonna click create and you can see we all I mean automatically we have a list of stuff here. These are just categories that are being recommended from Talos for, for blocking and we could, we could just.05:04Let's leave those, right? It's probably best practice. They also require that we block any child abuse content, so you'll see this is unmodifiable and it is a deny log. But what we want to do is blacklist, so I'm gonna go ahead and change uncategorized for now to allow log. I'm gonna change any.05:24To allow log, and I'm gonna go out to my top box here, which lets me, you know, add more categories if I wanted to add those in, which I'm not going to right now or I could type in any pearl compatible regex for matching.05:43So what I want to do is actually add one to say, hey, anything going to, you know, github.com, which is a domain. Now, if you had a prefix to this like with with a lot of, you know, gitHub.com, there's like raw user content, what have you. Again, we can use proar compatible regex.05:59Here, so I could say something like.06:19Dot star, we could match, you know, the backslash, you know, github.com. Matter of fact, we could, we could do a literal.com here. So again, this typically I urge customers go out to a website. There's like regexor.06:21If we look up regexor, learn build and test, I could come in here and paste in my query and just validate that it works. So I could say like, do we match, you know, github.com? Do we match www dot.06:41GitHub.com, do we match, let's see raw.github.com just coming up with some examples here and we just want to see if we're matching, and right now we're not matching anything, so I do have something wrong, so let's just.06:59Backspace this. So github.com would match github.com, it would match www.github.com, it would match it would not match raw.github.com. So we aren't matching everything if I just did a.star.07:18It starts to match pretty much anything before GitHub.com and let's let's just do a, a literal, and then that's gonna match anything with W, you know, any, anything prefixing github.com. So excluding gitHub.com, so if i wanna.07:37To get really crafty I could say zero or more instances of all of this, but I'm just gonna, I'm just gonna copy this out.07:56Just for expedience, and we'll go back to multi cloud defense, actually take that out and we'll paste in what we had before. There we go. So that should match. I'm going to.08:03Deny log, this is also where we could do decryption exceptions if we wanted to for specific domains and I'm gonna click save, and this should, oh, I need a name. So let's say.08:21Block FQDN and we'll say save and it's saved. So let's 1st get our baseline test done. So let me clear screen here. We'll make this bigger so everybody can see it. And we'll just curl.08:38At www.github.08:57Actually, let's do HTTPS, www gethub.com Actually, I had a query earlier. Let's use that.09:00So we've, we are able to get stuff back right now from GitHub, but NO, this is GitHub user content. So let's go to, let me actually just grab a quick.09:20Probably should have worked all this out before. And what the-K.09:43There we go. So we were able to, we were able to get data back if we look up, yeah, it's got a bunch of stuff here just cause it's the whole website.10:00We were able to get out. And actually let's just go back and use, let me also add this GitHub user content.com just cause it might be a little bit easier to filter out. So I'll go back into.10:23This we'll edit it and we'll say.star literal.github user content.com.10:35And we'll click save again. And we know that works cause we did see good site actually return with GitHub user content.com. So what I'll do now is we'll go to policies. We'll go back to our rule set.10:52I'll actually add that in because we, we use these security profiles when we're allowing traffic through to perform some advanced security functions on that traffic flow. So I'm gonna go to FQDN filtering. We'll say block FQDN, and we'll click save.11:11Oh Perfect. So we'll make sure that this applies. This might take just a minute and it's updated. And if I go back now to my host.11:29We get connection reset, right? So now when I'm going to GitHub user content, that connection's reset. Let's validate that that's actually happening from our system though. So if I go to investigate, like I said, we, we can look at traffic summary, all events, but what I really am focusing on is this FQDN filtering.11:48So let's just click on that table and we can see almost immediately that we are denying the request to raw.GitHub user content after applying the FQDN filtering profile. So this seems to be working as intended, we can see.12:08It's, you know, categorized as computers and internet, so I could also block that category if I wanted to. We could see the HTTP host header, the rule that it hit, all of the metadata. The other thing about this is I could look at the entire.12:27Flow using the session ID, I could click on this, say add to search, it adds it to that search bar for me, and then I'm able to go to like all events and we can see how that flow was treated based on the session ID.12:43Through the the entire security pipeline. So we could see like at the L four firewall level, it was allowed, but when it got to FQDM filtering, it was actually denied. So cool, right? FQDM filtering seems like some low hanging fruit that we could go out and kind of attack to reduce our attack surface a little bit.12:57What if, though, on GitHub, there were some components of GitHub that we actually wanted to get to? So like we wanted to be able to classify, you know, gitHub.com/bad site.13:15Versus github.com/goodsight. How could we actually provide that level of support for our users? And that's where URL filtering actually comes in because beyond the domain, we actually have the URI, the URL.13:30That we can look into. And what we're actually making callouts to in this case is the domain of github.com or www.github.com, but the URL is J ont-Cisco URL checker followed by like your bad site or your good site.13:46So how we could differentiate based on those is by going into our URL filtering. So URL filtering is a little bit different where FQDN filtering can go into a forwarding or forward proxy rule. If we look at URL filtering, it's only applicable if you're doing.14:03Forward proxy. Because if you think about.14:24The URL and if it's an encrypted flow, we need to be able to see into that encrypted flow in order to extrapolate the, the URL that that flow is going towards. So, we want to again make sure that we're running a forward proxy rule, and we want to define a URL filtering profile.14:28Now that we could use. So let's say this is going to be deny URL list. And again, we have all of our basic categorization coming in from Talos that's identified here. We're gonna do a very similar concept where we're deny log, deny log.14:48For these, I'm going to allow everything else that we haven't explicitly denied through. I might come up here and now we're going to differentiate between good site and bad site. And just to make this easy, maybe I just want to exclude anything that contains that string bad site.15:06So what I could do is very simply I could say, hey, I want to match anything, then bad site, and then anything. I want to do that for all different methods, so these are all your basic HTTP verbs.15:26I want to deny it, and then we allow you to specify return status codes. So like 400 we'll just do like an unauthorized, you can't access it. You also want to, again, I I always tell customers validate everything. So I'm gonna take bad site.15:42We'll go in here, let's say.star, and I'm not getting real crafty with my, with my regex here. It's, it's pretty simplistic, we're just matching anything with the string bad site, so it's not matching like github.com, but it would match, let's see github.com slash.15:57Bad site yeah index.html. Would it match, you know, good site, index.HTML, which are the two things we'll be testing. So it looks like it's gonna work, right? It's matching this, the, the, the URL with bad site in it versus.16:17Not matching the ones that don't have it. So we're gonna roll with that again just for the purposes of testing here. So bat site allowing everything else through, so we'll save that. We'll go back to our policies.16:36I go back to my 443 proxy rule. I'm going to take off the FQDN filter and I'm gonna add the URL filter. Do know that you can use these in conjunction with each other. It is.16:53Perfectly feasible to use both of these. I'm just doing for the purposes of testing these out, we're just gonna go through and make this as simple as we can, so we'll click save. This one might take a minute to update and if it does, I'll fast forward this video.17:11And it's updated now. So let's take a look at the jump host. So before we'll clear off the screen. We'll look at the good site, so I've got good site in here. I should get a webpage back.17:28And we do. So this is an example of a good website, and then if I take a look at a bad site, let's see, I know I've got it in here somewhere. So we see bad site in the URL here. Let's hit enter, and we actually get an access as restricted, which is exactly what we're hoping with that 400 return.17:47So let's go back to our policies.18:08Well or sorry, our investigate. Instead of going to FQDN, we're gonna go to URL filtering and we see two requests here. So I see the 1st one that is going, they allowed it.18:12To good site, which is again what we, what we encounter. And if we look at the other one, we're getting a denying request to the URI GitHub user content with the bad site in it, which is exactly what we kind of hoped for. Everything else.18:29Is still kind of trickling through, which is again exactly what we want. We can see the URI, we can see the URI string here that we were checking everything against. So everything seems to be operating as intended. Let's, let's check another random website just to make sure, so we'll do that curl.18:44HTTPS, yeah, Icon has IP.com, ok, and we get the we have so everything's working as intended here. And again, I just kind of wanted to go through we can see our logs already updated, which is great.19:03I just wanted to start going through some of these advanced security pro policies and how we can layer on these additional profiles for, for a lot of these advanced security functions on a per rule basis. So this is again a pretty simplistic example, but you can kind of see how this could scale. I could set my FQDN and URL filtering profiles almost.19:20Looks at a global level, and now if you know maybe I have gateways deployed in AWS, GCP, Azure, OCI, I'm able to apply that same profile without having to rewrite anything to gateways that are sitting in all of those disparate CSPs, and it really becomes powerful under that lens.19:40As always, if you found this video useful, keep a key eye on this channel as we will be releasing more and more content around the deployment and uses of multi cloud defense and how you can use it to protect your cloud infrastructure. Thank you for watching.19:58We look forward to seeing you in the next video.20:09
