DDOS attacks come in many styles and target various layers of a system. It is increasingly common to see attacks targeted at Layer 7, where a surge of HTTP requests is made to your site.

There are various ways to block these attacks, from rate limiting techniques, CAPTCHA, and Javascript detection injection, through to deep HTTP inspection.

Section allows you to use ModSecurity to block malicious HTTP traffic. Here we will talk about using ModSecurity to provide deep inspection to filter out bad traffic and allow good traffic through.

ModSecurity Setup

On Section, you choose the HTTP proxies that form the HTTP pipeline for requests coming to your application. You can choose from a library of proxies that we make available to you, which you can change at any time.

Adding the proxy to your site is based on our configuration-as-code principles, so that means you’ll commit to your Section git repository to declare that our traffic should pass through ModSecurity.

Our ModSecurity container comes preconfigured with the OWASP Core Ruleset (OWASP CRS), which is a set of rules designed by experts in the developer and security community.

Out of the box, Section runs the ModSecurity Apache Module in Detect-Only mode. This allows you to start running the proxy and collecting data, which feeds into our HTTP analytics toolchain.

In order to change the mode of the proxy you can follow the normal process for ModSecurity, by changing the SecRuleEngine option in modsecurity.conf to On.

{% gist 721981ee1462fad435ee2d303390f491 %}

Now, when the ModSecurity rules determine that the request should be blocked, the user agent will receive a HTTP 403 response code.

Measuring and Monitoring ModSecurity

It is important to understand exactly what ModSecurity is doing and to do this yourself you’d probably fall back to log file analysis. You’d need to log onto all your ModSecurity servers, possibly aggregate the logs and transform this data into meaningful information.

With Section, this happens by default. Our log processing based on logstash makes this easy for a high-availability ModSecurity installation.

ModSecurity Metrics

Section parses the ModSecurity audit logs using Logstash, statsd and Graphite. Each minute, we provide up to date metrics on which rules were tripped. This lets you see the volume of data traffic coming to your site, and which rules are blocking the most attacks.

Here’s an example of looking at which rules from the OWASP CRS were being tripped on a recent event.

I’ve removed the scale and the legend here, you’ll see these in your own instance of Section.

There are actually six ModSecurity OWASP CRS rules being tripped during the five waves of malicious HTTP traffic. One rule stands out - allowing ModSecurity to block traffic that is tripping this rule will force the source of the traffic to redesign their system. Usually, they move onto greener pastures.

It is also interesting to note the size of the attack waves, and their timing.

In the example above, the site started with ModSecurity in DetectionOnly mode and was switched to On at around 16:10. This caused the HTTP 200 responses to be changed to HTTP 403 response codes - the green line indicates blocked traffic.

These are the tools you need to understand and take action on a wave of undesirable traffic.

ModSecurity Log Analysis with ElasticSearch and Kibana

Because Section also parses the ModSecurity audit log into ElasticSearch via Logstash, and provides you with full Kibana usability to query your logs, you’re able to see some very interesting insights into the attack.

Section’s Kibana tool provides some really useful and neat query and visualization capabilities for these kinds of problems.

Let’s have a look at Kibana showing a Tile Map visualisation of this traffic.

Wow, this traffic originated from all over the world, with a hotspot in Asia. Let’s ask Kibana to get more information.

Yes, the main focus is traffic coming from Malaysia, then Indonesia. Have a look at the IP distribution of this traffic.

Geo-blocking techniques may have worked, and even IP blocking may have worked, but a better choice is using a Web Application Firewall, like ModSecurity.

ModSecurity Alerts Hooked up to Pingdom and New Relic

How do you know when these things are happening? Any operations team needs alerts hooked into their existing framework.

Alerts on Section are based on synthetic checks. You can configure synthetic check tools like Pingdom or New Relic to periodically check any graphite metric we expose.

Then, you can get an alert forwarded to your operations team that will give them early warning that there’s some unwanted traffic.

Handling ModSecurity False Positives

With any WAF solution, false positives can be a problem. A false positive is where ModSecurity blocks a request that it shouldn’t. This happens when there’s a clash between the application design and the firewall rules.

Because Section is the only CDN built for continuous integration, verifying in your local developer environment and in your CI systems before you go to production is the normal way to ensure that your WAF doesn’t break your site.

Change Management for ModSecurity

As Section is the only configuration-as-code based CDN, all the changes you would make to set this up are fully managed in git.

Results with ModSecurity

As you can see, using Section to run ModSecurity gives you full control of ModSecurity in a CDN. Also, the tools we provide to support the development experience, and the operational tools we provide to support runtime give you everything you need to effectively run ModSecurity with so much heavy lifting taken care of. This lets you focus on the outcome, not the implementation.