Network Security Groups in Azure — The Fundamentals , Which Direction to Apply Rules, What would source and target ports be, Does return reply traffic need to be explicitly permitted(1/3) ?
Hello Folks! I was preparing for my Azure Architect certification and realised that there is lack of clarification/emphasis on the very basics of Azure NSGs(Network Security Groups) across so many courses available online.
This post covers some fundamentals, if you are looking for answers in title directly, you may jump to second one in the series:
1.Starting with basics,What are NSGs?
-NSGs(Network Security Groups) are used to filter network traffic to and from Azure resources, such as VMs.
-NSGs can be applied at NIC ie network interface card (of VM) or subnet level(not VNET).
It must be noted that NSG cannot be applied to the virtual network as a whole.
Can I have multiple Network Security Groups per NIC/subnet?
No,It is not possible to have multiple NSGs linked to a single object.
NSGs are broadly segregated into incoming(inbound) and outgoing(outbound) rules(each NSG has both of these as separate sections).
2. How are these rules evaluated:
An NSG usually contains multiple rules under INBOUND and OUTBOUND rules sections.
i.NSG security rules are evaluated by priority. Low rule number implies higher priority.
Rules are processed and evaluated top-down,first match wins ie once a match found, further processing stops.
ii.Rules are evaluated using the 5-tuple information of the traffic to match the defined rules fields— source IP, source port, destination IP, destination port and protocol.
================================
NOTE1: ‘Action’ can be ALLOW or DENY(Unlike AWS where only ALLOW exists).
This means that when a match is found (the 5 tuple information) for a packet(traffic) going in /going out of the subnet (or NIC) ; Azure should apply the said action and stop further processing.
NOTE2:
It must be noted that the above images for INBOUND/OUTBOUND rules under NSG (Azure portal) show only Source IP, Destination IP and ‘Destination’ Port.(when the portal does not explicitly mention ‘source’ or ‘destination’ port,it always reflects ‘destination’ port and omits showing ‘source’ port)
For all practical purposes, while analyzing traffic flow, one must think of all 4 entries- Source IP, Destination IP, Source Port and Destination Port, as reflected clearly while clicking on a rule:
Kind of dislike Microsoft for not clarifying this in the overall dialog which is a cause of 90 percent of confusions/oblivion(will cover WHY in Part 2).
====================================
Example/Illustration:
A web server with IP address 1.2.3.4 running Linux in Azure needs people on the internet to connect to it for configuring the VM. The connection is via SSH(port 22 on the VM is listening for incoming connections).
Would clients on the Internet be able to do SSH(Putty) if we have the following NSG in place ?
<Image shows INBOUND rules of NSG,OUTBOUND have been omitted>
Pause and zoom in on the image/right click to open in new tab and visualize the scenario.
Answer is NO.
The traffic coming into the VM would be evaluated by the INBOUND rules section.
We start looking from top going down, and the Rule 1000 matches the incoming traffic, ie sourced from Any IP, going to destination IP 1.2.3.4 ,sourced from any random port on the PC connecting to Azure,going to destination port 22(Azure VM listens for incoming connections on this port).
The action is a DENY so this INCOMING traffic is blocked.
Now,post a match being established,further processing of rules stops.
So,the second rule, inspite of matching the criteria for the INCOMING traffic and having ALLOW action, will not be processed (processing stops after a first match is found).
End result,clients on Internet cannot launch SSH session over port 22 to this Azure VM.
FYI, the non highlighted rules above are part of default built-in rules, which will be covered in my later post.
3.Another point: Think at 2 levels when analyzing overall traffic flow:
First decide whether we are talking about inbound traffic(into VM) or outbound traffic(going out from VM).
When talking about traffic going out of the VM to be ALLOWED, it must be ensured that there are no blocks(DENY) at the NIC level NSG as well as subnet level NSG.
Traffic first hits the NIC of the individual VM and then the subnet:
Similarly,for traffic coming into Azure VM to be ALLOWED, it must be ensured that there are no blocks(DENY) at the subnet NSG or NIC level NSG.
Traffic first hits the subnet and then the NIC of the individual VM:
4.This diagram is another thing to keep in mind:
This post is getting long,so I will stop here now.
This covers the NSG Fundamentals before moving on to the next section: Which Direction to Apply NSG , What would source and target ports be,Does return reply traffic need to be explicitly permitted.
Please note that due to default rules in every NSG, communication within a virtual network(VNET) is allowed by default ie subnet to subnet communication between 2 VMs does not need any special explicit NSG modification (unless custom rules to override default rules have been created) ;this has been clarified further in next section.
