Hardening a live server is easy. Not breaking it is the hard part.
The free tools will find what is wrong with your server, and some of them will even generate the script that fixes it. The question is what breaks when you run it, and whether you can still log in afterwards. That is the part I do.
It has never been hardened, and nobody wants to touch it
The server works. It has worked for three years. Somebody set it up in an afternoon, it went live, and it has been serving traffic ever since without complaint.
Nothing about that is negligent. It is what a working server looks like. But it means root still logs in over SSH, packages are months behind because updating them broke something once, and the firewall was configured by somebody who has since left. None of that produces an error. A wide-open server and a locked-down one behave identically right up until the day they do not.
So the real blocker is not ignorance. Most people running a VPS know roughly what should be done. The blocker is that every one of those changes can take the site down, and the person who would have to fix it at 2am is the same person considering the change. The rational move, every single time, is to leave it alone for another month.
Run the free tools first. Seriously, they are very good.
The free tooling here is better than the free tooling for most things, and pretending otherwise would be insulting since you can find it in one search. Here is exactly where the line falls, so you can decide whether you need me at all.
What the free tools give you
Free · run it this afternoon
- Lynis — GPL, around since 2007, agentless, and installation is optional. It runs hundreds of individual tests against the box
- OpenSCAP and the SCAP Security Guide — free, ships CIS and DISA STIG profiles, and generates working remediation as bash fix files and Ansible playbooks
- ModSecurity and the OWASP Core Rule Set — free and open source, under the Apache 2.0 licence
- CIS-CAT Lite scores the server 1–100 against a benchmark, and fail2ban and the CrowdSec community plan are free too
- The health checker on this site — free, no signup — finds the part of this that is visible from outside
What this adds
Needs someone who knows the box
- Which nine of two hundred suggestions matter here, out of a scanner output with no severity ranking and no idea what you run
- What each change would break on this server — the column no scanner can populate, because the answer is not on the server
- A tested rollback for every change, written before it goes on, not worked out afterwards under pressure
- Rule-set exclusions written against your actual endpoints, which a rule set has no way of knowing
- The changes applied one at a time, with a second way in open throughout
Notice what is not in the right-hand column: finding the problems, and fixing them. Both are free. On this particular job the free tools genuinely do detect and remediate, and any page telling you otherwise is hoping you have not tried them.
“Remediation steps can restrict accesses or change how a system functions. After the remediation has been applied, it can’t be automatically reverted. Don’t apply remediation steps to production systems without testing them first.”Oracle Linux — OpenSCAP remediation documentation
That is the tool’s own warning, on the tool’s own documentation page. It generates the fix, tells you it may cut off your access, tells you there is no undo, and tells you not to run it on production without testing it first. Testing it first is the job. The script was never the hard part.
The change plan, and the column that costs money
Rather than describe it, here are three rows out of a real one. The first two columns are what a scanner gives you free. The third is the reason this page exists.
| Change | Why | What this could break here | How to undo it |
|---|---|---|---|
| Disable SSH password authentication | Every brute-force attempt against this box stops working the moment it lands. On most servers this is the single highest-value change on the list. | The nightly backup logs in from the office NAS with a password. It stops that night, silently, and you find out the next time you need a restore. | The original sshd_config is saved before the edit and restored with one reload. A second session stays open the whole time, so the door is never shut from the inside. |
| Firewall on, default deny inbound | Closes every service you forgot was listening. Most servers are running at least one thing nobody remembers starting. | The staging copy answers on 8443 and is not in anyone’s notes. So does the monitoring agent. Both go dark, and the monitoring going dark is the one that hides the next problem. |
The rule set is captured before the first rule is added. Applied behind a scheduled revert, so if the session drops the firewall undoes itself rather than stranding you. |
| ModSecurity with the OWASP Core Rule Set, blocking | Stops the common injection, traversal and scanner shapes before they reach the application at all. | Your checkout. A JSON body with an apostrophe in a delivery note reads as SQL injection at the wrong paranoia level, and real customers get a 403 at the payment step — which nobody reports, they just leave. | It does not go into blocking mode at all until it has run in detection-only against your real traffic and the log shows nothing legitimate would have been blocked. That week of logs is the deliverable, not the rule file. |
The third column cannot be generated, and not because the tooling is immature. It needs to know what the application does, which cron jobs run, how deploys happen, what talks to this box and who logs in from where. That information is not on the server in any form a program can read. It comes out of a conversation with whoever runs it, which is why tier 1 is a review rather than a scan.
The fourth column is only worth the paper if somebody tested the reversal before the change went on. A rollback written afterwards, during an outage, by the person who caused the outage, is not a rollback. It is a hope.
Six things, and it is nearly always these
Not an exhaustive list of everything that can go wrong on a Linux box. These are the groups the tools on this site route here, plus the ones no external check can see.
- The way in that nobody ever changed
- Root logs in directly over SSH. Passwords are accepted. There is no brute-force protection, so the attempts simply continue forever at no cost to anybody. And often there is one login that several people share, which means the logs cannot tell you who did anything — not after an incident, and not during one.
- What the server tells the internet about itself
- The response headers publish the web server version and the PHP version, which turns “is this box vulnerable” into a lookup rather than a probe. A directory listing is served somewhere. PHP errors are visible in the page source, complete with file paths. And
robots.txtnames a backup, a database dump, a key or a.gitpath — a file written to hide things from crawlers, being read as an index by everyone else. - Headers and cookies that were never set
- No Content-Security-Policy, and usually none of the rest of that family either. Session cookies without
SecureorHttpOnly, so one script on the page can read them. Credentialed cross-origin access allowed from a wildcard or anullorigin, which is the combination that lets another site make authenticated requests as your logged-in user. - Secrets and accounts
- Credentials committed to a repository — a database password, an API key, a private key — where they stay in the history long after somebody deletes the line. No account per person, so access cannot be removed when somebody leaves without changing it for everybody. Neither of these is visible from outside, and both are usually the fastest route in.
- It has simply never been hardened
- No baseline was ever applied, so there is nothing to drift from. Packages are months behind because updating them once broke something and nobody has updated them since. The firewall is off, or open, or was configured once by somebody who is no longer here. This is not negligence — it is what happens when a server works.
- And the other half: it falls over
- Six or more incidents a year. It runs out of memory and the kernel starts killing processes. The disk fills with logs nobody rotates. It goes down under load that was fine last month. This is the same visit: while somebody is on the box reading the SSH config and the firewall, they are also reading memory, swap, disk trend, the OOM killer’s history and the logs from the last time it fell over.
Groups two and three are visible from outside, which is why the free health checker here finds them and why you should run it before paying anyone — and if the site is WordPress, the WordPress security check as well. Groups one, four, five and six need somebody on the box. Every tool on this site is passive and external, so none of them looks at your SSH config, your firewall, your kernel parameters, your user accounts or the logs from the last time the server fell over. That is a real limit and it is worth knowing which half you have already covered for free.
If you would rather start further back — not with a scan but with whether this server should exist at all — the self-managed VPS versus managed AWS calculator answers that one directly, and the cloud architecture self-assessment and engagement builder both ask about hardening and incidents. All three are free.
Four ways in
Everyone starts with the review, because until somebody has read the server nobody knows how big the job is — including me. Where you go afterwards depends on what it finds.
Server Review
Everyone starts here. It also scopes everything else.
- The change plan — every proposed change, what it could break here, and how to undo it
- Lynis and OpenSCAP run and triaged against what you actually run
- SSH, sudo, accounts, firewall, brute-force protection and package currency read by hand
- Headers, cookies and what the server publishes about itself
- Memory, disk, swap and the logs from the last time it fell over
- What is already correct, not just what is wrong
- Nothing is changed. One server
Review + Hardening
The plan is agreed. This applies it.
- The agreed changes applied one at a time, in the agreed order
- Each rollback tested before the change goes on, never after
- A second route in held open the entire time
- Applied in a window you choose, or handed over for your team to apply
- Anything the plan flagged as risky here is skipped unless you say otherwise
- A re-scan afterwards, so you can see what moved
Review fee credited — you pay the difference, not both.
Hardening + ModSecurity
The above, plus a rule set that does not block your customers.
- Everything in the hardening
- ModSecurity and the OWASP Core Rule Set on one application, one hostname
- Detection-only first, against your real traffic, until the log shows what would have been blocked
- Up to 15 tuned exclusions written against your actual endpoints
- Blocking at paranoia level 1, with one revision round after go-live
- Needs a staging copy or a traffic sample — see below
Review fee credited — you pay the difference, not both.
Managed Hardening
Not a starting point. Follows the hardening.
Because a server hardened once stops being hardened.
- Packages tracked, and told what needs a reboot rather than just a patch
- Logs and bans reviewed, so a change in the pattern gets noticed
- Disk and memory trend watched before they become the incident
- Monthly re-scan, diffed against the agreed baseline — drift you can see
- New rule-set false positives tuned as your application changes
- Monthly in advance, cancel anytime, never auto-renewing
Five things about those prices, before you ask
- The cap is one server — one machine, one OS install. The number of sites on it does not change the price, because hardening scales with the machine and not the vhost count. A fleet is several engagements rather than one bigger one, since each box has its own applications and its own way of breaking.
- ModSecurity is capped at one application and 15 tuned exclusions, with one revision round. Rule-set tuning scales with your endpoint count, which you cannot count in advance and neither can I. Past that cap I look first and quote before anything is invoiced.
- The recommended tier is the monthly one, and that is deliberate. This page has to tell you that hardening decays; pointing you at a one-off after writing that would be dishonest. But it follows the work rather than replacing it — a retainer on a server nobody has reviewed is a standing charge for nothing.
- The review fee is credited for 30 days. Come back inside a month and you pay the difference. After that it lapses, and not as a sales tactic: packages move weekly, so a plan written last quarter would have to be rewritten anyway.
- If the review finds nothing serious, that is the end of it. The fee is earned, you get the reasoning in writing, and there is nothing further to buy — so the credit applies to nothing. Better said now than discovered later.
These are launch prices for a new practice rather than a permanent position, and they will go up once there is finished work behind them. If your situation does not fit any of the four, say so in the form and I will tell you honestly whether it is worth doing at all.
What you have to supply
One of these is not negotiable, and it is not the one about access. It is the second one.
You must have a second route in before anything is changed. Provider console, VNC, or recovery mode — something that works when SSH does not.
This is the one item I will not start without, and the reason is the entire argument of this page. Hardening a live server can lock you out of it. Doing that with no way back would be exactly the recklessness this service exists to sell against, and I would rather lose the job than take it on those terms. If you are not sure you have one, find out before you contact me — it is worth knowing whether you have one anyway.
Access — least privilege, always
- SSH as a named user with sudo. Not root. Disabling root login is usually on the change list anyway, and if root is currently the only account then that is finding number one before I have looked at anything else.
- A backup or snapshot taken before anything changes, and confirmed restorable rather than merely confirmed to exist. The rollback exists before the first edit, not after the first problem.
- A maintenance window, or explicit permission to work live with a clear understanding of what that risks. Both are workable. Only one of them is comfortable.
- Access removed when the work is delivered. That is your action, not mine, so you never have to trust that I did it.
Information — and the first item is the product
- What this server actually runs. Applications, cron jobs, the deploy process, what else talks to it, who logs in and how. Without this the third column of the change plan cannot be filled in, and that column is what you are paying for.
- What broke last time somebody touched it, if anything did. That story is usually worth more than the scanner output, and it is often the reason nobody has touched it since.
- For ModSecurity: a staging copy, or a traffic sample. Tuning a rule set against a live checkout with real customers on it is not acceptable and I will not do it. Detection-only mode exists precisely so the breakage can be previewed.
- Best guesses are fine. “Nobody knows what that cron job does” is a legitimate answer and a finding in itself.
Protecting the work
- Written authorisation naming the server and the change list. Before anything is changed. This protects you considerably more than it protects me.
- Written agreement that every change is staged and reversible, with a named rollback for each one. On a live server a correct change at the wrong moment is still an outage.
- Written acknowledgement that a second access route exists and that you have tested it. Not a formality — a console you have never logged into is not a second route, it is an assumption.
What I will not promise you
Hardening reduces exposure. It does not make a server unhackable, and nobody can promise that it does. This engagement covers the changes agreed and applied, and the reasoning behind them. It does not cover an outcome, because no honest person sells one.
This is not a penetration test. Nothing is exploited, no credentials are brute-forced, and no data is copied out to prove a point. That is a different engagement with a different authorisation, and if it is what you need I will say so rather than sell you the nearest thing I have.
It is not a compliance certification. CIS and STIG profiles get applied — that part is real. A profile applied is not a certification, no auditor signs it, and anybody blurring those two is selling you a document that will not be accepted.
It is a point in time, and this one decays faster than most. Packages go stale weekly. A server hardened in March and untouched since is not a hardened server. That is an honest limitation of one-off work rather than an argument for the monthly tier, and you should weigh it as one.
A WAF does not make an insecure application safe. ModSecurity buys you time against known attack shapes. It does not patch your code. Selling a rule set as a fix for an unpatched application would be dishonest, and if that is the situation I will tell you the patching is the job.
What happens if the server is already compromised
Not common, and it needs saying in advance, because the right response is nothing like the rest of this page.
Hardening a compromised box is worse than doing nothing
- You hear immediately, in whatever way reaches you fastest — not in a report four days later. A webshell, an SSH key nobody recognises, a rootkit, outbound spam or a miner all qualify.
- The engagement pauses there. Continuing down a hardening checklist while somebody else is inside the server would be the wrong order of work.
- It can bury the intrusion. Closing the doors around an attacker who already has their own way back in makes the box look healthier while changing nothing about who controls it. That is the misunderstanding that costs people their servers.
- Incident response is quoted separately. Different urgency, different hours, and it cannot honestly be folded into a fixed fee. I will tell you plainly if it is bigger than one person should take on.
How payment works
Plainly, so nothing about it is a surprise later. There is no account to create, no portal to log into and no card stored anywhere.
-
You apply through the form
No payment at this point, and no commitment. Tell me what the server runs, what it does, and what prompted this.
-
I review it and confirm the scope
If it is not worth doing, I say so here and it costs you nothing. If it is, you get the scope in writing before any invoice exists.
-
An invoice arrives, payable within 48 hours
It carries an invoice number and a due date. Unpaid past 48 hours, the application lapses and the slot is released to somebody else.
-
Work begins once payment is received
Not before. For one-off work there is nothing to suspend after delivery, so payment comes first — that is the standard arrangement and it runs both ways.
-
Managed hardening, if you take it, is monthly in advance
Non-payment simply stops the work. Nothing is billed silently in the background and you can stop whenever you like.
If the server is not in production yet
Everything above assumes a box that has been serving traffic for years. If you are still building, the same work costs less and none of it carries the risk that makes this page necessary.
What that involves
- Key-only SSH and no root login from the first boot, so there is never a live service depending on the thing you have to remove later.
- The firewall built before anything listens, rather than closed around services nobody can identify.
- An account per person from day one, so the shared-login problem never starts.
- The rule set tuned against staging traffic, which is the situation everyone wishes they had when tuning it later.
- A written baseline, so drift becomes something you can see rather than something you discover.
Mention that it is pre-launch in the form and I will quote it as its own piece of work. It is cheaper, and it is the version of this engagement I would rather sell.
Run the free checks first, then send me what they found.
They cost nothing, need no signup and no email address, and between them they will tell you what your server is publishing about itself. Then run Lynis on the box, which is free and takes an afternoon. If all of it comes back clean, you have saved yourself a fee and I would rather tell you that than take it. If it comes back with two hundred suggestions and no idea which matter, that is exactly what this is for.
Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.