On this page
What server security means in practice
Every server connected to the internet is probed within minutes of going live. Bots try common usernames over SSH, look for open database ports and check for software with known vulnerabilities. Server security is the work of making sure those probes find nothing useful: only the services that need to be reachable are reachable, only the people who need access have it, and the software that is running is kept up to date.
We work mainly with Linux servers — Ubuntu, Debian and similar distributions — on VPS providers, dedicated hardware and cloud platforms. The approach is defensive and documented: every change is recorded so the server can be rebuilt the same way, and so the next person who looks after it understands why it is set up as it is.
Who needs it, and the warning signs
If you run your own VPS or dedicated server, this applies to you. It is especially relevant for an e-commerce store that moved off shared hosting, a SaaS startup running its application and database on one or two machines, a manufacturer hosting an ERP or internal portal, or an agency hosting several client sites on a single box.
- Everyone logs in as root, or with the same shared password.
- SSH accepts password logins from anywhere on the internet.
- Database, cache or admin ports are open to the public.
- The operating system has not been updated in a long time, or nobody knows how.
- A developer who set the server up has left, and their access was never removed.
What’s included
- Access — individual user accounts, SSH key authentication, password login and direct root login disabled, and sudo rules reviewed so each person has only the rights they need.
- Services — an inventory of everything listening on the network, with unnecessary daemons removed or bound to localhost.
- Patching — operating system and package updates applied, with automatic security updates configured where appropriate.
- Brute-force protection — tools such as fail2ban to block repeated failed logins.
- Host firewall — a default-deny policy that allows only the ports your applications need.
- Logging — authentication and system logs retained and rotated so incidents can be investigated.
- Documentation — a written record of the hardened configuration and any exceptions.
How we deliver it
- Confirm authorisation and scope — which servers, and who needs to keep access during the work.
- Snapshot or back up the server so any change can be rolled back.
- Audit the current state: users, keys, open ports, running services, package versions and configuration.
- Plan changes and agree any that could affect running applications, such as closing a port another system relies on.
- Apply and test in small steps, keeping a working session open so nobody gets locked out.
- Hand over the documentation and a short list of anything that needs ongoing attention.
When something has to stay open
Real businesses have constraints. A payment provider may need to reach a webhook endpoint, a remote office may need database access, or legacy software may need an old protocol. Where something must stay open for business reasons, we make the compensating controls explicit — for example, restricting access to specific IP addresses, putting the service behind a VPN, or adding extra monitoring — and record the decision so it is revisited rather than forgotten.
What affects timeline and cost
- How many servers are in scope and whether they share a common setup.
- How much is running on each one — a single-purpose web server is simpler than a machine hosting mail, databases and several applications.
- The state of the operating system: a supported release is quicker to harden than one that needs an upgrade first.
- Whether downtime windows are available for changes that need a restart.
Common mistakes
- Changing the SSH port and treating it as security, while password login stays enabled.
- Running two web servers that fight over the same ports after an update, taking every site down.
- Leaving database admin tools publicly reachable.
- Hardening once and never reviewing again, so new services and users quietly undo the work.
Frequently asked questions
Will hardening break my applications?
We plan changes around what your applications need and test each step, keeping a rollback option available. Anything that could affect a running service is agreed with you first.
Which operating systems do you support?
Mainly Linux distributions such as Ubuntu and Debian, on VPS, dedicated and cloud servers. If you run something else, ask and we’ll tell you honestly whether it’s a fit.
Do you need root access?
Yes, administrative access is needed to change system configuration. We use an individual account for our own work, and you can remove it once the engagement ends.
Can you secure a server that is already running live sites?
Yes, that is the usual situation. We work in small, reversible steps, schedule anything that needs a restart, and keep an open session during changes so access is never lost.
How often should server security be reviewed?
Patching should be continuous, and a broader review makes sense whenever staff change, new services are added, or at a regular interval agreed with you.
Talk to us about server security
Hardened configuration, least-privilege access and services kept patched.