Deutsch
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.
