Azure : What do I put in front of my (web) application?

Introduction

In almost every design session, the following question pops up…

“What do I put in front of my web application to secure it?”

Today we will take a look at the different options at hand.Β Or better said … What is the difference between the following services?

Azure CDN vs Azure Front Door versus Azure Application Gateway (WAF) vs Azure Traffic Manager

 

TL;DR

If you do not want to go through the entire post, here is a brief summary of the different options ;

My gut feeling tells me this will already help out like a lot! πŸ˜‰

 

Web Application Firewall (WAF) : Azure Front Door vs Azure Application Gateway

Both Azure Front Door and Azure Application Gateway state that they can be configured to act as a Web Application Firewall. They key difference here is that the Azure Application Gateway can do a “detection only”-mode and that it supports CRS 2.2.9, 3.0, and 3.1. This means that there are out-of-the-box rules that provide a baseline security against most of the top-10 vulnerabilities that Open Web Application Security Project (OWASP) identifies. With Azure Front Door, you need to configure the rules yourself to your liking.

In terms of networking, there also is a very important difference between both. An Azure Application Gateway can be deployed (injected) in(to) an Azure VNET (Virtual Network). By doing so, the traffic between this gateway and your internal backend will flow through a private network. With Azure Front Door, your backend is always based on a public endpoint. Though you can harden / lock down the connectivity between Azure Front Door and your application by restricting the ingress of the traffic.

 

Geographic Redundancy : Azure Front Door vs Azure Traffic Manager

If you want to publish your webapp across regions, then you can leverage Azure Front Door or Azure Traffic Manager to do so. The most important thing to know is that Azure Traffic Manager is DNS based and serves as a redirection mechanism. Azure Front Door will serve as an entrypoint (think reverse proxy). So when using Traffic Manager, you will typically look at another reverse proxy / WAF (like Azure Application Gateway) to cover the need for the secure entrypoint for your application. Next to that, the Azure Traffic Manager is more feature rich in terms of the routing mechanisms, though Azure Front Door (just like Azure Application Gateway) have the advantage of working at layer 7 (Reference : OSI Model), thus also do header/path based routing.

 

Caching Content : Azure CDN vs Azure FrontDoor

The first thing to realize is what the intent was of both solutions?

  • Azure CDN is a Content Delivery Network and was designed to delivery content. Think in terms of media files (“video”) for instance.
  • Azure Front Door was built as a scalable entry point for applications (like Office 365)

Both will do caching (check the links above), though they differ in the sweet spots. Azure Front Door will cache files up to 8MB (as a side trait), where you should think that this is mainly done to optimize the delivery of your “web app”. Azure CDN its core function is caching… It was built to ensure that your files would be distributed world wide and delivered from a local pop.

The funky thing here, is that (if you ignore the Verizon and Akamai flavors of Azure CDN) both Azure CDN and Azure Front Door share the same POPs! Though the caching mechanics of both work differently.

 

DDOS

All services will have DDOS protection (“Basic”), as this is native to any Azure service! It is a key component of the Microsoft backbone actually. Though you can augment the services that reside in your VNET with the “Standard” protection. That being said, do know that the Azure Application Gateway does not scale as dynamic as the other services mentioned here (Azure Front Door and Azure Traffic Manager). So this could become a bottleneck for your design.

 

Closing Thoughts

With more than 100 services in Azure, you are bound to have services that overlap in terms of capabilities. I do hope this post provides you with some guidance towards a the external facing endpoints of your application! The above things are the recurring patterns I see in discussions with the organizations I talk to when deploying web applications on Azure.

Improving your code quality by linking Azure DevOps with SonarCloud

Introduction

In a customer workshop earlier this week, Hans mentioned a very nice tool (SonarCloud). He used it “in his previous life and was very enthusiastic about it. So this immediately triggered my curiosity… πŸ˜‰ As it is free for public projects, I investigated how easy it was to integrate into my existing pipelines. Which turned out to be quite easy! After browsing around a bit on how to integrate it into a YAML pipeline, I can proudly say that VMchooser is now fully hooked up with SonarCloud.

However, it did confirm my suspicion, that I am a lousy developer! πŸ˜‰ Though better lousy code fulfilling a purpose than having no alternative at all?!?

Anyhow, today’s post is about the experience of moving existing pipelines to SonarCloud and investigate the results you get out of it.

Continue reading “Improving your code quality by linking Azure DevOps with SonarCloud”

Improving the security & compatibility aspects of package management with native GitHub features

Introduction

Did you know almost every piece of software depends on OpenSource? Not sure… What libraries is your software using? Bingo! πŸ˜‰

Now we all know that package management can be a true hell. Tracking everything and ensure you are up-to-date to achieve the needed security level is hard. Next to that, there is always the risk that your build will break to moving to a library version.

What if we could enhance that flow a bit? You guessed it… Today’s post will be around how we can leverage native GitHub features to help us in this area!

 

Let’s hit the slopes!

For this walk-through, we’ll use the following ;

  • an existing code repository, where we’ve forked CoreUI’s VueJS repo
  • GitHub’s actions to run a workflow on every pull request
  • GitHub’s automated security feature that will send pull requests to us when it detects security issues

Want to test this one out or follow along? Browse to the following sample repository ; https://github.com/beluxappdev/CoreUI-VueJS-GitHubSecurityDemo

So let’s fork this sample repository!

Continue reading “Improving the security & compatibility aspects of package management with native GitHub features”

Hardening your storage account with Private Link / Endpoint

Introduction

Earlier this week, a new capability called “Azure Private Link” (and also “Azure Private Endpoint”) went into public preview. As a nice copy & past from the documentation page ;

Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer/partner services over a Private Endpoint in your virtual network. Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet. You can also create your own Private Link Service in your virtual network (VNet) and deliver it privately to your customers. The setup and consumption experience using Azure Private Link is consistent across Azure PaaS, customer-owned, and shared partner services.

As always, we’ll take this one out for a spin! For this we’ll see if we can access a storage account privately (from a virtual machine) over the VNET.

 

Continue reading “Hardening your storage account with Private Link / Endpoint”

Taking the user delegation SAS tokens for a spin

Introduction

A few days ago the preview for the “User delegation SAS token” has seen the light. In today’s post, we’ll take a first glance on this new capability! Though why should we care about this feature? You can now create SAS tokens based on the scoped permissions of an AAD user, instead of linked towards the storage account key. From a security perspective this is REALLY awesome, cause you can harden the scope of a possible even more.

 

Bibliography

Continue reading “Taking the user delegation SAS tokens for a spin”

Reverse engineering the “AADLoginForLinux” in order to tweak proactive user configuration

Introduction

Last summer I posted about taking a look under the hood of the Azure Active Directory integration for a Linux Virtual Machine. For today, let’s take it a bit further… What if we would want to pre-provision a set of UIDs (User IDs) & GIDs (Group IDs) on a range of virtual machines for cross machine consistency. Let’s say, we would want to make use of an NFS drive and use the same UID/GID across all those boxes. Can we do that with the AAD extension? If so, how can we do it? Let’s hope we can… Otherwise it’ll become a rather short blog post.

 

Disclaimer

This post is based upon my personal experience reverse engineering how this extension works. This is by no means a support statement. If you’re a technical nut (like myself) and want to know how you can tweak this at your own doing… Then this post is for you. πŸ˜‰

Continue reading “Reverse engineering the “AADLoginForLinux” in order to tweak proactive user configuration”

What the proxy?!? How to use a proxy with the typical Azure tools…

Introduction

Proxy servers are a very common thing in a lot of enterprises. They are used so that people cannot directly access the internet, and additional management capabilities to the flow (logging, authentication, …). Now that sounds very dandy, though what about those non-browser-based tools? How can we ensure that tools like Azure CLI, Azure Powershell & AzCopy work with our “beloved” enterprise proxy? That’ll be the topic for today!

Test Setup

What will we be doing today? I’ve setup a proxy server in my own lab… Basically deployed a Squid proxy by means of a container.

Next up, I’m going to use the three earlier mentioned tools on both Linux (WSL) & Windows, and see what needs to be done to get things working. In the following screenshots you’ll typically see a “split screen”, where left is a “tcpdump” on the box running the proxy server and right will be the commands on the box running the tools. If you see a lot of mumbo jumbo (network packets) on the left, that’ll mean that the proxy server was being used. Ready?!? Cool, let’s go!

Continue reading “What the proxy?!? How to use a proxy with the typical Azure tools…”

Hardening your Azure Storage Account by using Service Endpoints

Introduction

Earlier this week I received a two folded question ; “Does a service endpoint go over internet? As when I block the storage account tags with a NSG, my connection towards the storage account stops.” Let’s look at the following illustration ;

Β 

The first thing to mention here is that the storage account (at this time) always listens to a public IP address. The funky thing is, that in Azure, you’ll have a capability called “Service Endpoint“, which I already covered briefly in the past. For argument’s sake, I’ve made a distinction in the above illustration between the “Azure Backbone” and the “Azure SDN”. A more correct representation might have been to have said “internal” & “external” Azure Backbone in terms of the IP address space used. So see the “Azure Backbone” in the above drawing as the public IP address space. Here all public addresses reside. Where the “Azure SDN” is the one that covers the internal flows. Also be aware that an Azure VNET can only have address spaces as described by RFC1918. So why did I depict it like this? To indicate that there are different flows;

  • Connections from outside of Azure (“internet”)
  • Connections from within the Microsoft backbone (“Azure Backbone”)
  • Connections by leveraging a service endpoint

So how does the service endpoint work?

So to answer the question stated above ;

  • Q: Does a service endpoint go over “the internet”?
  • A : Define “internet”…
    • If you mean that it uses a public ip address instead of an internal one? Then yes.
    • If you mean that it leaves the Microsoft backbone? Then no.
    • If you mean that the service is accessible from the internet? Unless you open up the firewall, it won’t (by default, when having a service endpoint configured).

 

  • Q: When I block the storage tag in my network security group (“NSG”), then the traffic stops. How come?
  • A: The NSG is active on NIC level. The storage account, even when using a service endpoint, will still use the public IP. As this public IP is listed in the ranges that are configured in the service tag, you’ll be effectively blocking the service. This might be your objective… Though if you do this to “lock down the internet flow”, then you won’t achieve the requested you wanted. You should leverage the firewall functionality from the service for which the service endpoint was used.

 

Deep Dive

As always, let’s do a deep dive to experience this flow! So I did set up the above drawing in my personal lab ;

Continue reading “Hardening your Azure Storage Account by using Service Endpoints”

Landscaping a Secure/Closed Loop Infrastructure in Azure with Terraform & Azure Devops

Introduction

Posts about security are always the ones that make everyone get really excited… Or maybe not everyone. πŸ˜‰ Anyhow, what is typically the weakest link in any security design? Indeed, the human touch… The effects of this can range from having seen secrets to creating drift (unwanted changes vs de expected baseline). In today’s post, I’ll walk you through an example setup that aims to close some additional holes for you. How will we be doing this? By basically automating the entire infrastructure management with Azure Devops & Terraform. Now you’ll probably think, what does that have to do with security? Good response! We’re going to reduce the points to where human contact can interfere with our security measures. Though we want to do this without putting our agility at risk!

 

Blueprint

For this exercise, we’re going to leverage this blueprint ;

Continue reading “Landscaping a Secure/Closed Loop Infrastructure in Azure with Terraform & Azure Devops”

Call the Microsoft Graph API -and- your own API from a Single Page (JavaScript) Application

Introduction

If you have gone through the typical authentication scenarios, then you’ve probably seen that almost every single one is calling the Graph API. Where that is already cool as such, we’re all probably more interesting in using our own APIs… Today’s post will go through the process of calling -both- the Microsoft Graph API and your own API from the same code base.

 

Starting Knowledge Assumption

My assumption is that you are already familiar with the basics of Oauth, where you’re aware that a Single Page Application (SPA) is using an “Implicit Grant Flow“. Also be aware that the Azure Active Directory (AAD) v1 endpoint differs from the v2 endpoint in terms of resources & scopes.

In the v1 endpoint, you would target a “resource” in order to get authorization ;

Where the v2 endpoint rotates around the usage of scopes ;

The latter indicates both the resource & the permission that is targeted…

 

Setup of the day

As our test bed for today, we’re having a Single Page Application that has its own “Application ID” (clientid in Oauth). Which will be linked to two backend APIs; Microsoft’s Graph API and our own

Both our APIs have a given set of scopes that indicate the permissions that a user grants towards these APIs…

Continue reading “Call the Microsoft Graph API -and- your own API from a Single Page (JavaScript) Application”