17 Security Tips From A Pro To Protect Your Linux Server


Even if using Linux is one of the safest choice when it comes to your operating system, it doesn’t mean that nothing can be done to increase the security. And as Linux is mainly used on servers, it’s almost mandatory to take a few minutes after the installation to follow the recommendations I list in this article.

Protecting a Linux server goes from common-sense steps like using a strong password to installing active service to block specific attacks. Not all servers require the same level of security, but some of them are almost mandatory nowadays.

I’ve been a system administrator for nearly 20 years, and what I share in this article today is my checklist for any new Linux server I set up. Following them will keep you one step ahead of most security risks.

I answer your questions - Raspberry...
I answer your questions - Raspberry Pi FAQ

Introduction

Should I follow all of these tips?

As mentioned at the beginning of the article, if you’re installing a test Linux server at home, on a virtual machine with a few services and no forwarded ports in your Internet box, you are already pretty safe.

The risk level on your server depends on how it’s exposed to the “real” world. You won’t take the same measures for an old PC you use to watch Netflix on your TV, or for a VPS that is hosted online and accessible from anywhere in the world.

But all the tips listed here are good to know, and easy to apply, so if you share something on Internet, take 30 min to read the article and apply what you can.

How I wrote this article

I selected 17 main security tips, which apply to everyone who has a Linux server and share services on it. I have been a system administrator for 20 years, and these are the tips I apply to any new server installation.

They are in order of risk level. If you think you are highly exposed, follow all the steps, and you’ll be safe.
If your risk level isn’t very high, follow the first steps and stop when you think it’s no longer necessary in your situation.

Get My Cheat Sheet!
Grab your free PDF file with all the commands you need to know on Linux!

Reminder: Remember that all the members of my community get access to this website without ads, exclusive courses and much more. You can become part of this community for as little as $5 per month & get all the benefits immediately.

17 Tips to Secure your Linux server

1 – Keep your system updated

This may be obvious, but it’s important: keep your system up-to-date.
Like most operating systems, Linux can be updated easily, with packages provided by the distribution maintainer.

By doing them regularly, you not only get the latest features, but also all the security fixes for your installed applications.

Try to update your server regularly with:
sudo apt update
sudo apt upgrade

I assume you are using Debian, Ubuntu or any distribution based on Debian. The command will be slightly different on other distributions, but the idea is the same.

You can also automate this process with the unattended-upgrades package.
This procedure allows you to install security fixes automatically every day:

  • Install the unattended-upgrades package:
    sudo apt install unattended-upgrades
    It’s already installed by default on Ubuntu, and maybe on other distributions, but keep reading to know how to edit the configuration.
  • Open the configuration file:
    sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
  • Change what you want in this file.
    By default, it’ll download only security updates, but you can change this if you want to install all Debian updates, or even other repositories.
    I recommend to at least uncomment this line:
    //Unattended-Upgrade::Mail "";
    And choose a local user to receive the notifications. For example:
    Unattended-Upgrade::Mail "root";
    You can only use a normal email address if you have a mail server installed.
  • Save and Exit (CTRL+O, CTRL+X).

Then we need to configure a periodic upgrade.

  • Open this file:
    sudo nano /etc/apt/apt.conf.d/02periodic
  • Paste these lines (the file is probably empty, if not, change the corresponding values):
    APT::Periodic::Enable "1";
    APT::Periodic::Update-Package-Lists "1";
    APT::Periodic::Download-Upgradeable-Packages "1";
    APT::Periodic::Unattended-Upgrade "1";
    APT::Periodic::AutocleanInterval "1";
    APT::Periodic::Verbose "2";

    This will enable an automatic update every day.
    We ask apt to make: update, download upgrades, install upgrades, and auto-clean every day.
    The last line is the verbose level you’ll get in the /var/log/unattended-upgrades and email (1= low, 3=max).
  • Save and exit (CTRL+O, CTRL+X).
  • This should be ok, you can debug your configuration with this command:
    sudo unattended-upgrades -d

Don’t forget to check the log file and/or the emails received to make sure everything is working as expected.

2 – Don’t use auto-login or empty passwords

Passwords are a big part of system security.
It’s the kind of common-sense step I was mentioning in the introduction, but believe me, it’s worth to take a few minutes to think about it.

Get My Cheat Sheet!
Grab your free PDF file with all the commands you need to know on Linux!

First: make sure that all critical accesses ask for a password.
Don’t use auto-login, and be sure to add a login step for each application you can access directly.
I won’t list all apps, but for example, if you have a web server, make sure that personal data or administration pages aren’t accessible without a password.

Make sure that nobody uses an empty password on the server.
If you have a few accounts, it’s easy to check all access.
If you have a lot of user accounts, these commands could help you:

  • Search for empty passwords:
    sudo awk -F: '($2 == "") {print}' /etc/shadow
    This will display only accounts with an empty password.
  • Lock unsafe accounts:
    passwd -l <username>

On recent distributions, I think it’s no longer possible to create an account without a password, but if your server was set up a few years ago, it’s better to check that.

If you have a desktop environment (like GNOME), automatic login can be enabled or disabled for each user in the system settings. Make sure it’s disabled for everybody. If a reboot gives me access to a session opened automatically, it doesn’t matter how strong the password is…

3 – Use long passwords for your user accounts

A common mistake is to set the default password quickly during the installation, and not changing it afterwards (using something like “ubuntu” or too simple to guess).
So many people are scanning SSH ports and trying to log in with ubuntu/ubuntu or root/linux or whatever.

Changing the default password should be the first thing to do on a new installation.
In theory, use a strong password directly when you set up the account during the installation, but if needed, you can always do this later.

Doing this is easy, login with your main user and enter this command:
passwd

Try to use a sentence with over 15 characters to be safe against brute-force attacks, and to remember it easily (ex: iloveraspberrytips is a good password easy to remember). If you need some ideas, this website offers an easy-to-remember password generator (yes it’s mine, but I love that kind of password).

4 – Avoid obvious user names

As I said, when hackers and script kiddies try to brute force their access to your servers, they’ll basically try common user names and passwds.
Basically, if you have usernames like “ubuntu”, “admin” or “root” enabled, you take more risks than by using your real name or anything random.

If needed, create a new user now to prevent these kinds of attacks:

  • Create a new user:
    sudo adduser <username>
  • Give him the sudo privilege if needed:
    sudo adduser <username> sudo
    This will add your new user in the sudo group.
  • Check that everything is working correctly (ssh access, sudo, …).
  • Copy files from the old user to the new user if needed:
    sudo cp /home/admin/Documents/* /home/<username>/Documents/ ...
  • Delete the old user:
    sudo deluser -remove-home admin
    If you prefer, you can start by locking the account (like explained previously), and delete it only after a few weeks, when you’re sure everything is working fine.

5 – Stop unnecessary services

On a Linux server, almost everything run as a service. It’s convenient, but it can also lead to security issues, especially if you try new things regularly.

Let’s say you installed PHPMyAdmin 3 months ago to try something, but you’re not using it anymore.
This could create a breach for an attacker that will allow him to enter your system.

Try to stop or uninstall unneeded services and apps:

  • List running services:
    sudo service --status-all
  • To stop a service use:
    sudo service <service-name> stop
    If it starts automatically on boot, try:
    sudo update-rc.d <service-name> remove
  • Or to uninstall it, it should be something like:
    sudo apt remove <service-name>

6 – Make sudo require a password

As you should know, sudo doesn’t always ask for a password.
Most of the time, you don’t need to type your password again.
It’s cool for productivity, but for security reasons, it’s not a good idea.

If someone succeeds to get terminal access to your main user, super-user privileges will be accessible without a password.
I recommend you ask for a password when you use sudo.
If it’s not the case by default on your system, you can change this by following this:

  • Edit this file:
    sudo nano /etc/sudoers
  • Check if you can find a line for the user, something like:
    pat ALL=(ALL) NOPASSWD: ALL
    Replace “pat” with your user name.
  • Replace it or add a new line with:
    pat ALL=(ALL) PASSWD: ALL
  • Do the same for each user with sudo access.
  • Save and exit (CTRL+O, CTRL+X).

7 – SSH: Prevent root login

As I said previously, root and default users are often the main target for brute-force attacks. It’s especially true when SSH is enabled.

So, you need to make sure that root doesn’t have direct SSH access.
If you need root, log in with your normal user and then use sudo to get super-user privileges (as explained in this article).

Nowadays, most Linux distributions have root access disabled, which is a good thing.
If you have any doubt or want to disable the access, you need to edit the SSH server configuration:

  • Open the SSH server configuration file:
    sudo nano /etc/ssh/sshd_config
  • Find this line:
    #PermitRootLogin prohibit-password
  • If you have anything else, comment this line (by adding # at the beginning).
  • Save and exit (CTRL+O, CTRL+X).
  • Restart the SSH server if you changed anything in the configuration file:
    sudo service ssh restart

No idea what SSH is? Start by reading my complete guide about it.

8 – SSH: Change the default port

The SSH default port is 22.
So basically, attackers will create bots to make login attempts on this port.
To prevent this, you can change the default port and set another one:

  • Edit the SSH server configuration file:
    sudo nano /etc/ssh/sshd_config
  • Find this line:
    #Port 22
  • Replace the port with the one you want to use, and make sure to uncomment the line:
    Port 1111
    Avoid port conflicts by using a free one, full list here:
    List of known ports on Wikipedia.
  • Save and exit (CTRL+O, CTRL+X).
  • Restart your server:
    sudo service ssh restart

Don’t forget to adjust the firewall rules if you have one.
Make a new connection test before closing the current one, as it could help you if you made a mistake.
You need to update the used port in your connection settings, with Putty it’s just after the IP address:

9 – SSH: Use SSH keys instead of passwords

With the previous steps, we already block most of the script kiddies with broad attacks to any responding IP address.
We are now moving to things that could protect you even if you are facing a strong hacker who is especially interested in accessing your system (and not any other system).

Get My Cheat Sheet!
Grab your free PDF file with all the commands you need to know on Linux!

Using a strong password will slow the attack, but it’s always possible to find it, even if it takes weeks to get the correct password. What you can do to block this, is to use SSH keys instead of passwords for your SSH connections. An attacker can guess a 15-character password, but not an SSH key.

The main idea is to generate a key on your computer, and then add it to the Linux server to allow a connection from your computer (with or without a password).
I give you the step-by-step procedure at the end of this article.

Once this is working, you can disable SSH connections with a password.
Change this line in the SSH configuration file we opened before:
PasswordAuthentication no

10 – Install Fail2ban

Fail2ban is a tool that detects brute-force attacks and blocks them.
In the previous steps, I said that an attacker could try to find your password for months, and maybe they can succeed.
The main purpose of Fail2ban is to avoid this.

Fail2ban will block attackers’ IP if they fail to log in more than X times.
You can configure the number of tries before a ban, and the ban duration.
Follow these steps to install Fail2ban on your Linux server:

  • Install the package:
    sudo apt install fail2ban
  • By default, fail2ban will ban attacker 10 min after 5 failures.
    I think it’s ok to start, but if you want to change this, all the configuration is in the /etc/fail2ban folder.
    Mainly in /etc/fail2ban/jail.conf:
    sudo nano /etc/fail2ban/jail.conf
  • Restart the service if you change anything:
    sudo service fail2ban restart
Fail2ban comes with a bunch of supported apps with basic rules you can use.

This should really slow down your attacker. 5 attempts every 10 minutes is 720 tries a day.
If your password is something more difficult than “password” or “123456789” it should take a long time for the hacker to find it.

Here is a link to my tutorial on how to use Fail2ban on a Raspberry Pi. Feel free to check it if you need more details or want to go deeper with the configuration of this useful service. The idea will be the same for any Linux server (a Raspberry Pi is just a tiny server running Debian).

11 – Install a firewall

If you don’t know, a firewall allows you to block all ports except the ones you need and filter access by IP. For example, you can block everything, and just allow SSH access from your computer IP address.

As explained in this in-depth article, an antivirus is not mandatory on Linux, but a firewall is a good practice if you host some critical services.

I’m used to installing iptables for my firewall rules, but maybe for a beginner, it’s not the easiest route to take. So, I’ll explain to you how to install ufw (Uncomplicated FireWall), which is more straightforward, and then allow only what you need.

It’s a basic configuration with HTTP access for anyone, and SSH only for you, but you need to adapt this to what you want to do.

  • Install the firewall package:
    sudo apt install ufw
    UFW is sometimes pre-installed, so maybe you don’t even need to install it.
    For example, on Ubuntu it’s installed by default (not configured/enabled, but it’s already there).
  • Allow Apache access for anyone:
    sudo ufw allow 80
    sudo ufw allow 443
  • Allow SSH access for your IP address only (not mandatory, just to give you another example):
    sudo ufw allow from 192.168.1.100 port 22
    Don’t forget to replace values with your own settings.
    On a local network, you can get your IP address with ipconfig (Windows) or ifconfig (Linux/Mac).
    If you change the SSH port in the previous step (by 1111 or anything else), replace it here.
  • Enable the firewall:
    sudo ufw enable
    Be careful, this will enable the firewall now, and also on boot.
    If you lose access to your device, you won’t be able to fix this, even after a reboot.
    You’ll need to change the configuration directly on the server (physically).
  • Check that everything is fine.

To display your current rules once UFW is enabled, use this command:
sudo ufw status verbose

For more complex configurations, check the man page.
My other tutorial about building a wireless router with firewall features can also help you to better understand the goal of a firewall (I use iptables, but I have graphic explanations for the whole picture).

12 – Backup your system

One of the worst consequences of an attack is to lose data.
If you back up your files correctly and regularly, you’ll be safe even if the hacker destroys your SD card.

I already wrote an article on how to back up and restore a Raspberry Pi, so I won’t repeat it here, it’s the same idea for any Linux server.
Make sure that you can read your backup and that all of your important files are inside; otherwise, it’s useless. Testing your backup files regularly is a good practice.

13 – Crypt your connections

This is a vast topic, and I won’t give many details about this, but I’ll give you an example.

With basic protocols, data flows in clear on the network. That’s to say, if you type your password, a hacker could get it while listening to the network. Luckily, there are often better and safer protocols available, that will encrypt the data from one point to another.

The first thing is to stop using unsafe protocols (FTP, Telnet or HTTP for example). And then try to replace them with safer ones (SFTP, SSH, HTTPS).

The procedure depends on which protocols you are using. Let’s take the HTTP example.

HTTP is cool if you only use it for static content, you never type a password, and don’t have sensitive data on your server. But take the time to switch your application to use the HTTPS protocol anyway, it’ll be safer.
It’s pretty simple to do, you just need a certificate and change a few lines in the Apache or Nginx configuration. You’ll find plenty of helpful tutorials on the Internet.

And most of the time it’s easy. You can directly switch from FTP to SFTP, as your Linux server most likely already has SSH enabled. Same thing for Telnet users, why do you need Telnet while SSH is available?

Then look at all the protocols you are using (especially with sensitive data) and what you can do to improve the overall security of your system.

14 – Use a VPN

A more radical option is to access your server through a VPN.
VPN stands for Virtual Private Network and allows you to access remotely all services on your server as if you were in the local network.
All flows between you and the Linux server will be encrypted by a strong protocol.

This is a good option, especially on a simple network, to prevent opening many ports on the Internet without security.
I have an article on how to use a Raspberry Pi as an OpenVPN server, and you can easily find more help on the Internet. Recently, I switched to WireGuard, but it’s the same idea (you can find more about WireGuard here).

You can also install NordVPN or any other provider (my top VPN providers here) if you want to use a secured tunnel to access the Internet from your Linux server. But I guess, most of the time, it’s the other way that need to be secured.

15 – Protect physical access

The last protection is obvious but often ignored when we talk about security.
You can configure any security protocols, firewall, and VPN from all the steps before.
If your server is physically accessible by anyone, it’s useless.

Make sure that the Linux server can’t be stolen easily (or the hard drive at least), and that nobody could come and plug a keyboard and screen and be logged in automatically.
The steps to implement to protect that kind of attack will depend on your system.
Maybe you’ll need an auto logoff after X minutes, a password in the grub boot menu, or encrypt the data on the hard drive.

Think about it, what could be the worst thing that could happen if someone gets access physically to your server? Then find solutions to prevent this from happening.

16 – Check your logs regularly

The last two items from this list are not really protections, but more of a commitment to follow.
Most of the time, attacks are visible in the log files.
So, try to read them regularly to detect any suspicious activity.

All logs are in the /var/log folder, but the main log files to check are:

  • /var/log/syslog: main log file for all services.
  • /var/log/message: whole systems log file.
  • /var/log/auth.log: all authentication attempts are logged here.
  • /var/log/mail.log: if you have a mail server, you’ll find a trace of recent emails sent here.
  • Any critical applications log file, for example /var/log/apache2/error.log or /var/log/mysql/error.log

Some solutions are available to simplify this work.
For example, you can configure syslog to send logs to a master server, with an interface to read them, filter, etc.
You can also use logwatch to get daily reports about the system operation.

17 – Read the news

To keep a good security level in your projects, try to stay constantly updated.
I see new vulnerabilities in a lot of major software packages every day, and it could take weeks or more to have the fix available in the distribution repository.

If you read security news regularly, you can act faster to stay protected.
Here are some good websites to follow:

You could also use a vulnerability scanner like Nessus to find only the vulnerabilities that apply to your system.

Get My Cheat Sheet!
Grab your free PDF file with all the commands you need to know on Linux!

Additional Resources

Lost with the command line?
You don’t need to learn and remember everything, just download my cheat sheet where I explain the most important commands on Linux, with a brief explanation and some examples.
Download my free PDF cheat sheet.

VIP Community
If you just want to hang out with me and other Linux fans, you can also join the community. I share exclusive tutorials and behind-the-scenes content there. Premium members can also visit the website without ads.
More details here.

Need help building something with Python?
Python is a great language to get started with programming on any Linux computer.
Learn the essentials, step-by-step, without losing time understanding useless concepts.
Get the e-book now.

Patrick Fromaget

I'm the lead author and owner of RaspberryTips.com. My goal is to help you with your Raspberry Pi problems using detailed guides and tutorials. In real life, I'm a Linux system administrator with a web developer experience.

Recent Posts