Securing Your Server

It seems like every month there are new reports about companies getting their servers compromised. In some cases, entire databases end up freely available on the internet, which may even include sensitive user information that can aid miscreants in stealing identities. Linux is a very secure platform, but it’s only as secure as the administrator who sets it up. Security patches are made available on a regular basis, but they offer no value unless you install them. OpenSSH is indispensable for remote administration, but it’s also a popular target for threat actors trying to break into servers. Backups are a must-have but are potentially useless if they’re not tested regularly or they fall into the wrong hands. In some cases, even your own employees can cause intentional or unintentional damage. In this chapter, we’ll look at some of the ways you can secure your servers from threats.

In this chapter, we will cover:

• Lowering...

Lowering your attack surface

Your Ubuntu Server installations will likely have one or more important applications running on them, some of which might be available to the public internet. This is very common for web servers, for example, as it’s the primary goal of a web server to offer a website that your users can access.

Every application that is accessible from outside the walls of your organization is a potential entry point for threat actors who might attempt to break into your server. The attack surface of a server is essentially a list of all the things that are potentially exploitable. In regards to security, it’s important to understand which applications must be accessible remotely, and which ones you can lock down. Every application you lock down lowers the likelihood of it being taken over by an outside threat. The process of locking things down is what we refer to as lowering your attack surface.

Ideally, in a perfect world, we would disallow all...

Understanding and responding to CVEs

I’ve already mentioned some of the things you can do in order to protect your server from some common threats, and I’ll give you more tips later on in this chapter. But how does one know when there’s a vulnerability that needs to be patched? How do you know when to take action? The best practices I’ll mention in this chapter will only go so far; at some point, there may be some sort of security issue that will require you to do something beyond generating a strong password or locking down a port.

The most important thing to do is to keep up with the news. Subscribe to sites that report news on security vulnerabilities, and I’ll even place a few of these in the Further reading section of this chapter. When a security flaw is revealed, it’s typically reported on these sites and given a CVE number, where security researchers will document their findings.

CVEs are found in special online catalogs detailing...

Installing security updates

Since I’ve mentioned updating packages several times, let’s have a formal conversation about it. Updated packages are made available for Ubuntu quite often, sometimes even daily. These updates mainly include the latest security updates but may also include new features. Since Ubuntu 22.04 is an LTS release, security updates are much more common than feature updates.

Installing the latest updates on your server is a very important practice, but, unfortunately, it’s not something that all administrators keep up with for various reasons.

When installed, security updates very rarely make many changes to your server, other than helping to keep it secure against the latest threats. However, it’s always possible that a security update that’s intended to fix a security issue ends up breaking something else. This is rare, but I’ve seen it happen. When it comes to production servers, it’s often difficult to...

Automatically installing patches with the Canonical Livepatch service

In the previous section, I mentioned that if your updates include an update to the kernel, you’ll need to reboot your server for the new kernel to take effect. While this is generally true, Canonical offers a Livepatch service for Ubuntu, which allows it to receive updates and have them applied without rebooting. This is a game changer, as it takes care of keeping your running kernel patched without you having to do anything, not even reboot. This is a massive benefit to security, as it gives you the benefits of the latest security patches without the inconvenience of scheduling a restart of your servers right away.

However, the service is not free or included with Ubuntu by default. Even so, you can install the Livepatch service on three of your servers without paying, so it’s still something you may want to consider. You’re even able to utilize this service on the desktop version of Ubuntu...

Securing OpenSSH

OpenSSH is a very useful utility; it allows us to configure our servers from a remote location as if we were sitting in front of the console. In the case of cloud resources, it’s typically the only way to access our servers. Considering the nature of OpenSSH itself (remote administration), it’s a very tempting target for miscreants who are looking to cause trouble. If we simply leave OpenSSH unsecured, this useful utility may be our worst nightmare.

Thankfully, configuring OpenSSH itself is very easy. However, the large number of configuration options may be intimidating to someone who doesn’t have much experience tuning it. While it’s a good idea to peruse the documentation for OpenSSH, in this section, we’ll take a look at the common configuration options you’ll want to focus your attention on first.

The configuration file for OpenSSH itself is located at /etc/ssh/sshd_config, and we touched on it in Chapter 10,...

Installing and configuring Fail2ban

Fail2ban, how I love thee! Fail2ban is one of those tools that once I learned how valuable it is, I wondered how I ever lived so long without it. Fail2ban is able to keep an eye on your log files, looking for authentication failures. You can set the number of failures that are allowed from any given IP address, and if there are more than the allowed number of failures, Fail2ban will block that individual’s IP address. It’s highly configurable and can enhance the security of your server.

Installing and configuring Fail2ban is relatively straightforward. First, install its package:

sudo apt install fail2ban

After installation, the fail2ban daemon will start up and be configured to automatically start at boot time. Configuring fail2ban is simply a matter of creating a configuration file. But this is one of the more interesting aspects of Fail2ban: you shouldn’t use its default config file. The default file is /etc...

MariaDB best practices for secure database servers

MariaDB, as well as MySQL, is a very useful resource to have at your disposal. However, it can also be used against you if configured improperly. Thankfully, it’s not too hard to secure, but there are several points of consideration to make regarding your database server when developing your security design.

The first point is probably obvious to most of you, and I have mentioned it before, but I’ll mention it just in case. Your database server should not be reachable from the internet. I do understand that there are some edge cases when developing a network, and certain applications may require access to a MySQL database over the internet. However, if your database server is accessible over the internet, miscreants will try their best to attack it and gain entry. If there’s any vulnerability in your version of MariaDB or MySQL, they’ll most likely be able to hack into it.

In most organizations...

Setting up a firewall

Firewalls are a very important aspect to include in your network and security design. Firewalls are extremely easy to implement, but sometimes hard to implement well. The problem with firewalls is that they can sometimes offer a false sense of security to those who aren’t familiar with the best ways to manage them. Sure, they’re good to have, but simply having a firewall isn’t enough by itself.

The false sense of security comes when someone thinks that they’re protected just because a firewall is installed and enabled, but they’re also often opening traffic from any network to internal ports. Take into consideration the firewall that was introduced with Windows XP and enabled by default with Windows XP Service Pack 2. Yes, it was a good step but users simply clicked the allow button whenever something wanted access, which defeats the entire purpose of having a firewall. Windows implements this better nowadays, but the false...

Encrypting and decrypting disks with LUKS

An important aspect of security that many people don’t even think about is encryption. As I’m sure you know, backups are essential for business continuity. If a server breaks down, or a resource stops functioning, backups will be your saving grace. But what happens if your backup medium gets stolen or somehow falls into the wrong hands? If your backup is not encrypted, then anyone will be able to view its contents. Some data isn’t sensitive, so encryption isn’t always required. But anything that contains personally identifiable information, company secrets, or anything else that would cause any kind of hardship if leaked should be encrypted. In this section, I’ll walk you through setting up LUKS encryption on an external backup drive.

Before we get into that though, I want to quickly mention the importance of full-disk encryption for your distribution as well. Although this section is going to go over...

Locking down sudo

We’ve been using the sudo command throughout the book. In fact, we took a deeper look at it in Chapter 2, Managing Users and Permissions. Therefore, I won’t go into too much detail regarding sudo here, but some things bear repeating as sudo has a direct impact on security.

First and foremost, access to sudo should be locked down as much as possible. A user with full sudo access is a threat, plain and simple. All it would take is for someone with full sudo access to make a single mistake with the rm command to cause you to lose data or render your entire server useless. After all, a user with full sudo access can do anything root can do (which is everything).

By default, the user you’ve created during installation will be made a member of the sudo group. Members of this group have full access to the sudo command. Therefore, you shouldn’t make any users a member of this group unless you absolutely have to. In Chapter 2, Managing...

Summary

In this chapter, we looked at the ways in which we can harden the security of our server. A single chapter or book can never give you an all-inclusive list of all the security settings you could possibly configure, but the examples we worked through in this chapter are a great starting point. Along the way, we looked at the concepts of lowering your attack surface, as well as the principle of least privilege. We also looked into securing OpenSSH, which is a common service that many attackers will attempt to use in their favor.

We also looked into Fail2ban, which is a handy daemon that can block other nodes when there are a certain number of authentication failures. We also discussed configuring our firewall, using the UFW utility. Since data theft is also unfortunately common, we covered encrypting our backup disks.

In the next chapter, we’ll take a look at troubleshooting our server when things go wrong.

Further reading

• Landscape documentation: https://learnlinux.link/ls-docs
• Fail2ban manual: https://learnlinux.link/f2b-man
• sshd_config file guide: https://learnlinux.link/sshd-config-doc
• Ubuntu CVE tracker: https://learnlinux.link/u-cve
• Password haystacks (find out how secure your password is): https://learnlinux.link/haystack
• SECURITY NOW (a very informative security podcast): https://learnlinux.link/sn-podcast
• ShieldsUP! (a useful tool to see which ports your router has open): https://learnlinux.link/grc-su

Join our community on Discord

Join our community’s Discord space for discussions with the author and other readers:

https://packt.link/LWaZ0