Hannes
Cloudtech rocks!

Follow

Cloudtech rocks!

Follow
be carefule when you configure your Azure network security groups

Photo by Mark Duffel on Unsplash

be carefule when you configure your Azure network security groups

In this post you will learn what's behind the service tag VirtualNetwork and how you should consider it in your NSG configuration.

Hannes's photo
Hannes
ยทSep 25, 2022ยท

3 min read

Table of contents

  • Default rules
  • Service Tag
  • Conclusion

Now here comes an old one, but maybe not everyone reading this article is aware. Configuring Azure network security groups can be a pain, when you don't know what the default rules of a NSG (network security group) really mean. That's why I wrote this article and wanted to explain to you what you should pay attention to.

Default rules

If you look at NSG you will find in total 6 different default rules. 3 inbound rules and 3 outbound rules. No matter what you do or what you configure these rules will always remain and you can neither disable nor remove them. Of course, you can overwrite them. Screenshot 2022-09-23 at 10.05.44 PM.png

AllowVnetInBound is the first rule in that list. For source as well as for destination we have the same so called Service Tag "VirtualNetwork". So you probably think now "Hey that's easy. That is my virtual networks address space" and you are right, however this is only partially correct. But first, lets clarify what a service tag actually is. In Microsofts documentation you will find the following definition:

Service Tag

A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules.

Means by choosing a service tag for a rule you are selecting a bunch of ip address spaces which are managed by Microsoft. You do not always need to explicitly know each IP address. But it definitely makes sense to know what's behind a service tag - and VirtualNetwork is one of them. So coming back to this there is a clear definition what is covered bei VirtualNetwork:

  • virtual network address space (all IP address ranges defined for the virtual network),
  • all connected on-premises address spaces,
  • peered virtual networks,
  • virtual networks connected to a virtual network gateway,
  • the virtual IP address of the host,
  • address prefixes used on user-defined routes.

You could read this list as follows: Every network which your virtual networks gateway knows is included. This can be quite much. Especially if you have configured a default route for 0.0.0.0/0 on a route table which is attached to your subnet. Screenshot 2022-09-25 at 7.22.28 PM.png

This would mean the service tag "VirtualNetwork" includes everything! You do not believe me? Let's check the Network Watcher... Screenshot 2022-09-25 at 7.26.14 PM.png

Conclusion

So having a default rule configured on a route table which is attached to your subnet is quite risky. Of course in an enterprise environment such routing rules are very common but if you have this configured you should be aware and include proper rules with a higher priority. For example just add a DenyAll rule with priority 4096, followed by your allow rules with higher priorities:

Screenshot 2022-09-25 at 8.16.41 PM.png

Caution: Remember to implement the "AllowAzureLoadBalancer" rule otherwise you can face unexpected behavior when accessing virtual machines.

Hope you liked this post. If you have any questions, drop me a comment, happy to answer!

ย 
Share this