If you are using WordPress, this article Is just for you, as it focuses on security tips for VPS after WordPress migration from shared hosting. But if you are not using WordPress and have nothing to do with migration, that’s totally fine. All the tips explained there are pretty universal, and I guarantee that it will be useful for you if you are using a virtual private server.
Upgrading yourself from shared hosting to VPS might be a wise choice. There might be different reasons for this. Maybe you have a few personal websites on the shared hosting and you have decided that it is time for you to upgrade to VPS. Or maybe you want to take everything seriously from the beginning, and use a powerful server for your new project.
If you are searching for a migration guide, most of the hosting providers already have comprehensive tutorials that covers how you migrate to VPS from shared hosting (example), so this article will not be about it. It will rather explain to you how to keep your VPS safe after migration from shared hosting.
Shared hosting vs VPS from a security perspective
From a security perspective, there might be some risks related to Virtual Private Servers. For example, in case of misconfiguration, your server might be vulnerable. But this highly depends on the skills and attentiveness of you or someone who configures the server for you.
With shared hosting, however, you do not have to think about the servers’ security, as the hosting provider takes care of it. On the other hand, there are also security risks related to shared hosting, and it is out of the control of the customer of such hosting type. As there are many isolated websites on the shared hosting, owners of other websites might exploit existing vulnerabilities and get access to your part of the server.
There is a chance that your WordPress installation will be less secure if you are using VPS.
And the reason for this is simple – hosting provider configures everything for you, if you are using shared hosting. Magic happens behind the curtains: installation is made, file permissions are set, etc. Usually, installing WordPress is just a matter of click.
But with the VPS you have to take care of everything by yourself: database, web server and service installations, configuration, permissions, server monitoring, backups, etc. There is more space to make mistakes.
But the great news is that it’s not that hard, if you are following the most common security tips for VPS.
Security Tips for VPS (and OpenLiteSpeed security hardening)
Before diving into the details of the VPS security hardening, it is worth mentioning what technologies were used for illustrating the security tips for VPS:
- CentOS 7
- OpenLiteSpeed webserver
But do not worry, advises covered in the tutorial are universal. Even though we talk about OpenLiteSpeed security, concepts are the same for Apache or Nginx.
For the completeness of this tutorial, we will cover not only the VPS, but also the OpenLiteSpeed webserver security. And, as the topic of the article is security tips for VPS after WordPress migration, a few WP specific things will be mentioned, such as file permissions or MySQL security.
Tip no. 1: delete all unnecessary packages
While you might think that one or another unused package on your operating system won’t hurt, keep in mind that even sudo vulnerabilities are found once in a while. That one package that remains completely unused might become vulnerable over time. While this can be solved while keeping everything up-to-date, keep in mind that the more applications are installed, the bigger is the attack surface.
After you’ve done all the initial configuration, make sure you delete the unnecessary packages, and applications.
Also, keep in mind that the VPS provider might already had installed some applications for you. Make sure there is no unneeded ones. For example, there might be Apache server installed. If you’ve decided to use Nginx, or OpenLiteSpeed, present Apache is totally unnecessary.
Tip no 2: create dedicated service users (for application, webserver, and for the database), make sure correct file owners and permissions are set
A good practice would be to run the webserver as an unprivileged user. If you will use a user that has shell access, this might create additional risk. For example, you might use nobody as a user and group.
And for the application folders, you should have a dedicated user. and group. It can be created pretty easily:
And for the user:
useradd -M -g group-name user-name
What is very important is that you should set the ownership and permissions properly:
chown user-name:group-name /home/domain.com chmod 711 /home/domain.com chown user-name:nobody /home/domain.com/public_html chmod 750 /home/domain.com/public_html
And if we are talking about the user who should be the WordPress files’ owner, there should be a dedicated one. For example, if you were following the OLS (Open Lite Speed) configuration, at some point you will have to set a specific user and group that the application will run as. You will have to set in the settings page that you can find on Virtual Host > Virtual host’s name > External App
Tip no 3: restrict external traffic to the webserver’s dashboard
If you are using OpenLiteSpeed, you probably know that the dashboard is accessible by the port 7080. Even though any changes are guarded by the authentication, everyone can still see the login screen. And with this, there are two problems: attackers might exploit 0-day vulnerability and gain access to your account. However, the probability of this is pretty low. But another risk, that is more real, is that external actors will try to brute force your password. And if you are using an easy one, they might get lucky.
One of the most common security tips for VPS is to use the iptables, Linux firewall, and to block external access to the resources that should not be visible to anyone. If you are using a Linux distribution, such as CentOS, for the VPS, it will have the iptables. So, if you are willing to make the dashboard invisible to everyone except you, you should firstly whitelist your own IP:
iptables -A INPUT -p tcp --destination-port 7080 --src 220.127.116.11 -j ACCEPT
Instead of the 18.104.22.168 use your own IP. If you want it to be accessible by other IPs feel free to repeat this configuration command with the IPs you want to be whitelsited. Keep in mind that the LiteSpeed server uses port 7080 for its dashboard, so this rule affects only this port.
NOTE: if you do not have a static IP, do not do this, or you will not be able to access the dashboard when you will get another IP.
And when you have whitelisted your own IP address, you can block access for everyone else:
iptables -A INPUT -p tcp --destination-port 7080 -j DROP
With the command iptables -L you will be able to see the rules you made:
Tip no. 4: restrict external access to the MySQL database
If you are running MySQL on the same server, there is no need for it to be accessible from external addresses. Make sure that the WordPress has the DB_HOST set to localhost, and if you have no particular reason for keeping it accessible, restrict external access. You can do so by editing my.cnf file with any text editor:
sudo nano /etc/my.cnf
Restrict remote MySQL connection by adding skip-networking line at the beginning of a file:
That’s it, after a restart, MySQL server will only be accessible from a localhost.
Tip no. 5: use TLS
Every publicly accessible website must have TLS. Even a self-signed one is better than nothing. If you have your WordPress running on the OpenLiteSpeed web server, you can easily enforce the TLS.
Tip no. 6: use strong SSH root password
It is very important to use a complex password for SSH access. Public servers constantly are bombarded with login attempts. If you are using an easy password that can be found on password dictionaries, you are leaving a low hanging fruit for intruders. If you think no one will try login to your server, this is how many failed login attempts a new VPS received over the 3 days. And this server is not even hosting anything, so this was not a targeted attack, rather a blind attempt to compromise as many servers as possible.
Tip no. 7: use Fail2ban
Fail2ban is a necessary service in order to prevent brute force attacks on the SSH. If you are using CentOS, it can be installed pretty easily. Add the EPEL packages repository:
sudo yum install epel-release
sudo yum install fail2ban
sudo systemctl enable fail2ban
And now you are ready for making simple filters. You can create a simple one:
sudo nano /etc/fail2ban/jail.local
That bans hosts that makes an incorrect login to the SSH, for an hour. It automatically creates entries in iptables entries.
[DEFAULT] # Ban hosts for one hour: bantime = 3600 # Override /etc/fail2ban/jail.d/00-firewalld.conf: banaction = iptables-multiport [sshd] enabled = true
Additionally to the fail2ban on your server, you should use a WordPress plugin that provides the fail to ban functionality in the application layer. It will prevent brute force attacks of the wp-admin page.
Is VPS hosting faster than shared?
There is a reason why people use VPS. While there are different benefits, such as total control of the server, many people migrate to VPS from the shared hosting for the performance reasons. But does the migration always result in improved performance?
While logically thinking VPS should be faster than shared hosting, this is not always the case. We can answer to this question from different angles.
First of all, there might be many, possibly even 100s of websites on the same server. And if one website starts exhausting resources, other websites’ performance will suffer from this. For example, I had made a reverse IP lookup with an online tool to check how many websites are on the same shared hosting, that my website is.
On the other hand, if the plan of your hosting provider offers a specific number of resources (ex. 1 GB RAM and 1 CPU core), it might even be faster than a cheap VPS from another hosting provider. But in reality, not everything is so great, these resources might not be guaranteed for you on the shared hosting.
And of course, a lot depends on the server configuration. The webserver of shared hosting might have caching, or other performance features enabled, host OS is also a determinator. So, VPS does not guarantee performance by itself and it is hard to tell if VPS is better than shared hosting in terms of performance. But of course, there are other reasons why should you use VPS.
And for the final words, there are a few things that should be stressed out:
- If you use VPS, make sure you do not leave any critical security mistakes while configuring.
- Before migrating to VPS, decide if you have enough technical knowledge, if no, find someone who does.
- Before pointing DNS to your new server, make sure that everything works properly. Consider if you are willing to have any downtime during the migration. If everything is fine, you will have no downtime. But if something will go wrong, users might bounce into “Error establishing database connection” page, and for the end user it’s the same as getting error 500. They will not be able to use the website.
Highly passionate about cyber security (penetration testing, bug bounty hunting, cybersecurity in general), and blogging. I am experienced in vulnerability assessments, penetration testing, various security audits, had worked with various clients, most of them were in finance sector. Currently holder of CompTIA Security+, CEH, CEH Practical, and CEH Master certificates.