Failed to add new rule: IpSecurityRestriction.VnetSubnetResourceId is invalid.

This post is focused on a scenario where you are creating an Access Restriction rule in an Azure App Service to allow client requests from a subnet in a Virtual Network (VNET) and you get this error:

Failed to add new rule: IpSecurityRestriction.VnetSubnetResourceId is invalid. For request GET https://management.azure.com/subscriptions/xxxxxx/resourceGroups/xxxxxx/providers/Microsoft.Network/virtualNetworks/xxxxxx/taggedTrafficConsumers?api-version=2018-01-01 with clientRequestId xxxxxx and correlationRequestId xxxxxx, received a response with status code Forbidden, error code AuthorizationFailed, and response content: {“error”:{“code”:”AuthorizationFailed”,”message”:”The client ‘xxxxxx’ with object id ‘xxxxxx’ does not have authorization to perform action ‘Microsoft.Network/virtualNetworks/taggedTrafficConsumers/read’ over scope ‘/subscriptions/xxxxxx/resourceGroups/xxxxxx/providers/Microsoft.Network/virtualNetworks/xxxxxx’ or the scope is invalid. If access was recently granted, please refresh your credentials.”}}.

The Scenario

The customer wanted to deploy Standard Tier Azure App Services with some level of security in a hub and spoke architecture. The hub is in Subscription A. There a virtual network with an Azure Application Gateway (WAG)/Web Application Firewall(WAF) is deployed into a VNET/subnet. The WAF subnet has the Microsoft.Web Service Endpoint enabled, allowing the WAF to reverse proxy web requests via the direct path of the Service Endpoint to the App Service(s).

The App Service Plan and App Services are in Subscription B. The goal is to only allow traffic to the App Services via the WAF. All the necessary DNS/SSL stuff was done and the WAF was configured to route traffic. Now, the customer wanted to prevent requests from coming in directly to the App Service – an Access Restriction rule would be created with the Virtual Network type. However, when we tried to create that rule, it failed with the above security error.

Troubleshooting

At first, we thought there was an error with Azure Privileged Identity Management (PIM), but we soon ruled that out. The customer had Contributor rights and I had Owner rights over both subscriptions and we verified access. While doing a Teams screen share the customer read an article about Azure Key Vault with a similar error that indicated an issue with Resource Providers. We both had the same idea at the same time.

Solution

In the WAF subscription, enable the Microsoft.Web resource provider. This will allow the App Service to “configure” the integration with the subnet from its own subscription and solves the security issue.

Microsoft Ignite 2019 – Top 10 Azure Governance and Adoption Best Practices

Speaker: Nathan Lasnoski, Concurrency, MVP

Prepare & Execute

Picture of a tri-athlete. Riding on perfect smooth surface with perfect picture with hands off the brakes. The person is prepared – set up well. Azure operators & devs should be like this. Ready, confident, and on a smooth road with a great experience with no sudden stops.

Preface – Getting Started

Cloud Maturity Curve.

  • Legacy: On-prem, business not enabling. IT is a blocker to innovation.
  • Legacy +: IT stagnant. Scattered cloud across the business.
  • Platform: Target today – operationalized loud. Goverened.
  • Product:
  • Innovation
  • Fusion: Technology fully business integrated.

What is an “Azure Environment”?

  • Operated by the corporation
    • Runs with standards, policies, controls
  • Diverse workload enablement, powers innovation
    • Servers, containers, serverless, PaaS, AI, digital ledger
  • Stakeholder management
    • Delegated to targeted teams, under corporate oversight
  • Representative of technology investments
    • Areas like cost should relate to intended investment areas/business value. IT is not the bucket of all IT spend – Those spending should care about the things they pay for.

Number 1 – Employee Organizational Change and Operations

Transformation of organization, tied to DevOps

  • Increased multi-skill frameworks
  • Emphasis on code, repeatability, automation

New products/projects made up of:

  • Cloud architecture & operations
  • Innovation and business enablement
  • Application and Product DevOps Teams
  • Security

Number 2 – Define an operational and leave adoption strategy

High level view of a cloud program – diagram in the slides.

  • Define an iterative cloud program whith a MVP motion on operations
    • OPERATIONAL STANDARDS, PROVISIONING PROCESS, WIKI, MOTIONS
  • Be careful about overreaching – Corporation has a bad relationship with IT.

Number 3- Be a Blueprint That is Manageable

A structure of management groups and subscriptions, with limited resource groups.

Left-hand IT, Right-side business. Top – management groups, bottom – IT. Why split corp IT and business areas should be in different subscriptions/management groups.

Using 1 overloaded sub is BAD, even is MS people recommend it (AGREED!). RBAC, cost-management, quotas, etc.

Number 4 – Approaches for provisioning short-term and long-term

Using a portal for provisioning. It’s a manual process. Azure Portal, ServiceNow, whatever – minimise their usage. Problem with portals is that all the old manual problems of on-prem follow to the cloud. No documentation on config. No repeatability. No change control.

Source Code Release (Azure DevOps) > Control Plane (ARM, Policy) > Deployment.

Subscriptions should be read-only. Only time you use the portal to deploy/config should be sandboxes. Enterprise deployments should be done as code:

  • ARM
  • Script
  • Program code

This includes 3rd party stuff you put in VMs.

This is the right way to start. And it prepares you for PaaS, e.g. AKS, App Services, etc.

Number 5 – Define Structures for Naming and Tagging

You cannot work in the cloud long-term without this.

Critical tags:

  • Owning team
  • Business unit
  • Application Name
  • Classification (security)
  • Environment moniker (dev, test, production, etc)
  • Cost Center

Number 6 – Recovery and re-deployment approaches

  • Assume re-deployment at every level, especially corp-IT.
    • The Corp IT infrastructure is code too, store it in a code repository
    • Build based on release management pipeline
  • Re-deployability such as AKS
    • Re-deployable app environments
      • AKS
      • App Services
      • Data services
      • Functions
      • OAM, RUDR, DAPR

Number 7 – Adapt Security Controls For The Cloud

Movement to vertical network design. On-prem IT is flat and horizontal and things talk directly to things. In the cloud, direct connections should be limited with micro-segmentation – see previous blog posts.

This is easier to do in the cloud, and it should be done during migration and new-builds. According to Nathan, it’s one of the reasons to migrate to the cloud at all!

Use Azure Security Center to assess the environment and monitor it from a security perspective. Leverage automated responses to react, e.g. playbooks in Azure Sentinel. Use custom policies to audit Azure too.

Admin accounts:

  • Segment addresses – don’t use admin email accounts for Azure accounts.
  • Limit owner rights. Contributor at most. Read-only ideally in production.
  • Use PIM (AAD P5) to limit access but require rights escalation for admins. Consider approval.
  • Use MFA. Less than 8% of Azure tenants have MFA enabled.

RBAC applied to applications

  • Teams only get access to necessary RGs/subscriptions.
  • Admin owner credentials are different than application credentials
  • Deployments are encouraged to be automated from source code.

Number 8 – Monitoring responsibilities change as application owners take more responsibility

  • Corp IT is responsible for “cloud IT”.
    • Standards policies, connectity – not just things that go bump in the night
    • Ensures governance is applied, monitors for aggregate issues
  • Security might be a separate group
    • Measuring security compliance, reacting to incidents
    • Runs against playbooks but moving declaratively
  • Application teams
    • Own operational monitoring and reacting to their services
    • DevOps teams operating stuff

Azure Monitor/Logs provides data access via resources now that reflects RBAC to resources.

Number 9 – What do I do with my CMDB and how does it change?

  • Original function of the CMDB was to contain configuration data
  • Modern environment is quarriable platform, declarative config, DevOps

Resource Graph and DevOps can be your living always correct CMDB.

Number 10 – Building a methodology for cost reviews and organizational discipline

  • Tags are critical to cost analysis
    • Use policy enforced tagging regimes
    • Apply tags as needed for accounting purposes
  • Be able to judge costs on:
    • Owner
    • Business unit
    • Application
    • Technology
    • Dev/Prod/QU
  • Options:
    • Azure Cost Management
    • Custom PowerBI

Controlling Costs:

  • Setting budgets
  • Analysis and improvement
  • Limit high spenders
  • Optimize sizing
  • Cost management team should pay for itself.

Microsoft Ignite 2019 – Deliver Highly Available Secure Web Application Gateway and Web Application Firewall

Speaker:

  • Amit Srivastava, Principal Program Manager, Microsoft

Mission Critical HTTP Applications

  • Always On
  • Secure
  • Scalable
  • Telemetry
  • Polygot – variety of backed, IaaS, PaaS, on-prem

Many things to think about.

What Azure Pieces Can We Use?

  • WAG
  • AFD
  • CDN
  • WAF
  • Azure Load Balancer
  • Azure Traffic Manager

WAG

Regional ADS as a service. A full reverse proxy. It terminates the incoming connection and creates a new one to the web server.

  • Platform managed: built-in HA and sclability
  • Layer 7 load balancing: URL path, host based, round robin, session affinity, redirection
  • Security and SSL management: WAF, SSL Offload, SSL re-encryption, SSL policy
  • Public or ILB: Public internet, internal or both.
  • Flexible backends: VMs, VMSS, AKS, public IP, cloud services, ALB/ILB, On-premises
  • Rich diagnostics: Azure monitor, log analytics, network watcher, RHC, more

Standard v2 SKU in GA

  • Available in 26 regions
  • Built-in zone redundancy
  • Static VIP
  • HTTP header/cookies insertion/modification
  • Increased scale limits 20 -> 100 listeners
  • Key vault integration and autorenewal of SSL certs (GA)
  • AKS ingress controller (GA)

Autoscaling and performance improvements:

  • Grow and shrink based on app traffic requirements
  • 5 x better SSL offloads performance
    • 500-50,000 connections/sec with RSA 2048 bit certs
    • 30,000, 3,000,000 persistent connections
    • 2,500 – 250,0000 HTTP req/sec
  • 75% reduction in provisioning time ~5mins

Key Vault Integration in v2 GA

  • Front end TLS cert integrated with Azure Key Vault
  • Utilizes user-assigned management identity for access control on key vault
  • Use certificate or secrets on Key Vault
  • Pools every 4 hours to enable automatic cert renewal – you can force a poll if you need to
  • Manual override or specific certificate version retrieval

WAG v2 Header Rewrites

  • Manipulate request and response headers and cookies
    • Strip port from x-forwarded-for header
    • Add security headers like HSTS and X-XSS-Protection
    • Common header manipulation ex: HOST, SERVER
  • Conditional header rewrites … something

Ingress Controller

  • Ingress controller for 1+ AKS clusters at one time
  • Deployed using HELM – newer easier options by EOY
  • Utilized pod-AAD for ARM authentication
  • Tighter integration with AKS add-on support upcoming
  • Supports URI-path based, host based, SSL termination, SSL re-encryption, redirection, custom health probes, draining, cookie affinity.
  • Support for Let’s Encrypt provided TLS certs
  • WAF fully supported with custom listener policies
  • Support for multiple AKS as backend
  • Support for mixed mode- both AKS and other backend types on the same application gateway.

http://aka.ms/appgawks

Application Gateway Wildcard Listener

  • Managed preview
  • Support for wildcard characters in listener host name
  • Supports * and ? characters in host name
  • Associate wildcard or SAN certs to serve HTTPS

Telemetry Enhancements

  • GA
  • Diagnostics Log Enhancements
    • TLS protocol version, cipher spec selected.
    • Backend target server, response code, latency.
  • Metrics Enahncements
    • Backend response status code
    • RPS/healthy node
    • End-to-end latency
    • Backend latency
    • Backend connect, first byte, and last byte latency.

Azure Monitor Insights for Application Gateway

  • Public Preview
  • Sign health and metric console for your entire cloud network#
  • No agent/configuration required
  • Visualize the structure and functional dependencies
  • More

AKS Demo

He loads a Helm YAML config to the AKS cluster. Now the AKS cluster can configure listers, backend pools, rules, etc for the containers/services running on the cluster. Pretty cool.

Azure WAF

Cloud native WAF

  • Unified WAF offering
    • Protect your apps at network edge or in region uniformly
  • Public preview:
    • Microsoft threat intelligence
      • Protect apps against automated attacks
      • Manage good/bad bots with Azure BotManager RuleSet
    • Site and URI pathc specific WAF policies
      • Customise WAF policies at regional WAF for finer grained protection at each host/listener or URI path level
    • Geo-filtering on regional WAF

WAF

  • HA, scalable fully platform managed
  • Auto-scaling support
  • New RuleSet CRS 3.1 added, will soon be the default
  • Integration with Azure Sentinel SIEM
  • Performance and concurrency enhancements
  • More

WAF Policy Enhancements

  • Assign different policies to different sites behind the same WAF
  • Increased configurability
  • Per-URI policy

Geo Filtering Public Preview

  • Block, allow, log countries.
  • Easily configurable in WAF policy
  • Geo data refreshed weekly

Only in special Portal URI at the moment – normal Azure Portal soon.

Bot Protection (Public Preview)

  • Stuff

Microsoft Ignite 2019 – Building and Managing Distributed Micro-Perimeters With Azure Firewall

Speaker: Yair Tor, Principal Program Manager

Azure Firewall

Cloud native stateful firewall as a service. A first among public cloud providers.

  • Central governance of all traffic flows
    • Built in high availability and auto scale
    • Network and application traffic filtering
    • Centralized policy across VNets and subscriptions
  • Complete VNet protection
    • Filter outbound, inbound, spoke-spoke
  • Centralized logging
  • Best for Azure

Key Features

  • Application Rules
  • Fully stateful network rules
  • NAT support
  • Threat Intelligence (GA this week)
  • Monitoring
  • Support for inbound and hybrid connections
  • Network Watcher integration

Azure Firewall Updates

  • Recently released
    • Multiple public IPs GA – up ot 100
    • Availability zones now GA (99.99% SLA)
    • Threat Intelligence based filtering now GA
    • Azure HDInsight (HDI) FQDN tag GA
    • TDS (SQL) FQDN filtering in Preview
  • Sovereign Clouds
    • US Gov
    • China
  • Coming soon: tentative ETA H2 CY 2019
    • FQDN filtering for all ports and protocols
    • Native forced tunnelling support
    • IP groups in Azure Firewall rules – coming to NSG and UDR too.

Azure Firewall Manager – See Previous Post

Preview

  • Central deployment and configuration
  • Automated routing
  • Advanced security with 3rd party SECaaS

Roadmap:

  • Virtual network support – this is the legacy form of Azure Firewall that is not the new Azure vWAN Hub Azure Firewall.
  • Split routing

Public Preview

  • Extend your security edge to Azure with Secured Virtual Hubs.
  • A secured virtual hub is an azure Virtual WAN Hub with associated security and routing policies configured by Azure Firewall Manager.
  • Easily create hub-and-spoke architectures with cloud native security services for traffic governance and protection.
  • Azure Firewall now integrated with Virtual WAN Hubs.
  • Secured virtual hub can be used as a managed central network with no on-prem connectivity.
  • There is no resource called Security Virtual Hub – it’s more of a deployment/concept. If you did a JSON deployment, it would use legacy resources.

Getting Started with Secured Virtual Hubs

One method:

  1. Create your hub and spoke architecture
  2. Select security providers: Done by secured virtual hub creation or by converting a Virtual WaN hub to secure virtual hub.
  3. Create a firewall policy and associate it with your hub: applicable only if using Azure Firewall
  4. Configure route settings on your secured hub to attract traffic: Easily attract traffic to the firewall from the spoke VNets – BGP!

Demo

Network rules are always processed before application rules in Azure Firewall. Inherited policy cannot allow stuff that parent policy denies.

Central Security and Route Policy Management

  • Deploy and configure multiple Azure Firewall instances
  • DevOps optimized hierarchical Azure Firewall Policies
  • Centralized routing configuration

GA Pricing

  • Preview has 50% discount
  • Azure Firewall in secure virtual hubs will be the same price as normal Azure Firewall
  • $100 per policy for policies that are associated with multiple hubs. No cost with policies associated with single hubs.
  • Fixed fee for outbound VPN to SECaaS partners in addition to a VPN scale unit charge.

Microsoft Ignite 2019 – Securing Your Cloud Perimeter With Azure Network Security

  • Speaker: Sinead O’Donvan (Irish, by the accent)

Zero Trust Architecture document

7 pillars:

  • Identity
  • Devices
  • Data
  • Apps
  • Infrastructure
  • Networking – the focus here

Verify explicitly every access control

  • Being on the network is not enough

Use least privilege access

  • IP address is not enough

Assume breach

  • No one is perfectly secure. Identify the breach. Contain the breach. Do your best to stop breaches in the first place.

You cannot claim success:

  • It requires constant improvement.

Network Maturity Model

  • Traditional (most customers)
    • Few network security perimeters and flat open network
    • Minimal threat protection and static filtering
    • Internal traffic is not encrypted
  • Advanced
    • Many ingress/egress cloud micro-perimeters with some micro-segmentation
    • Cloud native filtering and protection for known threats
    • User to app internal traffic is encrypted
  • Optimal
    • Fully distributed ingress/egress cloud micro-perimeters and deeper micro-segmentation
    • ML-based threat protection and filtering with context-based signals
    • All traffic is encrypted

Three Cores of Azure Network Security

  • Segment – prevent lateral movement and data exfiltration
  • Protect – secure network with threat intelligence
  • Connect – embrace distributed connectivity … or face revolt from the users/devs

Deploy securely across DevOps process

Azure Features

  • Azure Firewall
  • Azure WAF
  • Azure Private Link
  • Azure DD0S Protection

Plus:

  • VNets
  • NSGs
  • UDRs
  • Load Balancer

Network Segmentation

3 approaches:

  • Host-based: an agent on the VM implements it
  • Hypervisor: Example, VMware SNX
  • Network controls

Azure Network Segmentation Controls

  • Subscription: RABC, logic isolation for all resources
  • Virtual network: An isolated and highly secure environment to run your VMs and apps. “This is the hero of segmentation”
  • NSG: Enforce and control network traffic security rules that allow or deny network traffic for a VNet or a VM.
  • WAF: Define application specific policies to protect web workloads.
  • Azure Firewall: Create and enforce connectivity policies using application, network and threat intelligence filtering across subscription(s) and VNet(s).

Multi-Level Segmentation

  • Connectivity:
    • Use both public or private IP. Public app interface is public, backend is private.
    • Choose cloud transit approach VNet peering or Virtual WAN.
    • Carefully control routing
  • Infrastructure
    • Segment across subscription, vnet, and subnet boundaries
    • Managed at an org level
  • Application
    • Enable application aware segmentation
    • Easily create micro perimeters
    • Managed at an application level

Azure Firewall Manager (Preview)

  • Central deployment and configuration
    • Deploy and configure multiple Azure Firewall instances
    • Optimized for DevOps with hierarchical policies
  • Automated Routing
    • Easily direct traffic to your secured hub for filtering and logging without UDRs
  • And more

Azure Web Application Firewall

Preview:

  • Microsoft threat intelligence
    • Protect apps against automated attacks
    • Manage good/bad bots with Azure BotManager RuleSet
  • Site and URI patch specific WAF policies
    • Customise WAF policies at regional WAF for finer grained protection at each host/listener or URI path level
  • Geo-filtering on regional WAF
    • Enhanced custom rule matching criterion

MS sees 20/30 DDoS attacks per day.

WAF as a Service

  • Barracuda
  • Radware

Both run in Azure.

Connectivity

It’s time to transform your network.

  • User to app moves to Internet centric connectivity
  • Application to backend resources use private connectivity
  • Redesign your network and network security models to optimize user experience for cloud
  • Continue to extend app delivery models and network security to the edge

Azure Firewall Manager

  • Easily create multiple secured virtual hubs (DMZ Hubs) in Azure
  • Use Azure Firewall or 3rd party security
  • Create global and local policies
  • Easy to set up connectivity
  • Roadmap:
    • Split routing – optimized O365 and Azure public PaaS

CheckPoint CloudGuard Connect will debut soon as a partner extension.

Azure Private Link

Highly secure and private connectivity solution for Azure Platform.

  • Private access from VNet resources, peered networks and on-premises networks
  • In-built data exfiltration protection
  • Predictable private IP addresses for PaaS resources
  • Unified experience across PaaS customer owned and marketplace services

Microsoft taking this very seriously. All new PaaS services “from Spring onwards” must support Private Link.

Azure Bastion

See previous posts on this – it requires more work IMO because it lacks VNet peering support and requires login via the Azure Portal – doesn’t support MSTSC or SSH clients.

Key Takeaways

  • Embrace zero trust network model
  • Segment your network and create micro-perimters with Azure Firewall, NSG, etc
  • Use a defense in depth security strategy with cloud native services
  • Enable WAF and DDoS
  • Explore Azure as your secure Internet edge with Azure Firewall Manager

Private Connections to Azure PaaS Services

In this post, I’d like to explain a few options you have to get secure/private connections to Azure’s platform-as-a-service offerings.

Express Route – Microsoft Peering

 

ExpressRoute comes in a few forms, but at a basic level, it’s a “WAN” connection to Azure virtual networks via one or more virtual network gateways; Customers this private peering to connect on-premises networks to Azure virtual networks over an SLA-protected private circuit. However, there is another form of peering that you can do over an ExpressRoute circuit called Microsoft peering. This is where you can use your private circuit to connect to Microsoft cloud services that are normally connected to over the public Internet. What you get:

  • Private access to PaaS services from your on-premises networks.
  • Access to an entire service, such as Azure SQL.
  • A wide array of Azure and non-Azure Microsoft cloud services.

FYI, Office 365 is often mentioned here. In theory, you can access Office 365 over Microsoft peering/ExpressRoute. However, the Office 365 group must first grant you permission to do this – the last I checked, you had to have legal proof of a regulatory need for private access to Cloud services. 

Service Endpoint

Imagine that you are running some resources in Azure, such as virtual machines or App Service Environment (ASE); these are virtual network integrated services. Now consider that these services might need to connect to other services such as storage accounts, Azure SQL, or others. Normally, when a VNet connected resource is communicating with, say, Azure SQL, the packets will be routed to “Internet” via the 0.0.0.0/0 default route for the subnet – “Internet” is everywhere outside the virtual network, not necessarily The Internet. The flow will hit the “public” Azure backbone and route to the Azure SQL compute cluster. There are two things about that flow:

  • It is indirect and introduces latency.
  • It traverses a shared network space.
  • A growing number of Azure-only services that support service endpoints.

A growing number of services, including storage accounts, Azure SQL, Cosmos DB, and Key Vault, all have services endpoints available to them. You can enable a service endpoint anywhere in the route from the VM (or whatever) to “Internet” and the packets will “drop” through the service endpoint to the required Azure service – make sure that any firewall in the service accepts packets from the private subnet IP address of the source (VM or whatever). Now you have a more direct and more private connection to the platform service in Azure from your VNet. What you get:

  • Private access to PaaS services from your Azure virtual networks.
  • Access to an entire service, such as Azure SQL, but you can limit this to a region.

Service Endpoint Trick #1

Did you notice in the previous section on service endpoints that I said:

You can enable a service endpoint anywhere in the route from the VM (or whatever) to “Internet”

Imagine you have a complex network and not everyone enables service endpoints the way that they should. But you manage the firewall, the public IPs, and the routing. Well, my friend, you can force traffic to support Azure platform services via service endpoints. If you have a firewall, then your routes to “Internet” should direct outbound traffic through the firewall. In the firewall (frontend) subnet, you can enable all the Azure service endpoints. Now when packets egress the firewall, they will “drop” through the service endpoints and to the desired Azure platform service, without ever reaching “Internet”.

Service Endpoint Trick #2

You might know that I like Azure Firewall. Here’s a trick that the Azure networking teams shared with me – it’s similar to the above one but is for on-premises clients trying to access Azure platform services.

You’ve got a VPN connection to a complex virtual network architecture in Azure. And at the frontend of this architecture is Azure Firewall, sitting in the AzureFirewallSubnet; in this subnet you enabled all the available service endpoints. Let’s say that someone wants to connect to Azure SQL using Power BI on their on-premises desktop. Normally that traffic will go over the Internet. What you can do is configure name resolution on your network (or PC) for the database to point at the private IP address of the Azure Firewall. Now Power BI will forward traffic to Azure Firewall, which will relay you to Azure SQL via the service endpoint. What you get:

  • Private access to PaaS services from your on-premises or Azure networks.
  • Access to individual instances of a service, such as an Azure SQL server
  • A growing number of Azure-only services that support service endpoints.

Private Link

In this post, I’m focusing on only one of the 3 current scenarios for Private Link, which is currently in unsupported preview in limited US regions only, for limited platform services – in other words, it’s early days.

This approach aims to give a similar solution to the above “Service Endpoint Trick #2” without the use of trickery. You can connect an instance of an Azure platform service to a virtual network using Private Link. That instance will now have a private IP address on the VNet subnet, making it fully routable on your virtual network. The private link gets a globally unique record in the Microsoft-managed privatelink.database.windows.net DNS zone. For example, your Azure SQL Server would now be resolvable to the private IP address of the private link as yourazuresqlsvr.privatelink.database.windows.net. Now your clients, be the in Azure or on-premises, can connect to this DNS name/IP address to connect to this Azure SQL instance. What you get:

  • Private access to PaaS services from your on-premises or Azure networks.
  • Access to individual instances of a service, such as an Azure SQL server.
  • (PREVIEW LIMITATIONS) A limited number of platform services in limited US-only regions.

Migrating Azure Firewall To Availability Zones

Microsoft recently added support for availability zones to Azure firewall in regions that offer this higher level of SLA. In this post, I will explain how you can convert an existing Azure Firewall to availability zones.

Before We Proceed

There are two things you need to understand:

  1. If you have already deployed and configured Azure Firewall then there is no easy switch to turn on availability zones. What I will be showing is actually a re-creation.
  2. You should do a “dress rehearsal” – test this process and validate the results before you do the actual migration.

The Process

The process you will do will go as follows:

  1. Plan a maintenance window when the Azure Firewall (and dependent communications) will be unavailable for 1 or 2 hours. Really, this should be very quick but, as Scotty told Geordi La Forge, a good engineer overestimates the effort, leaves room for the unexpected, and hopefully looks like a hero if all goes to the unspoken plan.
  2. Freeze configuration changes to the Azure Firewall.
  3. Perform a backup of the Azure Firewall.
  4. Create a test environment in Azure – ideally a dedicated subscription/virtual network(s) minus the Azure Firewall (see the next step).
  5. Modify the JSON file to include support for availability zones.
  6. Restore the Azure Firewall backup as a new firewall in the test environment.
  7. Validate that that new firewall has availability zones and that the rules configuration matches that of the original.
  8. Confirm & wait for the maintenance window.
  9. Delete the Azure Firewall – yes, delete it.
  10. Restore the Azure Firewall from your modified JSON file.
  11. Validate the restore
  12. Celebrate – you have an Azure Firewall that supports multiple zones in the region.

Some of the Technical Bits

The processes of backing up and restoring the Azure Firewall are covered in my post here.

The backup is a JSON export of the original Azure Firewall, describing how to rebuild and re-configure it exactly as is – without support for availability zones. Open that JSON and make 2 changes.

The first change is to make sure that the API for deploying the Azure Firewall is up to date:

        {
            "apiVersion": "2019-04-01",
            "type": "Microsoft.Network/azureFirewalls",

The next change is to instruct Azure which availability zones (numbered 1, 2, and 3) that you want to use for availability zones in the region:

        {
            "apiVersion": "2019-04-01",
            "type": "Microsoft.Network/azureFirewalls",
            "name": "[variables('FirewallName')]",
            "location": "[variables('RegionName')]",
            "zones": [
                "1",
                "2",
                "3"
            ],
            "properties": {
                "ipConfigurations": [
                    {

And that’s that. When you deploy the modified JSON the new Azure Firewall will exist in all three zones.

Note that you can use this method to place an Azure Firewall into a single specific zone.

Costs Versus SLAs

A single zone Azure Firewall has a 99.95% SLA. Using 2 or 3 zones will increase the SLA to 99.99%. You might argue “what’s the point?”. I’ve witnessed a data center (actually, it was a single storage cluster) in an Azure region go down. That can have catastrophic results on a service. It’s rare but it’s bad. If you’re building a network where the Azure Firewall is the centre of secure, then it becomes mission critical and should, in my opinion, span availability zones, not for the contractual financial protections in an SLA but for protecting mission critical services.  That protection comes at a cost – you’ll now incur the micro-costs of data flows between zones in a region. From what I’ve seen so far, that’s a tiny number and a company that can afford a firewall will easily absorb that extra relatively low cost.

Do Not Enable Azure Storage Account Firewall – IaaS

If you read through the security recommendations in Azure Security Center, you do get given out to a lot. A lot of it makes no sense if you understand Azure and the recommendations. One that appeared to make sense was to enable the relatively new firewall in Azure Storage:

  • Only allow trusted subnets – nice idea to limit the attack surface on the storage account in conjunction with service endpoints.
  • Allow “trusted Microsoft services” to access the storage account (on by default).

Note: A storage account can only be connected if you know one of the really long random access keys.

But if you do enable this firewall in an Azure deployment, things will break:

  • Boot Diagnostics: Does not know how to write to a secured storage account, even with firewall rules and service endpoints enabled.
  • Serial Console Access: Requires Boot Diagnostics to be working so that’s dead too.
  • NSG Flow Logs/Traffic Analytics: Another feature that doesn’t understand a secured storage account, even with “trusted Microsoft services” marked as enabled (default).

And there might be more!

So you have to aks yourself – do you want maximum security or a usable & manageable system? Storage account firewalls are pretty new – we didn’t need them a few months ago. So we can drop that feature, and maybe use the new Advanced Threat Protection for storage accounts feature instead?

It’s a pit that some joined-up thinking and integration testing weren’t done here.

Locking Down Network Access to the Azure Application Gateway/Firewall

In this post, I will explain how you can use a Network Security Group (NSG) to completely lock down network access to the subnet that contains an Azure Web Application Gateway (WAG)/Web Application Firewall (WAF).

The stops are as follows:

  1. Deploy a WAG/WAF to a dedicated subnet.
  2. Create a Network Security Group (NSG) for the subnet.
  3. Associate the NSG with the subnet.
  4. Create an inbound rule to allow TCP 65503-65534 from the Internet service tag to the CIDR address of the WAG/WAF subnet.
  5. Create rules to allow application traffic, such as TCP 443 or TCP 80, from your sources to the CIDR address of the WAG/WAF
  6. Create a low priority (4000) rule to allow any protocol/port from the AzureLoadBlanacer service tag to the CIDR address of the WAG/WAF
  7. Create a rule, with the lowest priority (4096) to Deny All from Any source.

The Scenario

It is easy to stand up a WAG/WAF in Azure and get it up and running. But in the real world, you should lock down network access. In the world of Azure, all network security begins with an NSG. When you deploy WAG/WAF in the real world, you should create an NSG for the WAG/WAF subnet and restrict the traffic to that subnet to what is just required for:

  • Health monitoring of the WAG/WAF
  • Application access from the authorised sources
  • Load balancing of the WAG/WAF instances

Everything else inbound will be blocked.

The NSG

Good NSG practice is as follows:

  1. Tiers of services are placed into their own subnet. Good news – the WAG/WAF requires a dedicated subnet.
  2. You should create an NSG just for the subnet – name the NSG after the VNet-Subnet, and maybe add a prefix or suffix of NSG to the name.

Health Monitoring

Azure will need to communicate with the WAG/WAF to determine the health of the backends – I know that this sounds weird, but it is what it is.

Note: You can view the health of your backend pool by opening the WAG/WAF and browsing to Monitoring > Backend Health. Each backend pool member will be listed here. If you have configured the NSG correctly then the pool member status should be “Healthy”, assuming that they are actually healthy. Otherwise, you will get a warning saying:

Unable to retrieve health status data. Check presence of NSG/UDR blocking access to ports 65503-65534 from Internet to Application Gateway.

OK – so you need to open those ports from “Internet”. Two questions arise:

  • Is this secure? Yes – Microsoft states here that these ports are “are protected (locked down) by Azure certificates. Without proper certificates, external entities, including the customers of those gateways, will not be able to initiate any changes on those endpoints”.
  • What if my WAG/WAF is internal and does not have a public IP address? You will still do this – remember that “Internet” is everything outside the virtual network and peered virtual networks. Azure will communicate with the WAG/WAF via the Azure fabric and you need to allow this communication that comes from an external source.

In my example, my WAF subnet CIDR is 10.0.2.4/24:

Application Traffic

Next, I need to allow application traffic. Remember that the NSG operates at the TCP/UDP level and has no idea of URLs – that’s the job of the WAG/WAF. I will use the NSG to define what TCP ports I am allowing into the WAG/WAF (such as TCP 443) and from what sources.

In my example, the WAF is for internal usage. Clients will connect to applications over a VPN/ExpressRoute connection. Here is a sample rule:

If this was an Internet-facing WAG or WAF, then the source service tag would be Internet. If other services in Azure need to connect to this WAG or WAF, then I would allow traffic from either Virtual Network or specific source CIDRs/addresses.

The Azure Load Balancer

To be honest, this one caught me out until I reasoned what the cause was. My next rule will deny all other traffic to the WAG/WAF subnet. Without this load balancer rule, the client could not connect to the WAG/WAF. That puzzled me, and searches led me nowhere useful. And then I realized:

  • A WAG/WAF is 1+ instances (2+ in v2), each consuming IP addresses in the subnet.
  • They are presented to clients as a single IP.
  • That single IP must be a load balancer
  • That load balancer needs to probe the load balancer’s own backend pool – which are the instance(s) of the WAG/WAF in this case

You might ask: isn’t there a default rule to allow a load balancer probe? Yes, it has priority 65001. But we will be putting in a rule at 4096 to prevent all connections, overriding the 65000 rule that allows everything from VirtualNetwork – which includes all subnets in the virtual network and all peered virtual networks.

The rule is simple enough:

Deny Everything Else

Now we will override the default NSG rules that allow all communications to the subnet from other subnets in the same VNet or peered VNets. This rule should have the lowest possible user-defined priority, which is 4096:

Why am I using the lowest possible priority? This is classic good firewall rule practice. General rules should be low priority, and specific rules should be high priority. The more general, the lower. The more specific, the higher. The most general rule we have in firewalls is “block everything we don’t allow”; in other words, we are creating a white list of exceptions with the previously mentioned rules.

The Results

You should end up with:

  • The health monitoring rule will allow Azure to check your WAG/WAF over a certificate-secured channel.
  • Your application rules will permit specified clients to connect to the WAG/WAF, via a hidden load balancer.
  • The load balancer can probe the WAG/WAF and forward client connections.
  • The low priority deny rule will block all other communications.

Job done!

 

Cloud Camp 2018 – It’s A Wrap!

Yesterday, Cloud Camp 2018, run by MicroWarehouse and sponsored by Microsoft Surface and Veeam, ran in the Dublin Convention Centre here in Ireland. 4 tracks, 20 (mostly MVP) sessions, 2 keynotes, and hundreds of satisfied attendees. It was great fun – but we’re all a little tired today Smile

Photo by Gregor Reimling

The message of the day was “change” and that was what I talked about in the opening keynote. In nature, change is inevitable. In IT, you cannot accept change, you’re pushed aside. Business pressure, security & compliance needs, and the speed of cloud make change happen faster than ever. And that’s why we had 20 expert-lead breakout sessions covering Azure IaaS, Azure PaaS, productivity, security, management & governance, Windows Server 2019 and hybrid cloud solutions. The conference ended with renowned Microsoft-watchers Mary Jo Foley and Paul Thurrott discussing what the corporation has been up to and their experiences in covering the Redmond giant.

We had a lot of fun yesterday. Everything ran quite smoothly – credit to John & Glenn in MWH and Hanover Communications.

After the conference, Paul & Mary Jo hosted their Windows Weekly podcast from Dogpatch Labs in the IFSC.

And then we had a small after party in Urban Brewing next door, where one or two beverages might have been consumed until the wee hours of the morning Smile

Picture by Gerald Versluis

Thank you to:

  • MicroWarehouse for running this event – Rory for OK-ing it and the team for promoting it.
  • John and Glenn who ran the logistics and made it so smooth
  • Hanover Communications for the PR work
  • All the breakout speakers who travelled from around Ireland/Europe to share their knowledge and experience
  • Kartik who travelled from India to share what Azure Backup are up to
  • Paul & Mary Jo for travelling from the USA to spend some time with us
  • Alex at TWiT for make sure things worked well with the podcast
  • Everyone who attended and made this event possible!

A Twitter competition with the #CloudCamp18 tag was run – a winner will be selected (after the dust settles) for a shiny new Surface Go. At one point the #CloudCamp18 tag was trending #3 for tweets in Dublin. Now I wonder what will happen with #CloudCamp19?