Securing a Linux Web Server in 2025

To lock down your Linux Web Server, we will need to secure the ssh service and the web server you have installed. I will be using nginx as my web server of choice throughout this article. We will go into how to install and configure your ssh service and fail2ban service. You can configure your web server however you wish, as that can depend on how your web application works on a technical level. What we can do is guard the thing you have configured and deployed.

I don't plan on going into how to set up the SSH or Nginx servers, as setup and configuration can be an entirely separate beast altogether. This assumes that you already have a computer with both of those technologies on it.

Locking Down SSH

Locking down your SSH service is the equivalent to putting a padlock on the front door of your house. This section will go over creating a non-root admin account that can perform certain tasks to deploy and maintain the software and remote in as that user.

Creating an Administration User Account

The administration account is a Linux user account with limited privileges. These administration accounts are necessary to perform certain required maintainence tasks without having the same power as the root user. This is very important as the root user can do anything on the server, including installing malicious packages or exfiltrating your data if it falls into malicious hands.

# create our linux user
useradd -aG admin admin

# set the password for the admin account
passwd admin -p <your password>

# create our home directory
mkhomedir_helper admin

# create the .ssh directory
mkdir ~/.ssh

# set ownership of the .ssh directory
chown admin:admin ~/.ssh

# set permissions of the .ssh directory
chmod 0700 ~/.ssh

I won't go over how to set up your admin user for your specific system, as you might need to access different files and directories to perform your maintainence tasks. The last task we have to perform is adding the following to the bottom of your /etc/ssh/sshd_config file.

AllowUsers admin

This allows your admin user to log into your server from a remote location using the SSH protocol.

Deploying your Private Key

We can currently only log into the system using the admin account using our password. This isn't really secure and can easily be brute forced. We want to set up our public/private keys and disable password authentication, making any remote login require the private key.

Important: NEVER give out your private key. This key is how you log into your server as the admin user. If someone else get's this key, your system can be compromised if you do not act fast enough and rotate the public/private key that you are using.

The first thing you need to do is create an ssh key. This will generate your public and private keys. We will want to ssh into the server just this once with a password to copy the private key over.

ssh-keygen -t ed25519

After you have your ssh key generated, we want to use the ssh command to remote into the server. You will be prompted for the password you set earlier for your admin user.

ssh admin@<your computer's ip address>

You will then be able to copy your ssh public key over to the server so that when you authenticate, it can check the private key on your machine against the public key that it contains.

ssh-copy-id -i ~/.ssh/<public-key-that-you-generated> admin@<your-server-ip-address>

Now that we have set up key authentication on our SSH server, we should log into it and test that it detects and authenticates using our private key.

Disabling Password-Based Authentication

Upon that first successful key based session into the server, go back to your /etc/ssh/sshd_config file and disable the PasswordAuthentication setting. Double check that the setting is disabled by using another computer or another account on your computer that doesn't have the private key to test sshing into the server. If all goes well, you should get an error. This validates that the computer connecting to the server must have the private key on it in order to connect to it.

Fail2Ban for Denial-of-Service Prevention

Fail2Ban is a software that can detect patterns in access to services on our server. We can use this to detect Denial-of-Service or Brute Force attacks against the SSH and Nginx servers. We are going to go over installing this service and configuring it.

apt install fail2ban -y

After installing Fail2Ban on your server, we will want to configure the jails, which are the banlists that we put users on when they attempt to attack our services. I personally like to configure shared jails, as I can usually assume that you shouldn't be able to access my ssh server if you attack my nginx server and vice versa. This section will focus on the SSH configuration and a separate section will focus on the nginx configuration later.

Securing our Web Server

Securing Nginx is pretty easy nowadays. You will need to configure DNS records to point at your server before performing any of these tasks. We will install SSL certificates onto our server to mitigate man-in-the-middle attacks by encrypting the traffic between your server and the client computers. Then we will install open-appsec onto our server, which uses machine learning to protect your applications from attacks. We will also configure fail2ban to protect our web servers from the same denial-of-service attacks and give it context to bad actors that have attacked other services on our server.

Let's Encrypt

Let's encrypt is a simple way to install SSL certificates onto your web server without self signing your own certificates or paying a certificate authority for the individual certificates on a per domain basis. This signs its own certificates for you and allows you access to them.

Open AppSec

Open AppSec is a Web Application Firewall (WAF) that analyzes traffic and determines if it is malicious or benign. It can detect bot activity, perform intrusion detection, and file security to keep your web applications and web apis safe from attackers. This is all accomplished by training a machine learning model based on your website asset definition.

Configuring Fail2Ban for our Nginx Server

This configuration will also pull from the ssh jail. We can safely assume that anybody attacking or even poking at our ssh server for too long without successful authentication is up to no good. So the ssh jail will share with the nginx jail as configured below.