Denial of Service Protection

In previous chapters, we focused on keeping threat actors out and considered what we can do when our defenses are breached. However, it is still possible for a threat actor to take our Moodle offline simply by sending the web server too many requests for it to cope with. This is a so-called denial of service (DoS) attack. If the requests are originating from multiple servers across the globe, then this is a distributed denial of service (DDoS) attack. In this chapter, we will discover that building a robust and resilient Moodle server will go a long way to defending against DoS and DDoS attacks.

In this chapter, you will do the following:

• Learn how to significantly improve server performance using the PHP FastCGI Process Manager (PHP-FPM)
• Learn how to use JMeter to benchmark your Moodle server and test for resilience
• Install and tune the mod_evasive Apache plugin
• Identify threat actors from server access logs

Note that by engaging...

Technical requirements

For this chapter, you will need command-line access to a Linux-based web server running Apache. We will also be using the Apache JMeter load testing tool – see https://jmeter.apache.org/ for details.

The Apache web server

Apache (https://httpd.apache.org/) isn’t the only web server application we could have chosen to include in our Mathaholics server infrastructure. Other popular alternatives to Apache include Nginx and LiteSpeed (see https://www.nginx.com/ and https://www.litespeedtech.com/ for details).

We chose Apache for the Mathaholics project because Apache has a huge user base (both in terms of deployment and development), robust security, and proven reliability. Like Moodle, the Apache web server can be enhanced and extended through the use of additional modules. In the previous chapter, we learned how the ModSecurity module can be used to add a powerful web application firewall (WAF) to Apache.

The Moodle framework is written in the PHP programming language. PHP is a scripting language, meaning any Moodle pages that are requested by a browser will need to be interpreted. Apache (or any of the popular web servers, for that matter) doesn’t have any built...

Introduction to Apache JMeter

Rather than simply flooding our Mathaholics server with page requests, we will use the Apache JMeter performance testing tool. As its name suggests, Apache JMeter (or simply JMeter) was originally designed for performance testing and load testing web applications, databases, and other services. Jmeter can simulate high loads on a server, and by so doing measure and analyze the server’s performance under different scenarios. JMeter will also provide detailed reports on the results. JMeter has a user-friendly GUI and, like Moodle, can be extended with custom plugins to support additional functionality.

A deep dive into JMeter performance testing is beyond the scope of this book, so to learn more, visit the jMeter website at https://jmeter.apache.org/ or check out the book Performance Testing with JMeter, by Bayo Erinle, at https://www.packtpub.com/product/performance-testing-with-jmeter/9781784394813.

Let’s begin this section by installing...

mod_evasive

mod_evasive is an open source module for Apache that was specifically designed to prevent excess web requests from consuming too much bandwidth. It works by maintaining a temporary hash table of client IP addresses and requested URIs. When a new request is received, a new hash key is created. This key is used as a reference to check for entries in the hash table. If the number of requests exceeds predefined thresholds, it can block the attack by returning an HTTP 403 response. We can also configure mod_evasive to notify us by email that a client IP has been blocked. For full details, visit https://github.com/jzdziarski/mod_evasive. The Nginx equivalent to mod_evasive is ngx_http_limit_req_module – see http://nginx.org/en/docs/http/ngx_http_limit_req_module.html.

It’s worth noting that ModSecurity (discussed in the ModSecurity web application firewall (WAF) section in Chapter 5) can also be configured to rate limit requests, although this specific behavior...

Identifying threat actors from server access logs

To understand how to identify rogue agents, we will use the well-known example of the Apache Log4j vulnerability. We’re using this specific example because it is so aggressively targeted by threat actors that you will likely find threat actors attempting to exploit it on your site – even if you’re not vulnerable to it. There are several reasons why the Log4j vulnerability is dangerous:

• It provides a frictionless way for a threat actor to upload their code to your site (via Apache logs)
• Log4j is ubiquitous, so threat actors are very likely to attempt to exploit this vulnerability, regardless of whether you have Log4j in use on your Moodle site
• Proofs of Concepts (POCs) are easy to find, meaning someone with very little experience can attempt to hack a site

To identify a threat actor attempting to exploit the Log4j vulnerability, we need to look in the server access logs. Here is an example...

Summary

Initiating a DoS attack is as easy as opening a browser, navigating to your Moodle, and keeping your finger pressed on the F5 key. We saw that repeated client requests can quickly consume server resources and that this may also damage data integrity. To mitigate this threat, we began by installing PHP-FPM, which not only allows us to manage server resources more effectively but also provides a more effective way for the server to service client requests.

We must understand the performance of our Mathaholics Moodle server and how it will cope with a range of loads – from expected to extreme. We introduced the concept of load testing, or simulating human activity on a website, using JMeter. If your server is operating under normal conditions with little headroom, then you need to be assured that a spike in activity (particularly from a threat actor) won’t cause your Moodle to fail.

Then, we implemented real-time application DoS protection using the mod_evasive...