How to Secure a VPS: Access, Updates and Recovery

Secure a VPS by controlling who can log in, keeping software supported, limiting exposed services and making recovery possible. Each change needs a check: an SSH restriction should still let an authorised administrator connect, and a backup should restore the service you depend on.

This guide explains how those controls fit together. It focuses on a self-managed Linux VPS, where you administer the guest operating system and applications. Virtarix provides full root access on Linux VPS plans; account security, updates, firewall rules, monitoring and recovery remain your responsibility.

Start with the workload and its risks

List the services you plan to run, the data they hold and who needs access. Include background jobs, deployment tools, third-party integrations and the credentials they use. A public website, an internal database and a build worker have different exposure requirements.

Consider how each could fail or be abused. Common paths include stolen keys, vulnerable applications, exposed databases, leaked deployment credentials and an operator deleting the wrong data. Record how much downtime and data loss the service can tolerate.

Before changing the server, collect a baseline:

• Listening ports and the process behind each one.
• Administrators, service accounts, automation identities and credential owners.
• Installed software, available patches and release support status.
• Host firewall rules and any separate provider firewall rules.
• Backup locations, retention and the last successful restore test.
• A tested way to regain access if the primary login stops working.

Use the provider's terms to establish its responsibilities. Do not assume that infrastructure support also covers the software you install inside the VPS.

Keep the operating system and applications updated

Patch every relevant layer: the operating system, kernel, SSH server, web server, database, control panel, container runtime and application dependencies. Updating one layer does not fix vulnerabilities in another.

Review the proposed updates before applying them. Authentication changes, database migrations and altered configuration syntax may need preparation. Save relevant configuration, back up the data and identify how you would recover from a failed update. Schedule downtime if a service restart or reboot is necessary.

Afterwards, check the running versions and exercise the application. A package manager can finish successfully while an old process continues running or a service fails to restart.

Automatic security updates can reduce delays. Enable them with a clear policy for restarts, compatibility failures and alerts so a failed update is noticed and recoverable.

Give each administrator a named account

Use an individual account for each person and grant only the privileges their work requires. Use sudo for controlled elevation, with appropriate logging, instead of sharing a root login. Service accounts should have limited access to application files and should not support interactive login unless it is needed.

Assign separate SSH keys to people and automation. Protect private keys with suitable permissions and, where practical, a passphrase. Record each authorised key's owner and removal procedure. Do not share private keys between administrators or embed long-lived keys in an image.

Before disabling root or password login, open a second session with the replacement account. Confirm that its key works, that it can perform the required privileged tasks, and that you can use the recovery route. Keep the original session open until those checks pass.

Restrict remote administration

Limit SSH access to trusted sources where practical. A VPN, bastion or source-address rule can reduce exposure. Account for administrators whose addresses change so an ordinary connection change does not force an emergency public allowlist.

After testing the alternative login, disable direct root SSH and password authentication where they are unnecessary. Validate the SSH configuration before reloading it, then test another new connection before closing the working session.

Moving SSH to a different port can reduce scan noise. Keys, restricted access, patching and monitoring still provide the security controls that matter.

Apply the same review to control panels, database tools and container dashboards. A login page alone is not a reason to expose an administrative interface to the Internet.

Allow only required network traffic

Build firewall rules from the services that must be reachable. For each exception, record the protocol, port, permitted sources and purpose. Deny other unsolicited inbound traffic while preserving established connections and necessary outbound access.

A host firewall controls traffic near the workload. A provider firewall, where available for the selected service, is a separate layer. Keep both configurations understandable; a connection may be blocked by either, and their rules do not necessarily synchronise.

When changing access remotely, add and verify the required SSH allowance before removing an old rule. Keep a working administrative session open. Test public services from an external client and confirm that a port intended to be closed is unreachable.

Check container-published ports separately. Container networking can use forwarding rules that behave differently from ordinary host input rules. Verify IPv6 as well as IPv4.

Remove services you do not use

Inspect TCP and UDP listeners, including container port mappings. Map each one to its process, package, configuration and owner. Uninstall software that is no longer needed, or disable its service if the package must remain.

Bind internal services to loopback or an appropriate private interface. Verify the actual listener address: restricting IPv4 does not establish that a service is also restricted on IPv6.

Check startup behaviour after the cleanup. A service that is stopped but still enabled can return on reboot. During an appropriate maintenance window, test startup and compare the resulting listeners with your intended exposure list.

Secure the applications as well as the host

Use supported application versions, remove default accounts and sample installations, and follow each application's permission model. Public applications should normally run under unprivileged service accounts. Separate writable uploads and data from deployable code where the application supports it.

Keep databases, caches, metrics endpoints and job dashboards private unless they have a justified public use. Require authentication, restrict sources and encrypt traffic across untrusted networks. Private addressing alone is not authentication.

For a web application, check its virtual host, certificates, access controls, upload handling and relevant security headers. Confirm that directory listings and sensitive files such as .env are not publicly accessible. Host hardening cannot compensate for an application authorisation flaw or a vulnerable plugin.

Back up the service and test restoration

Identify everything needed to rebuild: databases, persistent files, deployment definitions, service configuration, firewall policy, scheduled jobs and external dependencies. A copy of the running disk may miss application consistency or the credentials needed to restore it.

Every Virtarix VPS/VDS includes one snapshot. That snapshot does not replace independent backups. Keep a recovery copy outside the server's failure domain, restrict access, use encryption where appropriate and document retention.

Restore into an isolated location. Verify data integrity, application startup and access to required integrations. Include DNS or routing changes in the recovery procedure and measure how long restoration takes. Fix the procedure if the result misses the service's recovery needs.

Monitor access, health and recovery jobs

Collect the logs needed to understand authentication, privilege changes, firewall activity, services, applications and backups. Synchronise clocks so events can be compared. Restrict access to logs and avoid recording secrets.

Alert on events that need action: unexpected privileged accounts or keys, new listeners, repeated authentication failures, resource exhaustion, certificate expiry, backup failures and missing log delivery. Use observed behaviour to tune thresholds and reduce noise.

Send important alerts somewhere that remains available when the VPS fails. Monitoring only from inside the same server cannot detect every outage. Use an external check for important public routes and test that alerts reach the responsible person.

Use rate limits where they help

Rate limits and temporary bans reduce repeated automated attempts. They work alongside strong authentication and restricted exposure. Apply them to expensive or sensitive application actions as well as login attempts where appropriate.

Fail2Ban can help when its jail matches the service's real log format and can act on the correct client address. Behind a proxy, confirm that a ban will target the client rather than a shared gateway. Review ban duration, false positives and how a legitimate user regains access.

Keep a recovery path outside the same ban mechanism. Test an abusive sequence and a legitimate connection after the limit expires; a configured jail is not proof that either path works.

Track and rotate credentials

Keep secrets out of source control, images, shell history, public command output and support tickets. Give applications and integrations their own credentials with the minimum necessary scope. Separate development credentials from production ones.

Maintain a register of owners, purposes, storage locations, consumers and revocation procedures. The register should point to protected storage rather than contain secret values.

Rotate credentials after suspected exposure or a relevant staff, vendor or dependency change, and on a schedule where required. Update every consumer, verify application health and revoke the old credential. Confirm that the retired credential can no longer authenticate; distributing a replacement alone does not finish the job.

Prepare for lost access or compromise

Document how an authorised responder can recover access when a key is lost, an SSH rule is wrong or the main administrator is unavailable. Check the provider's actual recovery options instead of assuming a particular console is available. Protect emergency access separately from everyday credentials.

If compromise is suspected, preserve useful evidence, contain the incident where safe and rotate affected credentials from a trusted system. Decide whether the host can still be trusted or needs rebuilding from known-good software. Restoring a compromised image may also restore the attacker's access.

Practise the response. Confirm who can declare an incident, who controls DNS, where clean deployment files and independent backups live, and which checks must pass before traffic returns.

Turn the guide into a recurring review

Use the 15-step VPS security checklist for an ordered review of these controls. Run it after provisioning, significant access or network changes, and an incident, as well as on a regular schedule.

Record the owner, result and evidence for each check, with any unresolved issue and its next review date. That record makes the next review useful and gives another operator a clear starting point.