AZ-700 Microsoft Azure Networking Solutions- Network Security Groups

1. Overview of Network Security Groups (NSGs)

We are moving on to talk about something that’s pretty basic and fundamental when it comes to the security of Azure networks and that is network security groups. Now we kind of alluded to it in this course. We’ve seen that certain networks in this the demos have had network security groups attached to them. But in this section of the course we’re going to creating network security groups looking at the access control rules effectively that are set for inbound and outbound on networks. We can attach the network security group to either the network interface card or to the subnet. We’re also going be to talking about this concept of application security groups which makes it easier to group related resources and create our security rules to all resources that are related.

And finally we’re going to look at flow logs, flow rules and IP flow. So Network security groups is in this section. Now like I said, if we go into some of the resources we’ve created before now we can see that some of our servers have had network security groups. If we go under the VM resource group we can see that each that there is one network security group associated with one of the VMs. What we’re going to do is we’re going to create a network security group from scratch and then we can move that around to various resources. So if I look for a network security group, it’s a second option. It’s a basic Azure service. Now they’re calling it a firewall but it’s really just a list of rules.

It’s called five tuple. In terms of the set of rules, the five representing protocol, source IP, source port, destination IP and destination port, those five pieces of data together all have to match the incoming traffic in order for that rule to either allow or deny the traffic. So we’ll create a brand new network security group, create that with my virtual machines. So I’m going to call this new network security group and we might as well create it in the same location that we always do. Now we’re not going to do any sort of tags creating the network security group by itself it’s just a resource. We haven’t associated with it, anything with it yet, we haven’t actually looked at the rules.

All right, so let’s go to this brand new resource. Now the overview screen has both the inbound and outbound rules but we can deal with them separately here. So right away we can see that a network security group basically organizes a set of rules and it separates it into inbound rules and outbound rules. And as we mentioned before, it can be attached to either a network interface or a subnet or both. Now let’s think about the inbound rules. Now there are a set of default rules and I can actually hide them or show them. The default rules can’t be changed or altered in any way. They’re basically set the three default inbound rules is to allow traffic from the same Virtual Network, basically to travel across the Virtual Network.

So if one machine on a Virtual Network is communicating with another machine on the Virtual Network, that is allowed. And again, this can’t be modified. What we can do is we can override it by creating a higher priority rule if we wanted to. We’ve seen this before as well. That the load balancer traffic. Even if the load balancer is outside the Virtual Network, the load balancer traffic has a default allow position. So to add VMs into a load balancer, you don’t have to modify the network security rules. And then finally, the third default rule is to deny everything else. So every other source of traffic, including external Internet traffic, traffic from other Virtual Networks, traffic from other regions, it’s all denied unless we allow it. Now, we’re looking at the similarly outbound rules.

We’re going to see a slightly different so obviously, it can connect to other machines on the same Virtual Network. It can also connect to the Internet. So outbound Internet traffic is allowed by default. All other traffic is denied. Now, if you’re going to allow all traffic to the Internet and other traffic to the Virtual Network not sure what this third rule is actually blocking, but I guess it’s blocking traffic to private IP addresses that are not on the Virtual Network. So these are the default rules. When we come back, we’re going to add some new inbound rules, some new outbound rules, and we’re going to start playing with associating this with their network interfaces or subnets in order for it to do anything.

2. Assign Custom Inbound and Outbound Rules

So let’s add our first custom rule. I’m on the inbound security rules tab of the NSG. We can see the default rules and we’re going to hit the add button to add a new rule. Now don’t forget that the NSG uses the fivetupple format, which is source, source, port, destination, destination, port, and protocol. And then we decide whether we allow or we deny traffic. So I want to add an RDP rule. In this particular case, I want to allow my computer, my workstation here, to connect to RDP to any machine on the network where this NSG is attached. So I’m going to say source, IP address and I’m going to include my specific IP address. Now I’m going to allow all ports for my address. And in terms of the destination, I’m not going to restrict it to any specific IP address, but I am going to restrict it to the RDP service. So this is the RDP service.

Now, you notice I can go to custom and enter the number, or I can pick RDP from the list and it enters it for me. And RDP operates over the TCP protocol. So I’m going to say I want to allow this. Now, priorities in NSG are done by number, and the higher the number, the lower the priority. So all of the default rules start with 65,000 priority. The lowest number you can have is 100. I usually don’t want to get the lowest number because then you can’t add any rules that are higher priority. So I’m going to pick a number like 250, which is low, but there’s still room for more rules. And I’m going to say that I can RDP as the rule name and I’m going to say add. So any NSG, any network card or subnet that this is attached to will allow my IP address to RDP into that machine. Now, the second thing we might want to allow, we sometimes we get this when we’re creating a VM is we want to allow Http traffic. This case, we want to allow it from any source.

We’re going to pick the Http port. And so that means that port 80 is going to be open for all networks that this is attached to. And I’m going to say that this is fine. Now, you obviously don’t want to leave your ports open unnecessarily. And so for a back end server, having port 80 open probably doesn’t make sense. And maybe for those kind of back end subnets and back end servers, you want it very specific in terms of where they come from. So you’re not allowing public Internet traffic in, you’re basically only allowing internal traffic over different ports. But in this demo, I’m going to allow all public Internet traffic from port 80. So this is going to be Http. And if we’re adding port 80, we might as well add the Https port, which is four, four, three. And I’m going to call this https. So we’re allowing RDP just from myself and Http and Https from anyone to any server behind.

Now we can flip over to the outbound security rules, and we can see that again. It’s usually not a big issue to allow a machine outbound access, but in a world where you want to, let’s say, assume breach in a zero trust model, maybe. We do want to be very specific about what servers that this machine is allowed to connect to. You know what, I’m going to turn off public internet access. So even though we have this default 65,001 that allows internet access from the machines, I’m going to actually override that. And the way that you override that is by creating a rule. And I’m going to say that the destination is going to be a service tag and we haven’t talked about service tags yet, but I’m going to say any internet address is going to be blocked. And in this particular case I want to block all ports so from any machine that this NSG applies to, it is going to be broken.

Connecting outbound to the Internet over any protocol. So deny outbound. I actually do have to put the deny action on here. Now that might break a lot. So this might not be a great rule to blanketly deny everything to everywhere because then you can’t do Windows updates, you can’t send files anywhere or do any kind of maybe there’s some work implication but just denying outbound traffic, there are valid use cases for that. So here I am, I just overrode one of the default rules and what are the implications of that? All right, so now we have our network security group has a couple of three custom inbound rules and one custom outbound rule. In the next video we’re going to then assign this NSG to one or more subnets and we’ll see what the implications of that are.

3. Associate an NSG with a Subnet or a NIC

All right. So the first thing we’re going to do is we’re going to associate this rule with a subnet. Now like I said before, the NSG can be associated with the subnet or with the network interface card or both. And that can get confusing if you’ve got network security groups on both ends of the same connection. It’s like having a locked door on both sides of a hallway, right? So let’s do it at the subnet level which means it’ll cover all of the resources that are on that subnet. So I’m going to say associate, choose our virtual network and in this case I’m going to allow the mid tier. Now you’ll notice it doesn’t allow me to affect the firewall and that makes sense, right? So I’m going to associate this to the subnet of the mid tier. So it says it’s successfully associated and theoretically right now I could remote into the mid tier. Now it doesn’t have a public IP address and so that would be a little bit tricky.

But if it did, if we added a public IP to the mid tier then I could network RDP into it. Let’s go over to this machine, this network here. So if we go to the I think it’s called VM Three and we go under networking we can see that the virtual machine already understands that it has rules and that the rules that we custom added are being mentioned in terms of the rules here. Now the network itself, if we switch over to the network interface card and we switch over to network security group, you’ll see that the network interface card itself does not have a set of rules. So this was added at the subnet level and so that’s why it’s not listed here. But we can still see the rules because it’s added at the subnet level and actually it says attached to subnet.

The relevant part of is right here. So this is working pretty much as intended. We have our inbound and outbound rules associated with it. Remember, network security groups are quite they’re not intelligent, right? They’re not like an Azure firewall where it’s got checking the IP addresses against a list of known hackers and advanced threat detection and things like that. This is literally just a list of sources and destinations and allow or deny we saw how simplistic they are. Let’s call this working as intended. Now if we wanted to, we can go back to the network security group, go to the subnet, we can disassociate the NSG with the subnet and instead go to our network interface card and associate it with this. Now we’d have to know which of these is the network interface card for us.

I think it’s probably VM Three here. And so now we are protecting only the one device, not all of the devices on the subnet. With this NSG, it’s probably best that you have a fairly simplified list of NSGs instead of trying to have dozens of specific NSGs, have a few set that are basically designed to protect your websites, designed to protect your databases and your other application tiers, and use the same NSGs against all of those instead of creating separate NSGs for each one. Obviously, less is more when it comes to security in terms of the amount of things you have to manage, the things you have to remember, where the ports are open, the IP addresses are allowed in, et cetera. So that’s why we associate things with subnets and not network interfaces. But if we did, I would use the same NSG, several network interface cards, depending on the role of the device.

4. Create an Application Security Group (ASG)

Now we saw when it came to adding rules, whether it’s inbound or outbound, that we had a few choices from the source and one of them being IP address, pretty straightforward service tag we saw was some predefined generic services that Microsoft is offering to us. So from the Internet load balancers Azure Site Recovery If we ever need to allow that traffic to come in from an Azure data lake service or specifically going out to one, if the devices on the network need to connect to a data lake, you can add this data lake service as an outbound exception that allows that to happen. And the last interesting one is called Application Security Group. Now Application Security Group, we don’t have any because we haven’t created any. And so in this video we’re going to create ourselves a security group. And what this is going to do, it’s going to allow us to group together a number of related resources that all have the same role, almost like having roles in Active Directory or groups.

So I’m going to cancel out of here, go to the home, create a resource and we’re going to look for Application Security Group. If I can type Application Security Group by Microsoft, hit Create, put this into our resource group and I’m going to call it New ASG finally defaults to my region when we create it, it’s empty. Obviously there’s no resources associated with this group. Now adding resources to the Application security Group doesn’t modify the resources, doesn’t in and of itself change anything. It just allows us to create fewer network security group rules. So instead of having to create ten NSG rules for your ten web server VMs, you can put them all into the same group and then you just need to create the one rule.

So I’m here into the Application security group. We can see that there are no resources associated with this. So you’ll notice here within this there’s nothing here. There’s no way to other than the name of it and the location, there’s no configuration settings. All of the application security group settings are within both the Virtual Machine and then in the network security group. So let’s go back to our Virtual Machine VM three and under Networking, remember we already saw that it’s got the NSG rules because we’ve associated it to this Nic. But there’s this application security groups setting, and I can say configure application security group? And so I can assign the application security group that we created to this nick or make it associated.

Now again, doing this doesn’t affect the machine just yet because we don’t have any network security rules that choose this application security group as the destination. So we’ve added this, we can add it to more Application Security Group. That’s a checkbox metaphor so it doesn’t have to be only part of one if we do go back to the network security group. So the NSG into one of these security rules. Let’s say I want to delete this deny outbound rule and I want to restrict that only to the VM three. So delete that first. And now I’m going to add from the source I’m going to choose Application Security Group and I’m going to choose the ASG Application Security Group. And now I can say I want the destination to be a service tag Internet and all. And so deny. So now we’ve basically created this deny request specifically against this single virtual machine.