VDS Security: SSH, Firewall, Updates and Backups Guide

Because a VDS service provides root or administrator access, it gives more freedom than web hosting plans. For the same reason, the security of the operating system, services and access policies is largely the responsibility of the server administrator. The following basic precautions should be applied when putting a new VDS into use.

What to do on day one

1. Update the operating system and installed packages.
2. Change the default administrator password.
3. Create only the user accounts that are needed.
4. Close unnecessary services and ports.
5. Check the time zone, NTP and log records.
6. Set up the backup plan before the application goes live.

Secure SSH access

On Linux servers, an SSH key should be used instead of a password where possible. Instead of a direct root session, an authorised user and, when needed, sudo can be preferred. If management access can be made from specific IP addresses, an IP restriction in the firewall gives additional protection.

Changing the SSH port can reduce automated scanning noise but is not a security measure on its own. The real protection is strong authentication, up-to-date software, limited access and monitoring failed logins.

How should the firewall be planned?

First, list the services that will actually be used on the server. Traffic other than the HTTP/HTTPS ports needed for the web server, SSH or RDP management and application-specific ports can be blocked by default. Database ports should only be opened to the application server if required; they should not be left open to the whole internet.

Updates and vulnerability management

The operating system, web server, PHP, database, control panel and application components should be updated regularly. Release notes should be read before updating, and a backup or rollback plan prepared for critical systems. Unused plugins and packages should be removed because they enlarge the attack surface.

User and file permissions

Each application should access only the files and services it needs. Giving broad write permission to all web files can let a vulnerability in one application spread to other sites. API keys and database passwords should not be left as plain-text files in the web root.

Log and resource monitoring

Failed logins, unexpected services, unusual CPU use, disk fullness and network traffic should be monitored regularly. The CPU, RAM, disk and traffic view in the FiberVM panel can be a first checkpoint. Application logs and operating system logs should also be kept to determine the cause of an incident.

A snapshot is not the same as a backup

A snapshot is useful for quick rollback but should not count as an independent backup on its own. Critical data should be kept on a different physical system or storage service. Backups should be encrypted, their retention period set and restores tested regularly.

When should you use the VNC console?

If SSH/RDP access is cut because of a firewall or network setting, you can reach the server's screen through the VNC console in FiberVM. The console is useful for fixing a wrong network setting; the session should not be left open after use.

Full management support

If you have no system administration experience, clarify the scope of support before exposing a production application directly to the internet. Operating system installation, basic service configuration, the control panel, migration, security hardening and monitoring needs should be determined before the project starts.

To plan a secure infrastructure you can review the Türkiye VDS options and use the VDS buying checklist.