In this post we will go over creating VNETs and subnets using PowerShell, we will also be create a script to use a CSV to deploy multiple VNETs / subnets.

Azure PowerShell is a command-line tool that allows you to manage and deploy Azure resources using the PowerShell scripting language.

Azure VNETs provide a secure and isolated network environment within Azure. Subnets allow you to divide a VNET into smaller, logical segments to control network traffic and provide network segregation.

To deploy Azure VNET and subnets using Azure PowerShell, we first either need to create a resource group or use a pre existing one.

We can create a resource group using Az PowerShell

First connect to Azure PowerShell using

Connect-AzAccount

Once connected if there is multiple subscription make sure to select the correct one before creating the resource group or any other resource.

Next we will create the resource group this requires a name and a location.

New-AzResourceGroup -Name 'resource group name' -Location northeurope

Next we can create a VNET and subnet will be using splatting to specifying the parameters.

$vnet = @{
  Name              = 'vnet name'
  ResourceGroupName = 'resource group'
  Location          = 'northeurope'
  AddressPrefix     = '172.17.0.0/22'
}
New-AzVirtualNetwork @vnet

Once we have a VNET created we can create the subnets.

$vnet = Get-AzVirtualNetwork -Name "vnet name" -ResourceGroupName "resource group name"
$subnet = @{
  Name           = 'subnet name'
  VirtualNetwork = $vnet
  AddressPrefix  = '172.17.1.0/24'
}
Add-AzVirtualNetworkSubnetConfig @subnet

If we check the subnet wont be showing under the VNET.

The last step is to set virtual network config using

 $vnet | Set-AzVirtualNetwork

Now if we check the subnets we can see the subnet.

Now that we have the command we can use these to create the script to run using a CSV.

First create the CSV file for the script I used the below headings.

Below is the full script I added some error handling incase the VNET doesn’t exist or the subnet has an error when being created.

Below is the scripts running to create two new subnets.

If we check Azure VNET we can see the new subnets.

Below shows the error handling

Azure NSG flow logs are a feature of Azure Network Security Group (NSG) that allows administrators to track and monitor network traffic flowing through their Azure virtual network.

The flow logs provide detailed information on the source and destination of the traffic, as well as the protocol and port being used. This information can be used to identify trends and patterns in network usage, as well as to detect and troubleshoot potential security threats.

Azure NSG flow logs provide a valuable tool for administrators to maintain visibility and control over their Azure network environment.

To set the NSG flow logs to be sent to Log workspace we can use Traffic Analytics.

In this post we will be going through enabling NSG Flow Logs, enabling Traffic Analytics and reviewing the logs for allowed and denied traffic using Azure Log Analytics Workspace.

There will be a cost for using the Azure Storage, workspace and Traffic Analytics so confirm these before proceeding as the more data sent the more it will cost.

When creating a new deployment in Azure it is good security practice to restrict access between subnets to the required ports only. This can sometimes be a bit difficulty if the application communication is not fully documented.

This is where NSG Flow can be used as we can use this to review the traffic between the subnets going over the NSG’s. There are some prerequisite for this

• Storage account in the same region as the NSG
• Log Analytic workspace
• Network Watcher (this should be created automatically once a vNet is created)
• Network Security group
• VM running in two network and have an NSG assigned

Once all the above are ready we can start to enabled the logging. NSG flow can be either enabled from NSG directly or through Network Watcher. We will be doing this in Network Watcher.

First step is to go to Network Watcher > NSG Flow

Select the required Subscription, the required NSG’s, storage account and retention (0 on retention means the logs are kept forever) since this is a test environment I will only keep the logs for 5 days.

On configuration select version 2 and enabled traffic analytics. On traffic analytics set the process interval to either 1 hour or 10 mins, select the subscription and workspace.

Apply tags if in use, then review and create.

The deployment should only take a minute or so and then the NSG flow should show as succeeded.

Once enabled it can take little bit for data to start showing. We can check that the container has been create on the storage account.

Open the storage account and go to Containers there should be a new insight-logs container.

If we navigate down the folder structure there will be a JSON file that has all the NSG access requests, we could use the JSON file it self but it pretty difficult to read.

To check that data is going to the workspace, go to Log Analytics Workspace. Select the workspace we used earlier.

We will use the AzureNetworkAnalytics_CL table and flowlog to view the data. I used the below Learn article to help understand the table / fields and create the queries.

https://learn.microsoft.com/en-us/azure/network-watcher/traffic-analytics-schema

We can run the below KQL query this will return

AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| project FlowType_s, FlowEndTime_t, SrcIP_s, DestIP_s, DestPort_d, L4Protocol_s, L7Protocol_s

Now that we have confirmed data is being shipped to the log workspace, we can start to create the KQL query that will show all traffic between the specific IP of the servers.

The below query will return inbound and outbound request for specified source and destination IP

AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| extend Direction = case(FlowDirection_s == 'O', 'Outbound', FlowDirection_s == 'I','Inbound', FlowDirection_s)
| extend Access = case(FlowStatus_s == 'A', 'Allowed', FlowStatus_s == 'D', 'Denied', FlowStatus_s )
| extend Protocol = case(L4Protocol_s == 'T', "TCP", L4Protocol_s == 'U', "UDP", L4Protocol_s)
| project TimeGenerated, Direction, Access, SrcIP_s, DestIP_s, DestPort_d, Protocol, L7Protocol_s, NSGRule_s
| where SrcIP_s contains "Source IP" and DestIP_s contains "Destination IP"

We can now see all the traffic that is going from one server two the other, we can use this to review and allow the required traffic.

To export we can then export the results and use that to review the required ports.

The last step will be to update the rules on the NSG to only allow the required traffic.

In this post we will be going through configuring Network Security Group’s to restrict access between subnets under a single vNet.

Routing between subnets happens automatically and is allowed by default.

This can allow resources communicate over any port and there is no network access control.

To make the Azure network more secure this should be restricted as much as possible to only allow the required communication.

Below is a link to the Microsoft network best practice.

https://learn.microsoft.com/en-us/azure/security/fundamentals/network-best-practices?toc=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fazure%2Farchitecture%2Ftoc.json&bc=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fazure%2Farchitecture%2Fbread%2Ftoc.json#logically-segment-subnets

One way to limit the communication is to use NSG’s.

In this example we will be using a 10.10.1.0/24 address space

Then we will be creating multiple subnets with /28 mask.

I have added one server to both the Ops and Mgmt subnets. Now if we make a connection between each VM the traffic will be routed directly between both VM’s.

Next, we will setup the NSG to only allow connection between the subnets for RDP and SMB. In this case we will be creating an NSG per subnet, but this could be done in one NSG.

Next, we need to create two new inbound rules one to allow the required ports and the second to deny all other access.

Go to inbound rules and select Add.

Added in the required details

·       Source: IP Address

·       Source Port: 

·       Destination: IP Address

·       Destination IP Address:

·       Service: Custom

·       Destination Port Ranges:

·       Protocol TCP

·       Action: Allow

·       Priority: 110

·       Name: Allow_Mgmt_Subnet_Access

Next, we will create the deny rule.

 

I would usually set the deny to a much lower priority, so that if more rules are required in the future there won’t be an issue with the deny rule having a higher priority and blocking the traffic. 

Once saved, the allow and deny rule should show under inbound rules.

Now when we try to run tracert again, this time we won’t be able to connect.

 

If we try open a connection using SMB, we can connect without issue.

To block access back to the other subnet we will need to create the same rules but with the opposition subnet source and destination IP ranges.

After creating both set of NSG rules there will be no access between the subnets on any port other than those specified in the inbound rules.