Securing Sitecore Topology deployed on Azure web apps(PAAS) using Application Gateway(WAF), Log analytics and Azure Monitor
Primary focus for the blog post would be to setup an Application gateway(WAF enabled) in front of a sitecore content delivery PAAS web app and test Azure WAF functiionality with SQL Injection attack using Log analytics and Azure Monitor(Log alerts) feature.
Update: WAF Support for Sitecore is officially available from SItecore 9.1 as mentioned in KB article https://kb.sitecore.net/articles/682999
Sitecore environments deployed using the standard Sitecore ARM templates on Azure PAAS are deployed on Azure App Service in the multi-tenant model(using Basic, Standard, Premium service tiers) . Azure App Service is a standard Web App offering is a multi-tenant environment configured for public access (with a publicly accessible endpoint).
Some organizations (e.g. Government, Financial) have requirements that all access to applications come through a Trusted Internet Connection (TIC), which means that the web applications should not be accessible directly from the Internet through their public endpoints and are only routed either through a
- On-prem network integrated VPN or Express Route connection
- User Traffic routed to Virtual network which controls the inbound/outbound communication using a Network Security Group.
App Service Environments(ASE) provide the Network isolation as well as private access through ExpressRoute integration by deploying the Azure web apps inside a virtual network using only the Isolated web app tier.
ASE being a very expensive azure service and comes up with some additional complexities that may not fit for all customer requirements, the other available options to secure web app would be
- Restrict the access to web app using IP Restrictions – This approach will work for restricting access to Sitecore content management web app to content authors only with in the organization.
- Front-ending the Web App with an Azure Application Gateway and restricting access to the Web App such that only connections from the Gateway are allowed – This approach can secure the Content delivery web app by making sure the user traffic only reaches the Gateway Public endpoint and can be secured with a Azure WAF with out directly reaching the content delivery web app.
For the purpose of this blog post we will focus on the second option using Application gateway(WAF) to secure the content delivery web app in Azure cloud.
Steps to create/configure Application Gateway(WAF) for Sitecore environment:
- Make sure the the App Service plan for web app to be fronted with WAF is scaled-up to Standard Tier.
- Create a Application gateway in the same resource group and location as the web app.
In the 2nd step during the creation process the Virtual network and Public IP will be configured and make sure the virtual network is created in the same resource group where the web app exists.
Point to note: Please set the Firewall mode to Detection for the scope of the testing Sitecore content delivery website.
3. Review the results and click on OK to create the gateway.
Frontend IP Configuration
Once the Application gateway is created, you see the Frontend IP configuration is created. Frontend IP configuration shows how the gateway is exposed. It can be either either public or private or both. The same configuration can be used by more than one HTTP listener, using different port.
Configure the Application Gateway
Backend pools feature provided by the Application gateway is used to configure the azure resources to which the user traffic needs to be directed. The resources supported as of today are NICs, virtual machine scale sets, public IPs, internal IPs, fully qualified domain names (FQDN), and multi-tenant back-ends like Azure App Service.
For the context of this blog post, we will be using App Service. Once the Application gateway is created there will be an appGatewayBackendPool already created and we can use the same backend pool to configure the content delivery web app.
One the backend pool is assigned as shown below you can see the rule1 is created mapping to the HTTP url. Once he backend pool settings the incoming traffic that enters the application gateway would be routed to the backend address added here.
Configuring SSL Termination/Offloading
Application gateway can be configured to terminate the Secure Sockets Layer (SSL) session at the gateway to avoid costly task of decrypting HTTPS traffic off your web servers. Application gateway decrypts the request and sends it to backend server and re-encrypts the response before sending it back to the client.
To configure SSL offload with an application gateway, a certificate (pfx format) is required. This certificate is loaded on the application gateway and used to encrypt and decrypt the traffic sent via SSL. For the scope of this blog post i will be using a self-signed certificate.
Use the below powershell script to generate a self-signed certificate in order to use that during HTTPS Listener.
$thumbprint = (New-SelfSignedCertificate ` -Subject "CN=$env:COMPUTERNAME @ Sitecore, Inc." ` -Type SSLServerAuthentication ` -FriendlyName "$env:USERNAME Certificate").Thumbprint $certificateFilePath = "D:\Powershell\XPARM\$thumbprint.pfx" Export-PfxCertificate ` -cert cert:\LocalMachine\MY\$thumbprint ` -FilePath "$certificateFilePath" ` -Password (Read-Host -Prompt "Enter password that would protect the certificate" -AsSecureString)
HTTP Listener combines a frontend IP configuration and port it also include a protocol (HTTP or HTTPS) and optionally an SSL certificate. It will look for traffic based on its configuration and helps route the traffic to the backend pools
An HTTP listener is what the Application Gateway is listening to, for example:
- Public IP xx.xx.xx.xx on port 443, HTTPS with a given SSL certificate
- Private IP x.x.x.x on port 80, HTTP
Using the self signed certificate created earlier, please create a Basic HTTPS Listener as shown below by pressing OK button at the bottom. This process take about 15-20 mins for you to proceed with the next steps.
Create Rule for HTTPS Listener:
Once listener is created, you need to create a rule to handle the traffic from the listener. Click the Rules of the application gateway, and then click Basic option. Type in the friendly name for the rule and choose the listener created in the previous step. Choose the appropriate backend pool and http setting as “appgatewayBackendHttpSetting” for now and click OK to save.
Once the HTTPS rule is saved, we can see that Health Probes menu option in the Application Gateway shows both the health probes created automatically. A Health is described by a protocol, a URL, interval, timeout, etc. . Basically we can customize how a backend is determined to be healthy or not.
Once the HTTP/HTTPS probes are updated, you should see the HTTP Setting menu option with “appgatewayBackendHttpsSetting”setting set correctly or else you may have to manually upload the self-signed certificate(.CER file) and update the “appgatewayBackendHttpsSetting”
Once the configuration is completed, please ensure WEBSITE_LOAD_CERTIFICATES app settings is added to the CD web app Application settings so that it accepts the self-signed cerificate
Once the complete configuration is completed, the Gateway IP address found in the App gateway “overview” menu can used tested https://xxx.xx.xx.xx. If we use a CA authority certified SSL cert, we wont be seeing the invalid certificate issue and we should be able to route the traffic from Gateway IP to the Content delivery web app.
The Next step would be to restrict the content delivery web app to disallow web app public endpoint access. This can be achieved using web app IP restrictions by setting the Gateway IP address in the IP Address Block.
For you to make it work in a local machine and test you need to add an Gateway IP address in Hosts file on your local machine and map it to a custom domain say “ga-sea-sitecore.azure.cd“. The path would be c:\Windows\System32\Drivers\etc\hosts.
SQL Injection Security violation monitoring using Log analytics and Azure Monitor
- Make sure a OMS Log analytics workspace is created and Azure Activity analytics solution is added to the workspace.
- Make sure the content delivery web app diagnostic logs are exported to a storage account and storage account is connected to the log analytics workspace
- Azure Diagnostics logs get collected under the Azure metrics solution
In order to inject SQL Injection we will use a simple sql script and invoke a website request
Now if you go back to Azure Diagnostics as Log search query you should see the SQl Injection attack has been logged.
| where Message contains “injection” and action_s contains “detected”
Detecting and notifying customers on SQL Injection attack
Azure Monitor provides alerts on top of Log search queries which can be configured in Azure Monitor UI and selecting log analytics resource and the corresponding resource groups and select Log Search as the condition for alert
Once the alert has been created and an action group configured in Azure to send emails/notifications for the alert configured, you will receive an email alert below.
Hope this helps in configuring and alerting customers on any security violations.