How to Secure a VPS Server? – Essential Security Checklist

VPS security is the set of controls that protect your virtual private server from unauthorized access, data breaches, and downtime. Unlike shared hosting, where the provider manages most security controls, a VPS places that responsibility directly on you. Henceforth, it is necessary to have a good plan in the beginning. 

This guide will explain how to secure a VPS server, whether you are creating a new deployment or securing an existing deployment. In case you are still in the process of preparing the environment, then begin with our tutorial on how to create a VPS server. When your server is online, here is the checklist of how you can secure your VPS on the first day.

Key Takeaways from the Article

• Turn off password authentication and replace it with SSH key-based access to remove the vulnerability to brute-force attacks.

• Always use a non-root sudo user and prevent direct root logins.

• A well-configured firewall must block out all traffic coming into it unless it is the ports that your services require.

• Fail2ban automatically blocks IP addresses that exhibit malicious behaviour, such as repeated failed login attempts.

• Automated checkups, frequent backups with tested restore, and the constant monitoring of logs are not an option; they are the basis of VPS security.

Why VPS Security is Important?

According to the Verizon 2024 Data Breach Investigations Report, over 80% of breaches involving web application servers exploited stolen credentials or unpatched vulnerabilities. Automated bots scan the entire IPv4 address space constantly. A new VPS can start receiving brute force SSH login attempts within minutes of going live.

Large businesses or high-profile applications are not the only targets of attackers. They also seek typical weaknesses such as open ports of management, SSH access by passwords, out-of-date packages, silent monitoring, and services that were installed and forgotten. Any single vulnerability can pose an unjustified risk to your software, data, and availability.

A structured server security checklist is used to make security a routine rather than a one-time activity. It provides you with the clear means of hardening access, minimizing attack surface, enhancing recovery preparedness, and monitoring your setup periodically. There is a source of stronger VPS protection, too, not in a dramatic change, but in a set of intelligent controls, over a long time.

In small enterprises, and for first-time users, the aim is viable, secure VPS hosting that minimizes flagrant risks and facilitates stable functioning. Repeatable plans give you a far safer base when you are securing your VPS, and you have websites, applications, client portals, and business services. This is what a good VPS security checklist is all about: clear priorities, repeatable actions, and improved long-term results.

10 Essential Steps to Secure Your VPS Server

Step 1: Disable Password Authentication and Use SSH Keys

Password-based SSH login is the most vulnerable way in a default VPS configuration. Passwords can be guessed, forced, or stolen. It is replaced by SSH key authentication with a cryptographic key pair, i.e., local machine private key and server public key. The access is not reachable, even prior to the number of logins made, without the appropriate private key.

Create a key pair of SSH keys on your local machine:

 

 

The Ed25519 algorithm is the latest suggestion. It generates shorter keys and is more secure than the older RSA keys. A minimum of 4096 bits should be used: ssh-keygen -t rsa -b 4096.

 

Copy your public key to your server:

 

 

Then turn off password authentication of the server. Change the SSH daemon configuration file:

 

 

Identify and update the following directives:

 

 

Reload the SSH service to implement changes:

 

 

Note: You need to ensure that you can log in using your key before you close your current session and open up a new one. You do not want to lock yourself out of a remote server.

Step 2: Change the Default SSH Port

The default SSH port is port 22, and it is familiar to all automated scanners found on the internet. Switching to a non-standard port does not contribute to SSH being any more or less secure; it is security by obscurity, but it will drastically reduce the number of automated logins to your server. Fewer junk connections also translates to cleaner logs and less noise to filter through when monitoring for actual threats.

Edit your SSH configuration:

 

 

Adjust the port to some high number that does not conflict with common services:

 

 

Choose a port between 1024 and 65535. Do not use popular ports such as 8080, 3306, or 5432. After changing, restart SSH:

 

 

Before restarting, update your firewall rules to permit the new port, or you will lock yourself out. Start using the new port in the future:

 

 

Step 3: Create a Non-Root Sudo User and Disable Root Login

A root operation is similar to keeping all doors in a building wide open. One misplaced key that is typed can ruin your whole system. All your processes executed under the root have unlimited access. When a root session has been compromised, the attacker owns the whole server.

The less risky option is to make a special user with sudo privileges. This user will be able to gain access to root-level privileges when required, but has restricted access.

Open up a new user and add it to the sudo group:

 

 

Copy the SSH keys to the new user account and permanently avoid root logins:

 

 

 

 

In the future, you will have to use your sudo user and prefix any command that needs high privileges with sudo. This also generates an audit trail - each privileged action will be captured, and it will record which user ran it, and will restrict the blast radius in case the account is compromised.

Step 4: Set Up a Firewall

A firewall is the gatekeeper of your server. The rule is easy: just deny all the incoming traffic by default, and then explicitly permit only those ports that your services require. In the case of a regular web server, it implies SSH (on your own custom port), HTTP (port 80), and HTTPS (port 443). 

All other things must be blocked.

The simplest one is UFW (Uncomplicated Firewall):

 

 

Critical: It is always recommended to enable SSH before UFW. You will lose access to your server immediately after you turn on the firewall without an SSH rule.

When you have other services that you are running - a database, a mail server, an API on a nonstandard port, only add rules as necessary. Periodically, revise these rules and get rid of those that are no longer in operation. All the open ports can be entry points.

Step 5: Install Fail2ban to Block Brute Force Attacks

With SSH keys and a non-standard port, you are still going to get automated login attempts on your server. Fail2ban watches the log files of your server in real time and automatically blocks IP addresses exhibiting undesired behaviour, such as repeated failed login attempts, by creating temporary firewall rules.

Install and enable fail2ban:

 

 

Make a local setup file (so changes do not overwrite your settings):

 

 

Important settings to be made in the [sshd] jail:

 

 

This setup prohibits any IP that does not pass the 3 attempts of logging in within 10 minutes (600 seconds), restricting them to 1 hour (3600 seconds). For repeat offenders, you may have bantime. increment = true in order to increase the ban time slowly.

 

Status of active jails:

 

 

Fail2ban is compatible with your firewall - it is not a substitute. The firewall is the locked door, and the fail2ban is the security camera that catches a person attempting to pick the lock and prevents this person from coming closer.

Step 6: Keep Your OS and Software Updated

One of the most common attack vectors in server compromises is always unpatched software. The gap between active exploitation and disclosure of a vulnerability is reducing as the vulnerability is publicized. According to CISA (2024), threat actors will often start exploiting critical vulnerabilities within 24 to 48 hours after a public advisory. Postponing updates is not a non-committal choice; it is a risk of action.

Periodically run manual updates:

 

 

Auto update security: This is to ensure that critical patches are applied automatically without any delay.

 

 

The difference is important: It is safe to automate patches so that you never get left behind by delay, but it is important to review major version changes by hand to avoid introducing changes in your application stack. With automated security patching, a monthly review of the pending updates is the right balance between protection and stability.

Step 7: Remove Unused Software and Services

Any software that is on your server can act as an attack point. You will find many packages and services installed on default server installations that you will never need: FTP daemons, mail transfer agents, sample web applications, and development tools. All of them listen on a port, execute with some permissions, and are vulnerable to accumulating vulnerabilities as they go out of date.

Audit running services:

 

 

Check open ports and listening processes:

 

 

The service that you do not know, or do not want, must be terminated and disabled:

 

 

The most common culprits are default mail servers (Postfix, Exim), FTP ( vsftpd ), and outdated networking tools. When you are running a web application, you probably do not need any of them. This is a straightforward principle: when it is not serving a purpose, it must not be running.

Step 8: Set Up Automated Backups and Test Restores

Backups cannot be only a convenience; they are a very important security measure. The causes of the data loss may include ransomware, accidental deletion, corrupted updates, and compromised accounts. A backup strategy is often the key between a minor event and a disastrous one.

Use a 3-2-1 backup rule: make sure you have at least 3 copies of your data, 2 copies stored on 1-2 storage media, and 1 copy stored offsite (off-server).

Simple automated cron-based rsync-based backup:

 

 

In the case of database-driven applications, dump the database before the file sync:

 

 

Testing restores is the most neglected element of any backup plan. An untested backup is a liability and not an asset. Schedule a quarterly spin test with a restore test - spin up a test environment and make sure that all your data is available and your application is operating properly.

To have an additional examination of backup plans, together with disaster recovery planning, take a glance at the HostSailor backup and disaster recovery guide.

Step 9: Monitor Server Logs for Suspicious Activity

You have the complete history of what is going on in your server logs — read them. There is a record of failed logins, unexpected processes, abnormal network connections, and permission changes in log files. Whether or not you are watching is the question.

Key logs to monitor:

• Authentication logs (/var/log/auth.log): Failed and successful logins, sudo.

• Logs of the system (/var/log/syslog) service start, stops, crashes, and kernel messages.

• Web server logs (/var/log/nginx/access.log or /var/log/apache2/access.log) request trends, error messages, and malicious URIs.

Quick scan on the recent failed login attempts with the SSH:

 

 

To ensure that logs do not use all the disk space, configure the rotation of logs:

 

 

To monitor in a more systematic manner, utilities such as Logwatch may be used to provide a daily email summary of the log activity. The point is not to read each line; it is to achieve a level of normalcy so that the differences are noticeable when they occur.

Step 10: Install SSL Certificates and Use DDoS Protection

All the data that is being sent between your server and any users is unencrypted in transit. This traffic is encrypted with an SSL/TLS certificate, and the credentials of logins, form submissions, API calls, and session tokens will not be intercepted.

Install a free SSL certificate: Let’s Encrypt and Certbot:

 

 

Certbot deals with the issuance of certificates and automatic renewal. Confirm renewal procedure functions:

 

 

Use SSL not only on your primary site but on all your web-facing services - administer panels, API endpoints, and monitoring dashboards. Everything available with HTTP should be redirected to HTTPS.

The other essential layer of protection of the public-facing servers is DDoS protection. A DDoS attack overloads your server with traffic sources (thousands at a time) to the point that it cannot handle the traffic and goes offline. This cannot be mitigated with a firewall; it needs a network-wide mitigation before your server.

HostSailor KVM VPS NVMe plans are equipped with DDoS protection; hence, mitigation is managed on the infrastructure level, and thus, the malicious traffic is never released to your server. This gets one of the more challenging and costly security concerns off your plate altogether.

VPS Security Checklist

This quick VPS security checklist can be repeated as a review process:

• SSH key authentication is available; password authentication is not.

• SSH default port has been modified to a non-standard port.

• Root user was disabled, and a non-root sudo user was created.

• Firewall set up - default deny, only ports necessary open.

• Installation and configuration of fail2ban (SSH).

• Automatic security updates are on.

• Unneeded services and software eliminated.

• Automated restores under test, automated backups in action.

• Monitoring of logs is established with frequent reviews.

• SSL is installed, DDoS is on.

Additional Measures to Strengthen Your VPS Security

The above 10 steps are the main requirements. The following defenses provide extra protection, particularly to servers that contain sensitive information or provide support to a number of users.

Use Two-Factor Authentication for Remote Access

SSH keys are powerful, and it is even more difficult to gain unauthorized access with the use of a second authentication factor. OTP via time-based rotating passwords (TOTP) - the same 6-digit rotating passwords offered by applications such as Google Authenticator - can be added to your SSH login process.

Install the PAM module of Google Authenticator:

 

 

Go through the instructions and create your secret key and emergency scratch codes. After that, change the PAM and SSH setup to prompt for the use of TOTP with your SSH key. This particularly comes in handy when teams share the same server; although the key of one individual has been compromised, the attacker must still have the time-sensitive code.

Limit User Privileges and Access

The least privilege principle entails that each user and each service on your server must only have access to what they cannot possibly do without - no more. Do not provide developers with root permissions when all they have to do is deploy code. You should not invoke your web application as root, as all it requires is access to its directory.

Check on current user accounts frequently:

 

 

Turn off or delete accounts that are not in use. Separate roles should be done using separate accounts. Shared credentials should be avoided at all costs because they remove accountability and make it impossible to find out who did what when something is wrong.

In the case of application services, run each of them with its dedicated system user with limited permissions. When your web server is compromised, the attacker should not be in a position to access your database or other services that are running on the same machine.

Secure DNS and Use DNSSEC

VPS hardening usually ignores DNS, though it is an important component of the security of your server. DNS spoofing attacks and cache poisoning attacks spoof your visitors by corrupting DNS responses. Your users believe they are on your site, but instead, they are giving an attacker their credentials.

DNSSEC (DNS Security Extensions) is the addition of cryptographic signatures to DNS records that enable the resolvers to check whether answers have not been altered. A majority of domain registration authorities have now adopted DNSSEC - making it work is usually a question of key generation with your DNS vendor, and the addition of DS records at your registrar.

On the server side, make sure that you are using a trusted DNS resolver. Have your server set to deploy trusted resolvers such as Cloudflare (1.1.1.1) or Google (8.8.8.8) instead of the default ISP DNS, which can be more vulnerable to cache poisoning.

The Bottom Line

Server security is not a project with a finish line; it is a continuous discipline. This checklist, outlined in 10 steps, should keep your VPS safe against the overwhelming majority of automated attacks and typical exploitation methods. However, the threat environment varies, new vulnerabilities are revealed, and configurations change with time.

Add a quarterly security audit to your process:

• Check and delete user accounts that are not active.

• Audit firewall is countering existing service requirements.

• Check backups are running and perform a test restore.

• Check and install pending updates.

• Analyze the logs of authentication by unusual flows.

• Ensure that the certificates of the SSL are being renewed.

All these tasks last in minutes. Hardened servers are gradually injured by skipping them a quarter, then two, then three. HostSailor KVM VPS NVMe plans have a solid security foundation, including DDoS protection, full root access to take all the steps in this guide, and NVMe storage for high performance and reliability. A secure server begins with a solid platform.

Frequently Asked Questions About VPS Security

What is VPS security?

VPS security is the set of practices, tools, and configurations that protect your virtual private server from unauthorized access, data breaches, and service disruption. It covers everything from SSH hardening and firewall rules to automated patching, backup strategies, and log monitoring.

What is SSH key authentication, and why is it important?

Authentication of SSH key involves the utilization of two cryptography keys: a private key (kept on your local machine) and a public key (kept on the server) to authenticate. It is important since SSH keys cannot be brutally forced or guessed, as opposed to passwords. The key is 256-bit Ed25519, which would be virtually impervious to the automated attacks that are used against password-based logins, and it would take billions of years to crack using the current computing power.

Which ports need to be opened on a VPS firewall?

Only ports where your services are actively needed in the case of a normal web server, which usually implies your own SSH port, HTTP (port 80), and HTTPS (port 443). Each open port that you have adds to your attack area. You must only allow your database to receive connections through localhost or preferred IP addresses, and no longer the outside world.

How do I secure a VPS server for the first time?

Start by disabling password-based SSH login and switching to SSH key authentication, then create a non-root sudo user and disable direct root access. Next, configure a firewall to block all incoming traffic except the ports your services need, install fail2ban to block brute force attempts, and enable automatic security updates.

What is fail2ban, and do I need it?

Fail2ban is a log-inspecting device that identifies frequent unsuccessful access attempts and prevents the respective IP addresses by appending temporary firewall guidelines. Yes, you need it. Your server will automatically be logged in, even with SSH keys being enabled. Fail2ban prevents them on the network level so that you have no logs to clean and unnecessary traffic to your SSH server.

How frequently should I update the VPS?

The automatic application of security patches must be done immediately they are released - unattended upgrades or similar should be configured to do this. A monthly manual review is a realistic cadence for updating it in non-security releases and major version releases. The most important principle is that security patches must not be postponed, whereas application-level upgrades should be tested first.