Platform Protection: Network Security

1. Lecture: Network Overview

So, it's time to get started on our networking journey. And there's obviously a lot to cover here for the exam. If you look on screen, we've got this networkoverview image that Microsoft always presents us with. And you can see more on this at the link on the bottom of the screen. I do encourage you to check that out. It's just a tonne of documentation that Microsoft provides around networking. But if you look at the image on screen, on the left hand side, we have our on-premises network with options for like an encrypted tunnel direct connection over to the right hand side, which is our Azure network. And this right hand side is where we are going to focus primarily as we work through this module. And there are all sorts of concepts there,but let's start with the VNet. First of all, the Venet is one of the core pieces, and it has a number of capabilities that Microsoft provides for us to utilise with VNet in Azure. And if you look on the screen, we've got a boundary there. So we've got a VNet boundary inside there. I've got two subnets, subnet A and subnet B, and I've got a couple of virtual machines in each one. Each virtual machine has a network interface card that connects it to the subnet. And then, by default, these subnets can route to each other because they're in the same VNet. And then if we want to, we can put NSG and Network Security Group, which we will hear more about later, around these to say, okay, I want to filter traffic between them. So this is kind of the core concept: if I want to put machines out there in Azure, vnets are the way to do it. So what are all those capabilities? Let's just kind of summarise and work through this list. First of all, they are isolated. Vnets are isolated from one another unless we choose to connect them to each other. Isolation is very important,particularly in multitenant scenarios. They all provide Internet access. So if we want to connect these VMs to the Internet, we can do that by default unless we choose to restrict that. But that is available to us. They allow us to connect to multiple Azure resources, not just virtual machines. We could put cloud services like webapps and other services in there. We can plug them into the same VNet as our virtual machines. Everybody can share that network boundary if they wish. The VNet connectivity, I kind of mentioned briefly, can be chained if we want to,so we can connect VNet to other ones. And there are various methods to go about doing that. Connectivity. We can provide on-premises connectivity, so we can allow Vnets to route to on-premises. As you saw in that original diagram, we can apply traffic filters via network security groups. That's kind of the shields, again, you can see on the screen there. And finally, VNet provides a number of capabilities around routing, so we have default routes available. You can also define user-defined routes. And so we can basically customise this to manipulate it in a way that meets the needs of our organization. If we look at some of the key points, Let's just hammer this home. Number one, VNet, is our primary building block for Azure networking. So just think of this as the core of everything that we do in Azure and all the services we want to connect together. It's a private network in Azure based on an address space prefix. And this is something that we define. We create subnets in our veneer with our own IP ranges. So we need to plan for them. We do have to think about things like overlap inaddress space, much like we would on premises as well. We can choose to bring our own DNS or use Azure provided DNS, and there's more to come on that a little bit later on. And finally, we can choose to connect the network toon premises or the Internet if we wish to. But hopefully this gives you a brief overview. I think if you just understand these five points and work through the demos, I think you'll get a lot out of this and see very quickly how easy it is to connect all the pieces together as you're networking together.

2. Demo: Create VNets and Subnets via the Azure Portal and PowerShell

To begin with, I've already created a new resource group called SL Network. And on the left hand side,I'm going to select Virtual Networks. And as you can see, no networks are currently present. So let's go ahead and select Add, and the network blade comes up to create a new virtual network. And let's give this one a name. The first one we'll call SL 75 three three portal.Now, we're not going to go too much into address spaces in this course. If you want to read that, there are plenty of YouTube videos on the subnet. But for the purposes of this course, I'm going to create a 23-network for this one. So 100 00:23 and then I'm going to create 224 subnets inside that 23. The next thing we need to do is go ahead and select our subscriptions. I'm using my Pay as you Go to choose our resource group. So choose a slash network. And you can see I'm doing this in the north central US. And now I need to name my subnet. So the first one you see, it creates a default subnet. I'm going to call this subnet A, and we're going to give it the address range of 1024. That's the first 24 inside of our 23 range. We'll go ahead and click "Create." You can only create one subnet at this point from the portal, and within seconds or so, our network will be created. But we'll speed things up here and that's created. We'll hit refresh and there is our network. So now let's go inside there and we can see if we scroll down to address space, we've got our 1023 and let's go into subnets, we can see we have subnet A, but let's go ahead and create subnet B. And you can see it's already picked as the next Slash 24 for us. So 100, if you look closely underneath, it says, "our address range is 100 10 to 100 1255." So we actually only have 251 usable addresses in there because five are reserved for Azure. And we're not going to cover network security groups and route tables yet. We'll come on to those later on. So go ahead and click OK. And that will create our second subnet. It should only take a couple of seconds and we should have our subnet. So you can see we now have a VNet with two subnets, subnet A and subnet B. All right, so we can do things via the portal,but it can get a little bit cumbersome, particularly when I want to create a lot of subnets. So for that, in this next example,I'm going to use PowerShell instead. And that starts off in Visual Studio code. where I've already got a PowerShell script ready that I can walk you through. So the top section of the script is just a declaration of the kinds of global pieces I need. So the resource group and the locations In this case, I'm going to deploy this new virtual network along with its subnets into the same resource group I used before in the same location, north central US. In the second section, I've got myVNet name and address space. I'm calling this one SL 75 three three VNetPshells to differentiate it from the portal one. And I'm increasing my address space. This time I'm going to use a 22 because inside that 22, I'm actually going to create three twenty-four S. And there wouldn't be enough space if I just stuck with the 23. In the next section, I'm declaring some variables around my subnets just so I don't have to type everything in with every line. So I've got a subnet a name, which is slash, and that's the first 24 100 zero. Then I've got my next 24 for slash app, which is 100,and then my next one for slash data, which is 100 20.Next, I declare a variable which I'm going to use when I create the VNet itself. And I just called this "dollar subnets." And in this one, I created a new Azure RMVirtual Network subnet Config And this takes subnet a's name and subnet a's address prefix and adds it there. Consider this similar to when you created that VNet in the portal. I associated a subnet with it. This is the first one. If I scroll further down, this is where I actually create my Venet, and I include that subnet configuration. So I'm declaring this as a variable because I'm going to use it a little bit later. But the command here is "new AzureRM Virtual Network." further up my resource group name, my location, and the VNet's overall address prefix And then the first subnet I want to create, which I reference with subnet dollar subnets being my variable. At this point, the network is not created. But now I want to create those additional subnets. I use these additional commands which add Azure RM Virtual Network subnet config. I refer to the virtual network. I then reference my subnetconfigurations, which is my name. So subnet B's name is followed by subnet B's address prefix. And then I run that same command again for subnet C. Following that, I have to do one last task,which is to save the additional subnet configurations. They're only local at that point. They haven't been set against the virtual network. So I simply do a Set AzureRM Virtual Network and specify the VNet. And then that will save the changes that we added when we added the additional subnets. So with all that, let's go over to PowerShell and run this. And I've got it here in myC Drive script Skylines network folder. And I'm simply going to type in "Create." So create a VNet PS. One is the file. I've got to hit enter and that is going to go off and do all the hard work for us. So we'll give that about 20 seconds or so and that's completed and then it's added the additional subnets and now save that config. So if we go over to the Azure Portal now and back into virtual networks and do a refresh, I now see I have this PowerShell version as well. So we'll select this one and in there, if I go down to subnets, you will see that I have my web app and data subnets as well. Hopefully, you can really see the flexibility and ease of use that PowerShell will allow you here. I highly encourage you to get used to it straightaway, and you almost certainly will get questions on the exam related to PowerShell commands in this area.

3. Demo: Configure User-Defined Routes and VNet Peering

In this portal, The first thing we're going to do is show you how to configure the user-defined routes. To do that, simply search from the top for "route" and you should see something come up called "route Tables." Go ahead and select that. Once you're in the route tables, by default, unless you've created any user-defined routes,you won't see anything there. Go ahead and select Add. And now give your route table a name. So we'll call this our SLUDR test. For my example, choose your subscription and yourResource group and go ahead and select Create. It should take about 20 seconds to deploy,and once completed, you have your route table. So go ahead and select your route table. And now the way we go about doing this is to go to Settings, go to Route, and then create a specific route. For example, we could connect to a network virtual appliance such as a Palo Alto. We might say SL and VA palo route.So we might choose our address prefix for the hop, so it might say 100 00:24 for that address prefix, and then we can choose from the next hop type. You won't get an option to choose the IP unless you choose Virtual Appliance. So you can see there that now I'm able to enter my next hop address. So this could be a hop into a different subnet for that gateway appliance. So 100, let's say 590, for example, that could be where that appliance sits and hits, okay? And after about 30 seconds or so, that route will be created. Now, the routes themselves aren't any use unless you associate them with a subnet. And now that the route has been added, if I just refresh, you can see that route there. It won't actually do anything unless I go into subnets and associate this whole route table with my Virtual Network. So I could select one there and select my subnet as well. So this is just an example for you. I'm not going to do it in this case,but hopefully that shows you that you could design an entire route table and then associate it with multiple virtual networks and subnets that you see fit. Now the second thing we need to do is go back and look at Peering. So if we go to Virtual Networks and see we've got our two networks there, let's see what happens if we try to pierce this. To do that, we can go into the 75 three-dash portal. Scroll down and you'll see the section called "peeringsand." Go here and select "Add" to add a new pair in and give it a name. But what you'll notice, let's call this SL Testat the moment, because it's not actually going to work if we go down to the Virtual Network. Choose a Virtual Network and you'll see there's nothing it can appear with. And the reason for that is that everything there has overlapped and address space, which naturally will not work because we won't be able to route to it. So let's cancel out of this. Let's create a new virtual network. will go back to virtual networks, select Add. We'll call this one SL 75 33peer, and it's given an address space. Now watch out. If we type in 100, it will actually tell us when we build in Vnets, which is okay, we could if we wanted to build lots of Vnets with overlapand address space, but we didn't want to. But you can see here it does warn us that there's overlap and address space. I'm not going to use this one. I'm actually going to use ten 400:23 as well as other subscriptions use page.You go, choose your resource group and scroll down. I've got to create a default subnet for this one. So I'll just choose the first one, slash 24, and put it in the right box. There we go. and then give it a name. And with that, go ahead and create that VNet. It'll probably take a few seconds to refresh. There we go. And now, if I go into that VNet, peer, and peerings, I can click Add my name again. I can choose my virtual network and you will see that portal and my other virtual network, the Pshell one, are both available because they do not have overlap and address space. And so we'll just select one of those for now. Just to show you the rest of the settings available to you here. You've also got things like allow forwarded traffic, which basically says that I'm going to allow forward traffic from outside of the peer venet. So traffic that's destined for this virtual network came from outside the peer VNet. The other two that I've got here are around Gateway. So I can allow gateway transit.This enables the peer network to use the gateway in this VNet and, for example, use it to traverse on premises. And then the other option is to use remote gateways. And to use remote gateways, I do have to allow transit that requires that to be checked but thenallows this network to use the peer gateway instead. And with that, that's everything you need to know about user-defined routes and peerins. And I'm going to go ahead and close this out, and that's the end of the demo. You.

4. Lecture: Network Security Overview

In fact, we're going to go through these step by steps.And don't worry about remembering everything on the slide just yet, but this is a good reference for you to look at. Everything from Network Access Control, firewall in, securing remote access, service availability, name resolution, traffic routing, DDoS monitoring, login, and so on must be considered. There's a lot to kind of cover here, so let's break it down and use this kind of as a reference as you go through when you look at the slides and download them as a good reference for you to look at to make sure you have a good understanding in all these areas. Let's begin with network access control. And any secure deployment that you implement requires some measure of network access control. The goal is to restrict communication to what is absolutely necessary. And we can start with network layer control. We can control the network using network security groups to limit communication between, say, different subnets. We can limit communication between specific, say, virtual machines. At the next level, as you'll learn more about with NSGs, there are Application SecurityGroups, and there are Service Tags as well. So if there are particular services or applications we want to control access to, we can do that there. And then Azure Security Center also allows something called "Just In Time VM Access," where somebody can request access for a period of time. It opens up the network security group to allow access and then shuts it down when that timer expires. And finally, on there, you also see service endpoints that are all around, say, restricting. Let's say we've got a Blob storage account that we want to restrict to a virtual network. We don't want it to go over the public space. We can basically do that as well. That also brings us to resource control enforced tunneling. This is about controlling routing behaviour on vinyl with custom behavior, so we can say, okay, when this goes out, go through Palo Alto. In fact, that brings me to the third one, virtual Network Security Appliances.These are virtual appliances that can implement higher levels of security. So NSGs aren't always enough. You need that extra protection. Why not implement something like a PaloAlto or Checkpoint file, things like that,that are available in the marketplace? But using the user-defined routes fromResource Control, we can ultimately route traffic through those appliances if we want to. We also have something called Azure Firewall that's available now. And what is the Azure firewall? It's a cloud-based network security service to protect your Azure virtual network resources. So as opposed to something like thePalo where we implement a network virtual appliance, Microsoft is managing for us. It's a fully state-full firewall service. And why do you need one? Again, when energy just isn't enough,and many times for compliance reasons, energy is just not enough, you're required to have some additional protection in place. So that's kind of just controlling things at the network access control and, say, implementing a firewall to help provide additional protection. But what about securing remote and cross-premises connectivity? Well, one, we can connect individual workstations to a VNet. You can use what's called the point to SiteVPN connection that you may have heard of already,which allows our desktop machine to just connect in and VPN directly into that Venet. So that's one way to limit connectivity. We can connect an on-premises network to a VNet with a VPN that's known as a Sitetosite VPN Connection, or we can do it with a dedicated Wan link. The Express route service is available there as well,and we can connect virtual networks to each other. So again, this is part of your design and thought process. How do I limit connectivity to only what is necessary? Going back to that defence in depth methodology that you probably remember from the initial module on security, availability is another big, big concern. So, load balancing, what about using an app gateway? We need to ensure the availability of services. If something goes down, maybe there's another node that can take effect, and a load balancer will help us to do that. We also have network load balancing through Azure load balancers. There's a standard load balancer that's available now as well. global load balancing through something like a traffic manager. So across regions, we can have availability in the event the whole region goes down. And all of this is increasing availability and increasing performance. Again, one of the security concerns is making sure services are available. So it's certainly something that the application architects are designing around because they want a highly available application. But it's also a security concern as well. Other network security factors taken into account include DNS protects DNS, ensures DNS accuracy, and ensures your entries are correct. Whether you use your own DNS server or whether you use Azure DNS, that's a key piece there. Global traffic routing through something called FrontDoor now allows more efficient routing of your global traffic monitoring and threat detection,as well as login and auditing. And all of these are the factors that you need to be thinking of going back to the very beginning, to this kind of list. Here again, network access control. What am I doing to restrict access to the network? What am I doing about firewalling? How am I securing remote access and cross-premises connectivity and cross-VNet connectivity? How am I dealing with availability? What am I doing for name resolution? How do I improve global traffic denial of service,which we'll learn more about in a subsequent lecture? Monitoring, threat detection, and login auditing. Don't just think network security is a firewall. It's all of these things that we need to be thinking about. And look for questions about that on your exam.

5. Lecture: Network Security Groups (NSGs)

One of the core security components for networking in Azure are NSGs, also known as network security groups. And what are they? They're essentially a traffic filter, an anetwork filter that checks traffic. Think of it like a firewall that allows or restricts traffic to resources. In our Azure network, there are two types of rules. There are inbound rules and outbound rules that you'll see in the upcoming flow that we'll walk through. And finally, they can be associated with a subnet or a network interface card. And it's very important, something I'll reinforce over and over throughout the section. Finally, it is worth noting that in classic Azure you were able to associate NSG's with the virtual machine itself. But that changed under the R model. And now you've got the network interface card and the subnet that you can associate with only. Now, if we look at this from a flow perspective, we've got some virtual machines in subnet B that wish to communicate with virtual machines in subnet A, ultimately going through this kind of traffic flow. The virtual machine in subnetb wants to communicate with this virtual machine in subnet A, and the traffic goes out through the subnet NSG in this example. And that's what NSG is going to check from an outbound rules perspective. If it's all okay there, then the traffic will continue on to subnet A. The NSG and subnet A will check it from an inbound rules perspective and then, if everything's okay, allow it to talk to the virtual machine in subnet A. Now, again, this can be applied at the network interface or subnet level, and the subnet rules apply to all the resources in the subnet. Now think about this from a rule precedence perspective. If the NSG is applied to the network interface card and the traffic is coming outbound,it may never even reach the subnet. The network interface card overrules the subnet policy. The same in reverse. If we're coming into the subnet and, let's say, the energy associated with the subnet allows traffic in, it'll get to the virtual machine and then the network interface card can still deny it. So just think of it from that perspective. It gets denied, you know, outbound first from the networkinterface card, then to the NSG on the subnet. If it's reversing, coming in inbound, the traffic is stopped, potentially first at the subnet NSG and then again at the network interface card NSG. Now, what are some of the properties that you configure when you create a network security group? Aside from just giving it a name,we have to define these things. One is the protocol that we want to allow. For example, it could be TCP or UDP. Second, the source and destination port range. So anything in the range from one to 65 is 535. Or we could simply choose a star for all ports. We have our source and destination address prefixes. So this could be our ranges or we could use default tags, which I'll come on to shortly. We can follow our direction. So inbound or outbound, that's obviously a natural property there and, as we went through the flow previously, that's going to determine where things are going to be stopped. So the priority, which I'll also come on to in a moment, is in what order are these rules evaluated and then whether we choose to allow access or deny access based on the rule we've just defined. So we set the criteria and then at the end we say "allow or deny." So what about the rule priority dimension? Well, rules are enforced based on priority. As you can see, they have a range from 100 to 4096, and the lower numbers have the highest priority. So if you've got a rule that's 100, that's going to be a higher priority than a rule that's lower down the spectrum, closer to the 4096. So, hopefully that gives you an idea there. The default tags I mentioned are also really important because they can make things a little bit simpler when we're trying to restrict certain ranges of IP addresses. And these are system-provided to identify groups of IP addresses that Azure has provided for you. And there are three major ones that you need to deal with. Your virtual network is your virtual network.So this includes all the Sid definitions in Azure for virtual networks. In addition, you've got your Azure load balancer. This is Microsoft Azure's infrastructure. load balancer. This is an Azure Data Center IP address. And finally, we have the Internet. So this is all address space outside and reachable by the public Internet. And this includes all of the Azure-owned public IP space. If you're still unsure what these are for, just remember that when we create our rules, we can choose to use service tags instead. Rather than having to figure out all of the IPS that we want to deny in these services with groups and groups of IPS, we can simply use the default tag. And this just makes it a lot easier for us to say, "Okay, I don't want to allow any traffic to Azure load balancer, so I can use a default tag for that." Now when we look at the NSG's, we've created one. There are a number of default rules that are created as well. And we've got the inbound and outbound rules onscreen for you, and they are essentially the same if you look at the categories across them. So, if we look at the top row, which is labelled Allow VNetinbound and Allow VNet Outbound, this is for traffic that originates and ends in a virtual network. And this is allowed for both inbound and outbound directions, as you can see there. Then you have the Internet on the bottom there. This is allowed by default out,but is blocked from coming in. And finally, in the middle row there,we have our Azure load balancer. And this allows the load balancer to probe the health of your VMs and role instances. Now, you can change these rules,but you can't delete them. They have to be there in the network security group by default. What you will notice is that the priorities are very low, so they're not set to a high priority. A lot of the rules you create will be given higher precedence than these ones. One final thing we just need to learn about our networking is around networking limits. And you can see the limits on screen. You can get the latest limits by checking on the Azure website. There are a couple of things I'd like to draw your attention to right now. For one, there is a default limit for network security groups of 100. But this can be increased very easily to 400 NSG rules. For an NSG, we're looking at a default of 200, but this can be increased to 500. But the other ones I'll draw your attention to are public IP addresses, which for dynamic ones, you can have 60. For reserved public IP addresses, 20. And to actually get those increased,you have to contact support. And they don't like to increase those very easily. So that's just something to be aware of as you think through some of your network configurations.

ExamSnap's Microsoft AZ-500 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Microsoft AZ-500 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.