Hardened servers that stay hardened — and evidence that they are

Contents

1. 1Executive summary
2. 2The challenge
3. 3Architecture
4. 4How it works
5. 5Capabilities in detail
6. 6Security and data handling
7. 7Where it fits
8. 8Deployment and system requirements
9. 9Technical specifications
10. 10Getting started

1Executive summary

InfraGuard checks every Linux server against 79 hardening checks, shows the exact setting it found, alerts the moment a server drifts, and fixes what a second person approves — backing up every file, checking each fix took effect and keeping a rollback for every change.

2The challenge

Most server breaches start with a setting, not a zero-day: root logins over SSH, password logins open to the internet, weak ciphers, world-readable shadow files, no audit trail, no firewall. Servers drift — a hardened image is weakened by the next change — and auditors ask for evidence that nobody has.

The TotalHeal approach. InfraGuard runs a 79-check hardening benchmark on every Linux server through the TotalHeal server agent, scores each server and the fleet, alerts when a check newly fails, and fixes what you approve — with a backup, a check that the fix took effect, and a rollback for every change.

3Architecture

4How it works

1. ScanThe server agent reads the host — files, kernel settings, services — every 6 hours and on demand; nothing is changed.
2. ScoreEach check passes or fails with evidence; a severity-weighted score per server and for the fleet.
3. AlertA check that newly fails at critical or high raises an alert in the incident queue.
4. ApproveSomeone requests a fix with a reason; a different person approves it.
5. Fix and verifyThe agent backs up, applies, re-reads the host and rolls back any fix that did not take effect.

5Capabilities in detail

• 79 checks with evidenceSSH (root and password login, attempts, ciphers, MACs, key exchange, host keys), kernel and network settings, accounts and PAM, file permissions, services, logging and audit, updates, firewall, time sync, SELinux / AppArmor, Secure Boot and Docker — each result with the exact value found.
• Why it matters, how to fixEvery check explains the risk in one sentence and names its fix or the guidance to follow.
• Score per server and for the fleetA severity-weighted score from 0 to 100 (critical 10, high 6, medium 3, low 1), score history, and the checks failing on most servers.
• Drift alertsA check that newly fails at critical or high raises an alert (MITRE ATT&CK T1562.001) in the same incident queue as every other alert.
• Fixes with four-eyes approvalRequest a fix with a reason; a second person approves — never the requester, never an AI; the agent applies it as a signed command.
• Backup, verify, roll backEvery file a fix touches is backed up first; the host is re-read to check the fix took effect, and a fix that did not is rolled back automatically. Any applied fix can be rolled back later, byte for byte.
• Safe where it mattersSSH changes are validated with sshd -t before reload; firewall and partition changes are guidance only, never automatic; remediation runs only where the host owner allowed it.
• Accepted risksAn exception for one server or all servers needs a reason, an expiry of up to a year and a second person; it leaves the score while it lasts.
• Evidence by controlResults grouped by ISO 27001:2022 Annex A control and the CERT-In directions (log retention, clock synchronisation) for auditors.
• On the host toototalheal-server-agent infraguard scan | fix | rollback runs the same benchmark on a server without the cloud.

6Security and data handling

• Read-only by defaultScanning never changes a server; fixes run only where the host owner allowed remediation.
• Two people for every changeFixes, rollbacks and accepted risks need a second person; the requester and AI never approve.
• Every change can be undoneFiles are backed up before a fix and restored byte for byte by a rollback.
• No lock-outsSSH changes are validated before reload; firewall and partition changes are never automatic.

7Where it fits

8Deployment and system requirements

9Technical specifications

10Getting started

• The TotalHeal server agent on each Linux server, with infraguard.enabled
• infraguard.allow_remediation on servers where approved fixes may run
• Outbound HTTPS from each server to the TotalHeal cloud

Start a 30 days, up to 5 servers trial in the TotalHeal console with a Sttiz account. For a quote, an on-premises installation or the procurement dossier (compliance matrix, bill of materials, architecture and hardening, SLA, OEM authorisation letter), write to business@totalhealsecurity.com.