Category Archives: Networking

Azure Networking: how to monitor and analyze Azure Firewall logs

In network architectures in Azure where Azure Firewall is present, the firewall-as-a-service solution (FWaaS) which allows to secure the resources present in the Virtual Networks and to govern the related network flows, it becomes strategic to adopt tools to effectively monitor the relevant logs. This article explores how to best interpret logs and how you can do in-depth analysis of Azure Firewall, a component that often plays a fundamental role in network architectures in Azure.

An important aspect to check is that the diagnostic settings are correctly configured in Azure Firewall, to flow log data and metrics to an Azure Monitor Log Analytics workspace.

Figure 1 – Azure Firewall diagnostic settings

To get an overview of the diagnostic logs and metrics available for Azure Firewall, you can consult the specific Microsoft documentation.

One of the most effective ways to view and analyze Azure Firewall logs is to use Workbooks, that allow you to combine text, Log Analytics query, Azure metrics and parameters, thus conseasing interactive and easily searchable reports.

For Azure Firewall there is a specific workbook provided by Microsoft that allows you to obtain detailed information on events, know the applications and network rules activated and view the statistics on firewall activity by URL, ports and addresses.

The import of this workbook can be done via ARM template or Gallery template, following the instructions in this article.

Figure 2 – Azure Firewall Workbook Import

After completing the import process, you can consult the overview an overview of the different events and types of logs present (application, Networks, threat intel, DNS proxy), with the possibility of applying specific filters related to workspaces, time slot and firewalls.

Figure 3 – Azure Firewall Workbook overview

There is a specific section in the workbook for Application rule where are shown sources by IP address, the use of application rules, and FQDNs denied and allowed. Furthermore, you can apply search filters on application rule data.

Figure 4 – Azure Firewall Workbook – Application rule log statistics

Furthermore, in the section Network Rule you can view the information based on the actions of the rules (allow/deny), target ports and DNAT actions.

Figure 5 – Azure Firewall Workbook – Network rule log statistics

If Azure Firewall has been set to work also as DNS Proxy it is possible to view in the tab “Azure Firewall – DNS Proxy” of the Workbook also information regarding the traffic and DNS requests managed.

If it is necessary to carry out further information to obtain more information on the communications of specific resources, you can use the section Investigation going to act on the filters available.

Figure 6 – Azure Firewall Workbook – Investigation

To view and analyze activity logs, you can connect Azure Firewall logs to Azure Sentinel, the service that expands the capabilities of traditional SIEM products (Security Information and Event Management), using the potential of the cloud and artificial intelligence. In this way, through specific workbooks available in Azure Sentinel, you can expand your analytics capabilities and create specific alerts to quickly identify and manage security threats that affect this infrastructure component. To connect Azure Firewall logs to Azure Sentinel you can follow the procedure in this Microsoft's document.

Conclusions

Azure Firewall is a widely used service and is often the centerpiece of your network architecture in Azure, where all network communications transit and are controlled. It therefore becomes important to date yourself with a tool to analyze the metrics and information collected, able to provide valid support in the resolution of any problems and incidents. Thanks to the adoption of these Workbooks you can easily consult the data collected by Azure Firewall, using visually appealing reports, with advanced features that allow you to enrich the analysis experience directly from the Azure portal.

Azure Networking: new features to know to better design network architectures

Cloud solutions evolve very quickly and staying up to date is a key element in innovating and responding effectively to technological changes. With the change of pace imposed by the digital transformation, network infrastructures must also be increasingly efficient, flexible and able to best provide the services required by the company business. To modernize your Azure Networking design and implementation strategy, it is therefore important to evaluate how the various technologies evolve. This article describes the news recently released by Microsoft that may affect Azure networking design, with references to real use cases.

Azure Bastion and VNet peering

Azure Bastion is a PaaS service that provides secure and reliable RDP and SSH access to virtual machines, directly through the Azure portal. Azure Bastion service provisioning is done within an Azure Virtual Network and allows access without having to assign public IP addresses directly to systems.

The news is that Azure Bastion can now work in synergy with Virtual Network (VNet) peering. This means that it is possible to activate Azure Bastion on a specific VNet and the same service can also be used to connect to virtual machines attested on the VNet in peering with this.

Azure Bastion works both in the presence of network peering that connects VNets to the same Azure region, both with VNet peering type Global, that connect VNets located in different Azure regions. From the point of view of network architectures, this possibility opens up new possible scenarios. In the typical and widely used network model, defined hub-and-spoke, you have a virtual network in Azure of Hub which acts as a point of connectivity to the on-premises network and the virtual networks that perform peering with the Hub are definedspoke, useful for isolating workloads. By adopting this model it is possible to activate Azure Bastion on the network of Hub. In this way it will be possible to reach with a single Azure Bastion service also all the virtual machines distributed in the VNets of spoke.

Figure 1 – Azure Bastion in a hub-and-spoke architecture

The following diagram shows the Azure Bastion deployment in a hub-and-spoke network architecture where:

  • The Bastion host is activated in the Hub centralized virtual network.
  • Communications are allowed, per TCP port 3389 and 22, from the Azure Bastion subnet in the Hub virtual network, to the private IPs of the Spoke virtual networks.
  • No public IP is required to access virtual machines.

With this configuration, you can simplify your architecture and reduce Azure costs, as only one Azure Bastion service will be required for the entire hub-and-spoke network topology.

Furthermore, Azure Bastion can also be provisioned in full-mesh network topologies, obtaining the same experience of accessing systems in RDP / SSH for VMs attested on all virtual networks in peering.

Some observations are reported in this regard:

  • It is possible to have several Bastion hosts active simultaneously between virtual networks in peering. This can happen particularly during the transition period, when you want to consolidate several Bastion hosts according to the hub-and-spoke topology described above. In the presence of multiple Bastion hosts, when connecting, you will be offered to choose which Bastion host to use.
  • Azure Bastion currently supports peered virtual network scenarios only if they reside in subscriptions belonging to the same tenant.

Azure Firewall: new DNS settings

Azure Firewall is the firewall-as-a-service solution (FWaaS) present in Microsoft's public cloud, which allows you to secure the resources present in the Azure Virtual Networks and to govern the related network flows. Azure Firewall features have been enhanced by adding support for custom DNS and DNS proxy.

Custom DNS

By default Azure Firewall uses Azure DNS for name resolution. The ability to configure Azure Firewall to use specific DNS servers has now been included.

In the settings, you can configure a single DNS server or multiple DNS servers:

Figure 2 - Setting up custom DNS in Azure Firewall from the Azure portal

Azure Firewall can also perform name resolution by using Azure Private DNS. In this scenario it is required that the VNet within which Azure Firewall resides is connected to the Azure Private Zone.

DNS proxy

Azure Firewall can now be configured to play the role of DNS proxy. By enabling this new feature, you can configure the Azure Firewall private IP address as the DNS of the virtual network. In this way all DNS traffic is directed to Azure Firewall, which acts as an intermediary between the systems that make DNS requests and the DNS servers themselves, in this way avoiding possible inconsistencies in name resolutions if custom DNS are used.

When the Azure firewall acts as a DNS proxy, there are two types of caches:

  • Positive cache: DNS resolution is successful. In this case Azure Firewall uses TTL (time to live) of the package or object.
  • Negative cache: DNS resolution is not successful. In this case, the information is stored in the Azure Firewall cache for one hour.

Figure 3 - Configure Azure Firewall as a DNS proxy from the Azure portal

This feature allows you to evaluate a new usage scenario for Azure Firewall, very useful when you need to manage DNS resolution in the presence of Private link, the mechanism that allows you to establish a private connection to services in Azure.

Each Azure PaaS service that uses Azure Private Link is assigned a mapped FQDN and stored in an Azure Private DNS zone. Requests sent to Azure DNS Private Zones are routed to the platform IP 168.63.129.16, which can only be reached from within the Azure environment. For this reason, if the DNS request originates from on-premises systems (or in any case from outside Azure), it is necessary to activate a DNS proxy within an Azure virtual network connected to the on-premise environment. With this new Azure Firewall DNS proxy feature, you can manage this challenge of name resolution of PaaS servers using Private Link with the following steps:

  • The VNet within which Azure Firewall resides is connected to the Azure Private Zone.
  • Azure Firewall is configured to use the Azure default DNS and enable the DNS Proxy functionality.
  • You configure your local DNS server to conditionally forward requests to Azure Firewall for the requested zone name.

Azure Firewall: using FQDN filtering in network rules

In Azure Firewall Network Rules, you can now use fully qualified domain names (FQDN) based on Azure Firewall DNS resolution. This feature allows you to filter outbound traffic for any protocol TCP / UDP (NTP, SSH, RDP, etc.) and requires the DNS proxy functionality described in the previous paragraph to be active. Azure Firewall, when configured as a DNS proxy, stores all IP addresses resolved by the FQDNs used in the network rules. For this reason it is good practice to use FQDNs in the network rules as a best practice.

Azure Firewall, for both application rules and network rules, converts the FQDN into one or more IP addresses based on the selected DNS server (Azure DNS or custom DNS). When a new DNS resolution occurs, the new IP addresses are added to the firewall rules, IP addresses that are no longer returned by the DNS server have an expiration of 15 minutes. Azure Firewall Network Rules are updated every 15 seconds using DNS resolution. If you need to apply FQDN filters, it is still a good idea to always use the Azure Firewall application rules for HTTP / S or MSSQL protocols, while for all the remaining protocols it is possible to use both the application rules and the network rules.

New features for Azure VPN gateways

Following, are reported the new features that can be adopted in the presence of Azure VPN gateways:

  • High availability of RADIUS servers in point-to-site VPNs: this feature allows you to configure high availability for customers who use RADIUS / AD authentication for point-to-site VPNs.
  • Custom IPsec/IKE policies with DPD timeouts: the IKE DPD timeout setting (Dead Peer Detection) adjusts the IKE session timeout value based on connection latency and traffic conditions. This configuration is useful for minimizing tunnel disconnections, improving the reliability and user experience.
  • APIPA support for BGP speaker: this feature allows you to establish Border Gateway Protocol sessions (BGP), with Azure VPN gateways, using APIPA addresses (169.254.x. x). This feature is especially useful for customers with legacy VPN routers, Amazon Web Service (AWS) VGW, Google Cloud Platform (GCP) VPN that use APIPA addresses (Automatic Private IP Addressing) to announce BGP addresses.
  • FQDN support for site-to-site VPNs: this feature allows you to configure site-to-site VPN in the presence of devices that do not have static public IP addresses to connect to Azure VPN gateways. It is in fact possible to use the fully qualified domain name (FQDN) instead of IP addresses. Azure VPN gateway will be able to do DNS name resolution, automatically updating the destination to establish the VPN's IPsec / IKE connections.
  • Session management and user revocation for point-to-site VPNs: the ability to list and revoke individual user connections to VPN gateways is given, directly from the Azure portal and in real time.

Conclusions

There are several innovations recently released by Microsoft in Azure networking and it is advisable to carefully evaluate them to make an accurate design. In this way it will be possible to realize effective network architectures, optimizing costs and able to exploit all the potential offered by the Azure platform.

Microsoft Always On VPN: transparent access to the corporate network suitable in smart working scenarios

Technology can play an important role in reducing the impact of COVID-19 on people and business realities, helping staff stay productive when it is not able to be physically at his workplace. In these days of emergency, companies have been forced to adopt effective solutions quickly to allow their employees to work remotely without sacrificing collaboration, productivity and security. The solutions that can be adopted in this area are different, each with its own characteristics and peculiarities, able to meet different needs. This article presents the main features of the technology Microsoft Always On VPN, to assess the benefits and what are the main use cases of the solution.

Key Features of Always On VPN

Starting with Windows Server 2016 and later Microsoft introduced a new remote access technology for endpoints called Always On VPN that allows transparent access to the corporate network, making it particularly suitable in smart working scenarios. It is the evolution of the technology DirectAccess and, however effective, it presented some limitations that made it difficult to adopt.

As the name tell, VPN is “always active”, In fact, a secure corporate network connection is established automatically whenever an authorized client has Internet connectivity, all without requiring user input or interaction, unless a multi-factor authentication mechanism is enabled. Remote users access business data and applications in the same way, just as if they were in the workplace.

Always On VPN connections include the following types of tunnels:

  • Device Tunnel: the device connects to the VPN server before users log on to the device.
  • User Tunnel: it activates only after users have logged on to the device.

Using Always On VPN you can have a user connection, a device connection, or a combination of both. Both the Device Tunnel that the User Tunnel they work independently and can use different authentication methods. It appears therefore possible to enable the device authentication to manage it remotely through the Device Tunnel, and enable user authentication for connectivity to internal resources through the User Tunnel. The User Tunnel supports SSTP, and IKEv2, while the Device Tunnel only supports IKEv2.

Supported scenarios

Technology Always On VPN is a solution only for systems Windows 10. However, unlike DirectAccess, client devices don't have to run the Enterprise edition, but all versions of Windows 10 support this technology, adopting the tunnel type defined User Tunnel. In this scenario, the devices can be members of an Active Directory domain, but this is not strictly necessary. The Always On VPN client can be nondomain-joined (workgroup), therefore also owned by the user. To take advantage of certain advanced features, clients may be to join Azure Active Directory. Only for use Device Tunnel systems are required to join a domain and must have Windows 10 Enterprise or Education. In this scenario, the recommended version is 1809 or later.

Infrastructure requirements

The following infrastructure components are required to implement an Always On VPN architecture, many of which are typically already active in the business realities:

  • Domain Controllers
  • DNS Servers
  • Network Policy Server (NPS)
  • Certificate Authority Server (CA)
  • Routing and Remote Access Server (RRAS)

Figure 1 – Overview of VPN Always On technology

In this context it is appropriate to specify that Always On VPN is infrastructure-independent and can be activated by using the Windows Routing and Remote Access role (RRAS) or by adopting any third-party VPN device. Authentication can also be provided by the Windows Network Policy Server role (NPS) or from any third-party RADIUS platform.

For more details on the requirements, please refer to the Microsoft's official documentation.

Always On VPN in Azure environment?

In general,, it is advisable to establish VPN connections to endpoints as close as possible to the resources that must be accessed. For hybrid realities, there are several options for positioning the architecture Always On VPN. Deploying the Remote Access role on a virtual machine in Azure environment is not supported, however, you can use Azure VPN Gateway with Windows 10 Always On, to establish tunnels of both type Device Tunnel and User Tunnel. In this regard it should be noted that it is appropriate to make the correct assessments of the type and of the SKU to deploy Azure VPN Gateway.

Deployment types

For Always On VPN there are two deployment scenarios:

The deployment of Always On VPN can predict optionally, for client Windows 10 joined to domain, to configure conditional access to adjust how VPN users access company resources.

Figure 2 – Workflow for the deployment of Always On VPN for Windows 10 client domain-joined

The client Always On VPN can be integrate with the platform Azure Contitional Access to force multi-factor authentication (MFA), device compliance or a combination of these two aspects. If meets the Contitional Access criteria, Azure Active Directory (Azure AD) issues a short-lived IPsec authentication certificate that can be used to authenticate to the VPN gateway. Device compliance uses Microsoft Endpoint Manager compliance policies (Configuration Manager / Intune), which may include the status of integrity attestation of the device, as part of the compliance check for the connection.

Figure 3 – Client-side connection workflow

For more details on this deployment method you can refer to this Microsoft documentation.

Provisioning of the solution on the client
Always On VPN is designed to be deployed and managed using a mobile device management platform such as Microsoft Endpoint Manager, but you can also use Mobile Device Management solutions (MDM) of third party. For Always On VPN there is no support for the configuration and management via Group Policy in Active Directory, but if you do not have a MDM solution it is possible to proceed with a manual deploy of the configuration via PowerShell.

Integration with other Microsoft solutions

Besides the cases specified in the preceding paragraphs, technology Always On VPN can be integrated with the following Microsoft technologies:

  • Azure Multifactor Authentication (MFA): when combined with RADIUS services (Remote Authentication Dial-In User Service) and the extension NPS (Network Policy Server) for Azure MFA, VPN authentication can exploit multi-factor authentication mechanisms.
  • Windows Information Protection (WIP): thanks to this integration is permitted the application of network criteria for determining if traffic is permitted to pass through the VPN tunnel.
  • Windows Hello for Business: in Windows 10, this technology replaces passwords, providing authentication mechanism with two strong factors. This authentication is a type of user credentials related to a device and use a PIN (Personal Identification Number) biometric or personal.

Conclusions

Prepare your infrastructure to allow the endpoint to access the corporate network through technology Always On VPN it does not require any additional cost for software licenses and the necessary investments both in terms of effort and resources are minimal. Thanks to this connectivity method you can ensure the best user experience on the move, providing a transparent and automatic access to the corporate network while maintaining a high level of security. For the aspects listed above technology Always On VPN is not suitable for all usage scenarios, but it is certainly to be considered in the presence of systems Windows 10 that need remote access to corporate resources.

[Video] – Architecting and Implementing Azure Networking

To implement hybrid clouds securely and functionally, an in-depth understanding of the various aspects of Azure networking is crucial. Recently I had the pleasure of participating in the Italian Cloud Conference where I held a session related to the Azure Networking. In this regard, I report the video of the session where 360-degree exploration of the key elements to be considered in order to build hybrid network architectures, taking advantage of the various services offered by Azure, in order to achieve the best integration with the on-premises environment, without ever neglecting security. Advanced hybrid network architecture scenarios were explored during the session, showing real-world examples, result of a’direct experience in the field.

Azure Networking: managing micro-perimeters with Azure Firewall Manager

Microsoft's public cloud introduces the new management service Azure Firewall Manager that allows you to centrally manage security policies and routing rules. With this solution, you can better govern the security perimeters of your cloud environments and help you protect your business ecosystem. This article lists the key features of the new service, highlighting the benefits that can be gained by using it.

The security model, defined Zero trust by Forrester Research analysts, and in contrast with the conventional models based on perimeter security, directs us to adopt an approach related to micro-segmentation and the definition of granular perimeters in its network architecture. To facilitate this approach, Microsoft has released this tool that, providing a single centralized control panel, is able to simplify the configuration and management of network security policies, which often need to be deployed across multiple Azure Firewall instances.

Azure Firewall Manager at the moment is integrated with Azure Virtual WAN, the service that allows you to implement network architectures that are managed according to the hub and spoke model. Azure Firewall can now be enabled in Virtual WAN Hub networks, and when security and routing policies are associated by Azure Firewall Manager the Hub network is defined as a Secured Virtual Hub.

Figure 1 – Overview of Azure Firewall Manager

Adopting Azure Firewall Manager you can get the following benefits:

  • Centralized configurations and deployments: deploying and configuring multiple instances of Azure Firewall, in Virtual WAN Hub networks, can be done centrally. These Azure Firewall instances can reside in different Azure regions and on different subscriptions. Furthermore, you can organize a hierarchy of DevOps-optimized Azure Firewall policies, where Global firewall policies are managed by central IT and local policy firewalls are delegated to DevOps to promote better agility in processes.
  • Automated routing: comes the ability to easily route traffic in a centralized manner from the spoke networks to the Secure Virtual Hub, all without having to manipulate the User Defined Routes of spoke networks.
  • Integration with Partners Security as a Service (SECaaS) of third party: to further enhance the security features it can be integrated with SECaaS partners, today Zscaler and iBoss, but soon it will be possible even with CheckPoint.

Figure 2 – Central security e route policy management

In detail the steps to adopt the solution are as follows:

  1. Creating the hub-and-spoke network architecture, using the Azure Virtual WAN service and activating an Azure Firewall instance in the Hub network. To do this, you can do by using two separate modes:
    1. Creating a new one Secured Virtual Hub by Azure Firewall Manager and adding virtual network connections;
    2. Transforming an existing Virtual WAN Hub, activating the Azure Firewall service on the Hub network.

Figure 3 – Start the process using Azure Firewall Manager

  1. Selecting security providers (Optional). This can be done either during the process of creating a Secure Virtual Hub or during the conversion of a Virtual WAN Hub in a Secure Virtual Hub.

Figure 4 – Choosing the Trusted Security Partner

  1. Creating a firewall policy and association with the Network Hub. This is only possible for Azure Firewall Policies, while for Security as a Service solutions policies (SECaaS) provided by partners, you need to use their management tools.
  1. Configuring routing settings on the Secured Hub to attract the traffic of the spoke networks and make it filtered according to the defined policies.

At the moment Azure Firewall Manager is supported only for managing Hub and Spoke architectures created through the Azure Virtual WAN service. Support for managing Azure Firewall instances enabled in Virtual Networks is expected in the first half of next year.

Conclusions

Azure Firewall Manager is a tool that is very useful for managing complex environments composed of different network architectures that adopt the Hub and Spoke model over Azure Virtual WAN. This additional management service despite the dawn, and destined to get rich soon with new features, is essential to manage more easily and effectively the Azure network architecture. At the moment the service is Public Preview, so are not guaranteed SLA (Service-Level Agreements) and it should not be used in production environments.

Azure Networking: the new way to privately access services in Azure

The need to be able to access data and services in Azure in a totally private and secure way, in particular from on-premises environment, it's definitely very much felt and more and more widespread. For this reason, Microsoft has announced the availability of Azure Private Link, this simplifies the network architecture by establishing a private connection to services in Azure, without the need for exposure to Internet. This article describes the characteristics of this type of connectivity and how you can enable it.

Thanks to Azure Private Link you can bring Azure services to a virtual network and map them with a private endpoint. In this way, all traffic is routed through the private endpoint, keeping it on the Microsoft global network. The data does not pass ever on the Internet, this reduces exposure to threats and helps to meet the compliance standards.

Figure 1 - Overview of Azure Private Link

The concept that underlies Azure Private Link is already partly known under the Azure networking and invokes the Virtual Network Service Endpoints. Before the introduction of Azure Private Link the only available way to increase the level of security when accessing Azure services, such as Azure Storage and SQL Azure Database, was given by the VNet Service Endpoints. The difference is substantial, as using VNet Service Endpoints traffic remains in the Microsoft backbone network, allowing access to PaaS resources only from its own VNet, but the PaaS endpoint is still accessed via the public IP of the service. Consequently, the operating principle of the VNet Service Endpoints does not extend to on-premises world even in the presence of connectivity with Azure (VPN or ExpressRoute). In fact,, to provide access from on-premises systems you must continue to use the firewall rules to limit the connectivity only to your public IP.

Thanks to Azure Private Link you can instead access the PaaS resources via a private IP address of your VNet, which it is potentially also accessible from:

  • On-premises systems via Azure ExpressRoute private peering andor Azure VPN gateways.
  • Systems on VNet in peering.

All traffic resides within the Microsoft network and you do not need to configure access through public IPs of the PaaS Service.

Figure 2 – Access from on-premises and peered networks

Azure Private Link greatly simplifies the way you can access Azure services (Azure PaaS, Azure, Microsoft partners and private services) as they support cross configurations for Azure Active Directory (Azure AD) tenants.

Figure 3 – Private Link cross Azure Active Directory (Azure AD) tenants

Activating Azure Private link it's simple and requires a limited number of Azure networking-side configurations. Connectivity occurs based on a call approval flow and when a PaaS resource is mapped to a private endpoint, route table and Network Security Groups configuration is not required (NSG).

Since Private link center you can create new services and manage the configuration or configure existing services to take advantage of Private link.

Figure 4 - Starting Configuration from Private link center

Figure 5 - Creating an Azure Storage Account to make it privately accessible

Figure 6 - Classical parameters for the creation of an storage account

Figure 7 - Private endpoint configuration

Figure 8 - Private endpoint connection present in the created storage accounts

At this point the storage account will be available in totally private way. To test the connectivity access a virtual machine was created and verified through "Connection troubleshoot":

Figure 9 – Test performed by "Connection troubleshoot" that demonstrates private connectivity

To connect with each other more Azure Virtual Network are typically used VNet peering, that require there are no overlaps in VNets address spaces. If this condition occurs it is possible to adopt the Azure Private Link as an alternative way to privately connect applications that reside in different VNets with an overlapping address space.

Figure 10 – Azure Private Link in the presence of overlapping address space

Azure Private Link features allow you to have specific access only to explicitly mapped resources. In the event of a security incident within your VNet, this mechanism eliminates the threat of extracting data from other resources using the same endpoint.

Figure 11 - Targeted access only to explicitly mapped resources

The Azure Private Link also opens new scenarios for exposure of service in Azure provided by the service provider. In order to allow access to the services provided to its customers, one of these methods was typically carried out in one of these ways.:

  • They made themselves directly accessible via Public IPs.
  • To make them private, VNet peerings were created, but with scalability issues and potential IP conflicts.

Figure 12 - How Azure Private Links changing scenarios "Consumer Service" - "Service Provider".

The new possibilities that are offered in these scenarios, requiring a totally private access to the service provided, is the following:

  • Service Provider: set up an Azure Standard Load Balancer, creates a Azure Private Link and allows access to the Service Consumer coming from a different VNet, subscription, or Azure Active Directory tenant (AD).
  • Service consumer: create a Private Endpoint in the specific VNet and request access to the service.

Figure 13 – Azure Private Link workflow in “Service Consumer”-“Service Provider” scenario

For more details please visit the Microsoft's official documentation.

Conclusions

This new method allows you to privately consume Azure-delivered solutions within your network infrastructure. This is an important change that you should definitely consider when designing network architectures in Azure, particularly for hybrid scenarios. At the moment the service is in preview, therefore not yet usable for production environments and available for a limited set of Azure services. In the coming months, however, Microsoft has announced that it will also make this feature available to other Azure services and partners, allowing you to have a private connectivity experience, key to having more adoption and dissemination of these services.

Azure Networking: what's new in Azure Firewall

Azure Firewall is the firewall-as-a-service solution exists in the Microsoft public cloud, which allows you to secure the resources present in the Azure Virtual Networks and to govern the related network flows. This service has been officially released from several months and, as is often the case with cloud services, there are rapid evolutions, to improve the service and increase the feature set. This article lists the top news that recently affected Azure Firewall.

Public IP addresses associated with Azure Firewall

While initially, only one public IP address could be associated with Azure Firewall, now you can associate up to 100 public IP addresses. This opens up new configuration and operation scenarios:

  • In DNAT configurations you have the option to use the same port on different public IP addresses.
  • For SNAT outbound connections will be available a larger number of ports, reducing the ability to finish the doors available.

Currently the source Public IP address of Azure Firewall used for the connections is chosen randomly. This should be considered when you need specific permissions for traffic from Azure Firewall. Microsoft still has a roadmap of SNAT configurations by specifying the Public IP address to use. The steps to deploy Azure Firewall with multiple public IP addresses, using PowerShell commands, you can consult in this document.

Figure 1 – Assign multiple public IPs to Azure Firewall from the Azure portal

Availability Zones

In order to increase the availability levels of Azure Firewall, you can, during the creation phase,  plan to use the Availability Zones. Selecting two or more Availability Zones will allow you to get an uptime percentage of the 99.99 %. Full details about Service Level Agreements (SLA) of Azure Firewall are contained in this document. The adoption of this deployment methodology does not involve any additional costs, but you need to contemplate an increase in the costs of inbound and outbound data transfer from Availability Zones, available in this document. Compared to the cost of the Azure Firewall, these do not have a particularly significant impact. I personally think that if you adopt an architecture of the networking where Azure Azure Firewall is the core component for the security of the environment, it becomes very useful to use the Availability Zones to ensure a high level of availability of mission-critical applications protected by this service.

Figure 2 - Configuration of Availability Zones in the process of creating Azure Firewall

In the presence of Azure Firewall created without the use of Availability Zones, you do not have the possibility of carrying out a conversion to the use of the same. The only currently available method involves the creation of a new Azure Firewall migrating existing configurations. Backups in JSON format of the Azure Firewall configuration can be made using the following PowerShell commands:

[cc lang=”powershell”]

$AzureFirewallId = (Get-AzFirewall -Name “AzureFirewallName” -ResourceGroupName “Network-RG”).id

$BackupFileName = “.AzureFirewallBackup.json”

Export-AzResourceGroup -ResourceGroupName “Network-RG” -Resource $AzureFirewallId -SkipAllParameterization -Path $BackupFileName

[/cc]

With the availability of the JSON file you need to edit it to contemplate the Availability Zones:

[cc lang=”powershell”]

{

“apiVersion”: “2019-04-01”,

“type”: “Microsoft.Network/azureFirewalls”,

“name”: “[variables(‘FirewallName’)]”,

“location”: “[variables(‘RegionName’)]”,

“zones”: [

“1”,

“2”,

“3”

],

“properties”: {

“ipConfigurations”: [

{

[/cc]

After the change is complete, you can deploy the new Azure Firewall, using suitably modified JSON file, using the following command:

[cc lang=”powershell”]

New-AzResourceGroupDeployment -name “RestoreFirewallAvZones” -ResourceGroupName “Network-RG” -TemplateFile “.AzureFirewallBackup.json”

[/cc]

Centralized management with third party solutions

Azure Firewall exposes publicly REST APIs that can be used by third-party vendors to provide solutions that allow a centralized management of Azure Firewall, Network Security Groups (NSGs), and network virtual appliances (NVA's). At the moment these are the vendors that offer such solutions: Barracuda with Cloud Security Guardian, AlgoSec with CloudFlow and Tufin with Orca.

Just-in-time (JIT) VM access for Azure Firewall

When a user requests access to a VM with a Just-in-time policy (JIT), the Security Center first checks whether the user actually has Role-Based Access Control permissions (RBAC) required to make the request for access. If so the request is approved, and the Security Center is able to automatically configure not only the NSG, but also the necessary rules in Azure Firewall side to allow incoming traffic.

Application rules with SQL FQDN

In application rule of Azure Firewall the ability to specify the SQL FQDN was introduced. This makes it possible to control access from the virtual network to specific instances of SQL Server. Through SQL FQDN you can filter traffic:

  • From Virtual Network to a Azure SQL database or a SQL Azure Data Warehouse.
  • From the on-premises environment to a SQL Azure Managed Instances or SQL IaaS running on Virtual Network.
  • From spoke-to-spoke to Azure SQL Managed Instances or SQL IaaS running on Virtual Network.

Figure 3 - Creating Application Rule with SQL FQDN

FQDN Tag for Azure HDInsight (HDI)

Azure HDInsight clusters present on its Virtual Network have different dependencies on other Azure services (for example Azure Storage), with which an outgoing network traffic is necessary to operate in the correct way. With the introduction of the FQDN tags for HDInsight you can configure Azure Firewall to restrict outbound access for HDI clusters. For more details please visit the Microsoft's official documentation.

Automation to handle the backup

Having a strategy to restore the configuration of the service in a short time is critical because this service is the government center of your Azure networking environment and contains several rules to comprehensively manage the network traffic. The service currently does not have an integrated feature to make full backup periodically. In this article you can find a mechanism designed to make the scheduled backup of the configuration of this component using the Azure Automation service.

Conclusions

Azure Firewall is a solution that is increasingly being used in network architectures of Azure, for the advantages over firewall solutions by third party vendors and thanks to a constant enrichment of features offered. All these new features make Azure Firewall a more comprehensive solution, totally integrated in the platform, that allows you to secure the resources on Azure Virtual Networks with high flexibility.

How to remote access virtual machines in Azure

Being able to access via RDP (Remote Desktop Protocol) or via SSH (Secure SHel) to virtual machines present in Azure is a basic requirement for system administrators. Direct exposure of these protocols on Intenet is definitely a practice to be avoided as a high risk security. This article shows the different methodologies that can be taken to gain remote access to systems present in Azure and the characteristics of each of it.

Recently Microsoft has released a security update rated critical and directed to resolution of the vulnerability CVE-2019-0708 identified on the Remote Desktop service for different operating systems. The vulnerability allows code execution via RDP protocol allowing you to take full control of the remote system. This vulnerability is taken as an example to highlight how is actually risky to publish on Internet these access protocols. For this reason you should consider adopting one of the solutions below for even more security.

Figure 1 – RDP/SSH attack

VPN access

To have an easy administrative access to the Azure Virtual Network you can enable a Point-to-Site VPN (P2S). Through the P2S VPN can establish connectivity from one location to the Azure environment, easily and securely. When the VPN connection is established you will have the ability to remotely access to systems in Azure. For more information on VPN P2S I invite you to read the article Azure Networking: Point-to-Site VPN access and what's new. Adopting this methodology you should take into consideration the maximum number of connections for each Azure VPN Gateway.

Figure 2 - Protocols available for P2S VPN

Just-in-Time VM Access

It is a feature available in Azure Security Center Standard Tier, allowing you to apply the necessary configurations to the Network Security Groups (NSG) and more recently to Azure Firewall to allow administrative access to systems, properly filtered for source IP and for a certain period of time. Just-in-Time VM Access allows to perform the configurations needed to access remotely to systems quickly, targeted and only for a very specific time period. Without the use of this feature you would need to manually create the appropriate rules within the NSG or Azure Firewall (NAT Rule), and remember to remove them when no longer needed.

Figure 3 - Request access via Just-in-Time VM Access

Jumpbox

A scenario that is used in some situations is the presence of a virtual machine (Jumpbox) accessible remotely and dislocated in a suitably isolated subnet, that is used to access several other systems in communication with that subnet. In a network architecture that reflects the hub-and-spoke topology, typically this system is positioned in the hub network, but it is recommended to apply filters to make sure that this system is only accessible from certain public IP addresses, without exposing it directly on the Internet. In this scenario you should take into consideration that you will have a maximum of two remote connections simultaneously for single JumpBox.

Figure 4 - Positioning of the JumpBox in a hub-spoke architecture

Azure Bastion

It is a PaaS service, recently announced by Microsoft in preview, offering a safe and reliable SSH and RDP access to virtual machines, directly through the Azure portal. The provisioning of Azure Bastion service is carried out within a Virtual Network of Azure and it supports access to all the virtual machines on it attested, without exposing the public IP addresses.

Figure 5 - Azure Bastion Architecture

For more details on this please read the article Azure Bastion: a new security model created by Silvio Di Benedetto.

Azure Bastion is a paid service, to get cost details you can access the page Azure Bastion pricing.

At the time you should take into account that Azure Bastion and Just-in-Time VM Access can not be used to access the same systems.

SSL Gateway

A very valid solution in terms of security is an implementation of a Remote Desktop Services environment in Azure, which includes the use of Remote Desktop Gateway role, specially designed to be directly exposed to the Internet (TCP port 443). With this component you can encapsulate RDP traffic in an HTTP over TLS / SSL tunnel. The Remote Desktop Gateway also supports Multi-Factor Authentication that allows to further increase the level of security for remote access to resources. A similar solution is also available in Citrix environment. In this area you will need to consider, in addition to the costs associated with Azure components, also the license costs.

Figure 6 - Possible Remote Desktop Services architecture in Azure environment

Conclusions

There are several possibilities for providing a secure remote access to virtual machines in the Azure environment. The new Azure Bastion service is a safe and simple method, but that needs to be expanded with more features, the most important are certainly support for Virtual Networks in peering and for multi-factor authentication. These features probably will be available when the solution will be globally available. Waiting to use Azure Bastion in a production environment you can use the other methods listed, thus avoiding having to expose unprotected systems to the Internet.

Azure Networking: all you should know about the new Application Gateway

The Application Gateway is the offer for application delivery controller as-a-service present in Azure that enables customers to make the application republishing, with integrated layer-7 load balancing, Security and Web Application Firewall (WAF). Microsoft recently announced the availability of a fully revised version of Azure Application Gateway and its Web Application Firewall module (WAF). This article lists the improvements and additional features that are present in the new SKUs, calls respectively Standard_v2 and WAF_v2.

Enhancements and new features

The following section shows the areas where the new Azure Application Gateway version has made improvements and additional features.

Figure 1 - Diagram with the new features of SKU V2

Scalability

The new version of Azure Application Gateway allows you to automatically perform a scale-up or a scale-down of the number of instances to use, based on traffic detected towards the applications republished. In this way the size of the Application Gateway will always be suitable to support the necessary traffic and will not be more appropriate sizing this component to maximum capacity to sustain moments with traffic spikes. Consequently, with this feature you can get significant cost savings in scenarios where there are workloads that do not have a homogeneous flow, but subject to change.

Zone redundancy

In the new SKU it is possible to do the deployment of the Application Gateway in different areas of availability (availability zone) so as not to be subject to disruptions in the event of problems related to the single zone of Azure. This method of deployment allows increasing the resilience of published applications.

Public Static IP Assignment

The Virtual IP Address assigned to the Application Gateway can be static, thus ensuring a constant IP address assignment for the lifetime of the component. This feature is particularly useful for managing rules on Azure external firewall systems and for web publishing scenarios of Azure Web App.

Header Rewrite

Header Rewrite functionality allows you to easily manage the publications of applications as it is allowed to add, remove or modify HTTP request and response headers, directly from the Application Gateway and without needing to change the code of the application.

Performance

The adoption of the new Application Gateway SKU allows a significant improvement in performance during the provisioning and during the configuration update activities. Furthermore, it shows an improvement in performance, up to 5 times higher than the previous SKU, in SSL offloading scenarios.

The recommendation

For all new implementations is raccomanded to consider the adoption of the new Azure Application Gateway SKU, while for those who are making application publications by Application Gateway V1, it is recommended that you migrate the SKU V2 quickly, for the following reasons:

  • New features and improvements: Migrating to new SKU you can benefit from the improvements and new features listed above.
  • Cost: view the new pricing policy adopted for the SKU V2, based on consumption and no longer on the size and the number of instances, this may be generally more convenient than SKU V1. For more information on the costs of the new Azure Application Gateway version, you can see the relative costs page.
  • Platform support: soon Microsoft will disable the ability to create new Application Gateway V1. Furthermore, in the future, Microsoft will release additional new features, but most of these will be released exclusively for the SKU V2.

As migration occurs to the SKU V2

Currently the Azure platform does not provide an automatic procedure to migrate from V1 to V2 SKU, but it is necessary to proceed with a side-by-side migration. To proceed with this activity is necessary a suitable preliminary analysis to verify the presence of all the necessary requirements. The migration of existing configuration can be done through Special scripts of support, but may still be required manual activities. Completed the configuration of all settings to the new Azure Application Gateway V2 you need to redirect the flow of traffic coming from client to the new Application Delivery Service.

Conclusions

The introduction of the new features described above makes the offer of application delivery controller as-a-service available in Azure platform even more complete and functional, to the point of being highly competitive with other vendor solutions, long established on the market. To be constantly updated with the rapid evolution of the cloud is recommended to determine as soon as possible the transition to the new Application Gateway version in order to benefit from the advantages mentioned above.

Azure Networking: Point-to-Site VPN access and what's new

Among the different possibilities to establish a hybrid connectivity with the Azure cloud exist VPN Point-to-Site (P2S). Through the VPN P2S you can enable connectivity from one location to the Azure environment, easily and securely. It is a useful solution to allow communication from remote locations to the Virtual Network of Azure, mostly used for test and development purposes. Can be activated alternatively to Site-to-Site VPN if you must provide connectivity to Azure for a very limited number of systems. This article describes the features of this connectivity and displays the latest news about.

To establish hybrid connectivity with Azure we can use different methodologies, each of which has different characteristics and may be eligible for specific scenarios, providing different levels of performance and reliability.

Figure 1 – Options to enable hybrid connectivity with Azure

The Point-to-Site VPN definitely provide a more limited set of features compared to other hybrid connectivity options and are appropriate in specific cases, where only a limited number of places should be connected to the Azure environment. The P2S connection is established by starting directly from the remote system and in the solution are not expected native systems to activate it in an automatic way.

Figure 2 – Comparison of hybrid connectivity options

Protocols used by the P2S VPN

The Point-to-site VPNs can be configured to use the following protocols:

  • OpenVPN®: is a protocol recently added in Azure, but already widely used by different solutions, that enriches this type of connectivity. This is an SSL/TLS based VPN Protocol, that due to its characteristics more easily traverses firewalls. Furthermore, it is compatible with different platforms: Android, IOS (version 11.0 and above), Windows, Linux and Mac devices (OSX version 10.13 and later).
  • Secure Socket Tunneling Protocol (SSTP): This is a Microsoft proprietary VPN protocol based on SSL and it can easily cross firewalls, but has the limitation that can only be used by Windows systems. In particular, Azure supports all versions of Windows that include SSTP (Windows 7 and newer).
  • IKEv2: This is an IPsec VPN solution that can be used by different client platforms, but in order to function it requires that in the firewall are permitted specific communications. IKEv2 is supported on Windows 10 and Windows Server 2016, but in order to use it you need to install specific updates and set certain registry keys. Previous versions of the OS are not supported and can only use SSTP, orOpenVPN®.

Figure 3 – OpenVPN Protocols® and IKEv2 compared

The Point-to-Site VPN require the presence of a VPN gateway on the active virtual network of Azure and depending on the SKU vary the maximum number of possible connections. It should also be taken into account that the VPN Gateway Basic does not support IKEv2 and OpenVPN protocols.

Figure 4 – Gateway SKU in comparison for VPNs P2S

Coexistence between the P2S VPN and S2S VPN for the same virtual network is possible only in the presence of VPN gateway RouteBased.

Supported client authentications

Point-to-site VPN access provides the ability to use the following authentication methods:

  • Azure native authentication using certificates. With this mode, the authentication takes place via a client certificate present on the device that needs to connect. Client certificates are generated by a trusted root certificate and must be installed on each system to connect. The root certificate can be issued by an Enterprise solution, or you can generate a self-signed certificate. The client certificate validation process is performed by the VPN gateway while attempting to connect the P2S VPN. The root certificate must be loaded into the Azure environment and is required for the validation process.
  • Authentication using Active Directory (AD) Domain Server. Thanks to this type of authentication users can authenticate using domain credentials. This methodology requires a RADIUS server integrated with AD. RADIUS system can be deployed on-premises or in the VNet of Azure. Using this mechanism, during the authentication process, the Azure VPN Gateway communicates with the RADIUS system, therefore it is essential to provide this communication flow. If the RADIUS server is deployed on-premises, must therefore be a connectivity through S2S VPN with on-premises systems. The RADIUS server can use certificates issued by an internal Certification Authority as an alternative to certificates issued by Azure, with the advantage that it is not necessary to manage Azure upload root certificates and certificate revocation. Another important aspect is that the RADIUS server can be integrated with third-party authentication mechanisms, thus opening the possibility of also use multifactor authentication for P2S VPN access. At the moment the OpenVPN® Protocol is not supported with RADIUS authentication.

Conclusions

Point-to-Site VPNs (P2S) can be very useful to provide connectivity to the Azure Virtual Networks in very specific scenarios. Thanks to the introduction of the support to OpenVPN® protocol it is possible to activate more easily and from different devices (Windows, Mac and Linux), without neglecting safety aspects.