Protect / Linux Server Hardening
Authentication, firewall, services, permissions, patch posture, logging and recovery reviewed as one system.
Linux server hardening reduces unnecessary attack surface by tightening authentication, network exposure, service configuration, permissions, patch posture, logging and recovery controls. TechSteps applies hardening in the context of the workload, so a security change does not quietly break the application it is meant to protect.
What this solves
Most servers are configured to work rather than configured to be secure, and the difference is largely about what is left switched on. Default installations expose services nobody uses, permit authentication methods nobody needs, and log almost nothing useful.
The opposite failure is equally common. A hardening script is run, it applies a hundred changes derived from a generic benchmark, and something breaks. Nobody knows which change caused it, so the whole thing is reverted and hardening is written off as disruptive.
Useful hardening is specific to the workload. It requires knowing what the server actually does, so exposure can be removed without removing function.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
What the server runs, what talks to it, what it talks to. Hardening applied without this is how a security change becomes an outage.
Listening sockets, running services, accounts, keys, sudo rules, cron entries and open firewall ports. This is the baseline and it is also frequently where surprises appear.
A service that is uninstalled cannot be exploited. Reducing what exists is more durable than configuring around it.
Applied in reviewable groups with the application checked after each. This is the difference between hardening that survives and hardening that gets reverted wholesale.
Console access confirmed before changing SSH configuration. Locking yourself out of a production server is an avoidable and surprisingly common outcome.
What was changed, why, and what the server should now look like. Future drift becomes a diff rather than an investigation.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
A hundred changes at once from a standard nobody tailored. Something breaks, the cause is unclear, everything is reverted, and the server ends up less secure than a careful subset would have made it.
Password authentication disabled, key configuration wrong, no out-of-band access. Now the server is secure from everyone including you.
Public ports closed while a database still listens on all interfaces on a shared network. The exposure moved rather than disappeared.
The surface is reduced and nothing is recorded. After an incident there is no evidence, so the entry point is never established and the fix is guesswork.
Configuration drifts as software is installed and people are added. Hardening is a posture to maintain, not a task to complete.
Questions we actually get asked
Not if it is done in the context of the workload and applied in stages with verification. Breakage comes from applying a generic benchmark blindly. We change things in reviewable groups and confirm the application after each, which takes longer and is the reason it stays applied.
It is a reasonable starting point and a poor finishing point. A script does not know which services your application needs, which ports must stay open or which permissions a workload depends on. It also cannot tell you what it decided not to do. The value is in the judgement, not the checklist.
The baseline should be checked periodically, because servers drift as software is installed and people come and go. An annual review is a reasonable minimum for a stable server, and continuous baseline monitoring is better where the risk justifies it.
Usually reducing what is exposed to the internet at all. Most compromises begin with something reachable that did not need to be. After that, key-based SSH with passwords disabled, and a patching cadence you actually keep.
Yes. Cloudflare protects traffic that goes through it. If your origin server IP is discoverable, and it often is, an attacker can connect to it directly and bypass the edge entirely. Restricting the origin to accept traffic only from your edge provider is part of this work.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.