![[DoRoyal] Logo](https://cdn.doroyal.com/2026/08/DoRoyal_by_Sidular-1-scaled.png)
A new VPS can be online in minutes. That convenience is useful, but it also means a default installation can be exposed before your application, firewall rules, monitoring, and backup routine are ready. Server hardening is the work of reducing that unnecessary exposure so a compromised password, outdated package, or misconfigured service does not become a larger incident.
For a personal site or small business, the goal is not to turn a server into a complicated security project. It is to make practical choices that protect the services you actually run, preserve your ability to administer the machine, and keep maintenance realistic after launch.
What server hardening actually means
Server hardening is the process of securing an operating system, its accounts, network services, applications, and data by removing or restricting what is not needed. A default server is built to be flexible. A production server should be built to be specific.
That distinction matters. If the server only needs to run a website and a database, it should not expose unused management tools, open ports for services nobody uses, or allow direct administrative access from anywhere on the internet. Every enabled service, account, plugin, and package adds another thing that must be configured and maintained.
Hardening is also not a one-time checklist. Software changes, staff access changes, certificates expire, and new vulnerabilities are found. The initial configuration lowers the starting risk. A sensible maintenance routine keeps it that way.
Start with the hosting model you have
The right level of control depends on your hosting plan. On shared hosting or managed WordPress hosting, the provider handles much of the operating system and network layer. Your work is usually focused on strong account access, current themes and plugins, file permissions, backups, and application-level security.
An unmanaged VPS gives you far more control, and far more responsibility. You choose the firewall policy, SSH configuration, user accounts, update schedule, web server settings, and monitoring. That flexibility suits developers and experienced site owners, but it is not a reason to install every tool you might someday use.
Before changing anything, make sure you have a current backup and a tested way back into the server. A firewall rule or SSH change made too aggressively can lock out the administrator just as effectively as an attacker. Keep console access available through your hosting control panel whenever possible.
Secure administrative access first
Administrative access is the highest-value target on most servers. Start by creating a named, non-root user for routine administration. Grant elevated privileges only when needed through sudo, rather than working as root for every task. This gives you clearer logs and reduces the chance of an accidental destructive command.
SSH keys should replace password-based SSH login for administrators whenever practical. A key is harder to guess or reuse than a password, especially when the private key is protected by a passphrase. Once key-based access is tested from a second terminal session, disable SSH password authentication.
You should also prevent direct root login over SSH. On many Linux systems, these settings are managed in /etc/ssh/sshd_config:
text PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes
Test the configuration before restarting SSH. One typo in the wrong file can create an avoidable support issue. Leave the existing session open until you confirm that a new session can log in successfully.
For teams, avoid sharing one administrator account or one private key. Give each person a separate account and remove access when their role changes. Shared credentials are convenient right up to the point you need to know who changed a production setting.
Reduce what the server exposes
A firewall is not a replacement for secure software, but it is one of the simplest ways to narrow the attack surface. Start by identifying which ports the server must accept from the public internet. A typical web server needs ports 80 and 443. SSH on port 22 may be needed for administration, ideally limited to known IP addresses where that is practical.
Everything else should be denied by default unless there is a clear reason to expose it. Database ports such as 3306 should generally not be public if the database is used only by applications on the same server. Development dashboards, mail administration interfaces, and staging tools should receive the same scrutiny.
Changing SSH to a nonstandard port can reduce noisy automated scans, but it is not meaningful security by itself. Use it only as a minor operational measure, not as a substitute for key-based authentication, firewall rules, and timely updates.
Also review running services, not just firewall rules. On a Linux VPS, commands such as systemctl --type=service --state=running can show what is active. Disable services you do not recognize only after confirming their purpose. A package may be harmless, but an enabled network daemon deserves an explanation.
Keep the operating system and applications current
Many successful attacks do not require sophisticated techniques. They rely on known flaws in software that has not been patched. Enable security updates, then decide whether automatic installation fits your environment.
Automatic updates are often reasonable for a low-complexity VPS that runs a standard web stack. For an application with custom dependencies, scheduled maintenance may be safer because updates can occasionally affect compatibility. The trade-off is simple: manual patching gives more control, but only if someone reliably does it.
Use supported operating system releases. An old operating system that no longer receives security patches is a liability, even if the website appears to work normally. Apply the same rule to PHP versions, web server software, database engines, WordPress core, themes, plugins, and any control panel installed on the server.
Remove packages and applications that are no longer used. Old test sites, abandoned plugins, unused database tools, and forgotten subdomains are common weak points because they tend to miss the normal update cycle.
Configure the web stack for the site you run
The web server and application layer deserve the same attention as SSH. Use HTTPS for public websites, redirect HTTP traffic to HTTPS, and renew certificates before they expire. A valid certificate protects traffic in transit, but it does not secure an outdated application or weak administrator account.
Set file ownership and permissions carefully. Web processes need access to the files they serve and directories they write to, but broad permissions such as 777 are rarely the answer. If an upload directory needs write access, grant it narrowly. Configuration files containing database credentials should not be publicly readable.
For WordPress, remove inactive plugins and themes, not just deactivated ones. Keep a minimal plugin set, use unique administrator passwords, and limit administrator accounts to people who genuinely need them. If the site has a login page exposed to the public, rate limiting or a web application firewall can reduce automated password attempts.
Separate environments when possible. A staging site should not use live customer data unless that data has been handled appropriately. Development tools and debug settings should not remain enabled on a production site simply because they were useful during setup.
Backups, logs, and recovery are part of hardening
A hardened server can still fail. Hardware issues, faulty updates, accidental deletions, and application errors do not ask whether your firewall is configured correctly. Backups are what turn many of those events from a crisis into a recovery task.
Keep backups separate from the server being protected. A backup stored only on the same VPS may be lost during a full server compromise or account-level failure. Use an automated schedule that matches the rate at which the site changes, and retain enough restore points to catch problems discovered late.
More importantly, test a restore. Confirm that you can recover both the website files and its database, and that the restored site works. A backup report that says “successful” is useful, but a successful test restore is better evidence.
Logs help answer a different question: what happened? Review authentication logs, web server error logs, and application logs often enough to notice repeated login attempts, unusual traffic patterns, or errors after an update. Lightweight monitoring for uptime, disk space, memory use, and certificate expiration is usually worth setting up before the server is under pressure.
Build a maintenance routine you can keep
The strongest hardening plan is one that fits the people responsible for the server. A small business with no dedicated administrator may be better served by managed hosting than by an unmanaged VPS that receives attention only when something breaks. There is no prize for owning more infrastructure than you can maintain.
For a VPS, set a recurring schedule to review pending updates, backup status, disk space, user accounts, firewall rules, and active services. After major application changes, check that permissions, HTTPS redirects, and scheduled backups still work as expected. Document the basics: where backups are stored, who has access, how to reach console recovery, and what services are supposed to be running.
DoRoyal customers using unmanaged VPS hosting can apply these controls gradually rather than changing every setting at once. Start with administrative access, firewall policy, updates, and backups. Those four areas address a large share of preventable problems without making day-to-day hosting harder than it needs to be.
Security work is never fully finished, but it should become routine. When a server has only the access, software, and services it needs, maintaining it becomes clearer, faster, and far less stressful when something unexpected happens.
