Hardening pass · Intermediate · an hour, surface counted
How to secure a new VPS — Count the Listening Sockets, Then Make That Number Smaller
The server has been online for an hour and something is already trying passwords against it, and you have no list of what else is answering out there.
The short answer
Start by enumerating what is listening, because that list is your attack surface expressed as a number. ss -tulpn prints every socket bound on the machine with the process behind it, and on a fresh image it is almost always longer than you expect. Everything else in this runbook exists to shorten that list or to protect the entries you cannot remove.
Then the standard four, in order: patch everything before installing anything, create an ordinary user with sudo, lock SSH to keys with root login disabled, and put a default-deny firewall in front of what remains. The one people miss is a database bound to every interface, which is how a VPS ends up mining somebody else's coins.
By the HostingFast team · Reviewed 24 August 2026
Intermediate
Reader level
5
Stages to work through
Free
Cost of asking
Proven
Proven on our own hardware
An hour, on a machine that has not yet done anything important. Every step here is easier before your application is on it, and the snapshot at the end is what saves you repeating the hour from memory later.
Keep one figure in view: the number of sockets listening on a public interface. It should end this hour as a short list you can read aloud — SSH, and whatever the server genuinely serves.
Enumerate the surface before you defend it
ss -tulpn lists every listening socket with its address, port and owning process. Read the address column carefully: 0.0.0.0 or :: means the service is reachable from the internet, while 127.0.0.1 means it is only reachable from the machine itself. That column, not the port number, is what decides whether something is exposed.
A default image typically has more answering than the job requires. Anything you cannot name a reason for either gets removed, gets bound to localhost, or gets an explicit firewall rule with a source address on it. Write the surviving list down; it is the thing you will compare against in six months.
Patch first, then keep patching without you
A fresh image is only as current as the day it was built, and known holes in stale packages are exactly what automated scanning looks for. Run the full update before installing anything else, and check afterwards whether a reboot is pending — a kernel update that has not been rebooted into is a patch you have downloaded rather than applied.
Then automate it. Unattended security upgrades keep patches landing while you are busy with something else, which matters far more on a machine nobody logs into weekly. Pair it with a reboot policy you have actually decided on rather than one you keep postponing.
An ordinary user, and SSH reduced to keys
Working as root turns every typo into an incident. Create a normal account, grant it sudo, move your SSH key across, and keep root for the moments that genuinely need it. The habit costs nothing and it converts a category of catastrophic mistakes into a permission error.
Then reduce SSH to keys only with root login disabled and password authentication off. Do it with a second terminal open and the key already proven. fail2ban on top bans the addresses that keep guessing; its real benefit is a log you can still read, because an unprotected server's auth log is unreadable within a day.
Bind services inward, then snapshot the clean machine
MySQL or PostgreSQL listening on 0.0.0.0 behind a weak password is the single most common way a VPS is lost. Bind it to localhost unless a remote host genuinely needs it, and if one does, restrict the firewall rule to that specific source address rather than opening the port to the internet. The firewall and the bind address should agree with each other.
Finish with a snapshot. A hardened machine with no application on it is a known-good starting point you can return to, and it costs far less than reconstructing this hour from memory in six months. On our own shared platform this whole layer is managed for you, with DDoS filtering absorbed at the network edge before traffic reaches the account.
What you do not have to harden here
On the shared and reseller platform this entire layer is somebody else's job: patching, account isolation, hardened defaults and DDoS filtering absorbed at the network edge. A VPS is worth taking on when you need root and your own services, not because you want to spend an hour a month on package updates.
The rate you sign up at is the rate you renew at, so year two costs exactly what year one did.
- DDoS filtering absorbed at the network edge
- Imunify360, account isolation and hardened defaults on shared plans
- KVM virtual servers with root access when you want the whole box
- Engineers on shift at whatever hour something starts knocking
Why HostingFast
Standard on every plan
Surface as a number
One command turns 'is it secure' into a list of listening sockets you can shorten and then re-check later.
The address column read properly
0.0.0.0 versus 127.0.0.1 is what decides exposure, and this page makes that the thing you look at rather than the port.
Patching that continues without you
Unattended upgrades plus a decided reboot policy, because the machine nobody logs into is the one that goes stale.
Root demoted
An ordinary sudo account converts a class of catastrophic typos into an ordinary permission error.
The database trap named
A database bound to every interface is the most common way a VPS is lost, and the firewall has to agree with the bind address.
A clean image to return to
The snapshot at the end is what stops you reconstructing this hour from memory when something goes wrong later.
Quick Start
From order to online
- 1
List what is listening
ss -tulpn, and read the address column. Anything on 0.0.0.0 you cannot justify gets removed, bound to localhost, or given a source-scoped firewall rule.
- 2
Patch fully, then automate it
Full update before installing anything, check for a pending reboot, then enable unattended security upgrades so it continues without you.
- 3
Create a sudo user and move your key
Daily work stops happening as root. Copy your SSH key to the new account and confirm it works before you change any SSH settings.
- 4
Reduce SSH and add fail2ban
Keys only, root login disabled, passwords off — with a second terminal open. fail2ban then bans the persistent guessers and gives you back a readable auth log.
- 5
Bind inward, firewall, snapshot
Databases on localhost, default-deny inbound with a short allow list, then take a snapshot of the hardened machine before your application lands on it.
Built In
Loaded onto every plan
- DDoS filtering absorbed out at the network edge
- SSH, Git and Composer on the developer-focused plans
- Daily backups on every plan, with restores you run yourself from the panel
- NVMe SSD storage on every tier, including the entry plan
- 99.9% uptime as the target, monitored around the clock
- cPanel — the control panel most of the industry already runs
- Per-site PHP version switching from the control panel
- A renewal price identical to the one you signed up at
- Zero setup charges — there is no joining fee, ever
- Human support on duty every hour of every day
Frequently Asked
What people ask us most often
What should ss -tulpn show on a plain web server?
Very little: SSH on its port, the web server on 80 and 443, and anything else bound to 127.0.0.1 rather than 0.0.0.0. If a database, a cache or a mail service is listening on a public address, that is your next job. Read the address column rather than the port — that is the field that decides whether the internet can reach it.
Does fail2ban reduce load, or just log noise?
Mostly log noise, and that is more valuable than it sounds. Password guessing against SSH starts within hours of a server appearing online and it makes the auth log unreadable, which means you stop reading it and miss the entry that mattered. Banning repeat offenders keeps the log short enough to actually review.
How do I tell whether a reboot is pending after updates?
Most distributions leave a marker — a reboot-required file, or a notice printed at login — and your package tooling will report it. It matters because a kernel update you have downloaded but not rebooted into is a patch you have not applied. Decide a reboot policy up front rather than postponing the question every week.
Is automatic patching safe to leave on in production?
For security updates, generally yes, and it is safer than the realistic alternative of nobody applying them for months. Restrict it to the security repository rather than all updates, and keep a snapshot and a recent backup so an unlucky package is a rollback rather than an incident. A machine nobody logs into is exactly the machine that needs it.
Keep reading
How to Add Google Analytics
Install the tag once, prove it fires once, gate it behind consent, then measure its cost — beginner, roughly 30 minutes.
How to Connect With FTP and FileZilla
Move files in volume over an encrypted connection, with the settings that stop transfers stalling — beginner, roughly 15 minutes.
Best Most Secure Shared Hosting
Weighed up properly, with a verdict at the end rather than a table of ticks.
VPS Hosting
KVM virtual servers with root access, DDoS filtering and one flat monthly price.
Reseller Hosting
White-label WHM hosting — your brand at the front, monthly billing behind it.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Or let us keep the surface small.
Imunify360, account isolation, hardened defaults and DDoS filtering at the edge — with root-access KVM servers there when you want the whole box.
View VPS Hosting plans