With Azure Application Gateway v2 coming, a lot of new features have been added. Much faster deployment and change times, auto-scaling and the ability to assign different Web Application Firewall (WAF) policies per Application Gateway’s listener. This feature provides more control over each listener and also can limit the number of different Application Gateways you need to deploy. 

With a custom WAF policy we can control the firewall per listener (URL) with:

• Firewall mode, Prevention – Detection
• Request body properties
• WAF rule set category & version
• Custom Rules with If / Then conditions
  • Match IP address, Number, String, Geo location
  • Allow / Deny Traffic

This post scenario

We have on Azure Application Gateway with two Listeners (listens to two different URLs at its Public IP). The two listeners are forwarding the traffic to two different Web Apps, as shown at the below image.

My request is to allow all traffic to the first URL but allow traffic only from a specific IP to the second URL.

For the demo, I assume that you already have an Azure Application Gateway v2 in place and you have published two back ends (web apps, VMs, custom IP) and your web sites / apps are healthy and you can browse them behind the Application Gateway. 

Since I am using the default azurewebsites.net domain, I added two hosts at my workstation’s host file, in order to route the traffic to the Application Gateway’s IP and not directly to the Web Apps. 

I can browse both Web Apps, through the Application Gateway, from my browser. I am using http and not https for the demo since I am using the default domain and I cannot add a custom certificate.

We need to create two Web Application Firewall policies (WAF). One for each listener. To create  a WAF policy, search the Azure Portal for waf and click the “Web Application Firewall policies (WAF)”.

At the “Web Application Firewall policies (WAF)” page click +Add

At the Project details select “Regional WAF (Application Gateway)”. 

Select the Subscription that your Application Gateway resides, select Resource Group, add a name for the Policy and the same region as your Application Gateway. The policy must set to Enabled to apply. I named the policy URLNumber02 to start creating the policy for the second URL that I want the custom rule.

At the Policy Settings change the setting to Prevention from Detection and go to the Custom rules and Add custom rule

I named the rule “AllowOnlyOneIP”, since I want to allow only one IP to access the second URL (listener) of the gateway. Give a priority, I added 1 as it is the only one. At the conditions select:

• March Type: IP address
• Operation: Does not contain
• IP address or range: add the only IP that you want to allow access to the URL

At the “Then” condition, select “Deny Traffic”

This rule will allow traffic only of the IP is the IP address that we added to the condition. For all other IPs access will be denied.

Now that we created the policy, we need to assign it to the listener. At the next step of the WAF policy wizard we need to select the Application Gateway and the Listener.

First click the “Associate an application gateway” and select the Application Gateway. Remember that this policy will need to overwrite the default Application Gateway’s WAF policy. So before proceeding migrate your current WAF settings and customizations to the new WAF policy.

After you select the Application Gateway, associate the listener. I associate the “mylistener02” that is my second URL, with this policy.

After saving the policy, go to the Application gateway and check the “Web Application Firewall” settings. There you will see that all settings disappeared and you can only see that the gateway is associated with a WAF policy. We see that it is Associated to the URLNumber2 polily.

You need to create one more WAF rule for URL 01 for the correct functionality. Once you create a WAF policy and associate it to the other listener of the Application gateway, you will see that at the “Web application firewall” is associated to the new policy. Actually the Application gateway is associated to both WAF policies, one at each listener. You just cannot see this at the Azure Portal. 

We can see the WAF rules that are associated to the Application Gateway’s Listeners using the PowerShell. Running the “Get-AzApplicationGateway -Name AppGw01 -ResourceGroupName AppGw01” command you can see that the “URLNumber01” WAF policy is associated to the “mylistener” and the “URLNumber2” is associated to the “mylistener02”.

To test the policies, I tried to access both URLs from a computer that don’t have the Public IP that I added tot he policy and I can access the URL 1 app but I cannot access the URL 2 app. From the computer that has the Public IP we added at the rule, I can browse both sites. 

The WAF rules can be edited at the Web Application Firewall policies (WAF) blade and all settings will apply to the corresponding listener.

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Application Gateway | WAF Policy per Listener appeared first on Apostolidis Cloud Corner.

There is a big buzz out there about Azure Front Door.  Is it a Load Balancer? A CDN? A Traffic Manager? A Web Application Firewall ? A Reverse Proxy? An Application Gateway?

So, what is Azure Front Door?

Azure Front Door actually is all the above and more. It is a global service, that routes web traffic based on performance and availability. A Layer 7 multi-region load balancer with Web Application Firewall (WAF) capabilities, DDoS protection & CDN.

Azure Front Door is the entry point, the edge, of all Microsoft’s WAN. All Microsoft services, like Office 365 & Bing, are using Azure Front Door.

The services that Azure Front door provides are:

• Accelerate application performance
• Increase application availability with smart health probes
• URL-based routing
• Multi-site hosting
• URL redirection
• Session affinity
• SSL termination
• Custom Domain & certificate management
• Security via custom WAF rules
• DDoS protection
• URL rewrite
• IPv6 and HTTP/2 support

At Azure Front Door documentation there is a paragraph that can help to understand the difference between Azure Front Door and other publishing / load balancing Azure solutions and where to use each.

Azure provides a suite of fully managed load-balancing solutions for your scenarios. If you are looking for a DNS based global routing and do not have requirements for Transport Layer Security (TLS) protocol termination (“SSL offload”) or per-HTTP/HTTPS request, application-layer processing, review Traffic Manager. If you are looking for load balancing between your servers in a region, for application layer, review Application Gateway and for network layer load balancing, review Load Balancer. Your end-to-end scenarios might benefit from combining these solutions as needed.

For pricing information, see Front Door Pricing.

How to scale your web apps with Front Door

Create two simple Azure Web apps. Check this guide for a simple guide on how to create Azure App Service: https://www.e-apostolidis.gr/microsoft/azure/azure-start-point-your-first-web-app/

One at West Europe:

and one at North Europe:

Using FTP, I deployed an one-page html site at both regions. I change the text of both site to say “This Web Site is located at North Europe Azure Datacenter”

and “West Europe” to the other.

Then create a Front Door. Search for Front Door at Azure marketplace and Create one.

This is a high level diagram of the Front Door with two Web Apps design that we will create

The “create a Front Door” wizard will start and we can configure it step by step. First we will create a Frontend host by clicking the + at the Step 1

At the frontend host we will create the URL that our apps will be available. I added the papostolidis.azurefd.net. of course later you can add your custom domain and add a CNAME to route the traffic to the Front Door.

Then, at the Backend pools (Step 2), press the + to add the web apps. add a name for the backend pool, like “myapps” and press + ADD a backend to add the apps.

Select host type, you can add app service, cloud service, storage and custom host (URL). I selected the app service.

Select the subscription and the app service and add the correct ports for http and https traffic.

The priority defines if the traffic will be routed to the host with the lower priority number (e.g. 1) and if that host fails will route to the next host with bigger priority number (e.g. 2). If you add the same priority to more than one host then it will follow the weight number.

The weight number defines the percentage of requests that will be routed to each host.

The same way add the second web app

Finally select a path, protocol and interval for the probe that will do health checks to the app to define if it is active or not.

The third step is to add the routing rules. At the routing rules you can specify:

• The accepted protocol, http or https.
• the frontend host for this rule
• the patterns that the route will accept, like www.e-apostolidis.gr/mysite/* or just /* ro root.
• Route type forward or redirect.
• The backend pool that this rule will direct the traffic
• The protocol that the traffic will be forwarded. Here we define the SSL Offload if we select HTTPs for frontend accepted protocol and HTTP for backend.
• URL Rewrite rules
• Caching, for static content caching like CDN.

Once all steps are completed we can move on and create the Front Door

When the Front Door is ready, we can see the URL at the Overview.

And browse our web app using the Front Door URL:

How to protect your web apps with Front Door

Right now we scaled our web apps. If we use each app’s URL we can still access the app. The first security step is to lock the web apps to be accessed only through the Front Door URL.

Checking the Azure Front Door FAQ page, https://docs.microsoft.com/en-us/azure/frontdoor/front-door-faq it lists the Front Door’s address rance.

Front Door’s IPv4 backend IP space: 147.243.0.0/16

Go to the App Service, at the Networking section, select “Configure Access Restrictions”

Add an allow access restriction with the IP range of the Front Door.

Automatically a Deny rule will be created for everything else.

Add the rule to both web apps and then try to access the apps with their direct links.

Now on, we can access the apps only by using the Front Door URL:

This is a high level diagram after the restrictions

At the next article, we will see how to add Web Application Firewall (WAF) Rules to Front Door, Stay Tuned!! 

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Securely scale your Web Apps with Azure Front Door appeared first on Apostolidis Cloud Corner.

At my previous posts we have seen how to Protect your Web App using Azure Application Gateway Web Application Firewall and Use Log Analytics to Query the WAF Logs and email those logs to the Admins. At this post I want to share some tips on how to configure the Azure Web Application Firewall.

The Azure Web Application Firewall, like all WAFs, needs a period of detection “the training period”, in order to gather logs about what is logged as blocked so to configure it accordingly before turning the WAF to Prevention mode. The Azure Web Application Firewall uses OWASP ModSecurity Core Rule Set (CRS). You can select version 2.2.9 or version 3.0 of the OWASP ModSecurity Core Rule Set. These rules include protection against attacks such as SQL injection, cross-site scripting attacks, and session hijacks.

The configuration of the Azure Web Application Firewall has two parts. One part is the OWASP rules custom configuration, where we can check / uncheck the OWASP rules that the WAF will use to analyse the requests:

and the second part is the Exclusions and the Request Size Limits:

Let’s see how we can find out what to exclude and what to customize. Once you setup the Azure Application Gateway and Publish your web application turn of the Firewall in Detection mode. Enable the Diagnostic Logs and send the logs to Log Analytics and start using the we application. I have covered all those steps at my previous posts, Protect your Web App using Azure Application Gateway Web Application Firewall and Use Log Analytics to Query the WAF Logs and email those logs to the Admins. To make it more fun you can actually attack your application using sample attacks, like SQL Injection samples from this link: https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) and Cross-site Scripting (XSS) from this link: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) . Both links are from OWASP for testing.

After a while run the query to check the Azure Web Application Firewall logs:

AzureDiagnostics | where Resource == "PROWAF" and OperationName == "ApplicationGatewayFirewall" | where TimeGenerated > ago(24h) | summarize count() by TimeGenerated, clientIp_s , TimeGenerated , ruleId_s , Message , details_message_s , requestUri_s, details_file_s , hostname_s

You will get the below results:

At the Message part of the Log you will see the kind of attack that the WAF has detected.

At the ruleId_s you can find the OWASP rule ID. With this information you can search the Rule ID at the Advanced rule configuration and uncheck the specific rule. Of course every rule you uncheck you open a security hole. So I recommend to first check if you can alter your application to comply with the rule and only if this is not possible to drop the rule.

At the details_message_s column also you can find the matched pattern and configure the Exclusions

Finally you can configure the request size limits according to your application

Once you finalize your Azure Application Firewall configuration and you no longer have “Blocked” messages change it to “Prevention” mode to start protecting your web application.

Reference:
WAF Overview: https://docs.microsoft.com/en-us/azure/application-gateway/waf-overview
WAF Configuration: https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-waf-configuration
OWASP ModSecurity Core Rule Set (CRS): https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Configure The Azure Web Application Firewall appeared first on Apostolidis Cloud Corner.

In this post series we will go through some basic steps on how to start with Microsoft Azure. For start we will create a Web App.

If you don’t have an Azure Subscription, you can easily create a free trial by just going to https://azure.microsoft.com/en-us/free/

Let’s create our first Web App. Go to the Azure Portal by navigating to https://portal.azure.com and click “+ Create a resource”

At the search box write “Web App” and press enter

At the search results. click the “Web App” and at the next screen just press “Create”

The “Web App Create” wizard will open.

Enter a name for the App. This will be the Public name of your App. Azure by default provides the domain *.azurewebsites.net for free. So in my example the prowebdev.azurewebsites.net will be the URL of my App Select the Azure Subscription that will used to bill the Web App and a Resource Group. The Resource Group is used to organize the resources and provide role based access control among other. OS: Select the Operating System platform that will host your Web App. This can be Windows, Linux or a Docker Container. For the test I will select Windows.

As you can see the wizard has selected an App Service Plan by default with a random name and location. The App Service Plan is actually the Web Server that will host out Web App. Click on the “App Service Plan/Location”

Add a name for the Web Server, select the Location that is nearest to you (or your clients) and the Pricing Tier.

By pressing OK you will return to the Web App create wizard and press Create. Now you can monitor the creating process of the App form the “Notifications” option at the top right of the portal, it is the button that has a ringing bell image. First you will see the “Deployment in progress…” message and as soon as the App is ready you will see the “Deployment completed” message.

Now if you go to the Resource group you will see two resources. The App Service and the App Service Plan. In high level, the App Service Plan is the web server and the App Service is the Web Application.

Now click the App Service and at its blade you can see your applications URL.

Click the URL and you will see the Demo page

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Start Point | Your first Web App appeared first on Apostolidis Cloud Corner.

There are many scenarios where we want to have the Web Application on the Cloud but on the other hand, due to various limitations, the database stays on-premises. Azure has a service, called Azure Hybrid Connections, that allows the Web App to connect to on-premises databases, using internal IP address or the database server host name, without a complex VPN setup.

The Connection diagram

I have tested the connection with Microsoft SQL, PostgreSQL, MySQL, mongodb and Oracle.  The databse requirements is to have a static port. So the first step in case of a Microsoft SQL instance is to assign a static port. In my test environment I have a Microsoft SQL 2016 and I assigned the default port 1433, using the Sql Server Configuration Manager / SQL Server Network Configuration / Protocols for INSTANCENAME (MSSQLSERVER)

All paid service plans supports hybrid connections. The limits are on how many hybrid connections can be used per plan, as the below table shows.

To start creating the Hybrid Connections, go to the App Service / Networking / Hybrid Connections and press the “Configure your hybrid connection endpoints”

At the Hybrid connections blade there are two steps, the first is to “Add hybrid connection” and the second is to “Download the connection manager”.

First click the “Add hybrid connection” and then press “Create new hybrid connection”

The “Create new hybrid connection” blade will open. Add a Hybrid connection name, this must be at least 6 characters and it is the display name of the connection. At the Endpoint host add the hostname of the database server and at the Endpoint port, the port of the database. At my case I added 1433, as this is the port I assign to my SQL instance before.

Finally you will need to specify a name for a Servicebus namespace. As you realize, the hybrid connection uses Azure Servicebus for the communication, and press OK.

Once the connection is created it will be shown at the portal as “Not connected”

Now we need to download and install the hybrid connection manager by clicking the “Download connection manager”. For this test I will install the hybrid connection manager at the same server as the SQL database, but for a production environment it is recommended to install the hybrid connection manager to a different server that will have access to the database servers only to the required ports. For the best security install it to a DMZ server and open only the required ports to the database servers.

Run the downloaded msi and just click Install.

Open the “Hybrid connection manager” UI and press “Add a new Hybrid Connection.

Sign in to your Azure account

Once logged in, choose your Subscription and the hybrid connection configured previously will appear. Select it and press Save.

Now at the connection manager status it will show “Connected”

The same at the Azure Portal and your Hybrid connection is ready.

Test, test, test and proof of concept. Open the Console, form the Web App Blade, and tcpping the SQL server’s hostname at the port 1433

and also sqlcmd

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure App Service, get data from on-premises databases securely appeared first on Apostolidis Cloud Corner.

Web Application Firewall was always a big investment for a small or growing company as most of the top branded companies are charging a lot of money  A Web Application Firewall protects your application from common web vulnerabilities and exploits like SQL Injection or Cross site scripting. Azure provides enterprise grade Web Application Firewall through the Application Gateway. It comes in two pricing models, Medium and Large. More about sizes and instances you can find here, and more about pricing here

We can add the Application Gateway Web Application Firewall to protect our Azure Web App (PaaS) and our Web Application inside a VMs web server (IaaS). At this post we will see how to protect them both.

One difference in order to fully protect the Azure Web App (PaaS) is to integrate the App Service to a Virtual Network (VNET). In order to integrate an App Service to a Virtual Network it requires a Standard, Premium, or PremiumV2 pricing plan and requires the Virtual Network to have a Virtual Network Gateway that is configured with Point to Site VPN.

Virtual Network

First things first, create a VNET. The VNET must have at least two subnets. One subnet to deploy the Virtual Machine that we will use to publish an IIS Application and one dedicated for the Application Gateway WAF.

Once the VNET is created enable the Point-2-Site VPN. More details can be found here: https://www.e-apostolidis.gr/microsoft/azure/azure-start-point-point-to-site-vpn/ 

Web App

Create a Web App from Azure Portal. For more details check here: https://www.e-apostolidis.gr/microsoft/azure/azure-start-point-your-first-web-app/

VNet Integration

Once the Web App is ready, go to Networking and select “Click here to configure”

Add VNET, select the VNET and press save

Then go back to the Networking blade of the App Service and go to Firewall in order to disable public access and allow only access from the VNET. To do this click the “Configure Access Restrictions”

create an allow IP Restriction and add the WAF’s IP. Once you create an Allow rule, all other access to the app service is restricted automatically. If you try to browse the public URL of the App Service it will return “Error 403 – This web app is stopped.”

Web Application Firewall

Lets create the Secure public entry point for our Web App. Create an application gateway, select WAF Tier, select the required SKU, add it to the WAF subnet we created before, select Public IP configuration and WAF enabled.

When the Application gateway is ready we need to do some configuration. First at the Backend pools, open the default created backend pool, select “App Service” and browse to the required web app.

Then add a health probe. For host add the FQDN of the Web App.

at the HTTP settings check the “Use for App service”

Add a rule to bind the Listener, Backendpool and HTTP settings

And that’s all. Now we can try our Web App from the Internet. In order to do so we need to browse to the Web App’s URL, that is now published by the Application Gateway, from the Internet. So, we need to create a Public DNS record to point the FQDN to the Application Gateway’s FQDN. In this case we need to crate a CNAME papwaf3app.funniest.gr to point to the 8b0510c1-47e9-4b94-a0ff-af92e4455840.cloudapp.net. In order to test the app right now we can just add a host file to our computer pointing to the Public IP Address of the application gateway and we can access the Web App behind the WAF.

Logging

In order to be able to see the Application Gateway and Web Application Firewall logs we need to turn on diagnostics. The easiest way to see the logs is by sending them to Log Analytics (OMS).

With the Firewall at “Detection” mode, if we try an SQL Injection (?id=10||UTL_INADDR.GET_HOST_NAME( (SELECT user FROM DUAL) )–), the Web App still servers the landing page.

By switching the Firewall to “Prevention” mode, the same SQL injection attach stops by the WAF before accessing our Web App.

Protect an IaaS Web Application

To add a Web Application that runs inside a VM behind the Application Gateway Web Application Firewall, first add the VM as a Back End Pool. Create a new Backend Pool and select “Virtual Machine”. Select the Virtual Machine that runs the Web Application.

Then create a new probe adding the URL of the Web Application

next add HTTP settings and add custom probe the new created probe “vmsite”

Next step is to create two multi-site listeners, one for each host name

After the listener, add a Basic rule using the Listener, Backend Pool and HTTP settings we created for the VM Web Application,

Finally one extra step is to change the default rule1 to listen to the WeB App listener

Finally the Application Gateway Web Application Firewall provides secure access to both the Web App (PaaS) and the VM Web Application (IaaS)

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Protect your Web App using Azure Application Gateway Web Application Firewall appeared first on Apostolidis Cloud Corner.