Azure Network Security Groups - Simply Explained

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.