Security Diagnostics

Overview — what it does

Security Diagnostics runs a rootkit-trace scan plus a system-hardening scan across your registered servers, scores each result as a 0–100 score with an A–F grade, and shows your whole fleet's security posture on one screen. Every check carries a what/why/how-to-fix explanation, and any finding that is a failure whose severity is critical (fail + crit) is auto-promoted to a Problem Resolution case (deduplicated, and auto-resolved once the check later passes).

Core pieces:

• Probe infr_seccheck_probe.cjs — a Node script that runs locally and read-only on the target host (no credentials). It performs 36 checks and emits JSON.
• Canonical catalogue App\Support\SecurityCheckbook — owns the 9 categories, check keys, weights, and severities (locale-independent, cache-safe). Explanation text lives in resources/lang/{ko,en}/seccheck.php.
• Engine App\Services\Security\DiagnosticsService — ingest → score → case promotion/resolution → dashboard aggregation.
• Storage infr_sec_scan (migration 000766) — one row = one host scan; findings stored inline as JSON.

Running the probe as root enables privileged checks such as /etc/shadow, sudoers, and sshd -T. When not root, privileged checks are downgraded to skip and excluded from the score denominator (no penalty).

When to use

• Baseline hardening validation before admitting a new server into production.
• Rapid triage of rootkit / backdoor traces on a suspected host (hidden processes, ld.so.preload injection, promiscuous NIC, etc.).
• A recurring compliance rhythm — a daily cron probe that pushes scores via the API reporter to accumulate a trend automatically.
• Audit readiness — see at a glance which hosts run an EOL OS, have unapplied security updates, or permit root SSH login.

Layout

Top toolbar: [Run scan] (multi-server remote run) · [Paste result] · Refresh · Auto-refresh toggle · Fullscreen.

How to use

Four intake tracks

infr_sec_scan.source classifies how a scan was received:

1) Multi-server remote run — async polling

A synchronous full run would exceed PHP's execution time across many hosts, so the flow is register → fire-and-forget worker → poll.

1. [Run scan] → tick the target instances (each shows reachable / unreachable).
2. POST /security/diagnostics/run → creates a progress record and returns run_id immediately (Cache, TTL 30 min).
3. The front end calls POST /security/diagnostics/run-worker/{runId} without awaiting → the worker runs all hosts sequentially under set_time_limit(0) and ignore_user_abort (one host failing does not stop the rest).
4. The front end polls GET /security/diagnostics/run-status/{runId} to update progress (done/total/ok).

An instance marked unreachable does not match a run_report collector node, so it cannot be run remotely. Run the probe directly on the host and submit it via [Paste result]. See Remote Emulate for the remote-run wiring.

2) Paste / JSON ingest

Run the probe on the target host and paste its JSON.

# On the target host (recommended: root)
node infr_seccheck_probe.cjs --min

--min emits single-line JSON. Output shape:

{
  "host": "web-01",
  "generated_at": "2026-08-13T03:30:00Z",
  "os": "Rocky Linux 9.3",
  "kernel": "5.14.0-362.el9",
  "root": true,
  "checks": [
    { "key": "ssh_root_login", "category": "ssh", "status": "fail", "severity": "crit", "detail": "PermitRootLogin yes", "evidence": "/etc/ssh/sshd_config:32" },
    { "key": "svc_firewall",   "category": "services", "status": "pass", "severity": "crit", "detail": "firewalld active" }
  ],
  "summary": {}
}

It is received by POST /security/diagnostics/ingest. Binding an instance records source=emulate; leaving it unbound records source=paste.

3) API reporter (automation)

Each host's cron runs the probe and pushes the result into InfraGuard. Issue the API key in Administration ▸ API Keys; the key must carry the scan.write scope.

30 3 * * *  node /opt/infr/infr_seccheck_probe.cjs --min | curl -sS -X POST https://infraguard.example.com/api/v1/security/scan -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" --data @-

Response (201):

{ "ok": true, "scan_id": 812, "host": "web-01", "score": 74, "grade": "C" }

Scoring — SecurityCheckbook

The score is a weighted ratio of each check's weight and status.

Status factor (STATUS_FACTOR) — only these count; skip/info are excluded from the denominator:

Severity multiplier (SEV_MUL) — the heavier the implication of a failure, the more it moves the score:

Per-check weight w = check_weight(1–3) × severity_multiplier; overall score = round(100 × Σ(w × status_factor) / Σw). Category scores use the same formula per category.

Grade & tone:

(Grades are A/B/C/D/F; tone is good ≥ 80 · warn ≥ 60 · crit < 60.)

9 categories · 36 checks

Each category has a display weight and icon; actual scoring uses the per-check weight × severity multiplier above.

Unknown keys are absorbed into the other category. Each check's "what / why / fix" text renders in the report modal from seccheck.check.*.

Critical findings → Problem Resolution promotion

On every ingest, reconcileCases() reconciles the host's cases.

• Only findings with status = fail AND severity = crit promote. Dedup key: an internal fingerprint.
• If an open case exists it bumps occurrence_count++ and last_occurred_at; otherwise it creates a new case: infr_incident (area=security, source=detection, entity_type=seccheck, entity_key=host, severity=crit, status=open) plus an infr_incident_event (kind=created).
• Auto-resolve: a previously open case that is no longer fail+crit in this scan (fixed or no longer detected) is set to status=resolved with resolved_at and an auto-resolution note.

Promoted checks appear in the report modal with a "promoted to resolution" badge and a [View case] link. Cases are worked on the Security ▸ Problem Resolution board.

Deleting a scan (POST /security/diagnostics/delete) does not delete its promoted cases — they are independent.

Data sources

• Aggregation discipline: within the most recent 500 scans, keep only the latest one per host (dedupe) → fleet list, average, category rollup, trend, open-critical count.
• The probe's category/severity are hints only; the server re-normalizes them as canonical via SecurityCheckbook.

Access

• Read: requires access to the Security role area (in the current tier, staff = 5 / admin = 10; demo = 1 does not see the Security area). Views the dashboard and reports.
• Write (run / ingest / delete): requires session infr_user_level >= 2 (canWrite()). run·ingest·delete return 403 (seccheck.toast.forbidden) below that.
• API reporter: the infr.apikey middleware plus a key with the scan.write scope; otherwise 403 forbidden_scope.
• Audit: every write is recorded in infr_audit_log — sec.diag_run (target count), sec.diag_ingest (scan_id·score·source), sec.diag_delete (scan id). Review in the Audit log.

For the level model in general (infr.level:N middleware), see RBAC levels.

Troubleshooting & FAQ

Q. An instance shows "unreachable" in [Run scan]. It doesn't match a run_report collector node, so there is no remote-run wiring. Run the probe on the host directly and submit via [Paste result].

Q. "No checks found" error. The pasted JSON has no checks (or items) array, or entries lack a key. Paste the output of infr_seccheck_probe.cjs --min verbatim.

Q. The score is low even though the fail count is small. That's the severity multiplier. One crit failure weighs 1.6× a warn. Use the category scores and report modal to see which finding is pulling the score down.

Q. All privileged checks are skip. The probe ran as a non-root account. Checks like /etc/shadow, sudoers, sshd -T need root. skip is excluded from the denominator (no penalty), but run as root (or via the gateway) for a full diagnosis.

Q. A run takes a while — can I close the browser? Yes. The worker runs fire-and-forget and continues under ignore_user_abort even if the request aborts. Reopen and poll run-status, or just read the grades once they appear on the dashboard. The progress record is kept for 30 minutes.

Q. A case disappeared on its own. If a later scan no longer reports that finding as fail+crit (fixed or not detected), the engine auto-resolves the case. That is expected.

Related

• Security ▸ Problem Resolution — workflow for promoted critical cases
• Remote Emulate — multi-server probe deployment & run wiring
• API Keys — reporter-track keys (scope scan.write)
• Assets ▸ Instances — the target OS instance registry
• Security ▸ Overview — the full defense-funnel narrative
• Audit log — run / ingest / delete history