Securing your applications in Azure can be done by implementing a Web Application Firewall. Web Application Firewall is a feature that is part of the Application Gateway (AGW). Features of the Application Gateway include:
- Web application firewall – Protects web applications from common web-based attacks like SQL injection, cross-site scripting attacks, and session hijacks.
- HTTP load balancing – Layer 7 load balancing (HTTP(s) only)
- Secure Sockets Layer (SSL) offload – Decrypt your HTTPs connection the application gateway instead of your webserver. By doing this, there is more performance left in your webserver for other application related tasks. HTTPS connections are getting terminated on the Application Gateway. From there you can chose to have traffic running unencrypted to your webservers, or encrypt it with a more easy encryption method.
- URL-based content routing – Lets you route traffic for on a certain webfolder, to a certain (pool of) servers.
In this blogpost I will explain how you can enable the Web application firewall for your webserver.
Application Gateway Components
The Application Gateway consist of the following components:
- HTTP Listener – The application gateway sits between the public internet en your application/webserver. All HTTP(S) connections will content to a HTTP listener. This listener can be HTTP or HTTPS.
- Front-End IP Configuration – The IP configuration that your HTTP listener will use (internal IP, external IP etc.)
- Back-End Pool – The servers, IP-address or DNS-hostname that will represent your back-end servers (webservers)
- HTTP Setting – The settings that are used to let Application Gateway connect with the backend (port nr, certificate etc.)
- Rule – The magic glue that connects a HTTP listener to a backend-pool
- Web Application Firewall – The component that secures al the HTTP traffic that is send trough the Application Gateway to the back-end pool.
When you are going to work with a Application Gateway; you should be aware of the following limits:
- A maximum of 50 Application Gateways can be deployed per region per subscription.
- Only 20 HTTP listeners can be created within an Application Gateway. A HTTP to HTTPS forward will cost you a HTTP listener. That listener listens to port 80, and will redirect you to another listener that is running on port 443.
- Web Application Firewall settings are controlled per Application Gateway. This means that changing a setting in the WAF will affect all the traffic (from all the HTTP listeners) that is going thought the Application Gateway.
The Application Gateway requires it’s own subnet. In this subnet you can only deploy Application Gateways. Keep in mind that you probably would like to deploy multiple Application Gateways, therefore make sure that your subnet is big enough to host all these AGWs. I always try to use a /26 (64 IP addresses) for Application Gateways. This is enough space to run multiple Application Gateways and it leaves some space for upscaling.
Implement Web Application Firewall
In this implementation I assume that there is already a webserver running. Mine in running in the same virtual network and Azure subscription as where the Application Gateway gets deployed. I also made an subnet availabile in my VNET for Application Gateways. This is just an empty /26 subnet.
Creating the Application Gateway
- Click on the Add Resource button, search for “Application Gateway” and select “Application Gateway” in the results form. In the blade that appears, click Create
- In the form fill in the following values:
- Name: <name for your AGW>
- Tier: WAF
- Instance Count: 2
- Subscription: <Your subsciption>
- Resource Group: <Name for your resource group>
- Location: <Location in which you want to deploy the AGW>
- Click on OK
- In the following form, fill in the following values:
- Virtual Network: <The virtual network where a AGW subnet is available>
- Subnet: <Your subnet for AGWs>
- Front-end Configuration: Create a new public IP address
- Listener: HTTP
- Port: 80
- Firewall Status: Enabled
- Firewall Mode: Prevention
- Click on OK
- Click on OK again.
The Application Gateway gets deployed right now. This might take a couple of minutes.
Configuring the Application Gateway
Now that the Application Gateway is deployed, it is time to configure it. The Application Gateway gets deployed with an out of the box configuration. In order to have the web application firewall working, we only need to change the backend pool. In this tutorial we are going to leverage the default configuration; and only change the back-end pool.
- In the Azure Portal navigate to the Application Gateway that you just deployed. You can easily do this by clicking on the All Services button and look for Application Gateways. In the Window that opens, you will find your just created AGW
- Click on appGatewayBackendPool
- Make sure that endpoint will point to your webserver. This could either be a VM that is deployed in Azure, or an IP address that is publicly available.
- Click on Save.
Your Application Gateway is now configured. It should be working right now!
Testing the Application Gateway
Now that the Application Gateway is configured correctly, it is time to test. You can easily test the AGW by navigating to the public IP address of your AGW.
- In the Azure Portal navigate to the Application Gateway that you just deployed. You can easily do this by clicking on the All Services button and look for Application Gateways. In the Window that opens, you will find your just created AGW.
- In the overview tab, you will find the public IP address of the application gateway. Navigate to this IP address with a webbrowser, and you will see your website working.
The Web Application Firewall feature in the Application Gateway is quite a nice resource to work with; although there are some things to keep in mind when you design your solution:
- Settings on the WAF apply to all listeners in the Application Gateway. If you are using the Application Gateway to secure multiple applications, you are not able to change WAF settings per individual application.
- You need to have a Application Gateway subnet in your VNET. You may only deploy Application Gateway resources in this subnet. You can change the size of a subnet; so you can start with a small subnet, and later-on size it up once you hit the limits.