- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
DDoS Protection
Azure has had DDoS protection since day one. It relies on Microsoft's internal tooling and the fact that the world's second-largest network (after the internet itself) can redirect traffic around the world when attacks happen. But this DDoS protection (now called "Basic") aims to protect the platform itself. While it protects your resources (along with everyone else's) in the cloud, it doesn't provide visibility to you as a customer from attacks specifically targeted at your resources.
DDoS Standard (currently in preview) changes that. For layer 3 and 4 attacks, it monitors your traffic patterns. Using machine learning (ML), it profiles what's normal, creates protection policies, and mitigates any deviations from these policies. For application protection, the Application Gateway web application firewall (AppGW WAF) monitors layers 3 to 7. It also protects against HTTP protocol violations and anomalies, SQL injection, request-rate limiting, and cross-site scripting. Azure will include the AppGW WAF in DDoS Standard at a discounted price.
DDoS Protection is easy to set up and protects all resources in a vNet. It integrates with Azure Monitor for alerts, insights, and analytics.
Enabling it for a new vNet is very simple (as long as you're creating the vNet in one of the preview regions). Just tick the box. It's equally easy to enable it for an existing vNet.
Enabling DDoS Protection on a vNet
To have visibility, click on Monitor in the left-hand menu of Azure and select Metrics. Select your subscription, resource group, resource type, and a public IP address as the resource. Then pick under DDoS attack or not and optionally add a metric alert to send you an email if you're under attack.
Email alert for DDoS
If you want to test the functionality, don't generate the attack traffic yourself. Rather, open a support ticket, and an engineer will contact you to arrange the test based on the ports, protocols, and IPs you want to test.
Network security group improvements
NSGs have had a few recent improvements, with more coming soon. Today you can use tags in rules such as Internet, AzureLoadBalancer, and VirtualNetwork instead of specifying IP address ranges (it keeps the tags up to date with changes in IP addresses). You can also use vNet Service Endpoints, whereas custom tags and security groupings of network interface cards (NICs) and virtual machines (VMs) should be coming soon.
As we've already covered, application security groups (ASGs) are a nifty way of grouping your resources and VMs under different names and then using those names in NSG rules.
It's all about speed
In 2016 Microsoft announced 25-Gbps networking between VMs, calling the feature Accelerated Networking (AN). Single-root input/output virtualization (SR-IOV) essentially passes a copy of the physical NIC into the VM. Along with the field-programmable gate array (FPGA) custom cards each Azure host has, Microsoft increased this to 30 Gbps in early 2018, supporting both Linux and Windows VMs. Note that even without AN, high throughput is possible, but AN lowers jitter, latency, and CPU usage.
For high throughput in third-party network virtual appliances (NVAs) such as firewalls and intrusion prevention systems, Azure is supporting Data Plane Development Kit (DPDK). This open-source project improves packet throughput on any platform.
Peer-to-peer vNets
In 2016 Azure announced the ability to connect two vNets in the same region using vNet peering. In 2017 global vNet peering (currently in preview) followed this. The traffic between the networks remains on Microsoft's backbone and as such is low-latency, high-bandwidth traffic.
You can peer Azure Resource Manager (ARM) vNets together. Note, however, that it's not transitive; if you peer A and B as well as A and C, this doesn't connect B and C.
Interestingly you can peer a (single) classic Azure Service Management (ASM) vNet to an ARM vNet, which could be useful for migrating resources or data from ASM over to the new ARM world. The vNets you are peering can't have overlapping address spaces, nor can you add address ranges to a vNet after peering it. You'll have to remove the peering, add the ranges, and re-create the peering.
While cross-region peering is in preview, you have to register your subscription for it, using PowerShell in CloudShell:
Enabling global vNet peering
Then follow the instructions here to peer two networks together.
There are considerations for peering related to on-premises connectivity, required role-based access control (RBAC) permissions, and user-defined routing (UDR); see more here. After configuring peering, you can monitor the traffic in Azure Monitor.
DNS for everyone
Azure vNets have had built-in DNS name resolution since day one for deployed VMs. However, let's say you wanted to be able to resolve internal names on your on-premises network. For example, you may be connecting through site-to-site VPN or ExpressRoute. In such cases, you had to point back to your own DNS servers or set up a VM in Azure with DNS.
Currently in managed preview is the ability to create private DNS zones in Azure without having the overhead of running an infrastructure-as-a-service (IaaS) VM. See the step-by-step instructions here.
VPN: 6x faster and now for Mac
To connect to a vNet from a single endpoint (like a sysop's laptop), Azure has always offered point-to-site (P2S) VPN. Until recently this was a Windows-only affair, but now you can use OSX (10.11 and 10.12) as well. Note that Windows 10 and Server 2016 support both the old Secure Socket Tunneling Protocol (SSTP) VPN type and the new Internet Key Exchange v2 (IKEv2), whereas Mac only supports IKEv2.
Speaking of VPN, there are new stock-keeping units (SKUs) for the VPN gateway in Azure: VpnGw1 goes up to 650 Mbps, VpnGw2 tops out at 1 Gbps, and VpnGw3 can reach 1.25 Gbps (provided your internet connection can match that speed of course). If you have high bandwidth requirements, you should consider ExpressRoute. This is a private connection to Azure with service-level agreement (SLA) guarantees—we'll cover ExpressRoute in a future post. The VPN gateway metrics now also show up in Azure Monitor.
Containers
We looked at Azure Container Service (ACS) less than two years ago, and it's a testament to how fast the cloud world moves that most of that article is now out of date. Since then, Kubernetes has established itself as the most important container orchestrator, and Azure now supports it in a managed fashion through AKS (formerly ACS). Networking has worked hard to keep up, and Azure deploys a Container Networking Interface (CNI) plug-in automatically when you use ACS with Kubernetes but not with AKS. This plug-in automates a lot of the networking for Kubernetes, but it doesn't (yet) support Kubernetes networking policies or per-pod policies.
Subscribe to 4sysops newsletter!
My next post in this series covers Azure network monitoring.
