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

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more