Securing Azure Web Apps with the BIG-IP

With the recent release of the BIG-IP virtual edition for Azure enterprises can now take advantage of F5’s various services, (WAF, multi-factor authentication, endpoint inspection, etc.) to securely deploy their cloud-based applications. This includes support for applications that are deployed on:

IaaS - Enterprise deployed and managed Azure virtual machines (Virtual Machines); and
PaaS – Azure managed application hosting platforms, (Web Apps).

For those of us confused by IaaS and PaaS, here’s a post from Robert Greiner that provides a great overview of Azure’s related offerings.

While securing applications that utilize virtual machines and virtual network services is comparable to traditional data center deployments; securing Azure Web Apps with an upstream device, such as the BIG-IP presents an “interesting” challenge. Specifically, Web Apps run on shared platforms, (PaaS) with little to no visibility into or control of the underlying infrastructure. Additionally, there is no guarantee that the underlying networking configuration, (routes, IP addressing, etc.) won’t change periodically.

Fortunately, with the advent of the App Service Environment, (ASE) enterprises now have a means to deploy Web Apps into an ASE and reap the benefits of a dedicated and isolated environment that makes use of Azure virtual networking services. Here’s the cool part; with a little “creative networking” we can now utilize an upstream BIG-IP to secure the applications inside of the App Service Environment.

But hey, that's just me talking, (um….typing). Let’s take a look at an actual deployment scenario.

F5Demo Web Apps

In this scenario, we have two Azure Web Apps, (f5demo-1 and f5demo-2) that we want to secure with the BIG-IP Application Security Manager, (ASM). To accomplish this, we need to perform the following steps:

1. Deploy BIG-IP(s) VE for Azure – Refer to this previous article for deploying the BIG-IP into an Azure ARM environment. This particular BIG-IP has a network security group, (NSG) configured to allow public access via HTTP, HTTPS, and SSH.

2. Create App Service Environment - Refer to the following documentation to create an App Service Environment and migrate the existing Azure Web App(s) or deploy a new Web App into the ASE. The ASE will be connected to a v1 virtual network and subnet. Connecting to a virtual network is critical as it allows us to utilize Azure networking services. In the next step, we will be using a NSG associated to the subnet where the ASE resides. The NSG is used to restrict access to the Azure Web Apps, only allowing access from the BIG-IP virtual appliance.

3. Create a Network Security Group – Now that our Web Apps have been added into the ASE, we will use PowerShell to create a NSG and assign it to the subnet where the ASE resides. The script below creates the NSG with rules allowing HTTP and HTTPS connections from the upstream BIG-IP as well as allowing management access. Refer to this article for additional information on controlling inbound access to the ASE.

#Create new NSG, (Network Security Group)
New-AzureNetworkSecurityGroup -Name 'WebApp-NSG' -Location  -Label "Network security group for app service environment"

#Create inbound rules set
Get-AzureNetworkSecurityGroup -Name 'WebApp-NSG' | Set-AzureNetworkSecurityRule -Name "AzureMgmt" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name 'WebApp-NSG' | Set-AzureNetworkSecurityRule -Name "HTTP" -Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix   -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name 'WebApp-NSG' | Set-AzureNetworkSecurityRule -Name "HTTPS" -Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix   -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name 'WebApp-NSG' | Set-AzureNetworkSecurityRule -Name "RemoteDebuggingVS2012" -Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4016' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name 'WebApp-NSG' | Set-AzureNetworkSecurityRule -Name "RemoteDebuggingVS2013" -Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4018' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name 'WebApp-NSG' | Set-AzureNetworkSecurityRule -Name "RemoteDebuggingVS2015" -Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4020' -Protocol TCP

#Assign NSG to subnet where WebApp resides
Get-AzureNetworkSecurityGroup -Name "WebApp-NSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName  -SubnetName

4. Configure BIG-IP – With the above NSG configured and applied to the VNET/subnet web traffic we configure the BIG-IP and to act as a reverse-proxy. The configuration of the BIG-IP will depend on the type of application being published, (deployed) and the services being utilized, (ASM, APM, LTM, DNS, etc.). In this scenario, we are publishing two web applications and protecting them F5’s WAF module, (ASM). To accomplish this, at a minimum we will need to:

Create Application Member Pool(s) – We create two member pools, (f5demo1_pool & f5demo2_pool). Pool members are referenced using their respective FQDN, (see below and right).

Note: SSL Offload vs. Bridging – With the BIG-IP acting as a full proxy, we can either choose to offload SSL connection, (i.e. decrypt SSL connections and send to backend servers unencrypted) or bridge SSL connections, (decrypt and re-encrypt). However, since the data between the BIG-IP and the backend pool members travels across the public Internet, I would strongly recommend SSL bridging over SSL offload.

Create Virtual Server(s) – We will create a virtual server to receive external connections and proxy requests into the backend pool(s).

Since the BIG-IP is currently limited to one external facing Public VIP, (Azure limitation) we will utilize an iRule to direct incoming connections to the appropriate pool depending upon the HTTP request host header. In this scenario, the external FQDN for the our two Azure Web Apps, (f5demo-1 and f5demo-2) are site1.f5demo.net and site2.f5demo.net respectively. Therefore to ensure application functionality, we utilize the iRule, (shown below) to perform:

Host header redirection – requests received on the external FQDN are translated to the Azure Web App FQDN prior to being transmitted to web app.
Traffic Steering – The host header received in the HTTP request is used to determine the appropriate member pool to direct incoming connections. This allows us to service two separate applications from one external facing virtual server.

when HTTP_REQUEST {
    set host [ string tolower [HTTP::host]]
    if {$host contains "site1" } {
    HTTP::host "f5demo-1.appserverenv1.p.azurewebsites.net"
pool f5demo1_pool
} elseif {$host contains "site2" } { 
HTTP::host "f5demo-2.appserverenv1.p.azurewebsites.net"
pool f5demo2_pool
}
}