Properly securing your server can be a confusing and challenging task. There are multiple layers to it, and numerous guides on how to do it right. While it is true that there are many tactics and tools out there, coming up with a plan involves identifying and covering just a few basics.
We are going to discuss here what are the fundamentals you need to cover in order to dramatically reduce the risks involved in running a server.
At its heart, security is about risk management. When considering risks, you need to consider the Impact of a particular event or threat to your server, and the Likelihood of that threat happening.
Security is about managing the risks to your server. Rather than trying to eliminate them altogether, which is only achievable if you plug out your server, you want to reduce them to acceptable levels. While you are running a server, there is always going to be a level of risk from being online in this digital age. But you can do a lot to reduce your risks so you are secure against more than 95% of the most common attacks.
Consider a virus attack. If your server is running a service like SAMBA or a web server, and is accessible from the internet, then the Likelihood is high. If you are saving backups of important data, like family photos, there, then the Impact of that virus or ransomware attack is also high.
If your server is behind your home router though, port forwarding has not been enabled, and you are just using it as a media server for downloading and playing movies, then the Likelihood and Impact are both lower.
Most peoples home servers will lie somewhere in the middle when it comes to a variety of risks, and when setting up security measures, like backups or anti-virus, start with your higher risk servers.
But the first step is to consider the threats.
So what threats are there to your server?
– Hacker attack
– Hard disk crash
– Someone stealing your root password and gaining access
– A hacker getting onto your server by exploiting vulnerable software
– What else can you think of…?
There are a myriad of steps you can, and should, take to protect your server, but overall, to reduce your security risk to a manageable level, your security plan should boil down to four essential elements:
Choosing a strong password for you user accounts is one of the most fundamental steps you can take in securing your server. Lists of the most commonly used passwords are widely available on the internet, and many attacks target accounts using simple, weak passwords.
Firstly, you need to use passphrases rather than passwords. As a rule of thumb, a longer passphrase is a stronger passphrase. Put a series of words together, using special characters like brackets, commas, hyphens, etc, along with numbers. It should be easy to think up a phrase or line from a song or poem using these.
Don’t limit yourself to 10 or 12 characters, as per common advice. Go long. Go for 30-40 characters, even 50… This makes it much less likely that a hacker or automated script will be able to break into your account.
A very common attack target is applications with default passwords. The Mirai botnet was able to take control of over 400,000 IoT devices because their default passwords had not been changed. This is low hanging fruit for an attacker.
If you install an application, like a torrent client, etc, and it has a password pre-set, change it.
Disable User Account Logons:
Alongside strengthening passwords is removing default or common user accounts. Password attacks will only succeed if an attacker is able to attack the user account to begin with. For this reason, SSH access to the root user account should be disabled.
Also, on systems like a Raspberry Pi, which comes with a very well known user account, pi, a new user account should be set up with a non-standard name, and sudo privileges given to this account. The default pi user account can then be disabled/deleted altogether.
Reduce Brute Force Attempts:
While trying to guess or brute force a password for an account, attackers will make multiple repeated logon attempts. Installing Fail2Ban will allow you to limit the number of SSH logons from a particular IP address, before that IP address gets blocked for a set time.
Two Factor Authentication
Two factor authentication (2FA) is being offered on more and more services. You can install this for services such as Webmin, WordPress, and even SSH. This allows you to use a code on your phone as a second password to log on to your account. This reduces the risk of a remote attacker being able to log in as you if they manage to steal your password.
Ubuntu releases a Long Term Support (LTS) version of their server software every 2 years. These versions come with 5 years support and updates. It is important that the version of the server operating system you are using is current and has not gone out of support.
To check your server operating system, run cat /etc/os-release
To update it, you can download a new version and install it – be sure to backup all data first. You will need to reinstall your applications afterwards.
You can also run an in-place server upgrade. I have never tried this, but would advise strongly that you backup all data first again. To do this run:
Regular patching is critical to maintaining the security of your server. The vast majority of software exploits use old vulnerabilities for which patches have already been released. Regular patching is required to install these patches, or your system runs the risk of being attacked and breached.
Along with the server itself, it is important that all applications are also kept up to date. Luckily Ubuntu allows you to do both using the one command.
To do this, run the aptitude update and upgrade command below at least weekly. You can also set a cron schedule to run it automatically.
sudo apt update && sudo apt upgrade -y
This will update the software repositories on your server, and then do the actual server and application upgrades. The -y flag will automatically answer Yes to prompts on whether you want to proceed.
If you are cautious about updating everything at once, or automatically, Ubuntu allows you to install security updates only as they are released. At a minimum this should be enabled. This can be done via the command line or via the Webmin web interface.
Another way to make it easier to stay secure is to reduce the number of applications installed on your server. This is known as reducing your attack surface, as a vulnerability in an application wont affect you if you dont have it installed. So if you don’t need something on the server, you should remove it.
Unfortunately, from the command line, it isn’t easy to get an easy-to-read list of what packages are installed. The options you have are running:
sudo dpkg -l | less
sudo apt list --installed | less
Take some time to review the lists they produce, and if something looks out of place, or you see something you installed once but don’t use now, remove it. You will need to review the lists carefully to ensure you don’t remove any important system packages. In general, only remove something that you recognise as being something you installed previously.
Linux is a multi-user environment, meaning that it was originally designed to allow multiple users to log on at any one time. If you have many users set up on your server, the permissions of the files they work on and save will limit what other users can and cannot do with them, i.e. read, write and execute.
It is important that you are setting up the specific limitations on what users can and cannot do on your server. Take care of the sudo group, as these users have administrator privileges on the server. To review the members of this group, type:
cat /etc/group | grep sudo
On a linux filesystem (ext4), files are given a set of permissions dictating what users can read them, write to and delete them, and in the case of scripts, execute them. These permissions can be viewed by typing ls -l. It is important that these are set correctly.
Consider if a hacker or virus got onto your server. File permissions restrict or allow what they would be able to do. It is important to keep this in mind.
The most generous or open-ended permissions are 777, i.e. chmod 777, which gives everyone Read, Write and Execute permissions on a file or directory. Use this carefully as it would give an attacker more generous access than you might want to give.
When you install an application, like a web server or a torrent client, it will often set up a new user of its own. This is a good security mechanism. If you had opened your torrent server to the internet, so you could connect to it and download torrents, then attackers might begin probing it for vulnerabilities. If one was found, and they were able to use this to gain access to your server, then they are now on your server as the torrent client user.
This is your first opportunity to restrict what they can do, by restricting what the torrent client user, in this example, has access to or can do. This is the reason for using 777 permissions carefully, as outlined above. Doing so allows someone using a torrent client user account to read or modify that file or folder easily.
When setting up a web based application, like WordPress, it is common that these need a backend MySQL database to run. If you have more than one web application running on your server (RSS reader, …) it is important that, along with each application having a unique database for itself, the user accounts for the databases are unique also.
The threat is in having an attacker breach the security of your system through a vulnerability in a web application. Most often this will be an SQL injection attack. Using SQL injection, an attacker can read the contents of a database and even change or delete data.
If the user account for a database has no privileges on any other databases, then the problem is contained to just the breached database alone.
For this reason also, the database root user must never be used for applications to work with databases.
Backups are an important part of running a server. Having good, and tested, backup policy allows you to quickly recover from events as simple as accidentally deleting a file, to recovering from a fire or ransomware attack.
A good backup plan involves taking multiple copies of important files, and saving them to alternative locations. This can be online, i.e. a distinct folder on the same server, as well as offline, backups moved to the cloud.
When installing the server initially, you had the option to install it using RAID, i.e. across multiple hard drives. While this does protect your data in the event of a single hard drive failure, this is a redundancy solution and not a backup.
If you have a solution which syncs data between your server and the cloud, this should not be considered a backup either. Syncing solutions are usually near to real time, and thus an attack on your data, i.e. ransomware, would also impact your cloud synced data.
Finally, be sure to test your backups frequently to prove that the backups are working, and not corrupting the data. This also allows you an opportunity to test the restoration process, so it works quickly and easily when needed.
These steps above should be considered the fundamentals in terms of how you approach server security. There are other things you should do also, as listed below.
If you are interested in further guides to securing and hardening your server, the CIS benchmarks for Ubuntu LTS would be very recommended reading.