Ubuntu Server 18.04 – Preventing disasters

File Management Commands in Linux

As we proceed through this chapter, we’ll look at ways we can recover from disasters. However, if we can prevent a disaster from occurring in the first place, then that’s even better. We certainly can’t prevent every type of disaster that can possibly happen, but having a good plan in place and following that plan will lessen the likelihood. A good disaster recovery plan will include a list of guidelines to be followed with regards to implementing new servers and managing current ones. This plan may include information such as an approved list of hardware (such as hardware configurations known to work efficiently in an environment), as well as rules and regulations for users, a list of guidelines to ensure physical and software security, proper training for end users, and method change control. Some of these concepts we’ve touched on earlier in the tutorial, but are worth repeating from the standpoint of disaster prevention.

First, we talked about the Principle of Least Privilege back in Chapter 15, Securing Your Server. The idea is to give your users as few permissions as possible. This is very important for security, as you want to ensure only those trained in their specific jobs are able to access and modify only the resources that they are required to. Accidental data deletion happens all the time. To take full advantage of this principle, create a set of groups as part of your overall security design. List departments and positions around your company, and the types of activities each are required to perform. Create system groups that correspond to those activities. For example, create an accounting-ro and accounting-rw group to categorize users within your Accounting department that should have the ability to only read or read and write data. If you’re simply managing a home file server, be careful of open network shares where users have read and write access by default. By allowing users to do as little as possible, you’ll prevent a great many disasters right away.

In Chapter 2, Managing Users (as well as Chapter 15, Securing Your Server) we talked about best practices for the sudo command. While the sudo command is useful, it’s often misused. By default, anyone that’s a member of the sudo group can use sudo to do whatever they want. We talked about how to restrict sudo access to particular commands, which is always recommended. Only trusted administrators should have full access to sudo. Everyone else should have sudo permissions only if they really need it, and even then, only when it comes to commands that are required for their job. A user with full access to sudo can delete an entire filesystem, so it should never be taken lightly.

In regard to network shares, it’s always best to default to read-only whenever possible. This isn’t just because of the possibility of a user accidentally deleting data, it’s always possible for applications to malfunction and delete data as well. With a read-only share, the modification or deletion of files isn’t possible. Additional read-write shares can be created for those who need it, but if possible, always default to read-only.

Although I’ve spent a lot of time discussing security in a software sense, physical security is important too. For the purposes of this tutorial, physical security doesn’t really enter the discussion much because our topic is specifically Ubuntu Server, and nothing you install on Ubuntu is going to increase the physical security of your servers. It’s worth quickly noting however, that physical security is every bit as important as securing your operating systems, applications, and data files. All it would take is someone tripping over a network cable in a server room to disrupt an entire subnet or cause a production application to go offline. Server rooms should be locked, and only trusted administrators should be allowed to access your equipment. I’m sure this goes without saying and may sound obvious, but I’ve worked at several companies that did not secure their server room. Nothing good ever comes from placing important equipment within arm’s reach of unauthorized individuals.

In this section, I’ve mentioned Chapter 15Securing Your Server, several times. In Chapter 15Securing Your Server, we looked into securing our servers. A good majority of a disaster prevention plan includes a focus on security. This includes, but is not limited to, ensuring security updates are installed in a timely fashion, utilizing security applications such as failure monitors and firewalls, and ensuring secure settings for OpenSSH. I won’t go over these concepts again here since we’ve already covered them, but essentially security is a very important part of a disaster prevention plan. After all, users cannot break what they cannot access, and hackers will have a harder time penetrating your network if you designed it in a security-conscious way.

Effective disaster prevention consists of a list of guidelines for things such as user management, server management, application installations, security, and procedure documents. A full walkthrough of proper disaster prevention would be an entire tutorial in and of itself. My goal with this section is to provide you with some ideas you can use to begin developing your own plan. A disaster prevention plan is not something you’ll create all at once, but is rather something you’ll create and refine indefinitely as you learn more about security and what types of things to watch out for.

Comments are closed.