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

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:

  1. Make sure the the App Service plan for web app to be fronted with WAF is scaled-up to Standard Tier.
  2. 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

frontend conf

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/HTTPS Listener:

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.

add-basic listener

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.



Health Probe:

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”


Backend health


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 ““. 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”

log query.PNG

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.



Monitoring Sitecore Topology on Azure – Azure Metrics, App Insights, Azure Monitor, Service Health Alerts

Sitecore topologies(9.0.2) officially provided at contains the below Azure resources

  • Azure web app
  • Azure SQL Database
  • Azure Search
  • Azure Redis cache
  • Azure Application Insights

Looking at an overall Sitecore topology the below would be an architectural representation of the monitoring story.  App Insights collects the telemetry from all the web apps and measures web app availability. Azure monitor helps in configuring alerts and metrics. Azure Health Alerts gives the flexibility to monitor the availability of azure specific services which can help to notify customers during an outage in a data center and in a scenario where only a specific azure service is out of service.

For the scope of this blog, i am not covering infrastructure monitoring using log analytics.

monitoring arch

Sitecore environments deployed a resource group can be monitoring using App Insights, Azure metrics and Azure Monitor and we use use the Azure Dashboards to give a unified view of the performance metrics and statistics of all the azure resources within a topology.

Some features that Sitecore developers have to enable to leverage the monitoring capabilities in Azure.

Application Insights

Enable the Application map feature in App Insights by uncommenting the below code snippet in the ApplicationInsights.Config in the sitecore web app instances

    <!-- Uncomment the following line to enable dependency tracking -->
    <!-- <Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector"/> -->
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule, Microsoft.AI.PerfCounterCollector">
    <! -- cut a lot if information -->

2. Configure azure availability web tests(URL ping tests) in the azure portal to monitor the overall website availability


3. Metrics for web apps, Azure SQL databases, Redis cache and Azure search can be configured in the azure portal. For all the above resources we can configure the azure metrics for each above mentioned azure resources using the Metrics menu option.

Add metric option allows the metric selection and ability to add multiple charts for the same resource.


Once the required dashboards are added, “Pin to current dashboard” option adds the chart to the default azure dashboard.


Once you start configuring the required metrics for azure resources, you should be able to see a complete dashboard as shown below. For more clarity and simplicity i have updated the dashboard json for the below sitecore environment in Github at Sitecore-Azure-Monitoring . Few steps to make it work for you

  • Make sure the sitecore topology is deployed in a resource group in your azure subscription using Marketplace Sitecore Experience cloud.
  • Download the Sitecore-XPTopology902-Monitoring.json file
  • Replace the subscription id “xxxxxxxxx-xxxx-xxx-xxxx-xxxxxxxxxxxx” with relevant subscription id that you will be using for creating the dashboard
  • Replace the text “resourceGroups/ga-sea-exsmall-xp-rg” with the “resourceGroups/your-resourcegroup-name” in the json file.
  • Replace the other relevant azure resource name as required and upload the updated Sitecore-XPTopology902-Monitoring.json file in azure portal.


Azure Monitor

Azure Monitor gives the capability for alerting and notifications on metrics and logs as described in monitoring data sources. Azure monitor gives a cumulative monitoring on top of the below services

  • Metric values supported by Azure Metrics
  • Log search queries supported by Log analytics
  • Activity Log events supported by Log analytics
  • Azure Service Health alerts
  • web site availability test supported by App Insights

For each azure resource while adding the metrics for monitoring, a new alert rule can be created by specifying a condition for webapp-pin-createalert

Action Groups

An action group is a collection of notification preferences defined by the owner of an Azure subscription. Azure Monitor and Service Health alerts use action groups to notify users that an alert has been triggered.


Once the alert is configured along with alert condition and notification requirements, you would see the metric alert rule created as below.


Service Health Events

Service Health tracks three types of health events that may impact your resources:

  1. Service issues – Problems in the Azure services that affect you right now.
  2. Planned maintenance – Upcoming maintenance that can affect the availability of your services in the future.
  3. Health advisories – Changes in Azure services that require your attention. Examples include when Azure features are deprecated or if you exceed a usage quota.

By adding an Action group at a resource group level the action group can be used for any notifications related to the resource group.


Once the action group is created, the service alert can be created at a specific or multiple azure resources Ex: App Service , Web apps , SQL databases as shown below


Hope this help!!.



Saving costs for Sitecore environments on Azure PAAS using Automation

Azure Web apps and Azure SQL databases are primary components in Sitecore environments deployed on Azure PAAS. For example a XP Topology, Sitecore 9.0.2 ARM Templates deploys around

  • 9 web apps in 6 different App Service Plans(Except XP-Single)
  • 12 SQL databases in various service tiers


As for Azure consumption, an Azure month is typically counted for 732 hours. Azure web apps in Shared/Basic/Standard/Premium/Isolated tier will get charged even when the web-app in the App Service Plan is stopped.

Say we have a scenario where developers don’t use the Sitecore environment during weekends i.e approx 4 weekends or 8 days/month. That will be around 192 hrs/month of used usage per month.

If we can scale down our web apps to Free tier during the non-business hours, that would save around 10(web apps) * 192 = 1920 hrs/month for all the web apps in a specific environment. Using Automation we can scale up the web apps to their normal tiers on a monday morning.

For Sitecore web apps, where we have Application settings with below setting, scaling down to Free tier is not a straight forward choice.

  • Always On enabled for all Basic/Standard web apps
  • Platform = 64-Bit
  • xConnect, Marketing Automation web apps use client certificate a specific flag is set in to enable Client certificate settingsalwaysonxconnect

In order to scale down the web apps to Free tier we might have set the settings to false. This is a sample script which can help achieve that. Obviously this script doesn’t cater to all the requirements and scenarios so definitely can be improved.

Script for Scaling Down- Web apps:


Script for Scaling Up- Web apps:


Blog at

Up ↑