Weak or reused SSH access
Password authentication enabled, root login permitted, and keys shared between people who have since left.
[ Servers & DevOps / Server Security Hardening ]
Servers are scanned within minutes of coming online and probed continuously afterwards. Hardening is not paranoia, it is basic maintenance. I audit what you have, fix it, and give you a written record of what changed.
Read-only audit first · Report in 5 days · No agent installed
[ Attack surface ]
Almost never a sophisticated exploit. Nearly always one of these, left in place because it was never anyone's job.
Password authentication enabled, root login permitted, and keys shared between people who have since left.
Known vulnerabilities with public exploit code, sitting unpatched for months because updates are manual.
A database, cache or admin panel bound to a public interface because that was the quickest way to test it.
Nothing watching for repeated failures, new listening ports or changed system binaries.
Web processes running as root, so a single application flaw becomes full machine access.
Database passwords and API keys in world-readable config files and shell history.
[ How it works ]
A read-only review of access, exposed services, patch level, permissions, logging and secret handling. You get a findings report rated by severity.
Findings fixed in severity order, each change tested so nothing breaks. Anything risky is scheduled inside a maintenance window you choose.
Re-scan to confirm each finding is closed, then a written record of every change and an ongoing maintenance schedule for your team.
[ What actually changes ]
Applied proportionately — a marketing site and a system holding payment data do not need the same controls, and I will not sell you the same job twice.
[ Example engagement ]
A production server with password SSH, a publicly bound database, and eight months of missing security patches. All critical findings closed inside a week with no service interruption.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
[ Free · read-only · 5 days ]
A written audit of your servers with every finding rated by severity and effort. Yours to keep and fix in-house if you prefer.
[ Pricing ]
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
For a single bug or a short task where writing a full scope would cost more than simply doing the work.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
Not if it is done in the right order and tested, which is why the audit comes first. Anything with a risk of breaking something is scheduled inside a window you choose, with a rollback ready.
The audit is read-only and installs nothing. During hardening I may add standard open-source tooling for patching, file integrity and log shipping — all of it visible, documented, and removable.
Compliance and security overlap but are not the same thing. A checklist audit confirms you have controls documented; this confirms they actually hold up on the machine.
Yes, and that is a different and more urgent job — containment first, then forensics, then a clean rebuild. Get in touch and say clearly that you are actively compromised.
An annual review is reasonable for most businesses, with automated patching running continuously in between. If you handle payment or health data, more often.
[ Related services ]
[ Let's talk ]
Describe the problem in a few lines and you'll get a real reply from the person who'd do the work — same working day, no discovery call required.