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.

Application Publishing

Azure Active Directory Application Proxy is a very easy and secure way for web application publishing using the extremely secure Azure AD authentication mechanism. There are a tone of features, like SSO and 2 Factor Authentication. But lets see the basic here. You have a web application that you are using internal to your network, not even https, or you have developed a web application and you want an easy and safe way to publish it without having to wary about authentication or VPN. Use the Azure AD Application Proxy following the following simple steps.

For this example I have used a Windows Server 2016 with IIS and the SugarCRM application using the IIS Web Platform Installer. The internal link is http://appproxy01/sugarcrm/ that opens the SugarCRM login page.

Lets start

Navigate to Azure Portal and go to Azure Active Directory. Mind that Azure Active Directory Basic or Premium license is required. You can start a trial Azure AD Premium or Enterprise Mobility Suite E3 that includes Azure AD Premium.
Fist of all you need to enable Application proxy. Select Enterprise applications –> Application proxy and click Enable & Download the connector clicking the “Connector” link.

Next, install the connector to the web server or to an other domain member server. It requires Windows Server 2012 R2.

At the installation process it will ask to login with an Azure AD account that has access to publish applications.

Once installed, Run the Connector Troubleshooter to verify that the connector will run properly.

After the successful installation,back to the Azure Portal the server FQDN and the Public IP will appear under the Default Connector.

Now it is time to publish the application. Go to “All applications” –> +ADD –> On-premises application.

Give a name, the internal Url that is used to access the application at your local network and press Add. Note the External URL.

The next step is to assign users. Following the quick steps, press “Assign a user for testing”

an add at least a user and you are ready to test the application.

Now lets test the published application

Open your favorite browser and navigate the the External URL. You will be navigated to the Microsoft online service logon page. Once authenticated with your Azure AD account the SugarCRM login page will be served.

This is the simplest way to publish a web application without having to wary for Authentication and Security.

Of course if the application supports active directory authentication then it is very easy to setup SSO, but we will analyze that at the next post.

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 AD | Secure Web Application Publishing appeared first on Apostolidis Cloud Corner.