Secure access to a VNet - Azure Tutorial

A Network Security Group is like a virtual firewall. It establishes inbound and outbound traffic rules for VMs that sit on VNets. A network security group is either bound to a network interface, which the VM has at least one network interface so it can connect to the VNet or a network security group can be bound to a subnet. This feature will help us as we manage the security of the network. In this picture here, you can see that there's a network security group attached to this network interface that connects to this VM. And there's another network security group that's attached to the subnet itself. So you can have a network security group either to a NIC or to a subnet or to both. But realize if it's applied to both, then both sets of rules apply. I'll talk about how the rules work in a moment. But you can use this to your advantage if you're setting up, let's say, several web server VMs. Put them all on the same subnet and then apply the network security group to the subnet level. It could save you the trouble of having to set up individual inbound rules for VMs on the subnet. A best practice when you're setting up VMs in Azure is to create your VNets and subnets first that establishes your IP address space and also the subnets if you think through the design of what kind of workloads. Am I going to have database servers, web servers? What ports do I want open for web servers? So having that all laid out in your mind or on paper ahead of time is a great idea. Then create your network security groups, because you can go ahead and set up rules for subnets and network security groups. Then when it comes time to create your VMs, you can just place them on the VNet, assign the NSGs, if you need any individual NSGs, and then you're done. And then your network security is already established. So a network security group itself has several items associated with it. There's a priority which indicates the order in which the rules are evaluated. Rules are always evaluated in increasing priority order. When a rule in the NSG is matched, the search concludes and it doesn't look at any other rules and then the action is taken. And so the action is either allow or deny. There are some built in rules. They all start with priority 65,000 and above. You can't delete them, but you can just override them with a higher priority rule. Let me show you an NSG for a VM that I have in the portal. So here's vm1. You can find some good networking information on the blade here. Here's a summary of the network security group rules for inbound and outbound. But I can go look at details of the NSG itself here. So this particular NSG notice is bound to the network interface for vm1, and it's that IP address. Currently, this NSG is not bound to any subnets, but I could associate it with a subnet if I wanted to. I won't do that now, but I want to show you the rules and what they mean. So on the overview blade, we can see inbound and outbound rules. So inbound by default for network security group, there are these three rules. We allow traffic from other -- from any other IP address on the VNet. So allow VNet inbound. We also allow inbound traffic from a load balancer. If you have an Azure load balancer, in case this VM might be behind a load balancer. Notice everything else is denied. So by default, you can speak to other VMs on your VNet. The outbound security rules, you allow VNet outbound traffic. You allow Internet outbound. So if you're on the VM and you can open a web browser and connect out to the Internet, that works. Everything else is denied. So this would include VMs on other VNets, unless you set up some additional rules, which we'll discuss later. So this VM also has one additional rule that was added when I set up the VM that opened port 3389 source of any. Let's say I wanted this VM to also have port 443 open. If I want to add a rule, I go to the settings and on security rules and I add. Fill this out. My source can be anything or you can give a list of one or more IP addresses. You could also choose a service tag, which are types of Azure services or special things called application security groups, which we won't discuss in this lesson. Your source port range can be anything. You could specify an individual port. Typically, if someone is inbound, you don't know what their port is, and so asterisk makes sense here. Destination in this case, we'll just say any so we don't want to specify a specific IP. But we can choose something like HTTPS as the service which says, Oh well that's port 443 over TCP. So it pre-select my port and protocol, and then I would want my action to be allow. I need to assign a priority and I need to consider the rule that priorities are evaluated or rules are evaluated in priority order. So 310 sounds like a good idea. I'll change this to 443, just as a rule name and add that. And so now any web traffic over 443 would be allowed in or across this network security group and it's attached to my VM then it would be allowed into my VM. You can see how you'd want to carefully design the rules and the priorities for the rules and then try to group these as much as you can. So set up NSGs for different kinds of workloads and then apply them most likely to subnets, possibly to VMs if you need to make some special rules to override.