InfrastructureNew: our VPS servers are live in the United States

Our New York datacenter is live. Our Morocco datacenter is coming soon: your data stays on US servers until launch, and is then migrated. Clients who need data sovereignty in their own country can request the migration. Learn more

InfrastructureNew: our VPS servers are live in the United States

Our New York datacenter is live. Our Morocco datacenter is coming soon: your data stays on US servers until launch, and is then migrated. Clients who need data sovereignty in their own country can request the migration. Learn more

Learn more
News

VPS Security Checklist: 12 Actions Before Going Live

Securing a VPS before going live: 12 concrete actions on SSH access, the firewall, updates, services, and backups.

Securing a VPS before going live: 12 concrete actions on SSH access, the firewall, updates, services, and backups.

As soon as a server receives its public IPv4 address, it becomes visible from the Internet, and therefore to automated scanners looking for weak access, outdated services, or open doors. VPS security is therefore not added after the fact: it is put in place in the first hour, before you even install your site or application.

This checklist brings together the twelve essential actions to complete before putting a VPS server online. They are grouped into three stages: secure access, reduce the network surface, then lock down applications and prepare for recovery.

Step 1: secure access to the server (actions 1 to 4)

1. Create an administrative user and disable direct root login. Work with an account that has sudo rights: logs become traceable and the most powerful account on the system is no longer exposed.

2. Switch to SSH key authentication. A public key is far harder to compromise than a password. Once the key has been tested, disable password authentication in the SSH configuration.

3. Restrict who can connect. If your IP address is static, limit SSH to that address in the firewall. Otherwise, choose long, unique passwords for each user.

4. Install an anti-brute-force tool (for example fail2ban): after several failed login attempts, the source address is blocked automatically for a set period.

Step 2: reduce the network surface (actions 5 to 8)

5. Update the system immediately. A freshly deployed server must receive the latest security patches in its very first session: system packages, kernel, repositories.

6. Enable the firewall and open only what is necessary. For a website, only ports 22 (SSH), 80 (HTTP), and 443 (HTTPS) are generally open. Everything else should be denied by default.

7. Close unnecessary services. Every open service is an attack surface: disable those your project does not use and check the list of listening ports.

8. Do not expose administrative services. Databases, monitoring interfaces, and management panels should listen on the local interface, not on the public address.

Step 3: lock down applications and prepare for recovery (actions 9 to 12)

9. Serve the site over HTTPS from go-live. A valid, automatically renewed certificate encrypts exchanges and prevents browser warnings that erode visitor trust.

10. Harden the database. A strong root password, dedicated application accounts with minimal privileges, access limited to the machine itself: three settings that limit the damage if an application is compromised.

11. Enable and verify automatic backups. At Open Vista, every VPS plan includes automatic backups: confirm they are active, add an offsite copy, and test a restore before you actually need one.

12. Schedule maintenance. Set a regular slot for updates and review the logs (logins, web server errors): security is a rhythm, not a one-off event.

After go-live: keep the rhythm

These twelve actions make up the initial upgrade, but a server evolves: new plugins, new PHP versions, new accounts. Build security into your working habits:

  • apply security updates as soon as they are published;
  • review user accounts whenever someone leaves or the team changes;
  • monitor login attempts in the logs;
  • test a restore after every structural change.

A well-maintained VPS remains a predictable environment, where an anomaly is noticed quickly. If any point in this checklist seems unclear, Open Vista's 24/7 French and English support can help: the company, based in Rabat, Morocco, also offers IT consulting for teams that want to delegate administration.

FAQ

Do you need to be an expert to apply this checklist?

The twelve actions rely on standard tools documented everywhere (SSH keys, firewall, fail2ban). Someone comfortable with the command line can complete them in one to two hours. For others, occasional support is often enough.

Will the firewall block my site?

No, provided you open ports 80 and 443 in addition to the SSH port before go-live. Test access to the site after each rule change: the firewall must be checked in both directions.

Why disable password authentication in SSH?

Passwords can be guessed, reused, and stolen. An SSH key, by contrast, cannot be subjected to repeated attempts: it is either present on the authorized machine or it is not.

How often should these actions be repeated?

The initial checklist is done once, but actions 5, 11, and 12 become a rhythm: updates at every release, backups checked regularly, logs reviewed at least weekly.

Conclusion: twelve actions, one hour, one habit

A VPS is a powerful tool, but powerful also means exposed: the twelve actions above reduce the attack surface, lock down access, and prepare recovery before the need arises. Carry them out within the first hour after deployment, then keep up the rhythm.

Open Vista's NVMe VPS plans each include a dedicated IPv4 address, a management panel, automatic backups, and 24/7 FR/EN support, from $9.99/month with no commitment. See the Open Vista VPS page and order at my.openvista.ma : deployment in under 15 minutes.

Open Vista

An infrastructure, cloud or cybersecurity project?

VPS, domain names, software licences, Odoo, Microsoft 365 or managed IT: our teams answer you from Laval (Quebec) and Rabat.

🔒 Data hosted in the United States (USA)