8. Set up and experiment with a Web Application Firewall

Introduction

When exposing an application to the internet additional measures must be in place to ensure security across the network. This is a problem that can be solved in multiple different dimensions, such as setting up a DMZ - seperating the application from the rest of the network. In case it does get hijacked, the impact will be severely reduced. For this assignment, I will be configuring my portfolio to use the CloudFlare Web Application Firewall. Why? See a list of benefits listed down below. See this for more info

Execution

I had a few concerns before starting the implementation of the cloudflare WAF - chief being the automatic SSL & the proxy configuration would break. But it turns out that the WAF provided by CloudFlare automatically gives out an SSL certificate to websites it’s protecting. It is likely that it verifies if the original source is also secured by a SSL certificate. The WAF behaves like an additional proxy; a large benefit I saw was that my IP-address was no longer leaking after execution.

To get started with the implementation I had to change DNS settings from my domain provider – where I previously used a custom configuration pointing to my own IP(see below)

The company that sells me the domain oksolution.nl required me to disable DNS management and adjust the nameservers that pointed to the domain. During the Cloudflare setup I was given 2 name servers to implement.

About 2-4 hours after doing this the nameservers were updated and the WAF was functioning.

SSL

The SSL certificate that appeared on the front end had changed into the Cloudflare SSL.

Which makes sense – this SSL only extended itself to the Cloudflare WAF proxy. I then ran a test using SSL Labs

This certificate has a “average” rating due to it supporting older TLS versions. And that is because by default Cloudflare supports TLS 1.0 as can be seen here CloudFlare Certificate Options

And there’s a way to have Cloudflare use a more ‘strict’ version which is to assume only modern TLS protocols are supported. Though this requires the creation of a ‘page-rule’, which free users can create up to a total of 3 – a disadvantage of using CloudFlare in my opinion.

Here are the results if you wish to view them locally: SSL Labs results

Proxy

Instead of directly pointing at my IP-address, the WHOIS of the website queries to the following:

I ran a WHOIS on my own system and various online services and discovered that certain WHOIS sites have an 48 hour update cycle for their domain records.

WAF

As mentioned before, Cloudflare offers free customers up to three page rules. Here are the ones I have enabled and why:

Browser Integrity Check according to CloudFlare documentation seeks for Bad Behavior; meaning when a request is made with HTTP headers that are frequently used by spammers, abusive bots, crawlers it will deny access to the page or makes the visitor perform a challenge (captcha).

I set the SSL to strict because according to ssllabs.com there were old and outdated TLS versions supported. After enabling I found out that these rules were not applied immediately.

Another option called Security Level I put on high, the alternative option was I am under attack – but I reckon that would irritate regular visitors.

Additional benefits

Back when I was setting up this portfolio site I wrote some scripts that would track the amount of visitors and whatnot my site receives. The downside of this was that there were a lot of bots, spiders, crawlers etc. that visited my site daily. Through logs I found in my Suricata IDS I found out that most of these visitors were bots that ran exploit scripts (unsuccesfully). The CloudFlare WAF has a nice dashboard for visitors, therefore obseleting a need for custom scripts like that.

The dashboard tells me how many requests came in for a certain day but also where those requests originated from.