Security Hardening Audit

Security hardening audit checks selected settings on a Linux SSH host and explains the evidence it can collect. You choose the scope and approve each run. The assessment does not apply configuration changes, require a Zync account, or install a scanner or agent.

Available in Zync 2.38.0 and later. The catalog in 2.38.0 contains 183 checks and observations across 15 areas. This is configuration review, not vulnerability scanning or compliance certification.

Start an audit

1. Open Security hardening audit from global navigation, the + menu or the command palette.
2. Choose New audit, select a saved Linux SSH host and continue.
3. If the host is offline, use Connect or Reconnect. Connecting does not start an assessment.
4. Choose a Preset, then use Areas > Edit to adjust what runs. Configure application access only for observers you want to use.
5. Select Run assessment, review the host, selected areas and access, then approve the run.

You can also open Security hardening audit from a Linux SSH host’s workspace + menu and choose New assessment.

The host-scoped audit supports split panes beside a shell or another host tool. The global saved-report library is a separate global tab.

Back returns to the global saved-report list without discarding the current in-memory draft or unsaved result. Resume audit returns to it. Choosing another host replaces that draft; save a report if you want to keep it across app restarts.

Choose what to assess

Presets offer a starting selection. Only selected areas run; opening the view, editing the scope or reconnecting never starts a scan automatically.

Areas	What they inspect
Host baseline	38 checks and observations covering kernel settings, SSH defaults, accounts, named-file permissions, network, mounts and maintenance.
Additional host protections	Account hygiene, isolation, audit, clock and runtime controls.
SSH connection-policy preview	Current standard SSH configuration for the selected account and connection context. It does not prove the active daemon loaded those files.
Nginx, Apache, Docker, PostgreSQL, MySQL, Redis and Jenkins	Named service units and configuration evidence for the selected application.
Docker workloads	A bounded sample of running containers. This does not inspect every container or scan image vulnerabilities.
PostgreSQL, MySQL, Redis and Jenkins runtime	Opt-in observations of local application settings. Add these explicitly; presets do not select them automatically.

Reports identify whether evidence came from a service unit, a named file, a configuration preview or a runtime observation. A result applies to that source and target, not every application instance on the server.

Application access

For a selected runtime area, choose Add access. Enter the application’s local port, username and password or Jenkins API token. PostgreSQL also needs a database name. Use an observation account with the required read permissions; missing privileged views can remain unavailable without granting broad administrative access.

Connections target 127.0.0.1 on the SSH host. Sudo access and application authentication are separate: a sudo retry does not grant database or Jenkins access.

Observer	Connection limits
PostgreSQL	Uses an SSH-protected local connection. An inner TLS-only database policy can reject it.
MySQL	Requires an existing supported Oracle MySQL client on the Linux host and uses TLS. Passwords are limited to 79 UTF-8 bytes; keep a longer password unchanged and use service checks.
Redis	Observes plaintext local endpoints. TLS-only endpoints are unsupported; Zync does not weaken the server’s TLS policy.
Jenkins	Reads fixed local HTTP metadata without redirects or script-console calls. Custom context paths and HTTPS-only endpoints are unsupported. Public metadata may be readable without verifying the supplied token; the evidence identifies this.

Observers have fixed collection and target limits. They do not create application accounts or change grants. Unsupported tools, versions or access can leave individual checks unavailable.

Use sudo for protected checks

Without Use sudo, the assessment uses the SSH account’s existing privileges. A root SSH session already has elevated access; logging in as a user who belongs to a sudo group does not by itself run the assessment as root.

Enable Use sudo when you want to authorize fixed protected-read commands for that run. Zync asks for the password when server policy requires it. A valid server-side authentication cache or passwordless rule can allow sudo without a prompt. This does not open a root shell or change sudoers.

MFA, multiple password challenges and TTY-only sudo rules are unsupported. Closing the password dialog cancels the assessment; rejected or expired challenges do not retry automatically.

Results distinguish Standard access, Root session and Sudo allowed. Allowing sudo does not guarantee every check can collect evidence.

• Retry with sudo appears for eligible confirmed access denials.
• Try with sudo can appear for eligible protected-read failures whose cause is uncertain.
• Both require a new approval and rerun the report’s selected scope, replacing the in-memory result. Save the previous report first if you want to compare it.

Sudo passwords and application passwords or tokens are temporary inputs for the run. They are not saved to Vault, synced, included in reports or automatically reused for a retry. Authentication may produce normal server-side access logs.

Understand the results

Each report records its assessed host, date, scope, preset and access. Changing the next run’s choices does not relabel an existing report. Search and filter findings, then expand a row for its explanation and technical details.

About this assessment identifies the audit-rule revision, review date and check profile. Profiles are authored for Ubuntu 22.04/24.04 and Debian 12/13; other Linux releases use limited generic coverage. A profile label describes the checks’ scope, not certification or complete coverage of that OS.

Result	Meaning
Needs attention	Collected evidence meets a review condition. This is not proof of an exploitable vulnerability.
Informational	Context for you to review without an automatic pass or fail decision.
Passed	The named condition met the rule for the evidence collected.
Needs elevated access	A protected read was denied during an unelevated, non-root run.
Evidence unavailable	Collection failed, information was missing or the result could not be interpreted. This does not always mean sudo is needed.
Not applicable	Evidence establishes that the check does not apply to its stated target.

Coverage counts separate assessed checks, access limitations and unavailable evidence. Unavailable or not-applicable checks do not count as passed. Priorities help order a review; the counts are not an overall security score.

Findings can show what was observed, the expected condition, why it matters and a recommended next step. Expand available change, impact, verification and recovery guidance before making a change yourself. Collection failures show a next step for obtaining evidence instead of treating a missing result as a failed setting.

Save and open reports

Choose Save report to create a named copy or explicitly replace a saved report. Saving is manual. Unsaved results can be lost when their pane closes or Zync restarts.

In 2.38.0, the local library holds up to 50 reports, subject to a 64 MiB total report-data budget. Replace or delete a report when it is full; older reports are not silently evicted.

The global library lists saved reports from every host. Search by report or host, filter by host, and open a report by selecting its row. Reports remain available offline and after the saved host is removed. Returning to the list refreshes its metadata while preserving filters. Browse labels respect Show host addresses in lists; report details and exports retain the recorded endpoint.

Reports are local records

Saved reports and accepted-risk decisions stay in this device’s app data directory. They are outside Vault, are not protected by Vault encryption, and are not included in Drive Sync. Device file permissions apply. Review host details and configuration evidence before sharing an export.

Export and import

The Export menu includes all retained findings, not just the current page or filter:

• JSON preserves the report, evidence and recorded accepted-risk notes. Import it to preview a report or use it for comparison.
• CSV provides one row per check for spreadsheet workflows.
• Excel (.xlsx) includes Summary and Findings sheets, with filters and formatted headings.

Spreadsheet exports write evidence as text. Use JSON when exact programmatic values matter.

Compare reports

In the host’s report view, use a saved report’s Compare action or Report actions > Compare imported report to review it against the current report. Comparison checks the host identity, account, policy, rule and target compatibility; incompatible checks are skipped.

An assessment with sudo can collect information that a standard run could not read. Those checks appear as newly assessed, not as security problems that were automatically fixed. Missing or unavailable evidence does not make an earlier attention item resolved. Review the before/after evidence and the comparison’s unchanged and skipped counts.

Manage accepted risks

Use Accept risk on an eligible finding to record your reason and an expiry. The decision applies only to matching scope and evidence. It does not change the native check result or make a finding pass.

Open the host’s Accepted risks list to review, search or remove decisions. Expired decisions no longer apply to matching findings, while historical reports keep the notes recorded with them.

Deleting a saved report keeps independent accepted-risk decisions by default. The delete dialog offers a checkbox to also remove matching unchanged decisions. Reviewing an older report does not restore a decision you removed.

Requirements and troubleshooting

The collector requires a Linux SSH host with GNU coreutils timeout. Selected application checks can require additional existing host tools and suitable access. No tools are installed automatically.

Situation	What to do
Host is offline	Connect from the audit setup card. Saved reports remain usable without connecting.
Evidence is unavailable	Expand Technical details. Check the named tool, target, permissions or supported application context before retrying.
A protected read was denied	If appropriate for this host, approve the offered sudo retry. Application authentication can require separate access.
Application or service is absent	Review the target and selected area. An established exclusion can be not applicable; missing evidence alone is not a pass.
A collection or target limit is reached	Review the recorded scope and coverage. A bounded sample is not a complete inventory.
Saved-report storage is full	Replace or delete a saved copy. Zync does not silently evict older reports.

Related guides

• Connections for host authentication and routing.
• Dashboard for live resource snapshots.
• Security for audit data and credential boundaries.