Platform Protection: Network Security

6. Demo: Create and Configure a NSG

In the portal to create our network security group, simply select Create a resource, select the Network in section, scroll down and you will see Network Security Group. Select that and give your network security group a name. My case I'm just calling it slash NSG. I'm using a pay as you go subscription and I'm going to put this in the ournetwork resource group that we've been utilizing. Go ahead and click "create." This simply creates the shell, if you will, for the Network Security Group. It takes about ten or fifteen seconds, and once completed, we'll go to that resource so we can begin configuring it. So, as I mentioned in the tutorials, there are a number of default rules so you can see them. There are the inbound security rules and outbound security rules. But we're going to go ahead and create a new inbound security rule. Let's say we want to deny RDP traffic to a specific subnet. So we would go into Inbound security rules and there we click Add and now we get all of our options. So first of all, we can choose our source. This could be anything; it could be a specific IP address or it could be one of those default tags we described. I'll just show you that for the moment. If we look at the default tags, we can choose Internet, Virtual Network, Azure, Load Balancer, as well as other specific services available in Azure. But if we go ahead and selectany, we'll choose the port range. So in our case, any port could be the originator, the destination could be any, and we're going to say for port3389, which is the port for RDP over any protocol deny. And here we can now choose the priority for the rules. So in this case, 100 is the highest priority. It's going to override everything else. We can give it a name. We'll just accept the default one that's provided to us if we select OK. This creates the inbound security rule. It takes a couple of seconds and that will appear in your network security group. The next step is to decide where we want to associate this while it is creating. So, for example, we could associate it with a network interface and we can go in there, select Associate, and choose one of the network interfaces that's available to us, perhaps one of our virtual machines. Now, as you can see in this example,all of our virtual machines and their network interfacecards are already associated with NSGs that were created when they were built. So they're all greyed out. But now maybe I want to associate it with the subnet, so I can select the subnet, chooseAssociate, and now I select the Virtual Network. First of all, in this case, I'm going to use the only one I've got created currently, followed by my subnet. I'm going to choose subnet A. Select "okay." And now any traffic destined for subnetA on port 3389 will be denied. Now, it's very important to remember the precedence of rules associated with NSG's. So inbound traffic coming into that subnet could be denied by the network security group that we created there that's associated with the subnet. Now, perhaps it will be allowed through. We don't have that deny rule for 3389,but we have another network security group associated with the network interface card on the VM. It can further be denied at that level in reverse when we're going outbound. We could have outbound rules attached to the network interface that deny traffic before it even gets to the subnet rule. And then when it gets to the subnetrule again, we could have an NSG there denying traffic or allowing traffic out. So just remember the rules of precedence, especially for the exam. And with that, this concludes this demonstration.

7. Lecture: Azure Load Balancing Services

Let's now take a look at the Azure Load Balancing services you're expected to know about for the exam. And first of all, we have an Azure load balancer. This is the most common one. This works at the transport layer. So think of layer four in the OSI network reference stack. It provides network-level distribution of traffic across instances of an application running in the same Azure data center. Now, in contrast to loadbalancer, we have an application gateway. This works at layer seven, the application layer. It also serves as a reverse proxy service, terminating client connections and routing requests to back-end endpoints. And finally, we have the traffic manager. Think global scale, globally distributed endpoints. This works at the DNS level. So we might have applications running in multiple regions and users coming in from multiple locations. That's where we would utilise traffic manager.Now, in more detail, let's look at Azure Load Balancer first of all. So as I mentioned, it's layer four. It's important to know that there are basic and standard SKUs now available. The standard SKUs are now in preview. They're not required for the exams. You're only expected to know about the basic one,but just know that it's coming out and we'll certainly update the material when that actually happens. You have something called Service Monitoring as a feature that allows Azure Load Balancer to probe the health of various server instances behind the load balancer. When a probe fails to respond, the load balancer can stop sending new connections to the unhealthy, let's say, virtual machines that are behind the load balancer. We have something called "automatic reconfiguration" as well. So this can reconfigure itself automatically when you scale instances up or down, perhaps when you add new Web server instances, as an example. Next, we have something called hashbased distribution. And this is how AzureLoad Balancer distributes its traffic. To map traffic to available servers, it uses a five-tuplehash composed of a source IP, a sourceport, a destination IP, a destination port, and a protocoltype by default. It also provides stickiness within a transport session. So this means that if a client comes back to the same session, they will continue to connect to the same, say, Web server behind the load balancer as well. And finally, there are internal and public options. And you'll see some of the examples in a minute. But just know that you can configure an internal load balancer for traffic to hitit and then disperse it for internal applications. Or it could be people coming over the Internet and you want to expose the public IP. And then, once they hit that load balancer, they pass traffic to the servers behind the load balancer. So let's look at some of those examples. First of all, look at an internal example. And in this case, we have an internal load balancer at the top there, which has a private IP associated with it that can be dynamic or static as well. You can decide how you configure that. And then we could have said, two database servers behind the load balancer. Traffic will hit the private IP and then be sent over to one of either DB One or DB Two. Now let's look at a public example where if we look at the load balancer, which is in the centre of the screen, the traffic would come through the cloud at the top of TCP port 80 and then we would pass the traffic down to one of the three available web servers that are behind the load balancer there. Now, you're also going to get multiple-tier examples as well. So in this case, you might see traffic coming and hit one of the two load balancers. First of all, traffic from the public cloud would come in and hit that web load balancer at the top, and then that would pass the traffic down to the web tier. When those virtual machines, which could be websites, want to query the database, they will send traffic to another loadbalancer. In this case, the second load balancer is placed in front of the database servers, and the web servers simply query the database server. Now it's also possible that people can just hit that database server if they want to from other applications as well. This could be coming from the website and opens up a host of options for you there. So let's shift our attention now to the App Gateway, the other load balancer that's available to us from Azure. And first of all, it's layer seven load balancing, as I mentioned before. So just keep that in mind the whole time. When we want application loadbalancing, we need an App Gateway. When we want just layer four load balancing, we can get away with just the Azure load balancer. But a couple of unique features are important as well are important.So, cookie-based session affinity is a common requirement for many web applications. And this is required so that a user can maintain the same user session on a back-end server. It also supports SSL offloads, all those decryption tasks, etc. or that web servers would normally have to deal with They don't have to deal with that now. They can offload that to App Gateway and it can take care of it for them. We also have End-to-End SSL. So App Gateway supports end-to-end encryption of traffic. It does this by terminating the SSL connection, appGateway, and then applying routing rules to all of the traffic. It reencrypts the packet and forwards it to the appropriate back end based on the routing rules that you've defined. In addition, one of the most popular new features that they added recently was around web application firewall,and this has become a key feature. When you enable this, it provides protection for web applications from a lot of Commonwealth vulnerabilities and exploits. This can include things like SQL injection, cross-site scripting, and things like that. And you also have url-based content routing. And this allows us to direct traffic to different back-end servers. Based on the content that the user is actually requesting, a different server can serve that content up. Finally, one very important thing is that the App Gateway does require its own subnet, and you need to create that subnet before you can create your App Gateway. And you'll see this in the upcoming demonstration. In addition, there are a few things you need to know about app gateway sizes. In the following table, it shows you the average throughput for each application gateway instance, and this is shown with SSL or Float enabled. And Microsoft does include a disclaimer on their website. These values are approximate values for an application gateway through print. The actual throughput depends on various environmental details, such as your page size, the location of the back end instances, and the processing time to serve up a page. So just keep that in mind as well. Finally, if we just take a look at the comparison overall, we've covered Azure Load Balancer,we've covered App Gateway, and we've covered TrafficManagers just very briefly there. So just think at the top level. What am I trying to do? So if I need layer four Azure LoadBalancer, if I need layer seven App Gateway,and if it's something more geographically dispersed, think DNS Level, think Traffic Manager in that context. As far as endpoint monitoring goes, it's worth noting. At the bottom It's all supported via probes for Azure Loadbalance and application gateway, but traffic managers support http and https get requests. As far as endpoints go, that's the other different feature there. The Azure load balancer supports AzureVMs and cloud services. role instances The application gateway supports any Azure internal IP address or public Internet IP address Azure VMor Azure Cloud Service and Traffic Manager are both compatible with Azure VM Cloud Services. Again, Azure web apps and external endpoints as well. So that's just a brief summary there of all the different load balancing technologies for you. But that's it for this tutorial section. I encourage you to check out the subsequent demos.

8. Demo: Create and Configure an Azure Load Balancer

In the Azure Portal, just to set the stage for everything. If we go over to virtual machines, you'll notice that I have three virtual machines for this demonstration. I've got a jump box that I can RDP into over a public IP address. I've got two virtual machines. SL test VM one and SL test VM two. Both of those VMs are running a simple.is website. So if I just go into, say, test two and I'll connect there and if I open it up and just type inhttp localhost, you'll see that I'm on Skylines VM two. So on each VM I've just got a basic web page that's being served up and just identifies the virtual machine. So we'll go back to the Azure Portal and let's now go ahead and create our load balancer. So let's go to create a resource, select Networking, select Load Balancer, and we first have to go about creating the front end portion of the load balancer. So in my case, I'm going to call this Slinternal because we're going to create an internal load balancer LB,and I can select here between public and internal. So we're going to choose internal. But let me just go back and show you the public for the moment. When I choose public, I can choose a public IP address. This could be one I've already created, and it can't obviously be associated with another machine or another load balance already. And if I want, I can just go here and create a new public IP address, just like I would any other time. But I'm going to do this internally for the moment, so it's hit internal. And when I do it as internal,I get a choice of the network. So I'm going to choose my VNet and I'm going to choose my subnet. In this case, I'm going to choose subnet A, and you'll see that I can choose how the IP address is assigned. So I can choose to statically assign the IP and just type it in this box. Or I can choose Dynamic and Azure will assign one to the load balancer. Then I've got my subscription and my resource group, much like every other service we create. So I'm going to use Slash network for my resource group and I'm deploying this in North Central, so that's the front end portion of the load balance. So if I hit Create and we'll fast forward through that, it should take just under a minute to complete, and that's completed. So we'll go to that resource, and now I can start the backend portion of the load balancer. So you can see the configuration screen on the left-hand side. If I select frontend IP configuration, you'll see the IP that's been allocated 100 zero seven. That's because we made it dynamic. But now I can start configuring these three things underneath: the back end pools, health probes, and the load balancing rules, and I'll do them in that order. So start with back-end pools. And the first thing we need to do is click Add and give it a name. So I'll just call this the SL web back end. And now I choose how I want to associate with this. So I can select this dropdown and I can associate it with a single virtual machine or a virtual machine scale set. Or in my case, I'm going to choose an availability set that I already have, select that drop down, and select the SLAs Web. That's my availability set with two web servers running in it. Select that. And now this is very important. You need to add your target network IP configuration. So you're going to need to do two of these, one for each virtual machine. So select this box, scroll down, and choose our target virtual machine. I'll do number one first of all. And we can see it's got one network interface. And if you hit this drop down, select the IP, and then we'll select Add again. And now we will do number two. Select its IP and go ahead and select "OK." And that will now create that back-end pool. Just hit refresh. I can see SL Webs' back end is already there. It's still actually provisioning. So it's got one virtual machine in there. Now refresh again. And there you can see we have two virtual machines. If I expanded out, both of those were running and are in the back end pool. The next thing we need to do now is add our health probes, which essentially monitor the virtual machines and check whether they are healthy and available. So let's go over to Health Probes, select Add, give it a name, and then choose the protocol that you wish to check for. So in my case, I'm actually going to just select HTTP,and then I could select port 80, give it a path. But these parts are really important. At the bottom, the interval is the amount of time between probe attempts in seconds. So every 5 seconds it's going to check your health status and unhealthy threshold. This is the number of failures that have to occur before it considers the VM behind the load balancer unhealthy and will then take it out of the pool. And that's all there is to the probe. Go ahead and click okay. It takes about 30 seconds or so. Wait for this to update before you move on to the next piece. Okay, and as you can see, our probe is now there. It's still updating. So just give that a few more seconds. There we go. And now we go over to the load balancing rules. So in load balancing rules, this is where it all comes together. Select "Add," and now we give it a name. So we'll just call this SLLB Ruleand I can choose my IPV version. In this case, we use version four, but I now select my front end IP address. In this case, I chose the one I previously created (100 / 0/7). In my case, I'm going to use port 80 and then I choose my backend port followed by my back end pool. So in this case, I'm using that back endpool that I created for the SL Web back end. If I expand that out, you can see that's the only one I've got there followed by my Health Pro,which is for port 80 http. Now if we scroll down, there's a few more settings, for example, session persistence. This allows me to maintain session state based on either the client's IP or the client's IP combined with the protocol. I also have an idtimeout and a floating IP address. This is really for SQL, always on availability groups that you would use this, but if I go ahead and select okay, this is going to update the load balancer configuration. So again, we'll fast forward here. It'll probably take about a minute, OK? And we can see that the load balancing rule was created successfully. Let's go back to the overview and just grab our IP address, in this case 100 zero seven, and let's head over to our jumpbox machine to test it out. And so I'm just going to fast forward our RDP into the jumpbox. It's a VM on the exact same subnet as our test VMs. So we're now in the jump box itself and open up a web browser and if we type in 100 zero seven, you can see I got Skylinesvm One returned. Let me refresh again. I didn't get anything different. Let's try an incognito window. We'll do 100 zero seven again and you'll see I did a refresh there. Now I got Skylines VM Two, so it's put me on the second server and that is all there is to it. Both of those VMs are now successfully in an availability set that we created previously when we built the VM. So they're highly available across two fault domains and they are successfully behind a load balancer as well. So traffic has been dispersed between both of them, and with that, this concludes this demonstration.

9. Demo: Configure App Gateway

In this demonstration, we're going to take a look at the App Gateway and how to configure it. So here we are in the Azure Portaland we'll go ahead to all the services and types in the Application Gateway and upcoming Application Gateways. Before we begin, you might remember from the lecture some of the differences between this and other load balancing technologies. Well, just remember, this is an application gateway. You know, it can't handle TCP type traffic. It's really looking for web traffic to come. If you need to handle traditional firewalls and Azure firewalls in preview, you can use Network Virtual Appliances with Barracuda Palo Alto. There are other options there. This is really for web applications that have a public IP. You don't have to have a public IP. It could be an internal IP, but generally speaking, a public IP facing out to the internet that you want to protect. And so when you create your App Gateway, you click Addand we'll go ahead and walk through some of this. We'll do AZ demo app "Gateway" as our name. We'll choose our different tiers. So we've got Standard. And now there's also V Two. There are a lot of performance improvements coming with V Two. So we are encouraging people to move to that when it's supported. There's also a web application firewall. And then again, the two versions. So you've got the standard version of the AppGateway, which is your traditional load balancer, and some of the other features it's going to give you. And then you've got the version with the web application firewall as well. Actually, I'm going to go ahead and choose the WAF version here. We set our initial instance count there. So, from an H perspective, our SKU size and this is really just dependent on the amount of traffic. You're expecting a demo. I'm going to choose medium. I'll just put this in a new resource group. So, Azapp Gateway demonstration Click OK and everything is fine for me for this demonstration. So I'll configure my App Gateway and now I have to choose my virtual network if I've already created one. Or I can create a new one here. If I choose this one, you can see it's got my subnet there. And now I choose my front end IP configuration so I can go public and create a new public IP address. Or I can choose private. And if I want to, I can specify a specific private IP address. Now you can see an available private IP will be automatically selected from the subnet. You cannot specify because of existing AppGateway deployments in that selected subnet. So it has to be on its own if I want to basically choose a specific address there. So I'll just pick one from the pool. But in my case, I'm going to go ahead and choose Public. We'll scroll down, and now you can see configure my public IP address. So that's just going to be the basic skew there. I can put a DNS label on it if I want to on that IP address, but I don't have to. And then this is where I choose my listener configuration. So I'm listening for HTTP traffic on port 80 or HTTPS traffic on four four three. But then I am required to upload my SSL certificate as well. So I would need to go and do a certificate request, get a certificate, and then upload one here if I'm doing that. But we can just do HTTP for now. Http two can be disabled or enabled depending on what's required for your application. And then this is where we choose our webapplication firewall and whether to enable it or not. Now obviously, a web application firewall will introduce a little bit of latency, but it's going to provide a lot of protection for your application. And again, you can disable it if you're having trouble and then re-enable it later on. The other thing, though more importantly, is that you can put it in detection mode or prevention mode. So in prevention mode, it's essentially going to block attacks and things like that. Detection, it's really for viewing what's going on and you can help kind of modify your rule sets and things like that at that point. But with that, we'll click OK, and then I'll just deploy this. But I do have an app gateway already for us, but we'll kick this one off here. And if I go into this one, calla test, which I already have here. I just want to show you a few of the other settings that we have here, and don't worry that this has failed, it's just an old configuration here. If we go in here, I've got back end pools. This is where I decide what the targets are on the back end. So what are the things behind the appgateway that I want to load balance against? I've got my HTTP settings. In fact, if I click here, I can add multiple HTTP settings. It's very important if you're doing session-based workloads that you want to maintain session state then use cookie-based affinity. You'd want that enabled. Connection draining is all about when we're taking services out of the load balancer specifically, and it saysconnection drain allows for inflight active connections to the back end service to complete before the back end service is taken away from the pool. So no new requests were sent while the back-end server was being drained. Our protocol, we kind of talked about that already, and then we can do some things like custom probes and things like that as well from this section here. Now, something to keep in mind: there have been situations where I've seen people put an app gateway in front of another load balancer, and if you're going to do that for whatever reason, there's actually no need. It's not a best practice. Your cookie-based affinity will break because that only works from the appgateway directly to your back end workload. So, just something to keep in mind there. So that's your HTTP settings and you can add more there in your front end IP configurations. This is that public IP that gets configured that I did in the one I just built that's still building right now. And then if I want the private IP seat to say not configured,I have to go in here, configure it, give it a name,and then save, and then that gives me my private IP. And again, I can choose a specific address if I want to from that subnet, provided I don't have two app gateways in the same subnet. Then we have our listeners. So you can see I've got some SSLpolicy and some details around the firewall here. But if I go into the listener itself, it's the same thing here. I've got my front end configuration, my front endport, and then my associated rules and any custom error pages I want to create there. I can get to my rule sets right here,or I can go back, choose rules, choose ruleone as an example, and that's there for us. And if I edit this, you can see it's What's my listener? What's my backend pool? What's my HTTP settings? I can create rules with a combination of myListener, my back-end pool, and my HTTP settings. A few more things Just the health probes. Nothing there right now. If I click Add, we'll get a default kind of health probe that comes in here. Interval: 30 seconds. Time out of 30 seconds. unhealthy threshold of three here. But essentially, this is where I choose my host that I want to basically probe against, and then choose any specific path that I'm trying to probe to make sure, hey, is the service responding to web requests on a specific path. That's what the health probes are essentially for there. And then further down, aside from the usual governance pieces and automation, I've got all my alerts metrics, but a very useful one is this backend health, where you will see my server on my back end pool and whatits status is right there on the screen for us. One thing to note is that app gateways,whenever you make any updates to them, go through a lengthy restart process. It sometimes takes twelve to fourteen minutes. You'll see, this app gateway I'm deploying here will take a long time. So if you're following this through your own demonstration, then just sit tight. Don't try to do anything until everything is completed. That's how you kind of run into trouble. But with that, that concludes this demonstration, which hopefully gives you a good quick update on how to configure your app gateway.

Study with ExamSnap to prepare for Microsoft Certified: Azure Security Engineer Associate Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, Microsoft Certified: Azure Security Engineer Associate Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide Microsoft Certified: Azure Security Engineer Associate Practice Test Questions & Exam Dumps that are up-to-date.