While migrating an on-premise webserver to Azure for a client, we needed to expose the web traffic publicly while still protecting these sites, just like On-Premise. The customer is very keen on security and lowering risk and requested we utilize PaaS instead of IaaS as much as possible. We needed the solution to be secure (firewall) and be highly available (load-balanced and resilient). To do this, we implemented an Azure PaaS service, the Application Gateway. The Application Gateway allows load-balancing traffic that enables you to manage traffic to the web application on port 443 (HTTPS) and 80 (HTTP) directly to one or more backend servers.
A more traditional load balancer operates at the transport layer (OSI layer 4) and routes traffic based on source IP address/port to a destination IP address/port. But by adding Listeners, routing decisions can be made on additional attributes of an HTTP request, such as the header or the URI itself. For example, you can route traffic based on the incoming URL. So if /images are in the incoming URL, traffic can be routed to a VM, an On-Premise server, or Scale Set (known as a pool), configured to serve up 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 the application layer (OSI layer 7) load balancing.
The Application Gateway (AP) also acts as a Web Application Firewall (WAF). The firewall provides centralized protection for common vulnerabilities such as SQL injections, XSS attacks, and denial of service attacks. Also, SSL Offloading is available to limit traffic to port 443, with an SSL certificate, then redirect traffic to the appropriate internal port. The advantage of this is that you can apply the certificate to just the front-facing application gateway and forgo propagating the certificate to the individual VM's themselves. This makes the solution more comfortable to set up and manage.
Some of the features we utilized included.
URL-based Routing: Make routing decisions based on the URI path or host header. For the example above, we talked about routes bassed on the /images and /video folders. This is done by utilizing a back end pool (server or set of servers).
SSL/TLS Termination: We can secure the frontend servers with HTTPS traffic but also allows for unencrypted traffic between the backend servers and the Application Gateway.
Multi-Site Support: This enables us to configure more than one site within the same application gateway. It can be done by port or header as well.
Redirection: The redirecting of traffic from one listener to another site or listener.
Stick Session/Affinity: This allows us to keep a user session on the same server.
HTTP/2 & Websockets: Native support for HTTP/2 and Websocket protocols
HTTP headers rewrite: Ability to Add, Remove, and update HTTP request and response headers, while the packets move between the client and backend pools. There is much granular control here.
Custom Error Pages: Allows for the creation of custom error pages by backend pool.
The Requirements
For our requirements, we need to set up the Application Gateway with SSL/TLS termination that could handle not only secure web traffic but also logging/audit information passed on a different port.
The Parts
The Application Gateway has multiple parts and understanding these parts and how they interact with each other is an important step. To explain the relationships of each of these parts, let's refer to the diagram.
In our case, we first created a front end IP in the Application Gateway (AG) to associate with our domain. The front end IP uses a public IP Address to be able to map the underlying public IP resource in the Application Gateway.
Once this request is made, the AG inspects the hostname in the request and passes the request to the associated Listener (HTTP or HTTPS).
The routing rule tells the AG what to do with the incoming request. The routing rule can be used to determine which HTTP listener to use and which backend pool to forward the request. Again this rule can even be path-based routing and can be forwarded either internally or externally.
The backend pool is ultimately where the request ends up once it has been processed by the AG.
Next, we set up a virtual network (VNET) that included two subnets. One to handle the public webserver traffic and a more internal subnet that stores the backend service layers and microservices. The VNET itself is locked down with individual Network Security Groups, each with its own set of inbound and outbound rules. In those rules, we only allow specific port traffic to pass through.
In our case, the public subnet allows traffic from the AG through. The private subnet only allows traffic from the subnet1 but nowhere else. Traffic is limited on each individual VM via a Network Interface. Both the Network Security Group (NSG) and the Network Interface (NI) allows for inbound/outbound rules to be set for ultimate control.
In this brief introduction to using the Application Gateway, I hope you can see what is possible and why you might want to add an Application Gateway and Windows App Firewall in front of your public-facing websites.
Competitive Edge
Doug Romano is a Cloud Services Architect, at Software Design Partners. The Application Gateway provides a significant impact on the security of a business. Please contact us to explore how SDP can leverage this technology to create a competitive edge for your business.
.jpg)
