In this lesson, you will understand the importance of network security groups and how these control methods protect your subnets and virtual machines in Azure.
- [Instructor] In Azure, we use network security groups, or NSGs, to secure our Azure virtual machines and subnets. A network security group, or NSG, is a list of security rules that are processed in sequential order that allow or deny inbound or outbound traffic. We can apply these network security groups to subnets or to a virtual machine NIC. But there are few things you need to be aware of with NSGs. First of all, access control lists, or ACLs, and NSGs cannot coexist.
If you have an ACL applied to a resource, you must remove it and then apply the network security group. You can use network security groups to separate traffic. For example, you may have a network security group applied to a secondary NIC of a virtual machine which would only allow remote management traffic through such as RDP. Are you sick and tired of hearing me say planning yet? Well as with everything else in Azure, network security groups have to be planned, and this is important here, because you're only allowed 100 network security groups per region, per subscription and only 200 rules per network security group.
Please do not apply a network security group to a VPN gateway or an ExpressRoute subnet. This will block the flow of traffic. Finally, we will use network security groups to filter traffic to and from our virtual machines. We do not use them on our load balancers. Default tags are predefined system tags in Azure, and we can use these in the network security group rule for the source and destination. In Azure, we have three default tags.
The first one is virtual network, and this could be a network that is connected to our on-premise environment or to other Azure virtual networks. We have the Azure load balancer tag. This allows the Azure health probes to verify the health of our instances. Finally, we have internet, and this is any traffic outside of our internal virtual networks. Let's go ahead and take a look at our network security group workflow as this will help us build our rules.
Our traffic will enter the Azure virtual network. The rules from the network security group will be loaded. Next, our first rule is processed. The traffic will be allowed or denied, and if this is the last rule in our network security group, all following packets will be denied. If this is not our last rule, then the next rule is processed. In Azure, network security groups are already applied to our subnets and virtual machines.
Let's go ahead and take a deeper look into the default inbound rules. Our first rule is allowing virtual network inbound traffic. We can see here that our source is virtual network, and the destination is virtual network using those default system tags. Our next line is allowing the Azure load balancer to probe the health of our virtual machines, and finally rule 65500 is denying all inbound traffic.
Next, we have our default outbound rules, and we'll quickly run through this list. First of all, we allow any traffic outbound from any of our virtual networks to any of our virtual networks. We will allow all internet outbound traffic, and we'll deny all other outbound traffic. Now that we have the basics down, let's go ahead and build out a few network security groups based on this classic example of a front-end and back-end infrastructure in Azure. First, we only want to accept traffic on port 80 to our front-end web servers.
Next, our back-end servers can only accept traffic from our front-end subnet on port 1433, and data cannot be sent out. This keeps our back-end isolated. Let's go ahead and build out the network security groups to put this plan into action. First, we'll start off with our front-end inbound rules. Our first rule is to allow in traffic from the internet that is going to port 80. Our next rule is we're allowing traffic from the internet that will be going to port 3389.
That would be our RDP traffic. Finally, we are denying all other traffic. Next, we have our front-end outbound rules. Here we're denying any traffic leaving that subnet that is destined for the internet. Let's go ahead and take a look at the back-end rules. Remember, we are only accepting traffic here for port 1433, so our first rule is we are denying everything. You may be wondering well wait a minute, what happened to port 1433? We'll get to that on the VM level, hold tight.
Then we have our back-end outbound rules. Here we're denying all traffic that is going out to the internet, so as you can see, our back-end now is completely isolated. Now let's focus in on the virtual machines themselves, and the rules that are applied to those virtual machines. Our first rule is allowing traffic for port 3389, RDP traffic, and this can come from the internet. We're also allowing traffic destined for port 80 to our web server.
So now we're allowing traffic to the actual VMs. Now let's go ahead and take a look at how this works on the back-end servers. Remember we are only allowing traffic from the front-end subnet on port 1433. Here we're going to allow traffic from our source address range of 192.168.2.0 and only for port 1433. As you can see, building out our network security groups ensures that those virtual machines and subnets are totally protected and only the traffic that should be going to that virtual machine is.
- Designing virtual machines
- Selecting appropriate VM SKUs
- Designing template deployment
- Deploying ARM templates via PowerShell and CLI
- Designing for availability
- Designing Azure Virtual Networks
- Azure VPN and ExpressRoute architecture and design