1 00:00:00,000 --> 00:00:04,200 Welcome to another episode of Microsoft Knowledge Nuggets here on M365, FM, I'm Milko 2 00:00:04,200 --> 00:00:05,200 Peters your host. 3 00:00:05,200 --> 00:00:09,100 Today's topic is one almost everyone has heard of, but not everyone fully understands. 4 00:00:09,100 --> 00:00:12,000 As your network security groups, imagine you just moved into a new house. 5 00:00:12,000 --> 00:00:15,400 You have doors, windows and a garage, but you forgot to lock the front door. 6 00:00:15,400 --> 00:00:17,400 That's your Azure VM without an NSG. 7 00:00:17,400 --> 00:00:20,900 By the end of this episode, you'll understand what NSGs are, how their rules work and the 8 00:00:20,900 --> 00:00:23,900 common mistakes that leave your cloudhouse wide open. 9 00:00:23,900 --> 00:00:27,200 We'll walk through the problem first, then the solution, how the rules work, the gotchas 10 00:00:27,200 --> 00:00:29,400 and the best practices, all in plain English. 11 00:00:29,400 --> 00:00:31,000 So why do you even need an NSG? 12 00:00:31,000 --> 00:00:32,800 Let's dive into the problem. 13 00:00:32,800 --> 00:00:33,800 The problem. 14 00:00:33,800 --> 00:00:36,000 Why your Azure VMs need protection? 15 00:00:36,000 --> 00:00:38,800 Here's the thing that catches most beginners off guard. 16 00:00:38,800 --> 00:00:43,400 By default, an Azure VM with a public IP can receive traffic from the internet on any port, 17 00:00:43,400 --> 00:00:47,600 unless you tell it otherwise, which means spinning up a VM with a public IP is like standing 18 00:00:47,600 --> 00:00:51,800 at the curb, waving a sign that says, "Come on in, 20 years ago you'd lock a physical 19 00:00:51,800 --> 00:00:55,900 server behind a hardware firewall, but in Azure you have to lock down ports manually one 20 00:00:55,900 --> 00:01:00,500 by one." And most beginners skip that step, which is exactly how breaches happen. 21 00:01:00,500 --> 00:01:04,600 Microsoft built some default protections into the platform, attach an NSG to a resource 22 00:01:04,600 --> 00:01:06,700 and it comes with a few default rules. 23 00:01:06,700 --> 00:01:11,200 Allow all traffic within the virtual network, allow a zero load balancer health probes and 24 00:01:11,200 --> 00:01:13,700 deny everything else inbound from the internet. 25 00:01:13,700 --> 00:01:14,700 Those defaults are solid. 26 00:01:14,700 --> 00:01:17,860 They block inbound traffic from the outside world by default. 27 00:01:17,860 --> 00:01:19,140 But here's the real problem. 28 00:01:19,140 --> 00:01:22,700 Many people override these defaults or forget to attach an NSG altogether. 29 00:01:22,700 --> 00:01:27,740 They open port 3389 for RDP from any because they want to remote in from a coffee shop or 30 00:01:27,740 --> 00:01:32,340 they leave port 22 open for SSH because they'll lock it down later and later never comes. 31 00:01:32,340 --> 00:01:34,420 This happens more often than you think. 32 00:01:34,420 --> 00:01:38,540 Overly permissive inbound rules are the top cause of Azure security incidents and it's 33 00:01:38,540 --> 00:01:42,100 not a sophisticated zero day exploit or a platform floor. 34 00:01:42,100 --> 00:01:44,380 It's someone leaving the front door unlocked. 35 00:01:44,380 --> 00:01:46,540 That's exactly where network security groups come in. 36 00:01:46,540 --> 00:01:48,940 Think of them as your personal balancer at the door. 37 00:01:48,940 --> 00:01:51,420 What is an Azure network security group? 38 00:01:51,420 --> 00:01:54,900 Come to another episode of Microsoft Knowledge Nuggets here on M365 FM. 39 00:01:54,900 --> 00:01:56,380 I'm your host, Mirko Peters. 40 00:01:56,380 --> 00:02:00,500 Today we're breaking down Azure network security groups or NSGs for short and by the end of 41 00:02:00,500 --> 00:02:03,340 this episode you'll understand what they actually do and why they matter. 42 00:02:03,340 --> 00:02:04,660 So what exactly is an NSG? 43 00:02:04,660 --> 00:02:05,820 Here's the simplest definition. 44 00:02:05,820 --> 00:02:09,260 An NSG is a collection of rules that controls what traffic can flow in and out of your 45 00:02:09,260 --> 00:02:10,260 Azure resources. 46 00:02:10,260 --> 00:02:14,340 It works at layers three and four of the network model, which means it looks at IP addresses, 47 00:02:14,340 --> 00:02:17,620 ports and protocols without digging into the actual content of the traffic. 48 00:02:17,620 --> 00:02:19,980 It only checks the envelope, not what's inside. 49 00:02:19,980 --> 00:02:21,740 Think of it like a bouncer at a club. 50 00:02:21,740 --> 00:02:24,660 You walk up to the door with your IP address as your ID. 51 00:02:24,660 --> 00:02:28,180 The bouncer checks where you're coming from, then asks what you want to do and that's where 52 00:02:28,180 --> 00:02:29,180 the port number comes in. 53 00:02:29,180 --> 00:02:31,580 Are you here to dance on port 80 for web traffic? 54 00:02:31,580 --> 00:02:35,540 Or are you trying to cause trouble on port 3389 for remote desktop? 55 00:02:35,540 --> 00:02:39,260 Based on that check, the bouncer makes the call allow or deny. 56 00:02:39,260 --> 00:02:41,340 Now here's something that surprises most people. 57 00:02:41,340 --> 00:02:42,420 NSGs are stateful. 58 00:02:42,420 --> 00:02:43,420 What does that mean? 59 00:02:43,420 --> 00:02:48,380 If you allow inbound traffic on port 80, the reply traffic goes back out automatically. 60 00:02:48,380 --> 00:02:51,780 You don't need a separate outbound rule for the response because the NSG remembers that 61 00:02:51,780 --> 00:02:54,500 connection and lets the return traffic through. 62 00:02:54,500 --> 00:02:57,780 Compared to traditional firewalls where you'd write rules for both directions, that's 63 00:02:57,780 --> 00:02:58,780 a huge time saver. 64 00:02:58,780 --> 00:03:00,380 Where do NSGs actually live? 65 00:03:00,380 --> 00:03:04,500 You can apply them at two levels, the subnet level or directly to a VM's network interface 66 00:03:04,500 --> 00:03:06,660 card, which is the NIC. 67 00:03:06,660 --> 00:03:08,540 Subnet level is the recommended approach. 68 00:03:08,540 --> 00:03:12,700 One NSG per subnet protects every VM inside it, so it's cleaner and easier to manage without 69 00:03:12,700 --> 00:03:14,580 worrying about individual machines. 70 00:03:14,580 --> 00:03:17,940 You attach the NSG to the subnet and every VM in that subnet inherits those rules 71 00:03:17,940 --> 00:03:18,940 automatically. 72 00:03:18,940 --> 00:03:23,740 NIC level is for special cases where you have two VMs in the same subnet that need different 73 00:03:23,740 --> 00:03:24,740 rules. 74 00:03:24,740 --> 00:03:28,540 Say one is a web server that needs port 80 open and the other is a database server that 75 00:03:28,540 --> 00:03:30,220 should only talk to the web server. 76 00:03:30,220 --> 00:03:35,580 In that case, you'd apply an NSG directly to the database VM's NIC for extra restrictions 77 00:03:35,580 --> 00:03:36,940 on top of the subnet rules. 78 00:03:36,940 --> 00:03:37,940 Here's the best part. 79 00:03:37,940 --> 00:03:39,140 NSGs are completely free. 80 00:03:39,140 --> 00:03:42,100 No extra cost, no per rule fees, no association charges. 81 00:03:42,100 --> 00:03:45,220 That's why they're the first line of defense in Azure and there's really no excuse not 82 00:03:45,220 --> 00:03:46,220 to use them. 83 00:03:46,220 --> 00:03:48,740 Let's open the hood and see how the rules actually work. 84 00:03:48,740 --> 00:03:50,860 How NSG rules work? 85 00:03:50,860 --> 00:03:53,980 Priority allow, deny and defaults. 86 00:03:53,980 --> 00:03:58,740 Every NSG has two sets of rules, inbound and outbound and those rules get processed in 87 00:03:58,740 --> 00:04:00,740 a very specific order. 88 00:04:00,740 --> 00:04:04,860 Priority numbers start low for highest priority and go up, so a rule at priority 100 gets checked 89 00:04:04,860 --> 00:04:06,940 before a rule at priority 200. 90 00:04:06,940 --> 00:04:08,940 The first rule that matches the traffic wins. 91 00:04:08,940 --> 00:04:10,620 If it's an allow, the traffic passes through. 92 00:04:10,620 --> 00:04:14,220 If it's a deny, it gets blocked and no further rules are checked after that. 93 00:04:14,220 --> 00:04:16,340 So the order of your rules matters tremendously. 94 00:04:16,340 --> 00:04:18,780 Now every NSG comes with default rules baked in. 95 00:04:18,780 --> 00:04:20,220 You get three inbound rules. 96 00:04:20,220 --> 00:04:21,420 Allow vnet inbound. 97 00:04:21,420 --> 00:04:24,780 Let's traffic from inside your virtual network, talk to each other. 98 00:04:24,780 --> 00:04:26,660 Allow as your load balancer inbound. 99 00:04:26,660 --> 00:04:30,660 Let's the as your load balancer send health probes to your VMs and deny all inbound blocks 100 00:04:30,660 --> 00:04:32,100 everything else from the outside. 101 00:04:32,100 --> 00:04:36,060 On the outbound side you get allow net outbound, allow internet outbound and deny 102 00:04:36,060 --> 00:04:37,180 all outbound. 103 00:04:37,180 --> 00:04:39,100 These all sit at very high priorities. 104 00:04:39,100 --> 00:04:42,300 65,000, 65,000, 1,6,500. 105 00:04:42,300 --> 00:04:45,860 You cannot delete these default rules because they're baked into the system, but you can 106 00:04:45,860 --> 00:04:50,140 override them with custom rules that have a higher priority meaning a lower number. 107 00:04:50,140 --> 00:04:54,380 So if you want to allow RDP traffic from the internet, you create a custom rule at priority 108 00:04:54,380 --> 00:04:59,300 100 that allows port 3389 and because that rule gets checked before the default deny, 109 00:04:59,300 --> 00:05:00,980 the traffic passes through. 110 00:05:00,980 --> 00:05:05,500 The custom rule priority range goes from 100 to 4296 and here's a practical tip. 111 00:05:05,500 --> 00:05:07,140 Leave gaps between your priorities. 112 00:05:07,140 --> 00:05:11,780 Use 100, 200, 300 instead of 100 and 102. 113 00:05:11,780 --> 00:05:16,420 If you need to insert a new rule later, you can slide it in at 150 without re-numbering 114 00:05:16,420 --> 00:05:17,420 everything. 115 00:05:17,420 --> 00:05:19,940 It's a small habit that saves a lot of headache down the road. 116 00:05:19,940 --> 00:05:23,820 Each rule has several components, source and source port, define where the traffic is coming 117 00:05:23,820 --> 00:05:27,420 from, destination and destination port define where it's going. 118 00:05:27,420 --> 00:05:30,020 Protocol specifies TCP, UDP or any. 119 00:05:30,020 --> 00:05:31,820 Action is allow or deny. 120 00:05:31,820 --> 00:05:34,380 Priority determines where it sits in the evaluation order. 121 00:05:34,380 --> 00:05:36,060 And a name so you can identify what it does. 122 00:05:36,060 --> 00:05:39,740 Now one feature that makes NSG's really powerful is service tags. 123 00:05:39,740 --> 00:05:43,460 These are convenient labels that represent groups of IP addresses. 124 00:05:43,460 --> 00:05:47,900 Instead of trying to remember every IP range Azure uses for service, you just use the tag 125 00:05:47,900 --> 00:05:51,860 like internet, virtual network, Azure load balancer or storage. 126 00:05:51,860 --> 00:05:52,860 West US. 127 00:05:52,860 --> 00:05:56,980 Microsoft manages the IP ranges behind those tags, so you don't have to track changes. 128 00:05:56,980 --> 00:06:00,900 If Azure adds new IP addresses for service, the tag updates automatically. 129 00:06:00,900 --> 00:06:04,460 And then there are application security groups or ASGs for short. 130 00:06:04,460 --> 00:06:08,740 These let your group VMs logically instead of writing rules with individual IP addresses. 131 00:06:08,740 --> 00:06:13,700 You create an ASG called web servers, add those VMs to it and write one rule that says, 132 00:06:13,700 --> 00:06:15,900 allow traffic from web servers. 133 00:06:15,900 --> 00:06:20,220 If you add more web servers later, they just join the ASG and the existing rule already covers 134 00:06:20,220 --> 00:06:21,940 them with no updates needed. 135 00:06:21,940 --> 00:06:23,780 Great for scaling. 136 00:06:23,780 --> 00:06:27,420 That covers the theory, but here's where most people run into problems. 137 00:06:27,420 --> 00:06:29,500 Common misconfigurations and beginner mistakes. 138 00:06:29,500 --> 00:06:31,340 So here's the thing about network security groups. 139 00:06:31,340 --> 00:06:33,460 I see the same six mistakes all the time. 140 00:06:33,460 --> 00:06:35,020 And these aren't just small errors. 141 00:06:35,020 --> 00:06:38,060 The number one cause of Azure breaches isn't some advanced exploit. 142 00:06:38,060 --> 00:06:40,540 Simple misconfigurations. 143 00:06:40,540 --> 00:06:41,940 Let's break down the first one. 144 00:06:41,940 --> 00:06:47,860 Allowing traffic from any or internet to sensitive ports, RDP on port 3389 SSH on 22 SQL 145 00:06:47,860 --> 00:06:49,380 on 1,33. 146 00:06:49,380 --> 00:06:54,540 Someone spins up a virtual machine, once remote access, so they open port 3389 to the whole 147 00:06:54,540 --> 00:06:56,900 world, thinking they'll change it later. 148 00:06:56,900 --> 00:07:00,420 Attackers can find that VM in about 15 minutes instead always restrict source IPs to 149 00:07:00,420 --> 00:07:03,140 trusted ranges like your office IP or your VPN. 150 00:07:03,140 --> 00:07:04,500 Never the entire internet. 151 00:07:04,500 --> 00:07:06,900 Another common mistake is forgetting about outbound rules. 152 00:07:06,900 --> 00:07:09,780 The default outbound rule lets all internet traffic through. 153 00:07:09,780 --> 00:07:14,420 That means if a VM inside your network gets compromised, it can call home, download malware 154 00:07:14,420 --> 00:07:15,780 and X-Filtrate data. 155 00:07:15,780 --> 00:07:19,340 The NSG won't stop it because the default says allow outbound. 156 00:07:19,340 --> 00:07:22,860 For sensitive subnets, add outbound deny rules and only allow traffic to the specific 157 00:07:22,860 --> 00:07:24,980 destinations your application actually needs. 158 00:07:24,980 --> 00:07:29,260 Then there's the issue of applying NSGs at the NEC level when you should use the subnet 159 00:07:29,260 --> 00:07:30,260 level. 160 00:07:30,260 --> 00:07:31,260 This creates a management nightmare. 161 00:07:31,260 --> 00:07:35,020 You end up with 20 different NSGs, each with slightly different rules and nobody remembers 162 00:07:35,020 --> 00:07:38,140 which VM has which NSG stick to one NSG per subnet. 163 00:07:38,140 --> 00:07:40,940 Apply it once and every VM in that subnet is protected. 164 00:07:40,940 --> 00:07:43,780 Use NEC level NSGs sparingly for exceptions. 165 00:07:43,780 --> 00:07:47,420 Another mistake is not using application security groups or service tags. 166 00:07:47,420 --> 00:07:49,540 Hard coding IP addresses makes your rules brittle. 167 00:07:49,540 --> 00:07:53,500 If a VM moves to a different subnet or gets recreated, it's IP changes and your rule 168 00:07:53,500 --> 00:07:54,500 breaks. 169 00:07:54,500 --> 00:07:55,940 ASGs keep it flexible. 170 00:07:55,940 --> 00:08:00,180 Group VMs by function, write one rule against the ASG and you're done. 171 00:08:00,180 --> 00:08:02,860 Service tags do the same for Azure services, use them both. 172 00:08:02,860 --> 00:08:04,980 And don't forget to test with effective rules. 173 00:08:04,980 --> 00:08:08,860 The Azure portal has a feature called effective security rules that shows you the combined 174 00:08:08,860 --> 00:08:11,380 result of subnet and NEC NSGs. 175 00:08:11,380 --> 00:08:14,420 It's the single most useful troubleshooting tool for NSGs. 176 00:08:14,420 --> 00:08:16,460 Always check it before assuming traffic will flow. 177 00:08:16,460 --> 00:08:20,260 You'd be surprised how often that deny rule at the subnet level blocks traffic that 178 00:08:20,260 --> 00:08:21,900 the NIC rule allows. 179 00:08:21,900 --> 00:08:24,540 Finally, opening port ranges to wide. 180 00:08:24,540 --> 00:08:30,140 Instead of allowing port 3389 from any, allow it only from your office IP. 181 00:08:30,140 --> 00:08:35,900 Instead of opening ports 1 through 65535, open only the specific ports your application needs, 182 00:08:35,900 --> 00:08:38,020 the narrower the range, the smaller the attack surface. 183 00:08:38,020 --> 00:08:39,500 So how do you avoid these mistakes? 184 00:08:39,500 --> 00:08:41,500 Let's talk best practices. 185 00:08:41,500 --> 00:08:43,620 Best practices for NSG rule management. 186 00:08:43,620 --> 00:08:45,620 Here's the most important principle. 187 00:08:45,620 --> 00:08:46,620 Least privilege. 188 00:08:46,620 --> 00:08:48,340 Only allow what's needed nothing more. 189 00:08:48,340 --> 00:08:51,980 Start with a deny all posture and open specific ports to specific sources. 190 00:08:51,980 --> 00:08:54,260 Don't open everything and try to lock it down later. 191 00:08:54,260 --> 00:08:55,420 That never works. 192 00:08:55,420 --> 00:08:58,220 Another best practice is to use ASGs and service tags. 193 00:08:58,220 --> 00:08:59,580 Group your VMs by function. 194 00:08:59,580 --> 00:09:04,460 App servers in one ASG, application servers in another, database servers in a third, then 195 00:09:04,460 --> 00:09:06,500 write your NSG rules against those groups. 196 00:09:06,500 --> 00:09:12,140 The web ASG talks to the app ASG on port 443 and the app ASG talks to the database ASG 197 00:09:12,140 --> 00:09:13,740 on port 1433. 198 00:09:13,740 --> 00:09:18,460 When you add more web servers later, they join the web ASG and the rules already cover them. 199 00:09:18,460 --> 00:09:19,980 No need to update anything. 200 00:09:19,980 --> 00:09:21,140 And document your rules. 201 00:09:21,140 --> 00:09:24,100 Each rule should have a meaningful name and description. 202 00:09:24,100 --> 00:09:26,220 Allow RDP from office IP is a good name. 203 00:09:26,220 --> 00:09:27,340 Rule one is not. 204 00:09:27,340 --> 00:09:31,340 One else should be able to look at your NSG and understand why each rule exists. 205 00:09:31,340 --> 00:09:32,980 That someone might be used six months from now. 206 00:09:32,980 --> 00:09:34,620 Apply NSGs at the subnet level. 207 00:09:34,620 --> 00:09:35,620 One NSG per subnet. 208 00:09:35,620 --> 00:09:40,500 If you need per VM exceptions, combine a subnet NSG with a unique NSG, but always test the 209 00:09:40,500 --> 00:09:43,660 effective rules in the portal to see the combined result. 210 00:09:43,660 --> 00:09:45,020 Enable NSG flow logs. 211 00:09:45,020 --> 00:09:46,980 These capture traffic that's allowed or denied. 212 00:09:46,980 --> 00:09:51,420 Send them to a storage account or log analytics for monitoring and troubleshooting. 213 00:09:51,420 --> 00:09:52,420 One important note. 214 00:09:52,420 --> 00:09:55,140 New NSG flow log creation ends June 2025. 215 00:09:55,140 --> 00:09:58,060 After that, use virtual network flow logs instead. 216 00:09:58,060 --> 00:09:59,420 Regularly review your rules. 217 00:09:59,420 --> 00:10:03,260 Ordered for overly permissive or unused rules and removed them. 218 00:10:03,260 --> 00:10:06,220 Attackers love stale rules that someone forgot to clean up. 219 00:10:06,220 --> 00:10:08,860 And one more thing, don't apply NSGs to gateway subnets. 220 00:10:08,860 --> 00:10:13,900 If you have a subnet used for VPN or express route gateways, don't attach an NSG to it. 221 00:10:13,900 --> 00:10:16,100 It's unsupported and breaks connectivity. 222 00:10:16,100 --> 00:10:18,660 But wait, isn't Azure Firewall a thing? 223 00:10:18,660 --> 00:10:19,660 How does NSG compare? 224 00:10:19,660 --> 00:10:21,620 We'll cover that in another episode. 225 00:10:21,620 --> 00:10:24,980 NSG vs Azure Firewall went to use each. 226 00:10:24,980 --> 00:10:28,940 You might be wondering if NSGs are so great, why does Azure Firewall exist? 227 00:10:28,940 --> 00:10:30,420 And when should you pick one over the other? 228 00:10:30,420 --> 00:10:32,860 Imagine this, and NSG is the front door bouncer. 229 00:10:32,860 --> 00:10:36,780 It checks your ID, looks at what you want to do, and decides whether to let you in or keep 230 00:10:36,780 --> 00:10:37,780 you out. 231 00:10:37,780 --> 00:10:42,300 Azure Firewall is the full security team with cameras, metal detectors, and the whole package. 232 00:10:42,300 --> 00:10:43,300 Here's the thing. 233 00:10:43,300 --> 00:10:44,300 NSGs are free. 234 00:10:44,300 --> 00:10:49,220 They work at layers three and four, filtering based on IP addresses, ports, and protocols. 235 00:10:49,220 --> 00:10:52,500 Because they're distributed, you apply them per subnet or per ennick, which makes them 236 00:10:52,500 --> 00:10:54,220 perfect for basic filtering. 237 00:10:54,220 --> 00:10:58,580 If you just need to say, allow web traffic on port 80 from the internet or block RDP from 238 00:10:58,580 --> 00:10:59,580 outside. 239 00:10:59,580 --> 00:11:00,900 And NSG is all you need. 240 00:11:00,900 --> 00:11:06,220 Azure Firewall is a paid service at about 1.25 per hour plus data processing costs. 241 00:11:06,220 --> 00:11:09,060 It's centralized, so you deploy it once and route traffic through it. 242 00:11:09,060 --> 00:11:13,540 It works at layers three through seven, which means it can inspect packets deeply. 243 00:11:13,540 --> 00:11:17,940 Instead of allowing traffic to any IP on port 443, you can allow traffic to pomadeys, 244 00:11:17,940 --> 00:11:21,980 sunmicrosoft.com only because it filters by fully qualified domain names. 245 00:11:21,980 --> 00:11:27,380 It can also do TLS inspection, decrypting traffic to check what's inside, plus intrusion detection 246 00:11:27,380 --> 00:11:28,460 and prevention. 247 00:11:28,460 --> 00:11:32,700 And it uses threat intelligence feeds to block known malicious IPs and domains. 248 00:11:32,700 --> 00:11:34,140 So when do you use each one? 249 00:11:34,140 --> 00:11:37,220 For most beginners and small deployments, NSGs are sufficient. 250 00:11:37,220 --> 00:11:40,820 You have 102 v-nets, a handful of subnets, and you just need to control who can talk to 251 00:11:40,820 --> 00:11:41,820 what? 252 00:11:41,820 --> 00:11:42,820 And NSG handles that perfectly. 253 00:11:42,820 --> 00:11:47,060 As you grow, you add Azure Firewall when you have multiple v-nets that need to talk 254 00:11:47,060 --> 00:11:50,620 to each other, workloads that need controlled internet access. 255 00:11:50,620 --> 00:11:53,020 And you need centralized logging and auditing. 256 00:11:53,020 --> 00:11:54,500 That's when Azure Firewall makes sense. 257 00:11:54,500 --> 00:11:56,700 The real value comes from using both together. 258 00:11:56,700 --> 00:12:00,940 NSG at the subnet level handles basic segmentation, while Azure Firewall at the hub manages 259 00:12:00,940 --> 00:12:03,100 cross-finet and internet traffic inspection. 260 00:12:03,100 --> 00:12:04,100 That's defense in depth. 261 00:12:04,100 --> 00:12:08,460 The NSG handles the simple stuff and the firewall handles the complex stuff. 262 00:12:08,460 --> 00:12:11,300 Let's see all this in action with a quick walkthrough. 263 00:12:11,300 --> 00:12:13,900 Quick walkthrough, creating and applying an NSG. 264 00:12:13,900 --> 00:12:16,340 Let me walk you through creating an NSG in the Azure portal. 265 00:12:16,340 --> 00:12:19,260 It's straight forward and you'll have it done in under five minutes. 266 00:12:19,260 --> 00:12:23,820 Go to the Azure portal, search for network security groups and click Create. 267 00:12:23,820 --> 00:12:27,500 Choose your subscription, resource group, and the region where your v-net lives, then give 268 00:12:27,500 --> 00:12:32,420 it a descriptive name like NSG Web Subnet, not NSG1 or Test. 269 00:12:32,420 --> 00:12:34,820 You'll thank yourself later. 270 00:12:34,820 --> 00:12:39,460 Once it's created, go to Inbound Security Rules and click Add to create your first rule. 271 00:12:39,460 --> 00:12:43,740 For the source, select the internet service tag, which means traffic from anywhere on the 272 00:12:43,740 --> 00:12:44,740 internet. 273 00:12:44,740 --> 00:12:48,380 Leave the destination as any because this NSG applies to the whole subnet. 274 00:12:48,380 --> 00:12:53,860 For the service, select HTTP and HTTPS, which opens ports 80 and 4.43. 275 00:12:53,860 --> 00:13:00,180 Set the priority to 100, name it something like Allow HTTPS internet and click Add. 276 00:13:00,180 --> 00:13:04,740 Now add a second rule for RDP, but notice you're not going to open it to the internet. 277 00:13:04,740 --> 00:13:09,420 For the source, select IP addresses and enter your office IP or your home IP if you're 278 00:13:09,420 --> 00:13:10,420 remote. 279 00:13:10,420 --> 00:13:15,780 For the service, select RDP on port 3389, set the priority to 200, name it Allow RDP Office 280 00:13:15,780 --> 00:13:17,300 IP and click Add. 281 00:13:17,300 --> 00:13:19,300 Just associate this NSG with a subnet. 282 00:13:19,300 --> 00:13:23,540 Go to the Subnet tab, click Associate, select your virtual network and the subnet you want 283 00:13:23,540 --> 00:13:24,540 to protect. 284 00:13:24,540 --> 00:13:26,980 In this case, your web subnet and click OK. 285 00:13:26,980 --> 00:13:27,980 That's it. 286 00:13:27,980 --> 00:13:30,500 Every VM in that subnet is now protected by these rules. 287 00:13:30,500 --> 00:13:33,740 If you want to take it a step further, create an application security group called web 288 00:13:33,740 --> 00:13:38,380 servers, add your web VMs to it, then go back to your NSG rule and change the destination 289 00:13:38,380 --> 00:13:40,500 from any to that ASG. 290 00:13:40,500 --> 00:13:43,780 Now the rule only applies to those specific VMs, not the whole subnet. 291 00:13:43,780 --> 00:13:45,220 It's clean and flexible. 292 00:13:45,220 --> 00:13:48,500 Before you assume everything is working, check the effective security rules. 293 00:13:48,500 --> 00:13:52,100 Go to any VM in the subnet, click on Networking, then Effective Security Rules. 294 00:13:52,100 --> 00:13:56,180 You'll see the combined result of your subnet NSG and any NIC level NSGs. 295 00:13:56,180 --> 00:13:57,580 This is your single source of truth. 296 00:13:57,580 --> 00:14:00,220 If traffic isn't flowing, this is where you'll find out why. 297 00:14:00,220 --> 00:14:01,220 That's it. 298 00:14:01,220 --> 00:14:02,980 Simple, powerful and free. 299 00:14:02,980 --> 00:14:03,980 So there you have it. 300 00:14:03,980 --> 00:14:06,620 NSGs are your first line of defense in Azure. 301 00:14:06,620 --> 00:14:08,780 Think of them as a bouncer for your virtual machines. 302 00:14:08,780 --> 00:14:10,740 They control who gets in and who gets out. 303 00:14:10,740 --> 00:14:12,460 Stick with subnet level NSGs. 304 00:14:12,460 --> 00:14:16,660 Also the principle of least privilege, use ASGs and service tags and avoid those common 305 00:14:16,660 --> 00:14:20,940 mistakes we covered, especially opening sensitive ports to the whole internet. 306 00:14:20,940 --> 00:14:24,740 If this helped, subscribe for more Azure Knowledge Nuggets and share this episode with someone 307 00:14:24,740 --> 00:14:26,140 just starting their cloud journey. 308 00:14:26,140 --> 00:14:27,340 They'll thank you later. 309 00:14:27,340 --> 00:14:29,060 Don't leave your front door unlocked. 310 00:14:29,060 --> 00:14:30,220 Apply an NSG today.