We help startups start up.
x
One of the great advantages of building applications in the cloud is that you get to take advantage of a plethora of PaaS and SaaS applications and frameworks so you can focus solely on building out your application. From ASP.NET Core to Azure App Services, SQL Azure, and more; developers have never had it so good! Standing up an n-tier application architecture can be done seemingly in minutes. Pretty outstanding. However, SecOps, Network Admins, and Compliance Officers don't always feel the love when a lone ranger developer throws their app into the wild without any security other than what may or may not be included in the application platforms and frameworks that are being used.
It seems like a weekly event these days to hear about this company or that company being the subject of a data breach. And web apps are increasingly the avenue that hackers exploit with the use of malicious attacks such as SQL inject, cross-site scripting, and many more.
In this series of posts we'll be diving into the world of the Azure Web Application Firewall on Azure Application Gateway with the goal of bringing devs, IT, SecOps, and Compliance together as never before against intrusions as well as empowering developers to provide true OSI Layer 7 security for their applications without making changes to application code. We'll be covering topics such as front end and back end pools, SSL termination, creating custom policies and rules, as well as logging and the pure awesomeness that is Azure Sentinel.
To begin this series let's first discuss what the Azure Web Application Firewall or “WAF" is. However, before we can talk about the WAF we must first discuss the Azure Application Gateway or “AG" on which the WAF resides and why it's beneficial to include it in your architecture.
From the Microsoft docs:
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.
Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers. For example, you can route traffic based on the incoming URL. So, if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos.
This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can do URL-based routing and more.
Indeed, the AG is capable of much more such as SSL termination, end-to-end SSL encryption, cookie-based session affinity, and multi-site hosting. However, enabling the WAF within an AG adds OSI Layer 7 protection against common OWASP web vulnerabilities. The WAF comes preconfigured with OWASP ModSecurity Core Rule Set 3.1, 3.0, or 2.29 and can be configured to enable or disable specific rules or even create your own custom rules.
Let's dive in!
The scenario: An existing application with some serious security holes
First let’s take a brief look at our starting architecture.
There are a few important things to note here. To most developers this might seem pretty typical. You have IIS configured to accept public (potentially malicious) internet traffic over ports 80 and 443. Of course, any traffic over port 80 gets automatically redirected to port 443. In our first set of demos we will be looking at why this type of system architecture may not be enough to guard your users and data against malicious attacks.
To put things into context before we get rolling here is a very high level look at our end point system architecture which will provide OSI Layer 3, Layer 4, and Layer 7 protection against OWASP threats and more including Distributed Denial of Service (DDoS) which we’ll cover in another post.
There are several primary pieces that were just added to the puzzle and one puzzle piece that has changed.
As touched on above, the AG is introduced as a Load Balancer as well as an SSL Termination endpoint meaning the SSL Certificate used by the underlying applications are uploaded to the AG instead of the applications as is the case in the first diagram.
The WAF sniffs all traffic coming into the AG and will either detect malicious traffic or prevent said traffic from proceeding to the underlying applications. You can use the built in rulesets, customize the rulesets, and build your own custom policies (only allow traffic from specific countries, blacklist an ip address, etc).
The WAF can be configured to send, among other things, the firewall logs to a Logs Analytics Workspace where they can be queried, configured to trigger alerts, projected into charts, etc.
Sentinel is cloud native SIEM and SOAR solution which delivers intelligent security analytics and threat intelligence across the enterprise. Using the Workbook templates provided can surface very detailed information on the requests coming through the AG and whether it is safe or malicious.
Come back for the second post in this series where we will stand up the applications and architecture described in the “Starting Architecture” diagram and demonstrate SQL Injection and Cross-Site Scripting (XSS)
