Server security in practice
Harden the server before something happens — simple practices for access, updates and backups
This section collects practical measures that protect a VPS or a dedicated server. We stick to what actually lowers risk: key-based SSH access instead of passwords, a configured firewall, timely updates of the OS and installed software, and above all regular backups with a restore procedure you have tested. The split of responsibility is simple: the facility, the network, the hypervisor and the panel are on us; everything inside the server, backups included, is on you, because the root account is yours. Below are the baseline practices worth applying in the first hour after launch.
Baseline practices
Protect access
Log in with SSH keys instead of passwords, change the default port, limit privileges and disable password login for root.
Updates and firewall
Regular OS and package updates, a configured firewall and closed unused ports — a smaller attack surface to begin with.
Backups you have tested
Regular copies of data plus a verified restore. We do not guarantee fault tolerance on a single machine, so backups are not optional.
What to do in the first hour after launch
Four actions that close off most routine attacks.
Create a user with sudo
Working as root all the time is an unnecessary risk: one mistyped command affects the whole system. Create a normal user and raise privileges only when needed.
Switch to SSH key login
Unlike a password, a key cannot be brute-forced. Verify that key login works, and only then disable password authentication — otherwise you risk locking yourself out.
Close everything but the working ports
A firewall such as ufw or iptables leaves SSH, HTTP and HTTPS open and closes the rest. Changing the default SSH port also removes most automated scanning noise.
Take the first backup
A copy is created in the control panel in a couple of clicks. Immediately check that a working system comes back from it: an untested backup is not a backup.
What is on us and what is on you
Better to know the boundary before an incident than after one.
You are: the root account is yours, and so is the installed software and its configuration. On our side are the facility, the network, the hypervisor and the control panel.
No. It is a separate paid option matched to the specific service and traffic profile, rather than something switched on for every plan at once.
No, backups are self-service: you take copies yourself in the panel in a couple of clicks, with nothing to configure.
It gives hardware-level access: get in when SSH is closed or the network is misconfigured, pull the data off and reinstall the system from a clean image.
A single server does not provide it. For such requirements we build a distributed fault-tolerant cluster across several data centres, so the failure of one node does not take the service down.
Plan the recovery, not just the defence
We do not give a formal SLA on a single machine, so keep current backups and check in advance that a working system restores from them. If a project needs high availability, we build a distributed cluster across several data centres.
DDoS protection is not part of the plans: it is a separate paid option we match to the project. Write to us and we will advise on access hardening and the protection options that fit.
Ask about protectionFrequently asked questions
Did not find your answer?
Write to us via the contact page form.
With access: switch to SSH key login, disable the password for root and close unused ports with a firewall. That is the baseline for any server.
You are. Automatic backups are not included in the plan — you take copies yourself in the control panel in a couple of clicks, with nothing to configure.
SSH keys are safer than passwords because they cannot be guessed by brute force. Use key login and turn off password authentication for root.
When the project has already been attacked, or it is a game server, an exchange or a large store. For an ordinary website a well-configured firewall is enough. Protection is connected separately, matched to the service and the budget.
Cut public access, log in through the KVM console (it works even when SSH is closed), take a copy for investigation and reinstall the system from a clean image. Rotate every key and password afterwards.
Yes. A configured firewall closes unused ports and restricts access to services, which noticeably reduces the attack surface.
Apply security updates for the OS and software promptly and regularly — vulnerabilities in outdated packages are a common route into a server.
We advise on basic access hardening and on DDoS protection options. Write to us via the form on the contact page.