Azure Network Security Groups - Simply Explained

Welcome to another episode of Microsoft Knowledge Nuggets here on M365, FM, I'm Milko Peters your host. Today's topic is one almost everyone has heard of, but not everyone fully understands. As your network security groups, imagine you just moved into a new house. You have doors, windows and a garage, but you forgot to lock the front door. That's your Azure VM without an NSG. By the end of this episode, you'll understand what NSGs are, how their rules work and the common mistakes that leave your cloudhouse wide open. We'll walk through the problem first, then the solution, how the rules work, the gotchas and the best practices, all in plain English. So why do you even need an NSG? Let's dive into the problem. The problem. Why your Azure VMs need protection? Here's the thing that catches most beginners off guard. By default, an Azure VM with a public IP can receive traffic from the internet on any port, unless you tell it otherwise, which means spinning up a VM with a public IP is like standing at the curb, waving a sign that says, "Come on in, 20 years ago you'd lock a physical server behind a hardware firewall, but in Azure you have to lock down ports manually one by one." And most beginners skip that step, which is exactly how breaches happen. Microsoft built some default protections into the platform, attach an NSG to a resource and it comes with a few default rules. Allow all traffic within the virtual network, allow a zero load balancer health probes and deny everything else inbound from the internet. Those defaults are solid. They block inbound traffic from the outside world by default. But here's the real problem. Many people override these defaults or forget to attach an NSG altogether. They open port 3389 for RDP from any because they want to remote in from a coffee shop or they leave port 22 open for SSH because they'll lock it down later and later never comes. This happens more often than you think. Overly permissive inbound rules are the top cause of Azure security incidents and it's not a sophisticated zero day exploit or a platform floor. It's someone leaving the front door unlocked. That's exactly where network security groups come in. Think of them as your personal balancer at the door. What is an Azure network security group? Come to another episode of Microsoft Knowledge Nuggets here on M365 FM. I'm your host, Mirko Peters. Today we're breaking down Azure network security groups or NSGs for short and by the end of this episode you'll understand what they actually do and why they matter. So what exactly is an NSG? Here's the simplest definition. An NSG is a collection of rules that controls what traffic can flow in and out of your Azure resources. It works at layers three and four of the network model, which means it looks at IP addresses, ports and protocols without digging into the actual content of the traffic. It only checks the envelope, not what's inside. Think of it like a bouncer at a club. You walk up to the door with your IP address as your ID. The bouncer checks where you're coming from, then asks what you want to do and that's where the port number comes in. Are you here to dance on port 80 for web traffic? Or are you trying to cause trouble on port 3389 for remote desktop? Based on that check, the bouncer makes the call allow or deny. Now here's something that surprises most people. NSGs are stateful. What does that mean? If you allow inbound traffic on port 80, the reply traffic goes back out automatically. You don't need a separate outbound rule for the response because the NSG remembers that connection and lets the return traffic through. Compared to traditional firewalls where you'd write rules for both directions, that's a huge time saver. Where do NSGs actually live? You can apply them at two levels, the subnet level or directly to a VM's network interface card, which is the NIC. Subnet level is the recommended approach. One NSG per subnet protects every VM inside it, so it's cleaner and easier to manage without worrying about individual machines. You attach the NSG to the subnet and every VM in that subnet inherits those rules automatically. NIC level is for special cases where you have two VMs in the same subnet that need different rules. Say one is a web server that needs port 80 open and the other is a database server that should only talk to the web server. In that case, you'd apply an NSG directly to the database VM's NIC for extra restrictions on top of the subnet rules. Here's the best part. NSGs are completely free. No extra cost, no per rule fees, no association charges. That's why they're the first line of defense in Azure and there's really no excuse not to use them. Let's open the hood and see how the rules actually work. How NSG rules work? Priority allow, deny and defaults. Every NSG has two sets of rules, inbound and outbound and those rules get processed in a very specific order. Priority numbers start low for highest priority and go up, so a rule at priority 100 gets checked before a rule at priority 200. The first rule that matches the traffic wins. If it's an allow, the traffic passes through. If it's a deny, it gets blocked and no further rules are checked after that. So the order of your rules matters tremendously. Now every NSG comes with default rules baked in. You get three inbound rules. Allow vnet inbound. Let's traffic from inside your virtual network, talk to each other. Allow as your load balancer inbound. Let's the as your load balancer send health probes to your VMs and deny all inbound blocks everything else from the outside. On the outbound side you get allow net outbound, allow internet outbound and deny all outbound. These all sit at very high priorities. 65,000, 65,000, 1,6,500. You cannot delete these default rules because they're baked into the system, but you can override them with custom rules that have a higher priority meaning a lower number. So if you want to allow RDP traffic from the internet, you create a custom rule at priority 100 that allows port 3389 and because that rule gets checked before the default deny, the traffic passes through. The custom rule priority range goes from 100 to 4296 and here's a practical tip. Leave gaps between your priorities. Use 100, 200, 300 instead of 100 and 102. If you need to insert a new rule later, you can slide it in at 150 without re-numbering everything. It's a small habit that saves a lot of headache down the road. Each rule has several components, source and source port, define where the traffic is coming from, destination and destination port define where it's going. Protocol specifies TCP, UDP or any. Action is allow or deny. Priority determines where it sits in the evaluation order. And a name so you can identify what it does. Now one feature that makes NSG's really powerful is service tags. These are convenient labels that represent groups of IP addresses. Instead of trying to remember every IP range Azure uses for service, you just use the tag like internet, virtual network, Azure load balancer or storage. West US. Microsoft manages the IP ranges behind those tags, so you don't have to track changes. If Azure adds new IP addresses for service, the tag updates automatically. And then there are application security groups or ASGs for short. These let your group VMs logically instead of writing rules with individual IP addresses. You create an ASG called web servers, add those VMs to it and write one rule that says, allow traffic from web servers. If you add more web servers later, they just join the ASG and the existing rule already covers them with no updates needed. Great for scaling. That covers the theory, but here's where most people run into problems. Common misconfigurations and beginner mistakes. So here's the thing about network security groups. I see the same six mistakes all the time. And these aren't just small errors. The number one cause of Azure breaches isn't some advanced exploit. Simple misconfigurations. Let's break down the first one. Allowing traffic from any or internet to sensitive ports, RDP on port 3389 SSH on 22 SQL on 1,33. Someone spins up a virtual machine, once remote access, so they open port 3389 to the whole world, thinking they'll change it later. Attackers can find that VM in about 15 minutes instead always restrict source IPs to trusted ranges like your office IP or your VPN. Never the entire internet. Another common mistake is forgetting about outbound rules. The default outbound rule lets all internet traffic through. That means if a VM inside your network gets compromised, it can call home, download malware and X-Filtrate data. The NSG won't stop it because the default says allow outbound. For sensitive subnets, add outbound deny rules and only allow traffic to the specific destinations your application actually needs. Then there's the issue of applying NSGs at the NEC level when you should use the subnet level. This creates a management nightmare. You end up with 20 different NSGs, each with slightly different rules and nobody remembers which VM has which NSG stick to one NSG per subnet. Apply it once and every VM in that subnet is protected. Use NEC level NSGs sparingly for exceptions. Another mistake is not using application security groups or service tags. Hard coding IP addresses makes your rules brittle. If a VM moves to a different subnet or gets recreated, it's IP changes and your rule breaks. ASGs keep it flexible. Group VMs by function, write one rule against the ASG and you're done. Service tags do the same for Azure services, use them both. And don't forget to test with effective rules. The Azure portal has a feature called effective security rules that shows you the combined result of subnet and NEC NSGs. It's the single most useful troubleshooting tool for NSGs. Always check it before assuming traffic will flow. You'd be surprised how often that deny rule at the subnet level blocks traffic that the NIC rule allows. Finally, opening port ranges to wide. Instead of allowing port 3389 from any, allow it only from your office IP. Instead of opening ports 1 through 65535, open only the specific ports your application needs, the narrower the range, the smaller the attack surface. So how do you avoid these mistakes? Let's talk best practices. Best practices for NSG rule management. Here's the most important principle. Least privilege. Only allow what's needed nothing more. Start with a deny all posture and open specific ports to specific sources. Don't open everything and try to lock it down later. That never works. Another best practice is to use ASGs and service tags. Group your VMs by function. App servers in one ASG, application servers in another, database servers in a third, then write your NSG rules against those groups. The web ASG talks to the app ASG on port 443 and the app ASG talks to the database ASG on port 1433. When you add more web servers later, they join the web ASG and the rules already cover them. No need to update anything. And document your rules. Each rule should have a meaningful name and description. Allow RDP from office IP is a good name. Rule one is not. One else should be able to look at your NSG and understand why each rule exists. That someone might be used six months from now. Apply NSGs at the subnet level. One NSG per subnet. If you need per VM exceptions, combine a subnet NSG with a unique NSG, but always test the effective rules in the portal to see the combined result. Enable NSG flow logs. These capture traffic that's allowed or denied. Send them to a storage account or log analytics for monitoring and troubleshooting. One important note. New NSG flow log creation ends June 2025. After that, use virtual network flow logs instead. Regularly review your rules. Ordered for overly permissive or unused rules and removed them. Attackers love stale rules that someone forgot to clean up. And one more thing, don't apply NSGs to gateway subnets. If you have a subnet used for VPN or express route gateways, don't attach an NSG to it. It's unsupported and breaks connectivity. But wait, isn't Azure Firewall a thing? How does NSG compare? We'll cover that in another episode. NSG vs Azure Firewall went to use each. You might be wondering if NSGs are so great, why does Azure Firewall exist? And when should you pick one over the other? Imagine this, and NSG is the front door bouncer. It checks your ID, looks at what you want to do, and decides whether to let you in or keep you out. Azure Firewall is the full security team with cameras, metal detectors, and the whole package. Here's the thing. NSGs are free. They work at layers three and four, filtering based on IP addresses, ports, and protocols. Because they're distributed, you apply them per subnet or per ennick, which makes them perfect for basic filtering. If you just need to say, allow web traffic on port 80 from the internet or block RDP from outside. And NSG is all you need. Azure Firewall is a paid service at about 1.25 per hour plus data processing costs. It's centralized, so you deploy it once and route traffic through it. It works at layers three through seven, which means it can inspect packets deeply. Instead of allowing traffic to any IP on port 443, you can allow traffic to pomadeys, sunmicrosoft.com only because it filters by fully qualified domain names. It can also do TLS inspection, decrypting traffic to check what's inside, plus intrusion detection and prevention. And it uses threat intelligence feeds to block known malicious IPs and domains. So when do you use each one? For most beginners and small deployments, NSGs are sufficient. You have 102 v-nets, a handful of subnets, and you just need to control who can talk to what? And NSG handles that perfectly. As you grow, you add Azure Firewall when you have multiple v-nets that need to talk to each other, workloads that need controlled internet access. And you need centralized logging and auditing. That's when Azure Firewall makes sense. The real value comes from using both together. NSG at the subnet level handles basic segmentation, while Azure Firewall at the hub manages cross-finet and internet traffic inspection. That's defense in depth. The NSG handles the simple stuff and the firewall handles the complex stuff. Let's see all this in action with a quick walkthrough. Quick walkthrough, creating and applying an NSG. Let me walk you through creating an NSG in the Azure portal. It's straight forward and you'll have it done in under five minutes. Go to the Azure portal, search for network security groups and click Create. Choose your subscription, resource group, and the region where your v-net lives, then give it a descriptive name like NSG Web Subnet, not NSG1 or Test. You'll thank yourself later. Once it's created, go to Inbound Security Rules and click Add to create your first rule. For the source, select the internet service tag, which means traffic from anywhere on the internet. Leave the destination as any because this NSG applies to the whole subnet. For the service, select HTTP and HTTPS, which opens ports 80 and 4.43. Set the priority to 100, name it something like Allow HTTPS internet and click Add. Now add a second rule for RDP, but notice you're not going to open it to the internet. For the source, select IP addresses and enter your office IP or your home IP if you're remote. For the service, select RDP on port 3389, set the priority to 200, name it Allow RDP Office IP and click Add. Just associate this NSG with a subnet. Go to the Subnet tab, click Associate, select your virtual network and the subnet you want to protect. In this case, your web subnet and click OK. That's it. Every VM in that subnet is now protected by these rules. If you want to take it a step further, create an application security group called web servers, add your web VMs to it, then go back to your NSG rule and change the destination from any to that ASG. Now the rule only applies to those specific VMs, not the whole subnet. It's clean and flexible. Before you assume everything is working, check the effective security rules. Go to any VM in the subnet, click on Networking, then Effective Security Rules. You'll see the combined result of your subnet NSG and any NIC level NSGs. This is your single source of truth. If traffic isn't flowing, this is where you'll find out why. That's it. Simple, powerful and free. So there you have it. NSGs are your first line of defense in Azure. Think of them as a bouncer for your virtual machines. They control who gets in and who gets out. Stick with subnet level NSGs. Also the principle of least privilege, use ASGs and service tags and avoid those common mistakes we covered, especially opening sensitive ports to the whole internet. If this helped, subscribe for more Azure Knowledge Nuggets and share this episode with someone just starting their cloud journey. They'll thank you later. Don't leave your front door unlocked. Apply an NSG today.