The First Two Days Of A Brand New Server
Nobody knows the machine exists, and it still gets tried thousands of times before the second morning. The address was allocated, the scanners noticed, and everything below arrived without a domain pointed at it or a single link anywhere.
The Address Gets Found On Its Own
Whole ranges are scanned continuously, so a new address is discovered as soon as it starts answering. The first connections are just probes checking which ports respond, and they arrive long before you have finished setting up the machine.
Login Attempts Start On The Usual Names
Root, admin, ubuntu, test, git, postgres, and the name of whatever software the machine looks like it might run. Password after password, from a lot of different addresses so no single one gets noticed. If password login is switched on, this is the queue waiting to find a weak one.
Requests For Paths You Never Created
The web server starts logging requests for admin panels, environment files, backup archives and configuration paths from software that was never installed. Something is checking whether you left anything lying around, and it costs the sender nothing to ask.
Whatever You Installed Gets Tested Specifically
Once the server announces what it is running, the traffic narrows. A WordPress site starts receiving attempts at the login page and probes for old plugin paths. A mail service gets tested for relaying. The version numbers your software publishes in its responses are how that targeting happens, which is why hiding them is worth the two minutes it takes.
None Of That Is An Attack On You
It is automated, it is constant, and it is aimed at every address rather than at your business. Which is the good news, because software that tries the same handful of things everywhere is stopped by the same handful of measures everywhere. Keys instead of passwords removes the entire login queue. A firewall that drops silently makes the scanning far less productive. Automatic blocking handles whatever keeps trying anyway.
The servers that get compromised are almost never the ones somebody chose. They are the ones where the defaults were left as they came, which is exactly the situation this page is about fixing.
What It Costs
Three packages, priced per job rather than by the hour. Pick by how much of the stack you want covered. If your situation sits between two of them, we quote for what you actually need rather than pushing you up a tier.
Server Lockdown
One Linux VPS, no application work. The right pick for an app you built yourself, or a machine that only runs a tunnel or an API.
- Key based access, root login disabled
- Firewall configured to drop by default
- Fail2Ban tuned to your services
- TLS installed with automated renewal
- Security headers set and tested
- Server version and identity hidden
- Malware and rootkit scan
- Configuration notes handed over
Server And Site
The full server package plus the application on top. For WordPress, WooCommerce and anything else where the site is the thing people actually attack.
- Everything in Server Lockdown
- Core, themes and plugins updated
- Dashboard file editing switched off
- PHP execution blocked in uploads
- Admin login protected, XML-RPC handled
- File permissions corrected
- Weak user accounts found and reported
- Backups checked and a restore tested
Audit And Rollout
Several machines, or one that already looks wrong. Starts with a written audit so you can decide what gets done rather than approving a package blind.
- Written audit of every machine in scope
- Findings ranked by what to fix first
- Hardening applied across all servers
- Cloudflare or rate limiting in front
- Consistent configuration between machines
- Access reviewed, old logins removed
- Monitoring and alerting where you want it
- Full documentation for your team
Added To Any Package
- Each additional server on the same job $50
- Each additional site on the same server $40
- Cleaning up an existing compromise Quoted
- Monthly check and patch, ongoing $100 / mo
The scan runs before anything is priced as finished, so if the machine turns out to be compromised you hear that first and decide how to proceed. Hosting, certificates and any Cloudflare plan are billed to you directly by those providers rather than through us.
What Gets Changed On The Server
Eight things, in this order, because some of them only make sense once the one before is done. Each is explained as it goes in, so you finish the job knowing what is on your machine rather than trusting that something was done.
Keys Instead Of Passwords
A key pair generated, tested from your own machine, and only then is password login switched off and direct root access disabled. Doing it in that order matters, because plenty of servers have been locked out by someone turning off passwords before checking the key works.
A Firewall That Drops Rather Than Answers
Everything closed by default, with your web ports and your administrative access the exceptions. Traffic to anything else is dropped silently instead of refused, so a scan gets no response at all rather than a polite reply confirming the machine is there.
Automatic Blocking For Repeat Attempts
Fail2Ban watching the log files, so an address that fails several times in a row gets blocked without you touching anything. Tuned for your setup rather than left on the defaults, which is the difference between it catching attacks and it locking you out of your own site.
TLS With Renewal That Runs Itself
A certificate installed, plain HTTP redirected to HTTPS everywhere including the versions with and without www, mixed content sorted out, and renewal automated then tested. An expired certificate takes a site down as effectively as any attack and it is entirely avoidable.
Security Headers On Every Response
Strict transport security, frame and content type protections, referrer policy and a content security policy built around what your site actually loads. That last one gets tested properly, because a policy copied from a tutorial usually breaks a payment widget or a font.
The Server Stops Announcing Itself
Version numbers removed from response headers and error pages, directory listings switched off, and default pages and sample files taken away. It does not stop a determined attacker and it removes your machine from the automated lists built by matching version strings.
Traffic Filtered Before It Arrives
Cloudflare in front where it suits you, so floods and bad traffic are absorbed before they reach your server and your real address stops being public. Where a proxy is not wanted, rate limiting and connection limits go on directly instead.
A Scan Of What Is Already There
Malware and rootkit scans across the file system, a look at what is listening and what runs on a schedule, and a check of file permissions. Hardening a machine that is already compromised just locks the door with someone inside, so this happens before the job is called finished.
If It Is A WordPress Or Ecommerce Site
The server work above is the same. What sits on top of it is application level, and it is where most sites are actually broken into rather than through the server itself.
- Core, themes and plugins brought up to date, with anything abandoned by its author replaced rather than patched.
- File editing from the dashboard switched off, and PHP execution blocked in the uploads folder.
- Admin login protected, XML-RPC closed unless something you use needs it, and users on weak passwords found and dealt with.
- File permissions corrected, since a lot of sites have been left world writable by a plugin install that failed halfway.
- Backups checked, because most people have never confirmed that theirs restore.
What Hardening Does Not Do
This work removes the automated traffic almost entirely, and there are six things it leaves untouched. Anyone selling you a locked down server without saying this part is selling you a feeling.
It Does Not Fix Bugs In Your Own Code
A firewall cannot see the difference between a customer submitting a form and somebody sending something malformed into the same form. If your application accepts input it should not, that is a code review and a fix, and it is a different piece of work from the one on this page.
It Does Not Protect A Password You Reused
Credentials taken from somewhere else and tried on your admin panel look exactly like you logging in. Nothing on the server can tell the difference, which is why unique passwords and a second factor on anything that offers it matter more than most of the technical work here.
It Does Not Stay Current On Its Own
The configuration holds, and the software underneath keeps getting updates. Automatic security patching gets switched on where the risk of an unattended restart is acceptable, and where it is not, updating stays a job someone has to actually do.
It Does Not Undo A Compromise That Already Happened
If the scan finds something, cleaning up is a separate job and sometimes the honest answer is rebuilding onto a fresh machine and moving the data across. That costs more than hardening. Being told so on day one costs a great deal less than finding out in month three.
It Does Not Replace Backups You Have Tested
Every measure here reduces the chance of a bad day. Backups are what decides how bad that day is when it arrives anyway. We check yours exist and check they restore, because a backup nobody has ever restored is a hope rather than a plan.
It Does Not Absorb Every Kind Of Flood
Rate limiting and a proxy in front handle the volumes a small site realistically sees. An attack large enough to saturate your hosting provider's connection is answered by them and by the proxy, not by rules on your machine, and any page claiming otherwise is overselling.
Where That Leaves You
The automated traffic from the section above stops being a threat, which is the large majority of what actually reaches a small server. What remains needs your habits rather than our configuration, and you get told which is which at handover instead of being left with a report that implies the job covered everything.
You also get the configuration itself, in plain notes, so a different engineer can pick it up later without starting from nothing. Nothing here depends on us staying involved.
Tell Us What The Server Runs And Who Else Has Access
The host, the operating system, what is running on it, and whether anyone besides you has a login. That is enough for a quote. The scan comes first so you know what you are starting from, and if it turns up something already on the machine you will hear about it that day rather than at the end of the job.
Get your server locked down