Search icon
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Moodle 4 Security

You're reading from  Moodle 4 Security

Product type Book
Published in Mar 2024
Publisher Packt
ISBN-13 9781804611661
Pages 288 pages
Edition 1st Edition
Languages
Author (1):
Ian Wild Ian Wild
Profile icon Ian Wild

Table of Contents (18) Chapters

Preface 1. Part 1: Moodle Security Primer
2. Chapter 1: Moodle Security – First Steps 3. Chapter 2: Moodle Threat Modeling 4. Chapter 3: Security Industry Standards 5. Part 2: Moodle Server Security
6. Chapter 4: Building a Secure Linux Server 7. Chapter 5: Endpoint Protection 8. Chapter 6: Denial of Service Protection 9. Chapter 7: Backup and Disaster Recovery 10. Part 3: Moodle Application Security
11. Chapter 8: Meeting Data Protection Requirements 12. Chapter 9: Moodle Security Audit 13. Chapter 10: Understanding Vulnerabilities 14. Part 4: Moodle Infrastructure Monitoring
15. Chapter 11: Infrastructure Monitoring 16. Index 17. Other Books You May Enjoy

Building a Secure Linux Server

Having threat-modeled the Mathaholics platform in Chapter 2 and determined which of the industry standard frameworks best applies to our project in Chapter 3, we are now ready to build our Moodle server. At the time of writing, approximately 80% of servers run a flavor of Linux, so in this chapter, we will be building a Linux-based server. Specifically, the examples given in this chapter use the Debian-based Ubuntu operating system, but the techniques and tips we’ll describe will apply to any Linux flavor. More generally, the security concerns we’ll address in this chapter will certainly apply to any operating system.

Using a cloud-hosting provider to create a new server (which can also be referred to as a virtual machine, or VM) is a straightforward process. Cloud hosting providers offer the tools to create a new VM with just a few clicks. We also assume you have the skills to install a web server – a Linux, Apache, MySQL, and...

Technical requirements

In this chapter, we’ll be securing a Moodle server in a cloud-hosted environment. The server will be based on a LAMP stack. The operating system used in this chapter will be Ubuntu. The server will be publicly accessible. Don’t worry if your Moodle server doesn’t fit this description – we’ll also offer guidance where variations apply (in enterprise environments, for example). Some knowledge of configuring Linux-based servers is assumed. The sample files are provided at https://github.com/PacktPublishing/Moodle-4-Security/tree/main/Chapter-4.

Creating your first cloud-based VM

How you create your cloud VM very much depends on your cloud hosting provider. However, regardless of the provider, the process is the same:

  1. Choose a name for your server and the region in which you want to locate it.
  2. Choose the flavor of the Linux operating system you wish to install (again, all of the examples in this chapter will be based on Ubuntu).
  3. Finally, after reviewing your selection, go ahead and create your new instance.

There are variations between providers. For example, the Microsoft Azure platform provides dedicated port rules that govern access to your new machine.

SysAdmin top tip

Choose an operating system that best fits your organization’s skill set. Don’t be tempted to implement an operating system you’re not familiar with as your lack of experience may well introduce vulnerabilities.

Remember that any new VM will be weakly protected. For example, you would typically log on to...

Enabling TLS/SSL

To ensure secure communications between the server and the browser, we employ TLS technology. Security is achieved by installing an SSL certificate on the server to provide authentication and verification. Users are assured that they are connecting to a legitimate and intended website or server through the use of HTTPS – which the browser makes obvious by showing a closed padlock icon in the address bar (and no obvious warnings). It’s considered a fundamental requirement of web security and best practices that any website, regardless of how straightforward its content, must have TLS enabled.

The acronyms SSL and TLS are often used interchangeably. This is, in fact, incorrect. SSL, specifically, is legacy technology and uses a very weak encryption algorithm that is easy to crack.

SSL is a deprecated technology and should never be used. TLS replaces SSL as the more secure solution to the issues in SSL. For further details on the differences between...

Investigating firewalls

In a practical sense, a firewall is the means to ensure only specific data is allowed in or out of a specific context. For Moodle installations, the context is typically as follows:

  • The network, which means a web application firewall will filter IP packets before they reach the server. It can also filter IP packets when they leave the server and before they reach the internet.
  • The server, which means the firewall is a filter that’s built into the operating system kernel. It will filter incoming and outgoing packets journeying through the kernel.

Usually, one finds both types of firewalls operate in some form in production environments. This is because each type affords different kinds of protection against cyber threats. As the subject of this chapter is building a secure server, we will limit our discussion here to server firewalls only. We will learn more about network firewalls in Chapter 6.

A firewall filters IP packets, which...

Exploring server immutability

So far in this chapter, we have been describing ways to restrict and control server access. Taking this concept to its ultimate conclusion would mean forbidding any human user access. This is known as server immutability – the idea that, once deployed, a server should remain untouched. But how would this work in practice, given that we will be required to deploy patches to both the Moodle application and the server? Rather than running patch updates on the server, we would instead build a brand new server image and swap the original image for this new one. You may recognize this strategy as one way of implementing zero downtime deployments.

“Break glass” emergencies

Server immutability doesn’t necessarily mean absolutely no access at all. There will be instances when urgent access to a server is required. These are known as break glass emergencies and need to be factored into your plans.

Note that server immutability...

Summary

Creating a new cloud-hosted machine on which to install and run Moodle is as simple as clicking a button. But as soon as that machine is created, it is at risk of attack. The first step was to provide a secure way to log into the server using SSH keys. Knowing that there is always the potential for SSH keys to be compromised, given how they are generated, we also considered how the server might be further protected using multi-factor authentication.

We then saw how server access can be secured by controlling and monitoring the incoming and outgoing network traffic based on a set of rules. We configured UFW to block unused ports. We installed and configured fail2ban to actively monitor any open ports and defend these against attack by dynamically updating firewall rules.

Finally, we investigated the concept of server immutability as a way of ensuring our servers are built and configured in a consistent and repeatable way. This reduces the risk that a security vulnerability...

lock icon The rest of the chapter is locked
You have been reading a chapter from
Moodle 4 Security
Published in: Mar 2024 Publisher: Packt ISBN-13: 9781804611661
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime}