DNS Done Right: Mastering DNS-Layer Defence - Architecting Traffic Onboarding and Zero Trust Foundations

Oh, with respect to those who have joined on time, we're gonna go ahead and kick off today's.00:00The Cisco securing DNS with Umbrella and secure access. This is where everyone that's on the call at part of our expert insights series for APJC and really what we do in these expert insights series is give you a technical deep dive.00:18Into our various products. Today we're gonna be speaking about securing.00:38DNS, as you can see by the name of our webinar, it's called DNS done right. And we've got our experienced subject matter experts that will be sharing.00:44Some slides, some information, but not only that deep dive technical demonstrations with you guys. So we've got SAS Jaya Sakara and Handy Peter that'll be taking us through that today. So thanks very much for attending our session. I do want to make mention of the.00:59The fact that we would love for you to stay right till the end because this is really, you know, it's our 1st line of defense DNS. Everyone needs it, everyone should have it. And if you stay to the end and you complete our survey.01:19We have some awesome Cisco swag that we'd love to send your way. All you gotta do is complete our survey. So Sas, maybe you want to kick open into the into the agenda and what we will be covering today is basically.01:35I get started with DNS. So, that's both with Umbrella and secure access. I think I've mentioned that already. We've got the two products, but.01:54The intent is that we take you on a journey. This team here that we have in APJC will be building on top of this for you and we're starting at the basics. We're starting with DNS. Initially we gonna begin with.02:04How to set up categories and some of the best practice with that, you know, what are those, what are those security policy elements and then what are those categorizations as far as applications content, and that kind of thing goes?02:20We'll also run through how to build the policies out some best practice around the rule sets and how you would, how you would make those. We'll speak about how we take traffic into umbrella through the virtual appliances and some of the, the best practices associated there. We've also got.02:36Encrypting.02:56DNS traffic and how that works and what are some of those best practices. And then last but not least is the secure clients, which is the other way for us to bring traffic into our umbrella security service. With that said, I'm gonna hand over to SAS. If you have.02:57Any questions, please pop them.03:17In the Q and A panel for us, and we would gladly answer those for you. Thanks very much Cess over to you hi guys, my name is handy.03:19I'll be covering the 1st.03:40Topic that we're gonna talk about. Let's start with the how to send or get the your DNS traffic to the cloud. As you guys know DNS is always the 1st hop for every, every connections. Therefore the therefore the DNS is the very 1st layer of defense that.03:43Very critical to protect your traffic using the secure access or umbrella and send those traffic to, to our cloud. Now.04:02Cisco, if you guys aware that if if you guys are aware about Cisco umbrella, Cisco securex is basically using exactly the same DNS protections and infrastructures for for our DNS global network. So our global DNS global network will detects and protect any.04:12Malicious or threats that exist in the destinations before further packets are being sent.04:32On your right side there those are some of the the methods that you can send all your DNS traffic to our DNS cloud, to our global network cloud and then based on these methods based, it varies based on identities that these methods can.04:38Right, and then use that identities to protect or build your DNS policy in in securex as our umbrella.04:58This DNS policy is based on, it can it can be based on source source information and also destination information. It can be varies between the simplest method to the most granular controlled method that that you can do. And you can also combine.05:09Them together depending on on on the needs basically. We'll dig into it further on on each methodology that you can send your DNS traffic to, to the, to the cloud.05:27Be here are some five common ways that you can send your DNS traffic to to our cloud, to umbrella or secure access based it varies from distinctlest to the most granular controls.05:41Let's start with the public resolvers. Public resolvers is basically the most simplest way that you can send or send your DNS traffic to our, to our cloud by simply points your DNS server to our public resolvers, which is the anycast public resolvers that we have exactly the same like.05:58Cisco umbrella and the address are 108.67.222.222 or two oh eight.67220.220.06:18One of the requirements to do the public resolvers as your method sending your DNS traffic is for you to register your egress network to our registered network. The reason being we need to identify this particular DNS traffic it's coming from, from whom.06:27And to hit which tenant in our end basically. In order for us to identify it, we will need to be based on your egress IP or in your environment and then use that as an identity of your, of your network basically.06:472nd one we can do integration with Meraki using the API integration. You can integrate your Meraki MR devices or MX devices through, through Umbrella and and using the API integration.07:04Once you integrate Meraki and securex or Umbrella using API integrations, you can configure a group policies in your Meraki to send the DNS traffic to umbrella or securexs.07:22Once you configured your group policies in Meraki, you can you and then you can set your client that's sitting behind the Meraki to use that group policies to so it can send the DNS traffic to Umbrella and secure access. So these these integrations in terms of from Umbrella and securex.07:38Access we will see the Meraki network as an identity.07:58The 3rd one you can do an IPsec tunnel, by configuring IPsec tunnel in your edge devices like routers or firewalls to secure access, you have an option to send your DNS traffic.08:03And or web traffic as well to to correct umbrella. Once we receive those traffic, we will use that particular traffic and identify it as your network of of of the from the tunnel. The 3rd one, sorry, the 4th one is virtual appliances.08:18Now the virtual appliances is the most great granular controls that you can perform a DNS controls in terms of your policies and also scanning. We'll, we'll touch a little bit more in depth in in virtual appliances in in later slides.08:36The last but not least is roaming computers or roaming client. This method basically use the most of the use case for roaming computers or roaming clients that this particular protection, it can protect.08:52At the user anywhere and everywhere. Say e.g., if the user is sitting in in the coffee shop or in, in the airport by installing a secure client to that particular client, and then once you install the secure client with umbrella module, it will send DNS traffic to us basically to perform the.09:07And the protections.09:27Go to the next slide. Here are some of the comparisons between those methods with classified based on feasibility and identity reporting, post enforcement, high availability, high availability and more granular control.09:32As I said earlier, control appliances provide more granular controls compared with other method. Roaming computers use case is for you to protect your client if your client is is remote while the rest of the methodology are, they're all on prem protections.09:49In terms of identity, virtual appliances will have the most identity that you can use to create your policy. That's why we feel that as the most granular control that you can do to protect your DNS traffic.10:10I'm gonna show you a little bit how what what does it look like in terms of configuration in for each of the method. Let me quickly jump into my secure access. You guys can see my securexes ok?10:28So let's start with the public resolvers. Like I said before, one of the requirements to protect your DNS traffic using the public resolvers after methods, you will need to register your registered network, which mean your your normally used your egress IP of your network, right?10:48To register, to register that network, you can go to resolve this and register network.11:07Say e.g. in these scenarios with the configuration that I have, this is my egress network that that is sitting in my DMZ lab basically and it's active. So you can use this network name as your identity when you create a policy.11:14Right, let me let me show you what this looks like in terms of the traffic, I already used this one. You can monitor your traffic, just bear with me, I think it's timing out.11:32Okay, here we go. So you can see all your traffic under monitor and under activity search. To filter the traffic, there's a few options here on your left side depending on your source or or the type of the traffic.12:11That you want to filter basically. Now I want to see all my traffic that come from, a network which is the registered network such as the public resolvers. What you can do, you can filter it based on.12:31Networks, yeah, only, you can see this is all the traffic that use my egress IP as the registered network.12:46Example it's not showing the right one. Just bear with me the network's a little bit slow today, so bear with me.13:03Okay, there we go. But say e.g. this one, if you click on the full details, you will see the traffic comes from my registered network, which is my egress IP of my DMZ lab DMZ network.13:21Now, talked about 2nd one, which is the Meraki API integrations. To integrate Meraki with securex, the 1st thing that you need to do, you need to create an API key from the securexes. And once you configure, create a Meraki, sorry, the API key specifically for Meraki integration.13:36With these scopes.13:57You'll get API key and a also a key secret of that API. Once you have these informations, you can put those into the Meraki configurations. This is my Meraki, my MX devices. You can put those API key.13:59And key secrets under the general configurations.14:19And put those in to the sections of Cisco Umbrella account. Now is the naming is still showing Cisco umbrella, but this is also works exactly the same with secure access. Once you already connect.14:27Meraki to secure access now in Meraki you can configure your group policies and enable that integration. Say e.g., my group policies I have a network called VLAN 92.14:42In VLAN 92, I'll be enabling the the the integration to secure access basically. And then my client that's sitting behind VLAN 92, all the DNS traffic will goes to secure access.14:57Once you already configure those integrations, you will see the status of your registered Meraki devices under network devices, e.g., this one.15:18And the statuses online. Similarly, you can see, you can check the traffic again from the activity search by filtering the network devices to see the all the traffic coming in from your client that's sitting behind the Meraki devices.15:35Yep, identity type, let me network devices, there we go, so this is all the traffic that comes in from the client that's sitting behind the VLAN 92.15:54Move in my Meraki devices.16:13And the identity for this particular traffic will only shows the Meraki device as your integrations. The 3rd one is basically the network tunnel. This is a little bit more complex because you need to create an IPsec tunnel site to site tunnel from your edge devices like.16:15Routers or firewalls, and then goes to the IPsec tunnel goes to secure access. You can configure the tunnel configuration here in the network tunnel groups. Once you configure the network tunnel groups, we'll be providing you with the tunnel ID.16:35The data center that you want to connect it to and also the IP address for our site for you to configure your site to site IPsec tunnel from your edge devices to secure access. Now you can use this as well as an identity when you create a policy or DNS policy. You.16:52You can use the network tunnel ID as your source for your policy.17:12What the traffic looks like, again, you can go to activity search and filter it based on network tunnel as an identity, e.g., this one.17:18Let me refresh It will be the your remote your net.17:36The 4th one we talked about virtual appliances, to configure virtual appliances, you can configure it from connect and DNS forwarders. Basically feature appliances is acting as the DNS forwarders. On this page you have the option to download the image file for the future appliances for you to.17:59Install it in your environment. We support.18:19Host that be hosted by ESXi, and also KDM and then you can download this image file and then you can install it in your environment or hypervisor host. Once you installed the virtual appliances, it will come up in this page.18:25It will.18:44It will show you the status and the version, and also one of the requirements once you install the virtual appliances that you need to assign each virtual appliances to a certain site. What it does is basically, acting as a network segmentations, right? You can segment your your VA to belongs to which.18:45Network segment.19:05We call it site in in this in these terms. If you not assign a VA to a certain site, it will, it will be assigned automatically to a default site. So that's why we always recommend for you to give the site like more meaningful name, so you can use this as an identity or associate.19:07Course and when you configured your DNS policy.19:26As I mentioned before, future appliances provide more granular controls. Let me show you why if you go to the the activity search to see the traffic that comes coming from from future appliances or sites.19:31I'll show you the difference. Okay, let me filter based on five, ok.19:49The, if I go to full details, you will see the source coming from multiple sources. Especially if the virtual appliances have integration with AD connector, to fetch the user informations.20:04You will see those user informations in in in the traffic coming from virtual appliances. You can use this as a source as well in your policy and also you can configure what we call an internal network.20:19Internal network basically because virtual appliances when it carries the traffic, you will also expose your internal client IP, which is this guy, and then you can configure this client IP as your internal network, e.g., this.20:36And then once you configure internal network, you can use this internal network as a source when you create the policy. You can also create a policy based on site and based on network. So that's why we say we have more granular controls because we have you have a lot of options on how to configure your DNS policy.20:50Based on this information. The last one that I want to show you is that you have the roaming computers. You can configure roaming computers under connect and end user connectivity and goes to internet security.21:11On this page you have capabilities for you to download the secure client for you to use to install to your or deploy to your clients, windows or Mac. And once you install the secure client, you will need to install the umbrella module for that.21:31And also download the profile, we call it info.Json profile. Basically what it does is basically telling the client which secure access umbrella tenant that their traffic should go to.21:49Without this information, we wouldn't know the traffic coming from client coming from which tenant. That is why this one is quite crucial when you configure the roaming computers. Still on this on the same page, from this page you can configure your traffic steering.22:06Basically telling the secure client, what traffic that should go to secure access and what traffic to bypass. You have an option to bypass it from, from securexess. What the traffic looks like? Let's go to activity search again.22:24And let's filter it based on the roaming computers. I'm waiting for this to come up 1st before we can filter it. There you go.22:42Filter based on the device. This is all traffic coming from our roaming computers. You can also in terms of the source, it will have.22:58The host name of the roaming computers. Now, if you have a integration with the AD connector as well, it will also show you the user that the user login to that particular client that has a secure client, it will record record the user as well and you can use that user.23:15If you want to configure a DNS policy based on user information. That's pretty much it from from my side for this topic. I'll I'll pass it on to my colleague staff to continue with DNS categories and policy.23:36Apologies that terrific. Thanks, Andy. As Handy mentioned, there's multiple ways we can bring DNS traffic into secure access or umbrella. A common question that I get asked a lot is yes, now we have the traffic. What should I be blocking?23:54And the honest answer is, and this is the answer I always give and customers don't love it, but the reality is we can't really tell you what to block because it's gonna be dependent on your organization. So your industry will have specific categories that might be important or might be of risk.24:12To you. Now, by default, secure access blocks malware, so any website or application that shows malware as a threat, we block by default. Command and control. So any trojans or anything that's installed on your endpoints that's talking back to a control server, we block by default.24:29Phishing links, so any fake websites, any phishing links from emails, we will block by default, but those are the only categories we block by default. Now in secure access we have security categories. Now, by default, like I mentioned before, malware command and control, and phishing are blocked, but we have additional controls as well.24:49So e.g., if you're concerned about newly seen domains, DNS tunneling, DNS tunneling probably one that you should probably consider looking at blocking because DNS tunning basically means you can send information through the DNS port. So if someone wanted to exfiltrate information from your network, that's a really good.25:09Way of doing it. Crypto mining.25:29Yeah, like I mentioned before, if your, if your organization is all about mining bitcoins, blocking crypto mining wouldn't be the right approach. But if it's another type of organization, crypto mining might be something you want to block in your environment. Again, another example is dynamic DNS. Not all dynamic DNS is about.25:31That, but if your environment doesn't use dynamic DNS, then it might be a good one to look at blocking.25:51But that's all from a security standpoint. We've also got content categories that sits outside of security and this is what will be more config configurable to your environment. Now common content categories that we typically see blocked is things like encrypted DNS. So encrypted DNS is.25:57Using DNS but through an encrypted channel, so whether it's using port 443 or ensuring that the DNS traffic is encrypted overall. Now this is great when you're using secure access or umbrella, but a lot of 3rd party vendors also do encrypted DNS. So if you use 8.8.8.8.26:17For those who don't who know, that's the Google DNS resolvers. If you use that, Google will use encrypted DNS. If you have Apple devices in your network, Apple uses Apple relays, which is also encrypted DNS. Now the problem with having these up external encrypted DNS services is that we lose visibility.26:34Be into your environment. So e.g., if you're using, let's say a virtual appliance and you've got encrypted DNS running in your network, you might have policies to block social media, but if you're using a 3rd party vendor for DNS, then that traffic will still go through and will still resolve.26:54So if you want to control your environment and only allow certain DNS trusted DNS resolvers like Cisco, e.g., you would allow Cisco and you block all 3rd party vendors so you get further visibility. We also see gambling, again, if you're running a casino, blocking gambling wouldn't be the right approach, but.27:11Again it will be dependent on your environment.27:31Our recommendation is always to look at having a default policy to block everything and we'll go into more detail around how the policies are stacked, but also looking to look at look at identities. So separate your guest environment from your corporate environment to your server environment. Your servers probably don't need access to Facebook, but you.27:33Guests might do. So making sure you set up policies like Andy mentioned earlier, we can source different identities, whether it's from your VPN tunnels, whether it's from your roaming clients, whatever it maybe, but ensuring that you set up policies according to the expected traffic coming in will give you the greatest level of security across your environment.27:53Now, when we start looking at building policies for DNS, granted this is going to be different to how it is done in umbrella. In umbrella, we have DNS policies, we have web policies, they're all separated. In Secure access, they're all combined into one. In secure access, our typical recommendation for policies is to have a default.28:15Allow rule that's specific to destinations you've selected. So there might, you will have a destination list where there's URLs that umbrella typically might block because we consider it as insecure, but you've tested it in your environment and these are actually URLs that you trust. So you allow those destinations.28:35So that will be your 1st policy. Then anything below that will be your default policy.28:55So by default, like I mentioned before, we blocked malware, command and control and phishing. But in your environment, you also don't want crypto mining and you also don't want adult content, e.g.. So by default that's not allowed in your environment. So our default block policy will.29:00Block anything that organization wide you shouldn't have access to NO matter where your traffic is coming in from. Then at the 3rd layer, we want to do identity specific policies. So these are policies that's maybe unique to different departments in your organization. E.g., you might block social.29:21Media across your whole environment, but marketing might need access to Facebook.29:41So making sure you set up your policies in a way that you're restricting as much as you can from a default level and then changing your levels of control based on the identity will give you the highest level of security for your DNS space. So what we've got is a quick demo, just give me 2 s.29:45Get it open. Now in secure access, got a couple policies here. I'm gonna filter down to the ones that I think will be relevant here today. So let's look at my enabled policies.30:06So like I mentioned before, I've got a default allow policy. So in my allow policy, I've got an allow list, and in here I have a couple of domains that if I don't whitelist them from here, it's going to get blocked by my default rules. So in my case I have four domains, so I've got an allow policy created here.30:23Underneath that, I've got my default deny policy and also a region block policy. Now secure access currently supports geo blocking for certain destinations. So in my case, I want to block any website that have China as a, a domain or Russia. So at the moment I'm blocking those, but I also.30:43Also have a default deny policy as well and in my default deny policy I have a list that I of domains that I don't trust, and I also have a content category list.31:03With certain destinations that I don't want allowed in my network. Then underneath that I have a policy specific to identities. So in my default denied policy I'm blocking access to access to social media.31:17But I know that my marketing team that's part of this secure access group needs access to TikTok. So I've created a specific allowed policy in order for them to have access to those destinations. Now in secure access, your policies work like a firewall, so it's a, it's a top down structure, so what.31:32Whatever gets hit 1st, that's where it will stop at.31:52So what's important is when you're configuring your policies to take that into account and configure your policies accordingly. Yeah, if we go back to our slides, Andy touched on virtual appliances before. So a virtual appliances are essentially a Linux border that you can install.31:55All in your environment and it forwards DNS traffic to the forwarder which forwards it to our public resolvers. So the 2 086-722-2222 public resolver address, it just forwards those DNS requests back to us.32:15Now, the virtual appliances are important. They play a vital role for a lot of organizations because there might be instances where you have your own local resolvers as well. So most organizations that we run into use Windows DNS resolvers.32:29Now this is important because you might have local websites, local services running running within your environment, which is perfectly fine. So having a virtual appliance lets you send the request and if it's a locally resolvable address, we can broker at the destination and have your local DNS.32:46Resolvers resolve the destination instead of our public resolvers.33:05So we can conditionally forward w whatever destinations you want to your local resolvers and have it resolve it instead of going into our cloud. Now, these virtual appliances, like I mentioned, are Linux based and we always recommend setting up setting them up in a redundant fashion and handy will go into more detail around how we would do that.33:09But these virtual appliances instance have multiple ways of being configured. The two common ones is the 1st the 1st one you see here where you have the client sitting at the front, the DNS goes to the virtual appliance itself. In this case, let's say my request was to.33:29My company.local is the destination I want to resolve. Now, my company.local is obviously a local domain, so it's not gonna get resolved by our public resolvers, so it's gonna go to the local DNS resolver. Now, if my destination was google.com e.g..33:49We will pick up that request and we will send it to umbrella, DNS resolvers, which is the same resolvers that we use for secure access. Now, this approach works really well and an additional benefit of having it in this particular architecture is that this virtual appliance can talk to your umbrella or secure access AD connectors.34:05This lets us know who's making those DNS resolutions.34:26So, if a client, e.g., is looking up google.com, we will know what the LAN IP address of that particular client is, then we can look up Active Directory and see who made that request and then collect all of that information.34:30Together and have that go into the activity search within the secure access dashboard.34:49Now, another way of configuring this is having your client talk directly to your local DNS resolver, which then talks to our umbrella resolvers. So you'll have client that goes to Windows DNS resolver, e.g..34:55Which then goes into the umbrella AD umbrella virtual appliances. This approach is also good, but the problem with doing it this way is that we lose visibility on who's making the DNS request. So the client, if this client was trying to resolve google.com e.g., the request goes to the local DNS.35:12The destination is Google so it sends it out to our virtual appliance. The virtual appliance sees the source address of that traffic as the Windows DNS resolver. So we won't be able to associate an identity to it. So our recommendation always is if you're deploying virtual appliances is to have the client speak directly to the virtual.35:33Appliance itself instead of talking to your local resolver, which then talks to your virtual appliance.35:54And I think handy's got a bit of information on how we would set these up in a redundant fashion. Yep. All right. Thanks. Alright, so virtual appliances coverage and redundancy. When you configure virtual appliances.36:02We always recommend for you to install at least two virtual appliances or or install it in the pairs for a single site. I think we touched base a little site a little bit on on my previous demo, so you can consider site as your networks and location, right?36:19Say e.g., you have a network which is let's call it a VLAN 20. You can, if you install a virtual appliances on that particular network, you can call that visual appliances site as a VLAN 20 or you, if you install a virtual appliances for a certain locations, you can come.36:39Configure the site as that location, say e.g. Sydney as a, as a site or Melbourne as a site, right? Inside a single site, we always recommend we have to have at least two VA in in a single site. We can call it VA one or VA two, right?36:59When we configure to the VA in a single site, what we're trying to achieve, we're trying to achieve for high availability, so to achieve a failover in case there's some issues in in the in the in one of the VA, so the other VA can take over and we it's not, will not be.37:19Impacting your production DNS traffic protections, right? For the installing the VA will also recommend to install on a separate physical hypervisor host, say e.g. VA one installed on your favorite physical.37:40Hypervisor host apart from VA two. The reason being is that physical hypervisors is down that hosted the VA one.38:00It won't affect the VA too, so you still achieve a failover and high availability and it won't impact your DNS traffic to be protected by secure access. The other thing as well those when you install those vas, those CAs will become active.38:12Is gonna be active active, and then they are ready to to handle the, the DNS traffic that comes in from the client and act as the DNS forwarders to the cloud to provide protections. The other thing that we would recommend as well to always keep.38:32In keep in check on the health of the future appliances e.g. up to date versions of the VA because sometimes we publish a new versions that have a big source of the bug. Also the connectivity of those vas is worth.38:51Mentioning that you need to keep monitor it.39:10The other thing as well to make sure that your VA is scalable, right? Make sure you have a forecast of how many DNS traffic that single vas can want to handle. And based on that size, you need to consider the the sizing of the VA.39:13That the resources that you need to install on the VA and all all those information is listed on the user guide, you can see how many or how big is the memories, how many bigger the CPUs that you need to install on your VA based on your forecast DNS traffic for that single VA.39:33I'll go to the next slide please now why do we need to install the appliances in pairs? The main reason is basically to achieve high availability, so it won't interrupt your, your DNS traffic for us to perform the DNS protections, right?39:51The other three reasons for this is that.40:11For the virtual appliances, we have a functionality of automatic upgrade, right? When the virtual appliances undergoes the automatic upgrade, at the end of the upgrade, it will require the reboot.40:15This reboot will take can take two up to 20 min. Now, if you don't have a VA in place in single site, if that one VA is doing automatic upgrades and being rebooted automatically from the cloud, that VA will go down, right?40:31If you don't have a V virtual high availability, then basically it will impact your DNS traffic. But if you have another VA on the same side, those particular traffic will go to the other VA to to to perform or perform the other protection of your DNS traffic.40:48The other reason as well is that you can't have the ability to schedule upgrades. You can stagget the upgrades one at a time after another and you can configure it based on your off hours or plan maintenance window to minimize the impact.41:05And the 3rd reason is basically if one of the virtual appliances is having issues, say e.g. some for whatever reason the virtual appliances went down or it doesn't even accept a DNS traffic for whatever reason or timing out.41:21So those are for your particular production DNS traffic instead of goes to that unhealthy virtual appliances, it will go to the next virtual appliances. So you won't affect your traffic DNS traffic basically. Now on the next one, I'll do.41:37Do a brief.41:57Then one to simulate the failover of the VA and and to to showcase why you need two vas on a single site basically. Let me take over from here. All right. You guys can see my screen.41:59Okay, so on my previous demo, the configuration that I have for virtual appliances, I have two Va's here, VA one and VA two, and this CAs belongs to the same site.42:19What I call it a virtual app and VA one has the IP of.one 22 and VA two has.one 23. Now I have a lap here that I want to try to simulate the the failover.42:34So this particular client pointing like mentioned before, in terms of the virtual appliances placement, this client is pointing to my VM, which is.one 22 and.123.42:52Let me run script to simulate a DNS request. So my DNS request because both of the vas are active, it's healthy, then it will, it will goes to the 1st one 1st, which is zero.one.43:1101:22. Now imagine this particular VA went down, right? The thing I want to showcase is that the particular DNS request will automatic goes to the VA number two to simulate the failover.43:28So if I reboot VA with IP address 01:22, let me try to reboot, say e.g. it's already undergo an update and then it require reboot.43:46Document the upgrade.44:06Then it will went down. Yep, the VA is rebooting now. My script is still running, though, as you can see because.one 22 went down, it's been rebooted, the traffic will go.44:08Next to 0123 which is the VA number two.44:28So, in, in this simulations basically telling us my particular DNS traffic will not be impacted because the other healthy control appliances will take over in terms of handling acting as the DNS forwarder back to the secure access.44:33On the secure access in terms of the traffic was basically it remained the same. The traffic will still come to to secure access either from VA number one or VA number two and we apply the policies of the incoming DNS traffic like normal.44:51Give me let me let it run and then I'll filter based on the sites. Okay, so these are basically the the DNS traffic that I simulated based on my script.45:10I just simulate traffic goes to Google Yahoo and Microsoft and basically telling you that particular those particular DNS traffic and protections, it remains the same so it won't impact the DNS traffic. That's pretty much it that I wanna see, ok? Back to you sir.45:29Yeah. I think you're on mute sir. Thanks, Eddie.45:50Thank you for walking through how to set up virtual appliances in a redundant redundant fashion. Another question we get is around encrypted DNS. Now most of the time DNS these days is not encrypted. So if you've got a clever person on your network that's running a wireshark capture, they could probably figure out what users are requesting from a DNS perspective.46:07Now, secure secure access and umbrella support encrypted DNS with DNS crypt or doh. So we can use encrypted DNS, so whether you use roaming clients by default, we'll use encrypted DNS. Virtual appliances, as long as the traffic is supported, we will use encrypted DNS.46:28The public resolvers themselves also support encrypted DNS. Now, like I mentioned before, it is a matter of making sure those ports are available and open, but secure access and Umbrella both do support encrypted DNS.46:46Now, there might be local destinations in your environment that you want to bypass. So e.g., your company dot.local or any local domains or any destinations that's not publicly resolvable, you might want to.47:01Might might want to bypass on our side because what could happen is say you've got a domain, your company.local.server e.g., if you don't, add that as a local destination on our side, we will try and resolve that destination. And because it's a local destination and there's.47:16No publicly resolvable DNS query for that destination. We will be unable to un resolve it, so we will just keep trying the DNS resolution five times and if we can't resolve it, we just keep up.47:36Now that'll be a bad end user experience. So we always recommend if you're turning on Umbrella or secure access DNS, identify your local destinations. Now by default, things like.local e.g., we, we already don't try to resolve, but.47:47If there is other destinations or other domains that you look using in your environment, look at the traffic steering section within the secure access dashboard. So just under connect and user connectivity and traffic steering and add any destinations that might be a local destination. So it doesn't try to resolve you.48:03In public resolvers.48:23Over to you Andy. Thanks. All right, so move on to the application control. So we have an application control for DNS protections and also we have application control for web layer protections.48:27For DNS for application control for DNS is basically all for nothing. It's pretty much delimited and pretty much straightforward. It basically allow either allowed all applications or blocked the whole application. There's NO granular controls on on the DNS layer app.48:45Riction control.49:04It is useful, but depending on the use case that, that, that you have, say e.g. you know a certain risky application that you want to be completely blocked from it. In that use case, blocking it from the DNS layer for application control is much more unsuitable because it's more fast and.49:06But if you have a use case for more on activity level.49:28Of application control, that's where the web security application layer comes in or or SWGS we have said. If you have secure access with SIA subscriptions, you have the ability to control based on the web layer.49:33On the web layer, it will provide you with more granular controls in terms of application controls. E.g., you want to block a websapp messenger sorry you want to allow WhatsApp messengers, but you want to block uploading to that messenger, right? You can, you can achieve that using the.49:53From the the the web layer or you have a Facebook applications but you want, you allow Facebook application but you want to block posting or share on that Facebook. You can also achieve that from.50:13The, the web layer, so that's why it can provide more granular controls over and also it has the tenant restrictions in in in web application layer. You basically, you have a control to to allow your Microsoft 3605 enterprise tenants, but the.50:27Walking your personal, talent basically.50:47Now, on the web layer, the, for for knows the behavior or the activities of the users on that particular particular application, we will need to perform more deep dive inspections. E.g., we will need to do SSL description.50:52Because we will need to know the activity inside that application that the user did perform on the URL level and also on the certificate level. That's why on the web layer we will require SSL decryption for application control While on the DNS layer, we don't.51:12Probably need to perform decryptions.51:32Now in summary, so if you know a certain high risk application that you want to completely block or complete for all five slides up, you can use the application control on the DNS layer control While if you want to control application based more on the active.51:35City level you can use the the web layer for application control.51:55Next slide, please. These are just some of the example of web or FWG applications with advanced controls. We categorize it based on collaboration, office productivity, visual networking, cloud storage.52:01Can et cetera.52:20E.g., on the social networking, if you want to allow Facebook or you want to block post or share, you can do that. You if you want to allow dropbox, but you want to block any upload or download from dropbox, you can, you can also do that.52:22Via web application with the control. I'll show you briefly what it looks like in terms of DNS and also web application for application control. Let me take over a little bit.52:41Okay. All right. Well I've been my latest timing up again. Just bear with me.52:57Okay, so, under resources, internet and resources goes to application list, this is where you can control your application controls.53:14In my scenarios I have two applications list here that I configured. One is for DNS application control layer, the other one is for web layer. For DNS layer, I'm I'm blocking such as.53:32Adobe or pilot, right? On, on the web layer, I'm controlling applications such as.53:48WhatsApp alright so let me move to the access policy. This is where you configure your actions based on those applications that you have configured. On my 1st.54:06Access policy, I call it as a DNS layer app control. In this particular policy, I've configured any traffic that comes in from these roaming computers going to this application, e.g. Adobe or GitHub.54:22I want to block it. So basically I'm telling the secure access to block the whole application if you see the traffic coming from Adobe or GitHub copilot. This is based on the DNS layer, right?54:42On 2nd policy that I've configured, I call it web app control. Basically, I'm telling the to allow traffic coming from.54:58My roaming computers wind eleven going to that application such as WhatsApp, e.g., but I want to block on, it's not showing.55:13I have this before, I think because of my case she's been playing around. So ok right so basically I'm telling the secure access to allow any traffic coming from wind eleven from computers going to WhatsApp.55:32E.g., as an application, but I want to block just upload coming from WhatsApp applications and allow download and allow WhatsApp application as normal apart from just upload. Let me show you the traffic looks like.55:52I've already simulated the traffic before, I think in a matter of in because of the time constraint I think I'm just easier for me for me to show you what the lock looks like straight away. On again on activity search, you can see all your traffic.56:11You can, you can come you can filter based on the application that you want to see. Say e.g., let's let's let's look at the the DNS layer application control 1st. I'll be using Adobe as an example.56:29Let me look for that. Yep, you can filter based on public applications and say Adobe.56:44Okay, the traffic coming from Adobe coming from these roaming computers, right? It's it's because I've already set it to block on my policy called DNSLA app control, then the traffic will block. Let me easier to see.57:02Need to to.57:22To see the comparison of the request, basically this particular traffic, consider it as the DNS traffic, right? Now, if you want to see the the web layer application control which with which much more advanced.57:25Say e.g., we want to filter based on WhatsApp.57:46Where's that begin? Hey guy because my policy remember I'm allowing.57:51Traffic going to WhatsApp, but I'm only blocking any upload coming from WhatsApp, right? So on the DNS layer, the traffic is still being allowed because I'm not blocking the the whole application, right? And also in the web traffic as well, WhatsApp is still being allowed because.58:07As this particular traffic is not used for uploading.58:27Now if we filter based on what applied, it's.58:31Treat at the web traffic. Remember this is on the web layer, you can see it's been blocked by the application because we are telling the policy to block any uploads coming from website.58:52That's pretty much it that all all the things that I want to showcase in terms of application control. Back to you Seth. Thanks Henry. The last thing we quickly wanted to touch on just was around the secure client tool. The secure client has the umbrella.59:06Module installed, so this is the module we recommend where if you want your DNS to be protected where even when the users aren't in the office and they're roaming, the roaming module or the roaming client allows your DNS to be forwarded automatically to our cloud. It's a great tool because it also lets us pick up who the identity of the device is as well. So we.59:26We basically do a I look up on the device itself and we'll know who's logged into that endpoint. So the roaming client itself, it's a great tool and we strongly do recommend that you leverage it where you can.59:45And I might just pass it off to Casal. Thank you so thank you everyone for joining. So before we, well, if you do have questions, obviously for this Q and A, feel free to pop them into the chat and we'll try to answer them as soon as we can and get back to you obviously at a later date. Besides that.01:00:00But to summarize the 1st takeaway, match your method to the identity you need. This is a just match it to your use case. Customers use roaming clients, some use virtual appliances or you may need a Meraki integration. 2nd takeaway, so.01:00:20Turning on security categories before you touch anything else or the major red flags, malware command and control, phishing, these will all be blocked, but having your DNS tunneling.01:00:41All configured and on the 1st day, that's critical. As mentioned as well content categories, if you, need to block certain things based on your risk profile, you'll have some kind of acceptable use policy. This will all be dependent on your environment.01:00:55The 3rd takeaway was around your rules and I think there was a question about this or how the.01:01:15Access rules, look. So to summarize, you want specific rules at the top, your broad catch all rules at the bottom, and to lean on that default rule, to set it once, set it correctly and help, have it help you to catch anything you haven't explicitly called out.01:01:23The virtual appliances, these sit on separate hosts in front of your local DNS. So you're not looking at one egress IP and wondering what machine courses you all had and for the 5th encrypt DNS and keep local names local. Ok, so to, yeah, I guess close out this.01:01:43Session, as Jay mentioned at the beginning, please fill out the survey that you'll get at the end of completing this webinar and we'll be able to send you some Cisco merchandise. If you have left any questions or if you do want to reach back out to us.01:02:03Yeah, feel free to get in touch and we'd be happy to assist. Any other closing comments from the team? Sass handy? No, nothing from me, thanks everyone. Thank you, everyone.01:02:19