Virtual Private Servers (VPS) have seen a surge in popularity among the general public following the widespread adoption of AI. Indeed, developing solutions and applications has become much more accessible than before. VPSs are then used to publish applications and make them available to the public.
However, while we can point out vulnerabilities in some applications developed with artificial intelligence, we often forget that the server hosting them must be configured to secure the infrastructure. This becomes more complicated since a VPS is accessible by default to the entire internet.
Change the administrator password
When you order a new VPS, an email is usually sent once the deployment is complete, not only to notify you but also to provide a randomly generated password. If this is the case, it is important to change the password upon your first login.
The reason is that if you leave the provided password and your email account is compromised, the attackers will have your administrator account password. Generally speaking, when a password is transmitted via email or any other medium, it should be assumed that it is automatically compromised.
Furthermore, it is advisable to change your password frequently (1 to 4 times a year; you determine the criticality of each account), and to avoid using the same password for all your accounts. A password manager such as KeePass is recommended to maintain a complete inventory and to use complex passwords without having to memorize them all.
Limit the number of allowed IP addresses
By default, anyone on the internet can connect to your new VPS. If you have static IP addresses (assigned by your internet service provider and which will not change), you can set up IP-based filtering. This is intended to restrict access for certain services, such as SSH or RDP.
To do this, you can configure the server's firewall directly by creating rules that will be loaded when the server starts. Additionally, if your application needs to be accessible only from specific IP addresses, you can also filter the network ports used.
If you don't have a static IP address, you can restrict access to IP addresses from your country. To do this, you'll need to use a GeoIP service that integrates with your server's firewall. Currently, I haven't tested any such service because my servers are always protected by a front-end firewall that includes GeoIP. However, a search on your preferred search engine should provide the information you need.
Prefer the key-based connection
Password-protected SSH login is convenient for connecting from any machine, provided the password and login are known. However, a password can be brute-forced if the login is known.
A secure way to connect is by using public key authentication. The principle is that the public key is stored on the server and allows the connection to be validated as legitimate. This requires creating a private key for each workstation used and preparing the connection before logging in.
Define an administrative user
When you want to configure and perform maintenance operations, it is strongly recommended to create a dedicated user. This means that the root or administrator account should not be used to perform these tasks.
You can use the same account on all servers, but remember to choose a different password for each account (in case you log in with a password).
Segment the rights
This paragraph is somewhat related to the previous one. Ensure that your administrator account does not have access to the application's data or the application itself. This will limit the risk of data leaks and ensure that permissions are correctly configured.
Therefore, the user running the application service does not (in principle) need administrator rights to run the application. They only need access to the folders and/or services necessary for its proper functioning.
This best practice helps protect against the application if it has a vulnerability, and attackers try to take control of the server via the application, or simply destroy it by deleting system and application files and folders.
Monitor and back up the server
An unavailable application, or an error message following a user interaction or outage, reflects poorly on the service provided. Therefore, it is advisable to monitor and back up the service regularly.
Several monitoring services are available to alert you in case of a system failure. If you have the option to install one, you can consider PRTG, as it is user-friendly and intuitive. Furthermore, it's free for up to 100 monitoring points.
If you like to configure specific settings, or want to delve deeper into the behavior of alerts that are raised, I can recommend Zabbix, which is open source and free.
Regarding backups, it is advisable to have them and, above all, to verify that they are restoreable. It is always possible that the server storage could become corrupted, and that you could lose all your data and the entire service. To avoid starting from scratch, backups are strongly recommended.
You can either back up at the application level using scripts (depending on your application's architecture), or the entire server. It's up to you to define the most viable strategy.
Check the packages used
Applications often use third-party libraries. I understand this can be complicated to verify, but I advise you to check if the libraries used are not only reliable but also come from a known and official repository.
A corrupted library could lead to a backdoor that attackers can exploit. They can log in without knowing the administrator login and password. Worse, they can take control of the server and use it in massive DDoS attacks, or even host unwanted content.
Just like installing applications on your workstation, pay attention to the dependencies used, and make sure they are reliable.
Keep the server up to date
Finally, the last point I advise you to pay attention to is keeping your server and application up to date. Vulnerabilities and bugs are discovered in services, and updates allow you to fix these problems before they get worse.
Server updates can be done with a few commands or clicks, but they shouldn't be neglected. For application updates, remember to test in a development/validation environment (locally on your computer, for example) before pushing the updates to production.
A library in conflict with another, or a function that disappears following an update, can cause a service interruption, and a significant loss of revenue and reputation.
Conclusion
We've covered some general points, but there are other approaches depending on your architecture and expertise. Never forget that a server/service exposed to the internet without protection will be attacked or hijacked. It's only a matter of time before 2026.
