22.02.2026
11 min
409
Hardening a VPS involves 10 necessary processes, including; using SSH keys for access, disallowing root access, altering the default SSH port number, creating a firewall (using iptables or UFW) for security, and installing Fail2ban. It also includes regularly updating the operating system, deleting unnecessary applications from your server, maintaining backup files of your server data, utilizing an encrypted connection by using HTTPS and SFTP. Additionally, special emphasis has been placed upon viewing logs for activity and controlling who can access your server, based on their IP address.
Here’s an example of how it can happen: after launching a virtual server (VDS/VPS), in a few minutes there will be a flood of log entries from password guesses. At that point, it would be senseless to rely on the provider, since they are only responsible for isolating guests within a single hypervisor; everything else related to the guest operating system is up to you.
Below, I have collected ten basic VDS security principles. The most effective way to use these principles is to implement them all at the same time, which will make one solid setup.
Authentication is the foundation of security; weak passwords such as “admin123” are virtually handing over a gift to bots and script kiddies that can test thousands of combinations per second. A stronger password would be at least 12 characters long, with both upper and lower case letters, numbers, and special symbols — but even better than a password, is an SSH Key. When connecting via SSH Keys, the connection uses a key-pair: a public key (the public key is stored on the server), and a private key (kept on your computer); cracking or guessing such a key is almost impossible so brute force attacks will fail. SSH also encrypts all data transferred, providing additional protection to an attacker.
To create a key, go to PuTTY and search for “How to Generate a Key.” And as part of basic security hygiene: never use the same password on multiple services. Also, if your control panel allows for 2-factor authentication, activate it right now.
Linux servers are primarily targeted by attackers to attempt to gain access to the root user. Because the root user does not have any restrictions, bots tend to focus on brute forcing the root users’ password. It is easy enough to not provide the attackers with the ability to log into the root user over ssh.
Create a new user for admin purposes, assign that user the appropriate privileges by way of sudo, and turn off root login over ssh. You can do this in the /etc/ssh/sshd_config file by setting the PermitRootLogin directive to no. Before you apply this change, ensure that your new admin user is able to perform the actions you need him/her to perform, because you may accidentally lock yourself out. In most cases, if you lock yourself out, you can regain access to your server through the web interface provided by your hosting company.
After you’ve made these changes, root login will be turned off — which is the #1 thing hackers try to get into your system by — making your system more secure.
Thousands of scanners are running daily trying to find a server they can exploit. Most bots begin by scanning the default SSH port number — 22. To make it difficult for them, simply change the SSH port number to something other than 22 (you can pick something within the 49152-65535 range). Make sure to add the new port to your firewall settings, and include the -p option when specifying the port number when connecting to your server with your SSH client.
A further step in limiting access to your server is to allow access to only those IP’s that you deem safe. Typically, this is done with iptables or UFW rules. You can limit access to certain locations — such as your home or work IP — and block everyone else without hesitation.
In general, your server should only have open those ports that are absolutely required for normal operations — everything else should remain closed.
This is the rule of thumb we want to follow: “Only allow access to that which you explicitly permit.” What we mean by that is only allow the ports needed for critical services through your firewall.
Before you do anything else, go through your cleanup process. Delete any services and daemons you do not use, thereby eliminating the ports they occupy. To see what you currently have active, use the command netstat -ntulp, or ss -ntulp. Use iptables, UFW, etc., to block whatever is unnecessary.
Additionally, it is good practice not to host anything on your VDS that could be a risk factor. Unnecessarily CMS plugins, utilities, or modules could become security vulnerabilities. The less unnecessary code you run on your VDS, the more reliable your system will be.
Once you’ve gone through the cleanup process, set up your firewall correctly. A lot of providers offer their own traffic filtering, but you still need to implement protection at the operating system layer using iptables, nftables, firewalld, or at least UFW. First, set the default rule for incoming connection requests to DROP, and then allow only specific IP addresses and ports manually. This way, if an attacker guesses your new SSH port, they won’t be able to establish a connection without having an authorized IP address.
Next, you’ll need to protect yourself against brute force attacks. One of the best tools for doing this is Fail2Ban (you can install it via a package manager). It looks at your authentication logs, and when it detects repeated attempts to guess passwords by a particular IP address, it automatically blocks those IP addresses.
Fail2Ban doesn’t come pre-installed on Windows systems. On these systems, you would either need to use WSL2 (although daemons may not work well there) or find some alternative, possibly something like F2B or Fail2Ban4Win. Once you have installed Fail2Ban on Linux, it is best to create a jail.local file (this usually resides in /etc/fail2ban/) where you can configure the needed rules. At the very least, activate the protections for sshd.
Your newly created VDS needs to be current from the first moment. Each piece of software — whether it is the kernel, packages, or services — may contain flaws, and each time a developer finds out about a flaw, he/she creates a patch. The closer to current your software is, the lower the likelihood that an attacker will be able to take advantage of an existing vulnerability.
Automating updates is one of the easiest ways to prevent the need to check every single piece of software manually. For example, you can schedule cron jobs to update your antivirus databases once a day, or to check for package updates. However, while the tools themselves are important, your dedication to keeping your VDS current is more important.
Following the last point: do not install every program just in case. Each additional service or library that you install creates a potential entry point for attackers. If you do not require a mail server, and/or the Perl interpreter (since Nginx + PHP + MySQL are enough for you), do not install them.
If your VDS already has many programs installed, remove all the ones you do not use. Disable all unnecessary services, and close all of the ports they use.
Backups are not designed to stop attacks; however, they provide a good starting point in the event of a security incident. It is recommended that you set up automated backups every day via the command-line tool “rsync” or via a scheduled script (cron). Some web-hosting companies provide automated weekly backups of their VDS systems; however, if this is the sole method of backups, you could face significant difficulties during a security breach. To mitigate this risk, make sure to back-up your database(s) and files to off-site storage (e.g., cloud services, another server) as well as making a backup to your personal computer.
Secure all methods of transferring data between computers. For example, Legacy FTP uses un-encrypted transfer methods; therefore, use either SFTP (over SSH) or FTPS. Both SFTP and FTPS encrypt the transferred files as well as encrypt your login credentials. If you have servers that host websites or APIs, turn-on HTTPS/SSL encryption right away – even for internal applications. In addition to encrypting data, HTTPS/SSL encrypts the content of websites from being altered; thus, this type of encryption is particularly useful for administrator consoles. As additional security, you may want to consider encrypting entire directories or even full disk drives using LUKS.
As a final step in securing your VDS system, continually monitor your server. At least once per-week, review your server logs. Logs help identify potential unauthorized access to your server, such as multiple incorrect login attempts, and unusual traffic requests. You may want to set-up email notifications via your control panel or via cron jobs for severe errors or server failure. There are many third-party logging tools available to assist you in monitoring your server logs, including Zabbix, Prometheus with Alertmanager, or even a basic Logwatch, which provides a daily summary of errors. Additionally, you may want to periodically run tail -f /var/log/auth.log or dmesg to view your server’s logs.
