Protecting AppService using Front Door

Starting with the fact that every web application should be protected by a Web Application Firewall (WAF) and accelerated using a Content Delivery Network (CDN), combined with the simplicity of the deployment of the Azure Front Door service, gives you no excuses for not protecting your apps!

In this blog post, we're going to deploy an AppService and protect it using Azure Front Door. For the purposes of this demo, we're going to use the NodeJS - RequestInformation app that is available in my Github repo over here. This application provides information on the platform and incoming requests that is going to be very handy later on.

To deploy the demo resources, you just have to clone this repository, change to the FrontDoor-AppServiceBackend-001/101-Bicep-Templates/900-IaC-FullDeployment-001 directory, and execute the deploy.sh script. The script will create a subscription-level deployment that will deploy an AppService (including the plan) and an Azure Front Door. Make sure you are logged in and you have selected the right subscription! 

The completed deployment should look like the below:

If you open up the Overview page of the AppService and browse the app, you'll get something similar to the below:

It may take some time for AppService to download the container image and create the container, so don't be alarmed if the first request takes too long to complete. You can monitor the process in the logs section of the deployment center:

Part of the Bicep deployment is also the creation of an Azure FrontDoor resource and the configuration to use the AppService as a backend:

If you browse the endpoint created as part of the Front Door configuration you'll get the same page, however, there are a few changes and additional headers:

In case Front Door shows an error, give it some time to connect to the AppService, it usually takes a couple of minutes.

At this point, the configuration on DNS should direct all the requests targeting the AppService to Front Door. The AppService however is still reachable using its IP or URL and we have to find a way to allow traffic only from the Front Door services, and even better, only our Front Door instance.

Hopefully, AppServices provide the ability to restrict inbound traffic based on a number of conditions, including source IPs, Service Tags, and Headers.

Switch to the Networking blade of the AppService and click on the Access Restriction option under Inbound Traffic as shown below:

In the Access Restrictions page, you have the ability to create rules and control inbound traffic. We're going to create two rules:

  • one that will allow traffic from our Front Door instance, and 
  • one that will allow direct traffic from a public IP for troubleshooting purposes.
a default deny-all rule will be automatically created, taking care of the rest of the traffic!

Starting with the first rule, we are going to use an Allow action with Service Tag type and the  AzureFrontDoor.Frontend tag. The value for the X-Azure-FDID header should be the id of the Front Door resource, taken from the Overview page:

Your rule should be similar to the below:

If you take a closer look, the id shown on the above page matches the value of the X-Azure-FDID header in the second request, since the request went through Front Door!

At this point, the application should be available only via Front Door. If you try to access it directly, you should get a message that access is forbidden:

The second rule is a bit easier to implement, you just have to allow access from your public IPs using the source settings on the rule:

You should end up with three rules in total, the two that you have created and the default deny all that is created by Azure:

That's it, your AppService is now protected by Azure Front Door!

Popular posts from this blog

Domain Controller Machine Password Reset

Image
On my lab environment, I've configured two Active Directory sites since most enterprises have offices in more that one places. My lab however is not running 24/7 and the domain controllers in the second site are rarely turned on in order to save resources. This leads to issues with the Active Directory replication such as the "The target principal name is incorrect" error when I execute:  repadmin /syncall /AdeP. To remedy the issue, we have to reset the machine password of the domain controller that has been offline. First off, we are going to stop and disable the Kerberos Key Distribution Center (kdc) service on the problematic domain controller, in our case DC4. There may be some tickets in the cache so we should also clear them using klist purge Now it's time to change the machine password of the domain controller using the command netdom resetpwd /s:dc3 /ud:lab\administrator /pd:* Replace the "lab\administrator" with an account on your...
Keep reading

Managing Active Directory User Certificates using PowerShell

I first came across user certificates when I was working with email certificates a few years ago and I have to admit that I had trouble updating the certificates on the objects! Most organizations have a Microsoft Active Directory Certification Authority that issues the certificates used internally. When a certificate is issued to a user, the Microsoft Certificate Service saves the public key in Active Directory. The userCertificate attribute is a multi-valued attribute that contains the DER-encoded X509v3 certificates issued to the user. Although we rarely need to pay attention to this attribute, there are cases where we have to update it. To make things easier, I've written PowerShell functions to Get, Remove, Import and Export the certificates on that field. To get the list of certificates for an object, use the Get-ActiveDirectoryObjectCertificate function: PS C:\> Get-ActiveDirectoryObjectCertificate -UserPrincipalName cpolydorou@lab.local DistinguishedName  ...
Keep reading

Configuring a Certificate on Exchange Receive Connector

Today's article is about configuring Exchange receive connectors with specific certificates. Out of the box, Exchange uses self signed certificates to provide TLS secured mail flow. This will definitely be an issue if you expose the SMTP protocol to client computers since they won't trust the certificate. In this article we are going to configure a certificate that was issued by a third part authority to the Client Frontend receive connector. We'll start with getting the thumbprint of the certificate using the Get-ExchangeCertificate cmdlet: [PS] C:\> Get-ExchangeCertificate Thumbprint                               Subject ----------                               ------- 241B864DC82C664FECBA18B8D54987AAFB65B4C2 CN=*.lab.com, ... D4D210886B34E690191A1F008C78FDD0E7325DD4 CN=Exchange2013A 960171662EB26116...
Keep reading