Azure

Step-by-Step Guide: How to use Azure Bastion with VNet Peering? (Using Azure Portal)

In my previous blog post, I demonstrate how to setup Azure Bastion with Global VNet peering. This blog post can access using this link. In there I used Azure PowerShell for the configuration. Some of the readers asked if it’s possible to set up similar using Azure Portal. Therefore, I am writing this blog post to demonstrate how we can set up Azure Bastion with VNet peering by using the Azure Portal. The only difference in here is, instead of Global VNet peering, I am using VNet peering (with in Azure Region). This will also confirm that Azure Bastion works with Global VNet peering as well as VNet peering.
Demo Environment

The following diagram explains what we going to set up in this demo.

Here we are going to create three resource groups in the same Azure region. Each resource group will have its own Azure virtual network. For the connectivity, we will be using the hub-and-spoke network model. EUSVnet1 & EUSVnet2 will be Spoke virtual networks and BASVnet1 will be the Hub virtual network. Both Spoke virtual networks will have VNet peering with Hub virtual network. We will enable Azure Bastion service on hub virtual network (BASVnet1) and try to connect to virtual machines hosted in Spoke virtual networks. I have summarized virtual network configuration as follows,

Resource Group	Azure Virtual Network	Address Space	Azure Region
EUSRG1	EUSVnet1	10.15.0.0/16	East US
EUSRG2	EUSVnet2	10.75.0.0/16	East US
BASRG1	BASVnet1	10.2.0.0/16	East US

Create Resource Groups

As the first part of the configuration, I am going to create three new resource groups. To do that,

1. Log in to Azure Portal (https://portal.azure.com) as Global Administrator
2. Search for the Resource groups using the search function

3. Then click on + Add

4. It will open up a new window. In the form type name for Resource group and select East US as Azure region. Then click on Review + create

5. Once the validation is completed, click on Create to complete the resource group setup.

6. Follow the same method and create EUSRG2 & BASRG1 Resource Groups.

Step-by-Step Guide: How to use Azure Bastion with Global VNet Peering?

If we need to access an Azure VM using RDP or SSH, most of the time we access it using the public IP address. In this way, the virtual machine will have a public IP address (static or dynamic) assigned to it, and RDP or SSH service ports will open to the internet via NSG. This method provides easy access but not a very secure method.

If we have VPN or Express Route connectivity to Azure, we can connect to virtual machines using private IP addresses. It is secure than the public IP address method. However, it required additional configuration at the network level.
Azure Bastion is a solution that we can use to access Azure VM securely without the use of public IP addresses or VPN connectivity. This is similar to using a jump-server to connect to resources in the remote network but instead of the traditional RDP method, it is using browser-based secure HTTP connectivity.

Azure Bastion deployment is per virtual network. Once Azure Bastion service is enabled in a virtual network, remote access (RDP/SSH) will be available for all the virtual machines in that particular virtual network. According to Microsoft’s recent announcement, Azure Bastion is now supporting VNet Peering. Let’s assume we enable Azure Bastion for a Virtual network which is already peered with another VNet. Now we do not need another Azure Bastion deployment to access virtual machines hosted in the peered network. We can use centralized Azure Bastion deployment to reach virtual machines in all peered networks. Azure Bastion supports two types of peering.

• Virtual network peering – Virtual network peering in the same Azure region
• Global virtual network peering – Virtual network peering between different Azure regions

In peered virtual networks, Azure Bastion can be deployed either using hub-and-spoke or full-mesh topologies. In this post, I am going to demonstrate how to deploy and use Azure Bastion with Global VNet peering.
Azure VNet peering allows connecting virtual networks seamlessly via Azure backbone infrastructure. This is similar to inter-VLAN routing in on-premises networks. VNet peering can use to connect virtual networks in the same Azure region or different Azure regions. If it is between regions, we call it “Azure Global VNet Peering“.
Global VNET Peering has the following benefits,

• Low latency and high bandwidth as it uses Azure network backbone
• No requirement for encryptions, VPN gateways, or public internet to connect VNnets

Demo Environment

The following diagram explains what we going to set up in this demo.

Here we are going to create three resource groups in three different Azure regions. Each resource group will have its own Azure virtual network. For the connectivity, we will be using the hub-and-spoke network model. EUSVnet1 & UKSVnet1 will be Spoke virtual networks and BASVnet1 will be the Hub virtual network. Both Spoke virtual networks will have Global VNet peering with Hub virtual network. We will enable Azure Bastion service on hub virtual network (BASVnet1) and try to connect to virtual machines hosted in Spoke virtual networks. I have summarized virtual network configuration as follows,

Resource Group	Azure Virtual Network	Address Space	Azure Region
EUSRG1	EUSVnet1	10.15.0.0/16	East US
UKSRG1	UKSVnet1	10.75.0.0/16	UK South
BASRG1	BASVnet1	10.2.0.0/16	West US

For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

Create Resource Groups

As the first part of the configuration, I am going to create three new resource groups. To do that,

1. Launch PowerShell console and connect to Azure using Connect-AzAccount
2. Then create two new resource group using,

New-AzResourceGroup -Name EUSRG1 -Location “East US”

New-AzResourceGroup -Name UKSRG1 -Location “UK South”

New-AzResourceGroup -Name BASRG1 -Location “West US”

In the above, EUSRG1, UKSRG1 & BASRG1 are the names of new resource groups. From those, EUSRG1 is created in Azure East US region. UKSRG1 is created in Azure UK South region and BASRG1 is created in Azure West US region.

Create Spoke Virtual Networks

According to the plan, we need two virtual networks under EUSRG1 & UKSRG1 resource groups. Let’s start the configuration process by creating a virtual network under EUSRG1.

$vmsubnet = New-AzVirtualNetworkSubnetConfig -Name vmsubnet -AddressPrefix “10.15.0.0/24”
New-AzVirtualNetwork -Name EUSVnet1 -ResourceGroupName EUSRG1 -Location “East US” -AddressPrefix “10.15.0.0/16” -Subnet $vmsubnet

In the above, EUSVnet1 is the new virtual network name. It has 10.15.0.0/16 address space. It also has a new subnet 10.15.0.0/24 (vmsubnet) for virtual machines.

Then let’s go ahead and create another virtual network under UKSRG1 resource group. This will be in UK South Azure region.

$vmsubnet2 = New-AzVirtualNetworkSubnetConfig -Name vmsubnet2 -AddressPrefix “10.75.0.0/24”
New-AzVirtualNetwork -Name UKSVnet1 -ResourceGroupName UKSRG1 -Location “UK South” -AddressPrefix “10.75.0.0/16” -Subnet $vmsubnet2

In the above, UKSVnet1 is the new virtual network name. It has 10.75.0.0/16 address space. It also has a new subnet 10.75.0.0/24 (vmsubnet2) for virtual machines. [Read more…] about Step-by-Step Guide: How to use Azure Bastion with Global VNet Peering?

Step-by-Step Guide: How to configure user risk-based Azure conditional access policies?

In my previous blog post, I explained how to set up sign-in risk-based Azure conditional access policy. This article can be accessed using this link. As I explained in the article, sign-in risk is calculating based on user access behavior. If the user access behavior is flagged as risky, most probably the user account is also compromised. Most of the time, these compromised accounts are sold or shared on the dark web. Now with help of Microsoft, we can check if the corporate accounts are appearing in risky places. Microsoft uses various sources to identify risky user accounts. Such as,

Public paste sites
Dark web research groups
Law enforcement agencies

We can use Azure conditional access policies to verify if the sign-in request is coming from a known compromised account. User account risks are calculated offline, which means it can take 2- 24 hours to appear in reports.
Let’s go ahead and see how we can create a user risk-based Azure conditional access policy.

Configure Azure conditional access policy

1. Log in to Azure Portal (https://portal.azure.com/) as Global / Security / Conditional Access Administrator
2. Then go to Azure Active Directory

3. On the Azure Active Directory page click on Security

4. On the Security Home page, click on Conditional Access

5. Then click on + New Policy

Step-by-Step Guide: How to configure Sign-in risk-based Azure conditional access policies ?

Some time ago I wrote an article about sign-in risk-based conditional access policies. But things have been changed over time and I thought it is time to update it with new content.

Let’s assume we have a web application that is published via the internet. To access the services, the user has to provide a user name and password. If one of the users’ accounts compromised, how the system can differentiate legitimate access and illegal access? From the system’s point of view, as long as someone provides a valid user name and password system will allow access. But if we can analyze user access behaviour and detect anomalies, potentially we will be able to detect illegal access attempts. As an example, let’s assume the user is always log in from Canada. The user logged in to the system at 10 am successful. By 11 am the system detects another authentication attempt from UK for the same user. As we can see this behaviour is suspicious and if the system can detect this automatically, we can prevent a possible illegal access attempt.

Sign-in risk-based Azure conditional access policies help organizations to review user sign-in behaviours and detect risks. Then, based on risk levels, organizations can either block the user or enforce actions such as multi-factor authentication to prove their identity.
Azure categorizes sign-in risks into four levels.

High
Medium
Low
No risk

We can use one or more sign-in risk levels with a conditional access policy.

Due to security reasons, Microsoft does not provide exact details about how the risk levels are calculated. However, Microsoft says the following events contribute on risk level calculation.

Risk Detection Type	Description	Detection Type
Anonymous IP address	This risk detection type indicates sign-ins from an anonymous IP address (for example, Tor browser or anonymous VPN)	Realtime
Atypical travel	This risk detection type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behaviour.	Offline
Malware linked IP address	This risk detection type indicates sign-ins from IP addresses infected with malware that is known to actively communicate with a bot server.	Offline
Unfamiliar sign-in properties	This risk detection type considers past sign-in history (IP, Latitude / Longitude and ASN) to look for anomalous sign-ins.	Realtime
Password spray	A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access. This risk detection is triggered when a password spray attack has been performed.	Offline
Admin confirmed user compromised	This detection indicates an admin has selected ‘Confirm user compromised’ in the Risky users UI or using risky Users API.	Offline
Malicious IP address	This detection indicates sign-in from a malicious IP address.	Offline
Suspicious inbox manipulation rules	This detection is discovered by Microsoft Cloud App Security (MCAS). This detection profiles your environment and triggers alerts when suspicious rules that delete or move messages or folders are set on a user’s inbox.	Offline
Impossible travel	This detection is discovered by Microsoft Cloud App Security (MCAS). This detection identifies two user activities (is a single or multiple sessions) originating from geographically distant locations within a time period shorter than the time it would have taken the user to travel from the first location to the second, indicating that a different user is using the same credentials.	Offline

Source : https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#user-risk

As we can see above, there are two detection types. Realtime detection will take 5-10 minutes to show the results. Offline detection can take up to 24 hours to show the results.
Let’s go ahead and see how we can create a conditional access policy.

Configure conditional access policy

1. Log in to Azure Portal (https://portal.azure.com/) as Global / Security / Conditional Access Administrator
2. Then go to Azure Active Directory

3. On the Azure Active Directory page click on Security

How to use Azure Front Door for Global load balancing?

Microsoft Azure has various service, which can use to load balance your application traffic at the global level or regional level. Azure Front Door is also one of those services.

Traffic Manager
Application Gateway
Load Balancer

Traffic Manager, is a DNS based traffic load balancer. It examines the incoming DNS request and replies according to traffic routing rules.

Application Gateway is a layer 7 load balancer which can make routing decisions based on the attributes of an HTTP request (URL based routing).

load balancer works in layer 4 (transport layer) and can distribute network traffic to endpoints in the same Azure region. It can use to distribute internet traffic as well as internal traffic.

Azure Front Door also a solution that can use for Global load balancing. It also works in layer 7 and it can provide dynamic website acceleration (DSA) to globally distributed applications. It examines incoming HTTP requests and route traffic to the closest back end based on availability and configuration rules. Azure front door can offer,

- Accelerated application performance by using split TCP-based anycast protocol
- Intelligent health probe monitoring for backend resources
- URL-path based routing for requests
- Enables the hosting of multiple websites for efficient application infrastructure.
- Cookie-based session affinity
- SSL offloading and certificate management
- Define your custom domain
- Application security with integrated Web Application Firewall (WAF)
- Redirect HTTP traffic to HTTPS with URL redirect
- Custom forwarding path with URL rewrite
- Native support of end-to-end IPv6 connectivity and HTTP/2 protocol

In this blog post, I am going to demonstrate how to set up Azure Front door and show how we can use it for application load balancing.

Create New Azure Resource Groups

First, I am going to create two resource groups in Azure. One is in East US region and another one is UK South region. To do that,

1. Launch PowerShell console and connect to Azure using Connect-AzAccount
2. Then create new resource groups using,

New-AzResourceGroup -Name REBELRGEUS -Location “East US”

New-AzResourceGroup -Name REBELRGUKS -Location “UK South”

In here, we are creating two resource groups. The first one is called REBELRGEUS and it is created in East US Azure region.

The second group is called REBELRGUKS and it is created in UK South azure region.

Create Azure Web Applications

The next step of the configuration is to create two applications in these new resource groups. For that, I followed https://docs.microsoft.com/en-us/azure/app-service/quickstart-html and create two new Azure web applications.

East US Site

UK South Site

Create Azure Front End Object for Azure Front Door

We need a hostname for Azure Front Door. Then, users can access it from the internet. To do that we need to create Azure frontend object first.

$afd = “rebeladminapp-frontend-$(Get-Random)”
$feobject = New-AzFrontDoorFrontendEndpointObject -Name “rebelfrontend1″ -HostName $afd”.azurefd.net”

In here, New-AzFrontDoorFrontendEndpointObject command is used to create a new frontend object called “rebelfrontend1“. Also, in their rebeladminapp-frontend-$(Get-Random) value defines the hostname prefix.

In next step of the configuration, We are going to create a backend pool. [Read more…] about How to use Azure Front Door for Global load balancing?

Azure

Step-by-Step Guide: How to use Azure Bastion with VNet Peering? (Using Azure Portal)

Create Resource Groups

Step-by-Step Guide: How to use Azure Bastion with Global VNet Peering?

Demo Environment

Create Resource Groups

Create Spoke Virtual Networks

How to use Azure Front Door for Global load balancing?

Create New Azure Resource Groups

Create Azure Web Applications

Create Azure Front End Object for Azure Front Door

Recent Posts

About Rebeladmin.com

Azure

Create Resource Groups

Demo Environment

Create Resource Groups

Create Spoke Virtual Networks

Configure Azure conditional access policy

Configure conditional access policy

Create New Azure Resource Groups

Create Azure Web Applications

Create Azure Front End Object for Azure Front Door

Footer

Recent Posts

About Rebeladmin.com

Social Media

Tags