Full Disclosure: I am a Sales Engineer for Barracuda Networks.

If you need perform a proof of concept (PoC) for a WAF and don’t have a lot of time to do it, then this post will hopefully help you speed up the process and get you testing the WAF’s capabilities. In this post, I will take you through setting up a vulnerable Web App on AWS and then protecting this vulnerable Web App with Barracuda’s WAF-as-a-Service. In most cases this process can be adapted to any WAF. 

Step 1 – Setting Up A Vulnerable Web App For the purposes of this post, we will deploy the Damn Vulnerable Web Application (DVWA). When performing a PoC, you want to ensure that the WAF can protect your web application from external attacks which is why I have chosen to use DVWA. I have also tested this with the OWASP JuiceShop and the process is almost identical. So why wouldn’t you want to use your own website for this instead of using the DVWA? That’s a good question. The main reason is that when you place the WAF in protection or block mode, you don’t want to impact production systems. The main purpose of the PoC is to test the WAF’s capabilities rather than testing if your website can be exploited or not. 

Okay, lets get started. If you don’t have a AWS account, you can sign up for a free tier account. Once you have signed in, navigate to services and EC2.

 

Once the EC2 dashboard has opened, under images select AMI Catalog

To make it easier and cheaper, I have narrowed down my selection to Free Tier Only, Linux and 64-Bit(x86). You don’t need a powerful machine to run this PoC, so in this instance cheaper is better.

Choose the Amazon Linux 2 AMI (HVM) – Kernel 5.10, SSD Volume Type

Select the Amazon Linux 2 AMI (HVM) – Kernel 5.10, SSD Volume Type and then click on the Launch Instance With AMI

A new page will load where you can configure the EC2 instance. There are only a couple of things you need to worry about in this section. Everything else can be be left as default.

Give your webserver a name. In my case, I have called it DVWA

Leave the Application and OS Images (Amazon Machine Image), Instance Type and Key Pair (Login) as default.

Note: In normal circumstances, you will set up the Key Pair. As the DVWA is vulnerable and does not contain any personally identifiable information, I chose to skip configuring the Key Pair.

Scroll down to Network Settings. This is where we will make our first change.

To allow DVWA to be available externally, select Allow HTTP Traffic From The Internet. Also de-select Allow SSH Traffic From setting. (We wont need to SSH into the box for the PoC)

Under the Advanced Details section keep all the defaults section scroll down all the way to the end to User Data. This is where we will configure the machine to install Docker and DVWA.

In the User Data section, add in the following

For DVWA

#!/bin/bash
yum update -y
yum install -y docker
service docker start
docker pull vulnerables/web-dvwa
docker run -d -p 80:80 vulnerables/web-dvwa

For OWASP JuiceShop

#!/bin/bash
yum update -y
yum install -y docker
service docker start
docker pull bkimminich/juice-shop
docker run -d -p 80:3000 bkimminich/juice-shop

Once you have copied the above into the User Data section. Over on the right hand side select Launch Instance. This will begin to create the instance.

That is pretty much it. Once the instance has been created, you need to take note of the public IP and the FQDN that has been assigned to the instance.

To get that information. From the Instance Dashboard, select Instances (Running)

You should now see the instances you have created. You can give your Web Applications names. I have creatively called my instances DVWA & JuiceShop. Click on the instance ID to get the public IP and FQDN.

Take note of the IP and FQDN. We are going to need this to set up the WAF.

Step 2 – Setting Up The Web Application Firewall using Barracuda WAF-as-a-Service

If you are performing a PoC, you Barracuda account representative would have likely allocated you a trial license. If not reach out to your local Barracuda account representative or Sales Engineer to get a trial of the WAF-as-a-Service set up for you.

Assuming you now have access to the WAF-as-a-Service and have logged in successfully, it is now time to add our application.

On the right hand side click on Add Application button.

A dialog box will open. Give you application a unique name. In this instance I have called it PoC-DVWA. I have then added in the FQDN. Click on the Continue button.

The domain name should now resolve to the public IP Address. The only change we need to make is to change the Backed Server Protocol from HTTPS to HTTP. For the purpose of the PoC we don’t need to worry about certificates.

Once that has been done, click on the Test Connection Button.

If everything is working correctly you should see a green tick advising that The Backend Server was reached successfully and the supplied domains belong to the backed IP Address. Click on the Add button to continue.

 

Woop Woop, we have successfully added the DVWA to the WAF-as-a-Service. That was quick and easy.

Normally, you would go and make your DNS changes so that the website will route traffic through the WAF and you configure the Web App to only accept traffic from the WAF. For the purposes of the PoC, we will not do this.

The reason being that you want to be able to test the WAF’s capability and ensure that it protects against the attacks you while also confirming the attacks actually work when the Web App is not being protected.

So now we have the Web App being protected (well semi protected) lets move on to the final step.

Step 3 – Adding Protection Components To Your Vulnerable Web Application

As the WAF provisions everything in the back end, you can start to add some components which you can configure to protect your Web Application.

On the left hand side of the screen you will see the + sign that says Add Components. Click on it to select all the different components you want to protect your web application.

A dialog box will open and you will see a list of different components you can add to the WAF-as-a-Service.

Depending on your PoC criteria and your overall use case, you can select any or all of these components. For this I will select the following.

• Advanced Threat Protection
• Clickjacking Protection
• Parameter Protection
• URL Protection

All you need to do is click on the Add button for each component you want to add.

It should now look similar to this.

Go through each component and ensure that they are all enabled. Most of these will get enabled once you add the component but it is always good to double check.

During the initial setup it is wise to keep the default configurations. As you progress through your PoC, you can make adjustments to the configuration to suit your specific needs.

Okay, we are now on the home stretch. All you need to do is enforce blocking to block attacks.

On the right hand side of the screen toggle the Block Attacks slider to the right to start blocking attacks.

A dialog box will open confirming that you want to begin to block attacks.

Ok, we are all done.

There are now two ways to access the vulnerable web application. The first is using the public IP address that was allocated when creating the EC2 instance in AWS.

This method bypasses the WAF and you shouldn’t be restricted in anyway.

The second way is to connect to the WAF using the CNAME that was provided during the setup. This will take some time as we need to have DNS to propagate, but once that is done you can access the vulnerable web app that is being protected by the WAF-as-a-Service.

Step 4 – Let`s test to see if it is working.

So I have browsed to the DVWA and I will now login.

Once I login, I will head over the SQL Injection section. In the User ID: section, I will enter the following:

?id=a' UNION SELECT "text1","text2";-- -&Submit=Submit and then press the submit button.

If everything is working the WAF-as-a-Service blocking mode should prevent us from performing a SQL injection attack.

And sure enough it does.

So what would happen if the web application was susceptible to SQL Injection and wasn’t protected by a WAF? Let’s connect to the DVWA using the AWS public IP and try it out.

So same website, same SQL Injection, let’s see what happens. Boom, we have succeeded. If this was a real situation, we would have been able to exfiltrate data from the database.

Conclusion

So now we have everything working properly we can begin to test everything in more detail. It is important to establish a test criteria and look at your specific use cases. My advice would be to test against the OWASP Top 10. This way you can be sure that the WAF that you are putting in place will do the job and protect you against the most common attacks.

For any production systems, I would recommend having a penetration test regularly performed on the web application to ensure that the web application and controls you have in place are doing their job effectively. identifying any vulnerabilities and remediating them is far easier, cheaper and quicker than having to clean up after an attack has occurred.

I would also recommend setting up a bug bounty program to allow security researchers to test and identify any vulnerabilities in the web application without fear of any repercussions. While it is always good to reward a security researcher for identifying a vulnerability in your application sometimes an organization is unable to afford to pay a security researcher for their efforts so look at other options to reward the security researcher for their efforts like swag or public kudos.

Finally, this is just my approach to how I went about things, you may have a different method that can make this more efficient. If you do write a blog about it so others can learn. We are all here to learn, so sharing your knowledge with others is a great thing.

That’s enough from me. Stay curious and stay safe.