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.
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.
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. In addition, 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) 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.
In detail the steps to adopt the solution are as follows:
- 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:
- Creating a new one Secured Virtual Hub by Azure Firewall Manager and adding virtual network connections;
- Transforming an existing Virtual WAN Hub, activating the Azure Firewall service on the Hub network.
- 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.
- 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.
- 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.
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.
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.
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.
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.
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).
From Private link center you can create new services and manage the configuration or configure existing services to take advantage of Private link.
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":
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.
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.
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.
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.
For more details please visit the Microsoft's official documentation.
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 Firewall is the firewall-as-a-service solution exists in the Microsoft public cloud, that allows you to secure the resources in Azure Virtual Networks and to govern its 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.
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.
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:
$BackupFileName = ".AzureFirewallBackup.json"
Export-AzResourceGroup -ResourceGroupName "Network-RG" -Resource $AzureFirewallId -SkipAllParameterization -Path $BackupFileName
With the availability of the JSON file you need to edit it to contemplate the Availability Zones:
After the change is complete, you can deploy the new Azure Firewall, using suitably modified JSON file, using the following command:
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 (NVAs). 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
The adoption of the new Application Gateway SKU allows a significant improvement in performance during the provisioning and during the configuration update activities. In addition, it shows an improvement in performance, up to 5 times higher than the previous SKU, in SSL offloading scenarios.
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. In addition, 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.
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.
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.
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.
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. In addition, 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®.
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.
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.
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.
In the modern era of cloud computing, the tendency is to move more frequently workloads in the public cloud and to use hybrid cloud. Security is often perceived as an inhibitor element for the use of cloud environments. Can you extend the datacenter to the cloud while maintaining a high level of network security? How to ensure safe access to services in the cloud and with which tools? One of the main reasons to use Azure, for your own applications and services, is the possibility to take advantage of a rich set of functionality and security tools integrated in the platform. This article will be a overview of network security services in Azure, reporting guidelines and useful tips to best utilize the potential of the platform, in order to structure the network in Azure respecting all security principles.
In field Azure Networking are available different services for enabling connectivity to distinct environments, according to different modes, to activate the protection of the network and to configure the application delivery. All these services are integrated with monitor systems offered by Azure, going to create a complete ecosystem for the provision of network services.
In order to configure the network protection for Azure we find the following services, available natively in the platform.
Network Security Group (NSG)
The Network Security Groups (NSGs) are the main tool to monitor network traffic in Azure. By the rules of deny and permit you can filter communications between different workloads on an Azure virtual network. In addition, you can apply filters on communications with systems that reside on-premises, connected to the Azure VNet, or for communications to and from Internet. The Network Security Groups (NSGs) They can be applied on a specific subnet of a Azure VNet or directly on the individual network adapters of Azure virtual machines. The advice is to apply them if possible directly on the subnet, to have a comprehensive and more flexible control of ACLs. The NSGs can contain rules with Service Tags, They allow you to group with predefined categories of IP addresses, including those assigned to specific Azure services (examples. AzureMonitor, Appservice, Storage, etc.).
In the rules of Network Security Groups can be referred the Application Security Groups (ASGs). These are groups that contain network adapters of virtual machines on Azure. ASGs allow you to group multiple servers with mnemonic names, useful in particular for dynamic workloads. The Application Security Groups also enable you no longer have to manage in the rules of NSGs IP addresses of Azure virtual machines , as long as these IPs are related to VMs attested on the same VNet.
Through the Virtual Network (VNet) service endpoints, you can increase the level of security for Azure Services, 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. For the supported services and get more details about this you can see the Microsoft documentation.
The Azure Firewall is a firewall, fully integrated into the Microsoft public cloud, of type stateful, which makes it possible to centrally control, through policy enforcement, network communication streams, all cross subscriptions and cross virtual networks. Azure Firewall also allows you to filter traffic between the virtual networks of Azure and on-premises networks, interacting with connectivity that is through the Azure VPN Gateway and with Express Route Gateway. For more details about it you can see the article Introduction to Azure Firewall.
Web Application Firewall
The application delivery may be made using the Azure Application Gateway, 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 on Web Application Firewall (WAF), that provides application protection, based on rules OWASP core rule sets. The WAF protects the application from vulnerabilities and against common attacks, such as X-Site Scripting and SQL Injection attacks.
In Azure, DDoS protection is available in two different tiers: Basic or Standard.
The protection Basic is enabled by default in the Azure platform, which constantly monitors the traffic and enforces real-time mitigation of the most common network attacks. This tier provides the same level of protection adopted and tested by Microsoft online services and operates for the public IP addresses of Azure (IPv4 and IPv6). No configuration is required for the Basic tier.
The Azure DDoS Protection Standard provides additional mitigation capabilities compared to Basic tier, which are optimized specifically for the resources in Azure virtual network. Security policies are auto-configured and are optimized by a specific network traffic monitoring and by applying machine learning algorithms, that allow you to profile in the most appropriate and flexible way your application studying the traffic generated. In the moment in which the thresholds set in the policy of DDoS are exceeded, DDoS mitigation process is automatically started, and it is suspended when it falls below the traffic thresholds established. These policies are applied to all public IP of Azure (IPv4) associated with resources present in the virtual network, such as: virtual machines, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway and Azure Service Fabric instances.
For more details about it you can see the article Protection from DDoS attacks in Azure.
Synergies and recommendations for the use of various security services
In order to obtain an effective network security and direct you in the use of the various components, are reported the main recommendations which is recommended to consider:
- The Network Security Groups (NSGs) and the Azure Firewall are complementary and using them together you get a high degree of defense. The NSGs is recommended to use them to filter traffic between the resources that reside within a VNet, while the Azure Firewall is useful to provide network and application security between different Virtual Networks.
- To increase the security of Azure PaaS services is advised to use the Service endpoints, which can be used in conjunction with Azure Firewall to consolidate and centralize access logs. To do this, you can enable the service endpoint in the Azure Firewall subnet, disabling the subnet present in the Spoke VNet.
- Azure Firewall provides network protection Layer 3 for all ports and protocols, it also guarantees a level of application protection (Layer 7) for outbound HTTP/S traffic. For this reason, if you wish to make a secure application publishing (HTTP/S inbound) you should use the Web Application Firewall present in the Application Gateway, then associating it to Azure Firewall.
- Azure Firewall can also be accompanied by third-party WAF/DDoS solutions.
All these security services, properly configured in a Hub-Spoke network architecture allow network traffic segregation, achieving a high level of control and security.
Azure provides a wide range of services that provide high levels of security, acting on different fronts. The security model that you decide to take, you can resize it and adapt flexibly, depending on the type of application workloads to be protected. A winning strategy can be obtained by applying a mix-and-match of different network security services, to get a protection on more layers.
A cyber attack of type distributed denial-of-service (DDoS attack – Distributed Denial of Service) is intended to exhaust deliberately the resources of a given system that provides a service to clients, such as a website that is hosted on web servers, to the point that it will no longer be able to provide these services to those who require it in a legitimate way. This article will show the security features that you can have in Azure for this type of attacks, in order to best protect the applications on the cloud and ensure their availability against DDoS attacks.
DDoS attacks are becoming more common and sophisticated, to the point where it can reach sizes, in bandwidth, increasingly important, which make it difficult to protect and increase the chances of making a downtime to published services, with a direct impact on company business.
Often this type of attack is also used by hackers to distract the companies and mask other types of cyber attacks (Cyber Smokescreen).
Features of the solution
In Azure, DDoS protection is available in two different tiers: Basic or Standard.
The protection Basic is enabled by default in the Azure platform, which constantly monitors the traffic and enforces real-time mitigation of the most common network attacks. This tier provides the same level of protection adopted and tested by Microsoft online services and operates for the public IP addresses of Azure (IPv4 and IPv6). No configuration is required for the Basic tier.
The Azure DDoS Protection Standard provides additional mitigation capabilities compared to Basic tier, which are optimized specifically for the resources in Azure virtual network. Security policies are auto-configured and are optimized by a specific network traffic monitoring and by applying machine learning algorithms, that allow you to profile in the most appropriate and flexible way your application studying the traffic generated. In the moment in which the thresholds set in the policy of DDoS are exceeded, DDoS mitigation process is automatically started, and it is suspended when it falls below the traffic thresholds established. These policies are applied to all public IP of Azure (IPv4) associated with resources present in the virtual network, such as: virtual machines, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway and Azure Service Fabric instances. This protection does not apply to App Service Environments.
The Azure DDoS Protection Standard is able to cope with the following attacks:
- Volumetric attacks: the goal of these attacks is to flood the network with a considerable amount of seemingly legitimate traffic (UDP floods, amplification floods, and other spoofed-packet floods).
- Protocol attacks: These attacks are aiming to make inaccessible a specific destination, exploiting a weakness that is found in the layer 3 and in the layer 4 of the stack (for example SYN flood attacks and reflection attacks).
- Resource (application) layer attacks: These attacks are targeting the Web application packages, in order to stop transmitting data between systems. Attacks of this type include: violations of the HTTP protocol, SQL injection, cross-site scripting and other attacks in level 7. To protect themselves from attacks of this type is not sufficient DDoS protection standard, but you must use it in conjunction with the Web Application Firewall (WAF) available in Azure Application Gateway, or with third-party web application firewall solution, available in the Azure Marketplace.
Enabling DDoS protection Standard
The DDoS protection Standard is enabled in the virtual network and is contemplated for all resources that reside in it. The activation of the Azure DDoS Protection Standard requires you to create a DDoS Protection Plan which collects the virtual networks with DDoS Protection Standard active, cross subscription.
The protection Plan is created in a particular subscription, which will be associated with the cost of the solution.
The Standard tier provides a real-time telemetry that can be consulted via views in Azure Monitor.
Any DDoS protection metrics can be used to generate alerts. Using the metric "Under DDoS attack"you can be notified when an attack is detected and DDoS mitigation action is applied.
DDoS Protection Standard applies three auto-tuned mitigation policies (TCP SYN, TCP & UDP) for each public IP address associated with a protected resource, so that resides on a virtual network with active the DDoS standard service.
To report generation, regarding the actions undertaken to mitigate DDoS attacks, you must configure the diagnostics settings.
In the diagnostic settings it is possible to also collect other logs relating to mitigation activities and notifications. For more information about it you can see Configure DDoS attack analytics in the Microsoft documentation. The metrics for the DDoS protection Standard are maintained in Azure for Moniotr 30 days.
How to test the effectiveness of the solution
Microsoft has partnered withBreakingPoint Cloud and, thanks to a very intuitive interface, it allows you to generate traffic, towards the public IPs of Azure, to simulate a DDoS attack. In this way you can:
- Validate the effectiveness of the solution.
- Simulate and optimize responses against incident related to DDoS attacks.
- Document the compliance level for attacks of this type.
- Train the network security team.
Costs of the solution
The Basic tier foresees no cost, while enabling the DDoS Protection Standard requires a fixed monthly price (not negligible) and a charge for data that are processed. The fixed monthly price includes protection for 100 resources, above which there is an additional unit cost for each protected resource. For more details on Azure DDoS Protection Standard costs you can see the Microsoft's official page.
The protection from DDoS attacks in Azure allows us to always have active a basic protection to deal with such attacks. Depending on the application criticality, can be evaluated the Standard protection, which in conjunction with a web application firewall solution, allows you to have full functionality to mitigate distributed denial-of-service attacks.
Azure Virtual WAN is a new network service that allows you to optimize and automate the branch-to-branch connectivity through Azure. Thanks to this service you can connect and configure network devices in branch to allow communication with Azure (branch-to-Azure). This article examines the components involved in Azure Virtual WAN and shows the procedure to be followed for its configuration.
The Azure Virtual WAN configuration includes the creation of the following resources.
The Virtual WAN resource represents a virtual layer of Azure network and collect different components. It is a layering that contains links to all the virtual hubs that you want to have inside the Virtual WAN. Virtual WAN resources are isolated and cannot contain common hubs.
When creating the Virtual WAN resource you are prompted to specify a location. In reality it is a global resource that does not reside in a particular region, but you are prompted to specify it just to be able to manage and locate more easily.
By enabling the option Network traffic allowed between branches associated with the same hub allows traffic between the various sites (VPN or ExpressRoute) associated with the same hub (branch-to-branch).
The site represents the on-prem environment. You will need to create as many sites as are the physical location. For example, if you have a branch office in Milan, one in New York and one in London, you will need to create three separate sites, which contain their endpoints of network devices used to establish communication. If you are using Virtual WAN partner network equipment, provides solutions to natively export this information into the Azure environment.
In the advanced settings you can enable BGP, which if activated becomes valid for all connections created for the specific site . Among the optional fields you can specify device information, that may be of help to the Azure Team in case of any future enhancements or Azure support.
A Virtual Hub is a Microsoft-managed virtual network. The hub is the core component of the network in a given region and there can be only one hub for Azure region. The hub contains different service endpoints to allow to establish connectivity with the on-prem environment. Creating a Virtual Hub involves the generation of a new VNet and optionally a new VPN Gateway. The Hub Gateway is not a classic virtual network gateway that is used for ExpressRoute connectivity and VPN and it is used to create a Site-to-site connection between the on-prem environment and the hub.
The Hubs should be associated with sites residing in the same region where there are the VNet.
Hub virtual network connection
The resource Hub virtual network connection is used to connect the hub with the virtual network. Currently you can create connections (peering) with virtual networks that reside in the same region of the hub.
Configuring the VPN device on-prem
To configure the VPN on-prem device, you can proceed manually, or if you are using Virtual WAN partner solutions, the configuration of the VPN devices can occur automatically. In the latter case the device controller gets the configuration file from Azure and applies the configuration to devices, avoiding the need to proceed with manual configurations. It all feels very comfortable and effective, saving time. Among the various virtual WAN partners we find: Citrix, Riverbed, 128 Technology, Barracuda, Check Point, NetFoundry and Paloalto. This list is intended to expand soon with more partners.
By selecting Download VPN configuration creates a storage account in the resource group 'microsoft-network-[location]’ from which you can download the configuration for the VPN device on-prem. That storage account can be removed after retrieving the configuration file.
After configuration of the on-prem device, the site will be connected, as shown in the following figure:
It also provides the ability to establish ExpressRoute connections with Virtual WAN, by associating the circuit ExpressRoue to the hub. It also provides for the possibility of having Point-to-Site connections (P2S) towards the virtual Hub. These features are now in preview.
The Health section contains useful information to check the connectivity for each Hub.
Virtual WAN is the new Azure service that enables centralized, simple and fast connection of several branch, with each other and with the Microsoft public cloud. This service allows you to get a great experience of connectivity, taking advantage of the Microsoft global network, which can boast of reaching different region around the world, more than any other public cloud providers.