In this article, we will look at some best practices to secure Ubuntu systems. Linux is considered to be a well secured operating system. It is quite easy to maintain the security and protect our systems from unauthorized access by following a few simple norms or rules.

Prerequisites

You will need access to a root or account with sudo privileges. These steps are intended for a new server setup. You can apply them selectively for the servers already in productions.

Ubuntu security practices

Follow these steps to discuss Ubuntu security best practices:

• Install updates from the Ubuntu repository. You can install all the available updates or just select security updates, depending on your choice and requirement:

$ sudo apt-get update 
$ sudo apt-get upgrade

• Change the root password; set a strong and complex root password and note it down somewhere. You are not going to use it every day:

$ sudo passwd

• Add a new user account and set a strong password for it. You can skip this step if the server has already set up a non-root account, like Ubuntu:

$ sudo adduser john $ sudo passwd john

• Add a new user to the Sudoers group:

$ sudo adduser john sudo

• Enable the public key authentication over SSH and import your public key to new user’s authorized_keys file.
• Restrict SSH logins:
  

• Change the default SSH port:

port 2222

• Disable root login over SSH:

PermitRootLogin no

• Disable password authentication:

PasswordAuthentication no

• Restrict users and allow IP address:

AllowUsers john@(your-ip) john@(other-ip)

• Install fail2ban to protect against brute force attacks and set a new SSH port in the fail2ban configuration:

$ sudo apt-get install fail2ban

• Optionally, install UFW and allow your desired ports:

$ sudo ufw allow from <your-IP> to any port 22 proto tcp 
$ sudo ufw allow 80/tcp 
$ sudo ufw enable

• Maintain periodic snapshots (full-disk backups) of your server. Many cloud service providers offer basic snapshot tools.
• Keep an eye on application and system logs. You may like to set up log-monitoring scripts that will e-mail any unidentified log entry.

How it works

The preceding steps are basic and general security measures. They may change according to your server setup, package selection, and the services running on your server. I will try to cover some more details about specific scenarios. Also, I have not mentioned application-specific security practices for web servers and database servers. A separate recipe will be included in the respective chapters. Again, these configurations may change with your setup.

The steps listed earlier can be included in a single shell script and executed at first server boot up. Some cloud providers offer an option to add scripts to be executed on the first run of the server. You can also use centralized configuration tools such as Ansible, Chef/Puppet, and some others. Again, these tools come with their own security risks and increase total attack surface. This is a tradeoff between ease of setup and server security. Make sure that you select a well-known tool if you choose this route.

I have also mentioned creating single user account, except root. I am assuming that you are setting up your production server. With production servers, it is always a good idea to restrict access to one or two system administrators. For production servers, I don’t believe in setting up multiple user accounts just for accountability or even setting LDAP-like centralized authentication methods to manage user accounts. This is a production environment and not your backyard. Moreover, if you follow the latest trends in immutable infrastructure concepts, then you should not allow even a single user to interfere with your live servers. Again, your mileage may vary.

Another thing that is commonly recommended is to set up automated and unattended security updates. This depends on how trusted your update source is. You live in a world powered by open source tools where things can break. You don’t want things to go haywire without even touching the servers. I would recommend setting up unattended updates on your staging or test environment and then periodically installing updates on live servers, manually. Always have a snapshot of the working setup as your plan B.

You may want to skip host-based firewalls such as UFW when you have specialized firewalls protecting your network. As long as the servers are not directly exposed to the Internet, you can skip the local firewalls.

Minimize installed packages and service on single server. Remember the Unix philosophy, do one thing and do it well, and follow it. By minimizing the installed packages, you will effectively reduce the attack surface, and maybe save little on resources too. Think of it as a house with a single door verses a house with multiple doors. Also, running single service from one server provides layered security. This way, if a single server is compromised, the rest of your infrastructure remains in a safe state.

Remember that with all other tradeoffs in place, you cannot design a perfectly secured system, there is always a possibility that someone will break in. Direct your efforts to increase the time required for an attacker to break into your servers.