Network Security (Part 1 of 3)

By Ashwin Venugopal -

 



To read part 2 please click here
To read part 3 please click here

Network Security Groups (NSGs)

Network traffic can be filtered to and from Azure resources in an Azure virtual network with the help of a network security group while also providing an advanced security for the VMs you create via deployment model (Resource Manager or classic) and controls inbound and outbound traffic passing through a network adapter (in the Resource Manager deployment model), a VM (in the classic deployment model), or a subnet (in both deployment models).

Network Security Group Rules

NSGs contains rules that specify whether the traffic will be approved or denied. each rule consists of the following properties:

  • Name- This is a unique identifier for the rule.
  • Direction- This specifies whether the traffic is inbound or outbound.
  • Priority- If multiple rules match the traffic, rules with a higher priority apply.
  • Access- This specifies whether the traffic is allowed or denied.
  • Source IP address prefix- This prefix identifies where the traffic originated from.
  • Source port range- This specifies source ports by using either a single port number from 1 through 65,535; a range of ports (for example, 200-400), or the asterisk (*) to denote all possible ports.
  • Destination IP address prefix- This identifies the traffic destination based on a single IP address, a range of IP addresses in CIDR notation, or the asterisk (*) to match all the possible IP addresses.
  • Destination port range- This specifies destination ports by using either a single port number from 1 through 65,535, a range  of ports (for example, 200-400), or the asterisk (*) to denote all possible ports.
  • Protocol- This specifies the protocol that matches the rule. It can be UDP, TCP, or the asterisk (*).  

Custom Network Security group Rules

Predefined default rules exist for both inbound and outbound traffic and the default rules allows all inbound and outbound traffic within a virtual network, in which outbound traffic is allowed towards the internet, whereas inbound traffic to an Azure load balancer. 
Whenever you create a custom rule, you can use default tags in the source and destination IP address prefixes to specify predefined categories of IP addresses. These default tags are:

  • Internet- This tag represents internet IP addresses.
  • Virtual network- This tag identifies all the IP addresses that the IP range for the virtual network defines.
  • Azure_loadbalancer- This tag specifies the default Azure load balancer destination.

Planning Network Security Groups

You can conveniently design NSGs to isolate virtual networks in security zones, like the model used by on-premises infrastructure does and apply NSGs to subnets, which allows you to create protected screened subnets, or DMZs, that can restrict traffic flow to all machines residing within that subnet. 

You can also create NSGs as resources in a resource group, but you can share them with other resource groups in your subscription.

NSG Implementation

When implementing NSGs, keep these important limits in mind:

  • By default, you can create 100 NSGs per region per subscription and can raise this limit to 400 by contacting Azure support.
  • You can apply only one NSG to a VM, subnet, or network adapter.
  • By default, you can have up to 200 rules in as single NSG and can easily raise this limit to 500 by contacting Azure support.
  • You can apply an NSG to multiple resources.
An individual subnet and a network interface both can have zero, or one associated NSG, so that you can effectively have dual traffic restriction for a virtual machine by associating an NSG first to a subnet, and then another NSG to the VMs network interface. The application of NSG rules in this case depends on the direction of the traffic and priority of the applied security rules.
to help secure and protect your Azure resources, you have to make sure that NSG planning is Standard Operating Procedure (SOP) for your deployments.

Inbound Traffic

For inbound traffic, Azure processes the rules in a network security group associated to a subnet first, and then the rules in a network security group associated to the network interface, if there is one respectively.
  • VM1- The security rules in NSG1 are processed, since it is associated to Subnet1 and VIM1 is in Subnet1; unless you have created a rule that allows port 80 inbound, the traffic is denied by the Deny-AllInbound default security rule, and never evaluated by NSG2, since it is associated to the network interface.
  • VM2- The rules in NSG1 are processed because VM2 ia also in Subnet1. The traffic is either allowed or denied to all resources in the same subnet when a network security group is associated to subnet.
  • VM3- Since there is no NSG associated to Subnet2, all traffic is allowed into the subnet and processed by NSG 2, because NSG2 is associated to the network interface attached to VM3.
  • VM4- Traffic is allowed to VM4, because an NSG isn't associated to Subnet3, or the network interface in the virtual machine.

    Outbound traffic

for outbound traffic, Azure processes the rules in an NSG associated to a network interface first, and then the rules in an NSG associated to the subnet, if there is one repectively.

  • VM1- The security rules in NSG2 are processed, unless you have already created a security rule that denies port 80 outbound to the internet and the traffic is allowed by the AllowInternetOutbound default security rule in the both NSG1 and NSG2.
  • VM2- All traffic is sent through the network interface to the subnet, since the network interface attached to VM2 does not have an NSG associated to it. The rules in NSG1 are processed.
  • VM3- If NSG2 has a security rule that denies port 80, then the traffic is denied, but if it has a security rule that allows port 80, then the port 80 is allowed outbound to the internet, since an NSG is not associated to Subnet2
  • VM4- All the network traffic is allowed from VM4, because an NSG isn't associated to the network interface attached to the virtual machine, or to Subnet3.   

Intra-Subnet Traffic

It is important to specify that the security rules in an NSG associated to a subnet can affect the connectivity between the VMs within it. For example, if a rule ia added to NSG1 which denies all inbound and outbound traffic, then VM1 and VM2 will no longer be able to communicate with each other. Another rule would have to be added specifically to allow this.

General Guidelines

It is recommended to associate an NSG to a subnet, or a network interface, but not both. As rules in an NSG associated to a subnet can conflict with the rules in an NSG associated to a network interface, you can have unexpected communication problems that will require troubleshooting.    



To read part 2 please click here
To read part 3 please click here






Comments

Post a Comment

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

By Ashwin Venugopal -
Image
  Azure Sentinel Workbooks Several ready for use templates are provided by the Azure Sentinel that can be used to create your own workbook and then modify them as needed for Contoso. Most of the data connectors it uses to ingest data come with their own workbooks, but better insight can be obtained by simply looking into the data that is being ingested by using tables and visualizations, including bar and pie charts. You can also make your own workbook easily by using this data from the beginning instead of using the predefined templates. Workbook Page You can easily access the workbook page from the Azure Sentinel from the navigation pane which consists of the: Workbook header- You can add a new workbook and review the saved workbooks as well as templates that are available on the workbook page. Templates section- You can access existing workbook templates on the Templates tab. You can save some of the workbooks for quick access and they will appear on the My Workbooks tab.  From the
Read more

Planning for Implementing SAP Solutions on Azure (Part 2 of 5)

By Ashwin Venugopal -
Image
  To read part 1 please click  here To read part 3 please click  here To read part 4 please click  here To read part 5 please click  here Load Balancing The load balancer uses probe ports to determine as well as route the traffic to an active DBMS node, but of there's any failover then the most common SAP application architecture can automatically reconnect against the private virtual IP address without the need for the SAP application to reconfigure it, while the load balancer redirect the traffic against the private virtual IP address without any need for the SAP application to reconfigure. The loaf balancer also offers an option of DirectServerReturn which if configured, can help in directing the traffic from the DBMS VM to the SAP application layer directly to the application layer without routing through the load balancer. But, if it isn't configured, then the return traffic to the SAP application layer is routed through the load balancer. You can also use Azure Load Balan
Read more

Work with String Data Using KQL Statements

By Ashwin Venugopal -
Image
  Extract Data from Unstructured String Fields Unstructured string fields often contains the Security log data and requires parsing to extract data. There are multiple ways of pulling information from string fields in KQL and the two primary operators used are extract and parse.  Extract It gets a match for a regular expression from a text string. You can convert the extracted substring to the indicated type.  Arguments regex- A regular expression. captureGroup- A positive int constant indicating the capture group to extract. 0 stands for the entire match, 1 for the value matched by the first '('parenthesis')' in the regular expression, 2 or more for subsequent parenthesis.  text- A string to search. typeLiteral- An optional type literal. If provided, the extracted substring is converted to this type.  Returns If regex finds a match in text- the substring matched against the indicated capture group captureGroup, optionally converted to typeLiteral. If there's no mat
Read more