Category Archives: Azure Networking

Azure Application delivery: which load balancing service to choose?

The transition to cloud solutions to deliver applications is a trend that is proceeding at a very fast pace and ensuring an access fast, secure and reliable to such applications is a challenging task that must be directed by adopting the right solutions. Microsoft Azure provides a wide range of services to ensure optimal application delivery, but in assessing which load-balancing solution to adopt there are several aspects to consider. This article wants to clarify what you should consider to adopt the most suitable Azure solution in this area.

The need to distribute workloads over multiple computing resources may be due to the need to optimize the use of resources, maximize throughput, minimize response times and avoid overloading every single resource. Furthermore, it can also be aimed at improving application availability by sharing a workload between redundant computing resources.

Azure load balancing services

To provide Azure load-balancing services we find the following components.

Azure Load Balancer and cross-region Azure Load Balancer: these are components that enable Layer-4 load balancing for all TCP and UDP protocols, ensuring high performance and very low latencies. Azure Load Balancer is a component zone-redundant, therefore provides high availability among availability zones.

Figure 1 – Azure Load Balancer and cross-region Azure Load Balancer overview

Azure Application Gateway: it is a service managed by the azure platform, with inherent features of high availability and scalability. The Application Gateway is a application load balancer (OSI layer 7) for web traffic, that allows you to govern HTTP and HTTPS applications traffic (URL path, host based, round robin, session affinity, redirection). The Application Gateway is able to centrally manage certificates for application publishing, using SSL and SSL offload policy when necessary. The Application Gateway may have assigned a private IP address or a public IP address, if the application must be republished in Internet. In particular, in the latter case, it is recommended to turn onWeb Application Firewall (WAF), that provides application protection, based on rulesOWASP core rule sets. The WAF protects the application from vulnerabilities and against common attacks, such as X-Site Scripting and SQL Injection attacks.

Figure 2 – Azure Application Gateway Overview

Front Door: is an application delivery network that provides global load balancing and site accelleration service for web applications. It offers Layer-7 functionality for application publishing such as SSL offload, path-based routing, fast failover, caching, in order to improve the performance and high availability of applications.

Figure 3 – Azure Front Door Overview

Traffic Manager: is a DNS-based load balancer that enables optimal distribution of traffic to services deployed in different Azure regions, while providing high availability and responsiveness. Are available different routing methods to determine which endpoint to direct traffic to. Based on DNS, failover may not be immediate due to common challenges related to DNS caching and systems not meeting DNS TTLs.

Figure 4 – Azure Traffic Manager Overview (performance traffic-routing method)

Things to consider when choosing Azure load balancing services

Each service has its own characteristics and to choose the most appropriate one it is good to make a classification with respect to the following aspects.

Load-balancing services: global vs regional

  • Global load-balancing: are used to distribute traffic to globally distributed backends across multiple regions, which can be deployed in cloud or hybrid environments. Fall into this category Azure Traffic Manager, Azure Front Door and the cross-region Azure Load Balancer.
  • Regional load-balancing: they allow you to distribute traffic to virtual machines connected to a specific virtual network or to endpoints in a specific region. This category includes Azure Load Balancer and the Azure Application Gateway.

Type of traffic: HTTP(S) vs non-HTTP(S)

Another important differentiating factor in the choice of the load-balancing solution to be adopted is the type of traffic that must be managed:

  • HTTP(S): the adoption of Layer-7 load-balancing services that accept only HTTP traffic is recommended(S). They are suitable for this type of traffic Azure Front Door and Azure Application Gateway. Typically they are used for web applications or other endpoints HTTP (S) and include features such as: SSL offload, web application firewall, path-based load balancing, and session affinity.
  • Non-HTTP(S): the use of load-balancing services is required that allow to contemplate the traffic non-HTTP (S), such as Azure Traffic Manager, cross-region Azure Load Balancer and Azure Load Balancer.

In the evaluation of the Azure load-balancing service to be adopted, it is also appropriate to include considerations regarding the following aspects:

To facilitate the choice of the load-balancing solution, the following flow chart can be used as a starting point, which directs the choice on a series of key aspects:

Figure 5 – Flowchart for choosing azure load-balancing solution

Note: This flowchart does not cover the cross-region Azure Load Balancer as at the moment (11/2020) are in preview.

This flow chart is a great starting point for your evaluations, but since each application has unique requirements it is good to carry out a specific more detailed analysis.

If the application consists of multiple workloads, it is appropriate to evaluate each of these separately, as it may be necessary to adopt one or more load balancing solutions.

The various load load-balancing services can be used in combination with each other to ensure reliable and secure application access to the services provided in environments IaaS, PaaS or on-premises.

Figure 6 – Possible example of how to combine the various Azure load-balancing services

Conclusions

Thanks to a wide range of global and regional services, Azure is able to guarantee performance, security and high availability in application access. In order to establish the architecture that best meets your needs, there are several elements to evaluate, but the right combination of Azure Application Delivery solutions can deliver significant value to IT organizations, ensuring a distribution that is fast, secure and reliable for applications and user data.

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.

How to configure the Azure Bastion service to securely access virtual machines

Azure Bastion is a PaaS service that provides secure and reliable RDP and SSH 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 having to assign public IP addresses directly to systems. This article describes how to activate the service and what things to consider.

Azure Bastion deployment is per virtual network and not per subscription or per single virtual machine. Therefore, after the configuration is complete, you will be able to access directly from the Azure portal all the virtual machines attested on the Host Bastion virtual network.

Activating the Azure Bastion service requires:

  • One subnet at least /27, which should be called AzureBastionSubnet and on which the Bastion host will be attested. On this subnet is not currently supported the configuration of User Defined Routes.
  • A Static Public IP address that will be assigned to the Bastion resource. The public IP must be standard SKU and must be in the same Azure region on which you want to activate the service.

On the subnet AzureBastionSubnet you can apply a specific Network Security Group (NSG). NSGs are the primary tool for controlling network traffic in Azure and allow you to filter communications with deny and permit rules.

To do this, you should review the network traffic required for Azure Bastion:

Figure 1 – Network flows required for Azure Bastion

The Network Security Group (NSG) on the subnet AzureBastionSubnet must include the following rules.

Inbound security rules

  • Inbound traffic from Internet: Azure Bastion Public IP address must be accessed on TCP port 443. The ports 3389/22 *are non required.
  • Inbound traffic from the Azure Bastion control plane. You need to enable the port 443 inbound using the service tag GatewayManager. This allows the control plane, (Gateway Manager), to be able to communicate with Azure Bastion.

Figure 2 – AzureBastionSubnet NSG – Inbound security rules

Outbound security rules

  • Outbound traffic to target VMs: Azure Bastion will reach the destination VMs via private IP address. NSGs must allow outbound traffic to other destination subnets for ports 3389 and 22.
  • Outbound traffic to other public endpoints in Azure. Azure Bastion must be able to connect to various public endpoints within Azure (For example,, to store diagnostic logs and metering logs). That's why, Azure Bastion must be allowed to exit with the port 443 towards the service tag AzureCloud.

Figure 3 – AzureBastionSubnet NSG – Outbound security rules

For the subnet on which the machine that needs to be accessed by Azure Bastion is attested, the following rules must be provided.

Inbound security rules

  • Inbound traffic from Azure Bastion: Azure Bastion will reach the destination VM via private IP on ports RDP / SSH (ports respectively 3389 and 22). Therefore, as best practice, you can only add the Azure Bastion subnet as the source in this rule.

Figure 4 – NSG on the target subnet

The creation of the Azure Bastion host can be done directly from the Azure portal by completing the following steps:

Figure 5 – Adding the Azure Bastion service

Figure 6 – Parameters required when creating the Azure Bastion service

After configuring the Azure Bastion service, you can use it as follows.

Figure 7 – Accessing a VM from the Azure portal

Figure 8 – Enter credentials to sign in to a VM from the Azure portal

Figure 9 – RDP access to the VM directly from the browser

To allow access to the service, you must assign the following roles:

  • Reader role on the virtual machines that you want to allow access to
  • Reader role on NICes with virtual machine private IP address
  • Reader role on Azure Bastion resource

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

Conclusions

Azure Bastion guarantees simple and secure remote access to systems in the Azure environment. There are several features that will be released soon for this service and that will make it even more complete and flexible. These include support for Virtual Network in peering and multi-factor authentication.

Azure Networking: how to secure Window Virtual Desktop deployments

Windows Virtual Desktop is a full desktop and application virtualization service available in Azure that, in a period like this, where work from home has increased exponentially, has seen wide adoption. Enabling your employees to work from home requires organizations to address major changes in their IT infrastructure in terms of capacity, network, security and governance. The Virtual Desktop Infrastructure solution (VDI) in Azure can help business companies effectively address these evolutions, but you need to protect access to these VDI environments appropriately. This article describes how you can structure networking in Azure to effectively protect Windows Virtual Desktop deployments.

In order to adopt the right approach, it is necessary to evaluate which are the components of Windows Virtual Desktop (WVD) and their iterations. The service is distributed according to a shared responsibility model and sees:

  • RD Clients connected to the desktops and applications provided by the WVD service. The environment can be reached from any location with Internet access and client management falls under the customer's responsibilities.
  • Managed Azure Services responsible for piloting connections between RD clients and Windows virtual machines in Azure. These are the server roles that are required for this environment, such as Gateways, Web Access, Brokers and Diagnostics, fully managed by Microsoft.
  • Virtual machines in Azure attested on a virtual network, whose management is totally in charge of the customer.

Figure 1 – Shared Responsibility model di Windows Virtual Desktop

To secure your Windows Virtual Desktop environment, you must define the most appropriate network topology and the necessary communication flows.

Hub-Spoke Network Topology for Windows Virtual Desktop

In a Hub-Spoke network architecture, theHub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. TheSpoke are virtual networks running the peering with the Hub and can be used to isolate workloads. A good approach would therefore be to structure Azure networking by adopting this network topology right away and place the Windows Virtual Desktop virtual machines on a Spoke network. This network architecture is also designed to place in the Hub network a network virtual appliance (NVA) to control network flows centrally. Control of network communications can be assigned to a network virtual appliance (NVA) or to Azure Firewall, Microsoft's managed and fully integrated public cloud service, that allows you to secure the resources present on the Virtual Networks of Azure.

Figure 2 – Hub-spoke network topology in Azure

Communication flows required for Windows Virtual Desktop

There are several communication flows that need to be predicted and that thanks to the Hub-Spoke network topology you can easily and centrally govern.

Figure 3 – Communication flows for the Windows Virtual Desktop environment in the Hub-Spoke topology

Windows Virtual Desktop does not require that you have to open inbound communication streams to the virtual network on which its virtual machines are attested.

However, in order for the service to work properly, you must provide access from WVD machines, attested on the spoke virtual network, towards specific Fully Qualified Domain Names (FQDNs). The full list of addresses required for Windows Virtual Desktop to work can be found in this Microsoft's document. To simplify this configuration, Azure Firewall has the appropriate tag FQDN called WindowsVirtualDesktop, that you can use in a specific application rule. In this regard, it is good to specify that this tag does not include access to the storage and service bus accounts required for Windows Virtual Desktop pool hosts. As deployment-specific URLs, you can go to allow https traffic on time to specific URLs, or you can use the wildcard for the following FQDNs: *xt.blob.core.windows.net, *eh.servicebus.windows.net and *xt.table.core.windows.net. These FQDN tags are also present in third-party Virtual Appliances to facilitate configuration.

Windows Virtual Desktop machines must also have access to DNS servers, KMS service for activation jobs and NTP servers for time synchronization.

Depending on your business needs, you may also need to enable Internet access for end users, optionally applying specific navigation rules. A secure web gateway located on-premises or the network virtual appliance located in the Hub network can be used to filter Internet traffic.

Finally, you should allow the necessary communication flows between Windows Virtual Desktop machines, placed in the Spoke network, resources that reside in the on-premises environment.

Conclusions

One of the first aspects to consider when you implement solutions in the cloud is the network architecture to be adopted. Establishing the most appropriate network topology from the outset allows you to have a winning strategy and avoids being in the condition of having to migrate workloads later, to adopt different network architectures, with all the complications that ensue. The Hub-Spoke network architecture also lends itself well for Windows Virtual Desktop deployment scenarios, as it allows to obtain a high level of control on aspects related to network security and to segregate network traffic by adopting Azure Firewall or third-party Network Virtual Appliance.

Azure Networking: IP address management for outbound traffic from Azure

When designing architectures in Azure, it is often important to accurately determine which public IP addresses are used for outbound network traffic. A commonly required requirement is to ensure that outbound traffic from the Azure virtual network occurs with established public IP addresses. This requirement is typically due to the need to explicitly authorize traffic from Azure on other resources. This article describes how in Azure you can govern this aspect, what are the elements to be taken into consideration and what innovations have recently been introduced in this area.

By default, outbound traffic from an Azure virtual network uses randomly allocated public IP addresses, and they can change.

Public IP Assignment to the Single Virtual Machine

When you need to fix the Public IP address for the outbound traffic of a single virtual machine, the easiest method is to assign a Public IP address to it. This IP address will be used for inbound traffic, if necessary, and for outbound traffic. Through Network Security Groups (NSGs), the primary tool to control network traffic in Azure, you can filter communications with deny and permit rules.

Public IP Assignment to Load Balancer

Instead of assigning a public IP address directly to a virtual machine, you can assign it to a load balancer. In this way, any virtual machine added to the load balancer back-end pool will use the public IP assigned to it for outbound network traffic.

Figure 1 – Load Balancer with Public IP

This approach is recommended if there is a real need to use a Load Balancer to balance inbound network traffic across multiple virtual machines. This also allows you to limit the number of public IPs required, configuring multiple virtual machines behind the same load balancer.

Using Azure Firewall

If you have Azure Firewall, if network traffic is appropriately channeled to this component through specific routes, you are sure that it will go out to the Internet using the Public IPs assigned to the Azure Firewall instance. You can associate to Azure Firewall up to 250 public IP addresses, However, consider that the Azure Firewall Source Public IP address used for connections is currently randomly chosen from the assigned IPs. This is something to consider when you need specific permissions for traffic from Azure Firewall and whether you need to manage access to FTP Passive (unsupported if Azure Firewall has multiple IP addresses assigned). Microsoft still has a roadmap of SNAT configurations by specifying the Public IP address to use.

Figure 2 – Azure Firewall overview

Azure Firewall is an increasingly popular component and its activation is recommended to better manage and govern network traffic. However, In the absence of this component it is possible to evaluate less expensive alternative methods if the only goal is to govern which IP addresses are used in outbound network traffic.

Virtual Network NAT

Virtual Network NAT is a new method that was recently introduced to simplify Internet connectivity in virtual networks and affects outbound network traffic only. If configured on a subnet, all outbound traffic will use the specified static public IP addresses. All this is possible without the adoption of public IP addresses directly linked to virtual machines and load balancers.

Figure 3 – Virtual Network NAT

A subnet can then be configured by specifying which NAT Gateway resource to use. When configuration is complete, all outbound network flows (UDP and TCP) from any virtual machine attested on that subnet, will use the Public IP (standard SKU), the Public IP Prefix or a combination of these. The same NAT Gateway resource can be used by multiple subnets, as long as they belong to the same Virtual Network.

Virtual Network NAT is compatible with the following resources, having Standard SKUs:

  • Load balancer
  • Public IP address
  • Public IP prefix

These components, used in conjunction with Virtual Network NAT provide inbound Internet connectivity to subnets. Virtual Network NAT instead manages all internet connectivity outbound from the subnet. The joint use of these components is possible as they are aware of the direction in which the flow was started and allow them to be managed correctly.

Figure 4 – Virtual Network NAT flow direction

The guaranteed SLA for this feature is 99.9%, as it is automatically distributed by the platform on multiple fault domains to best support any fault.

Virtual Network NAT is by default a regional service and you can isolate it in a specific area (zonal deployment), when you have to contemplate scenarios that adopt different availability zones.

Figure 5 – Virtual Network NAT with availability zones

To monitor the usage of this component and to perform troubleshooting operations, you can review the metrics exposed in Azure Monitor:

  • Bytes
  • Packets
  • Dropped Packets
  • Total SNAT connections
  • SNAT connection state transitions per interval.

NSG flow logging is not currently supported for Virtual Network NAT.

The cost of this component is due to two factors:

  • Hours of resource existence
  • Processed data

For more details on costs please visit the Microsoft pricing page for this component.

Conclusions

To govern which IP addresses are used by systems in Azure to communicate externally there are several possibilities, each with its own characteristics. If you are adopting the Hub-spoke network topology with an Azure Firewall in the Hub network, control is guaranteed by design. A great solution in the absence of Azure Firewall or other Network Virtual Appliances is the adoption of the methodology Virtual Network NAT recently introduced.

Training: Cloud Community with the school to explore the digital world

We are pleased to inform you that our community will participate in a major training project dedicated to the classes fourth and fifth of the’State Higher Institute P. Gobetti in Scandiano (RE).

The training initiative in two months will involve about 50 Guys. It is a training course specifically designed to bring students closer to the big digital topics. The following are the themes covered during this project.

Automation with Powershell

Powershell is Microsoft's multi-platform shell designed to automate and make repeatable administrative operations on IT systems. Automation makes certain and repeatable operations applied to a few units or thousands of systems. In this introductory module, you will limit ourselves to the management of the Windows platform and you will not cover themes related to the Linux platform.

Goals

Making students able to:

  • Identify different versions of Powershell and usage scope
  • Describe powershell features, search and perform basic commands
  • Use powershell pipeline
  • Working with variables, array and hash tables
  • Write a simple powershell script
  • Run remote powershell commands and scripts

Prerequisites

  • Object programming logic
  • Understanding the basic mechanisms for authentication and authorization in an Active Directory Domain

Teacher

Cloud Networking in Hybrid Environments

Enterprise IT is no longer limited to proprietary networks between locations or factories, the public cloud in its various forms is now a fundamental component of any IT architecture. The ability to interconnect systems and services is the first brick for building a hybrid environment between public and private (on-premises). In this module, students will be able to understand public cloud networking and connect the public cloud with the private network.

Goals

Making students able to:

  • Identify major public cloud providers
  • Describe the different types of cloud computing
  •  Describe cost management differences between proprietary systems and cloud computing (if they also study economics there may be a reference to the difference between capital expenses and operational expenses)
  • Describe what virtual networking is all about, and in particular, Microsoft Azure virtual network concepts
  • Gather the information you need to create a virtual network on Microsoft Azure
  •  Creating subnets into virtual networks, define routing rules and network security groups
  • Know the different types of connectivity between different virtual networks and between virtual networks and private networks
  • Connect an Azure virtual network with a private on-premises network
  • Security overview for public cloud virtual networks.

Prerequisites

  • Knowledge of the tcp/ip protocol and routing modes

Teacher

Conclusions

The main goal of this community initiative is to help and incentivize young talents to grow and train for digital professions. Thanks to this training course, it will be possible for young participants to approach the world of work with greater awareness and a wider vision..

How to activate an SFTP service in Azure based on Container

A communication protocol that is commonly used for transferring files between different business realities is certainly SFTP (SSH File Transfer Protocol or Secure File Transfer Protocol). To date, Azure does not have a fully managed platform service that allows you to provide access over the SFTP protocol. Activating a virtual machine in Azure that hosts the SFTP service incurs activation costs and a significant management effort. This article provides a solution that you can use to deliver the SFTP service to Azure in an Azure environment., Azure Container Instances (ACI) and Azure File Shares.

The proposed solution is based on the following components::

  • Azure Container Instances (ACI), It is the easiest and quickest way in Azure to run containers on-demand in a managed serverless environment. All this is made possible without having to activate specific virtual machines and the necessary maintenance is almost negligible. The solution Azure Container Instances is eligible in scenarios that require isolated containers, without the need to adopt an orchestration system. The service Azure Container Instances costs depend on the number of vCPUs and memory GBs used by the container group.. For more details on costs please visit the Microsoft official page.
  • Azure File, the managed Azure service that allows you to access file shares in the cloud through the Server Message Block (SMB).

Figure 1 – Azure architecture

You will then be activated Linux-based docker container to deliver the SFTP service through Azure Container Instance (ACI). In order to have a persistent storage access from the container it will be made the mount of an Azure Files Shares. Files transferred via the SFTP service will therefore also be accessible via SMB protocol, managing the appropriate permissions, also stopping the execution of the container created.

To deploy this solution, you can use the referenced templates as a starting point in this Microsoft's document. These are two templates, where the first also involves creating a storage account, but of type V1.

Figure 2 – Deployment via custom template

In order to get a proper integration with existing Azure environments and to ensure a filtered access to the SFTP service you must deploy instances of containers inside an Azure virtual network. To do this, you need to enable a feature in preview, and as such has some limitations, between which does not support peering of virtual networks. In this scenario, if the SFTP service is required to be published to the internet, this will necessarily have to take place via Azure Firewall, as it is not supported directly assigning Public IP to Azure Container configured in Virtual Network. In order to improve the security postures of your Azure environment, it is also recommended that:

  • Take a micro-segmentation and granular perimeter definition approach in Azure network architecture. To do this, addition to the adoption of Azure Firewall, you need to plan for the use of the Network Security Groups (NSGs), the tool used to segregate network traffic internally with the Azure Virtual Network. Through deny and permit rules can be filtered communications between different subnets where different application workloads are attested.
  • Predicting the use of Virtual Network (VNet) service endpoints to increase the security level of the Storage Account, preventing unauthorized access. The vNet Service Endpoints allow you to isolate the Azure services, allowing access to them only by one or more subnets defined in the Virtual Network. This feature also ensures that all traffic generated from the VNet towards the Azure services will always remain within the Azure backbone network.

To complete this solution, you must also have a data protection strategy that is placed on the storage account through the SFTP service. Content transferred via SFTP service to Azure file shares can be backed up using the Azure Backup. Again, this is at the time of a feature in preview, so you can have a protection with a daily frequency.

To date, as an alternative to this solution, you can adopt third-party solutions available in the Azure marketplace to deliver the SFTP service. These are significantly more expensive solutions that typically require more effort to deploy and manage them.

Conclusions

Waiting for Microsoft to release a fully managed SFTP service in Azure, this solution enables this service quickly and easily, with reduced costs and without having to maintain and manage virtual machines. The adoption of this solution need integration with other Azure services platform to implement it effectively, without neglecting the safety aspect. At the time you may need to use services in preview, but not officially supported in a production environment.

[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 the network architecture. To facilitate this approach, Microsoft has released this tool that, providing a single centralized control panel, , it is able to simplify the configuration and management of network security policy, often deployed across multiple instances of Azure Firewall.

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.