Linux system audit

Linux System Audit

Perform an evidence-based Linux infrastructure audit without changing the target.

Inputs

Resolve these values from the request:

• TARGET: local, SSH alias, hostname, IP, or user@host.
• MODE: standard by default; use deep only when requested or clearly needed.
• OUTPUT_DIR: current workspace by default.
• ALLOW_SUDO: auto by default; use only noninteractive sudo -n.
• ALLOW_EXTERNAL_LOOKUPS: no by default.

If no target is identifiable, ask for only the target. Do not ask again for values already provided.

Write the report to:

<OUTPUT_DIR>/<safe-target-name>-full-audit-report.md

Sanitize the filename to letters, digits, dots, underscores, and hyphens.

Non-negotiable safety rules

1. Operate read-only. Never install, update, restart, reload, enable, disable, delete, prune, remediate, or modify configuration.
2. Proceed only on a system the user owns or is authorized to audit.
3. Never request passwords, private keys, tokens, API keys, or other secrets in chat.
4. Never disable SSH host-key verification. Reject targets beginning with - and use ssh -- "$TARGET".
5. Never trigger interactive authentication or sudo. Use BatchMode=yes and sudo -n only.
6. Distinguish not-installed, not-configured, permission-denied, unsupported, timeout, and failed.
7. Apply timeouts to potentially blocking checks and limit parallelism to four concurrent groups.
8. Do not contact public IP, package-lifecycle, or TLS endpoints unless external lookups are explicitly allowed.
9. Do not perform external port scans, password tests, exploit checks, or denial-of-service tests.
10. End the report with Changes applied during audit: None — read-only audit.

Secret-safe collection

Prevent secrets from reaching model context, terminal transcripts, or the final report.

• Never print complete .env files, secret files, private keys, registry credentials, or password hashes.
• Never request complete container environments with unsanitized docker inspect, podman inspect, env, or printenv.
• For container environments, return key names only and replace every value with [REDACTED] on the target.
• For Compose files, prefer runtime metadata and structural extraction. Do not print complete files merely to analyse them.
• Report secret-file path, owner, group, mode, size, key names, and referencing service; never report values.
• Treat names containing PASS, PWD, SECRET, TOKEN, KEY, PRIVATE, CREDENTIAL, AUTH, COOKIE, SESSION, BEARER, CLIENT_SECRET, ACCESS_KEY, CONNECTION_STRING, DATABASE_URL, DSN, SMTP, or LDAP_BIND as sensitive.
• When uncertain, redact.
• Sanitize potentially sensitive output on the target before it reaches the agent. Prefer commands that emit metadata or key names only, and apply shell redaction before returning text.
• Do not depend on a bundled sanitizer. If safe extraction cannot be guaranteed, record the check as partial and omit the sensitive content.

Safe remote environment pattern:

container='<validated-container-name>'
docker inspect "$container" --format '{{range .Config.Env}}{{println .}}{{end}}' \
  | sed 's/=.*$/=[REDACTED]/'

Context-efficient execution

Preserve audit depth without flooding the agent context:

1. Keep SKILL.md as the control plane. Load only the reference module needed for the current collection stage.
2. Run preflight and platform detection first. Skip irrelevant modules based on detected software and init system.
3. Group related checks into a small number of SSH sessions rather than one connection per command.
4. Save sanitized raw evidence to local files with mode 0600; do not paste all raw output into conversation context.
5. After each collection stage, normalize evidence into a compact phase summary containing facts, warnings, unknowns, and evidence-file pointers.
6. Reuse collected facts. Do not run duplicate commands merely because two report sections need the same information.
7. Include no more than 20 lines of sanitized evidence per finding in the report.
8. Do not truncate collection needed for completeness, such as listener or firewall inventories. Summarize complete evidence instead.
9. For very large systems, process containers and services in bounded batches and update the normalized inventory incrementally.
10. If the context becomes constrained, preserve the normalized inventory and evidence files; discard redundant raw excerpts rather than omitting audit domains.

Workflow

1. Preflight

• Determine local versus SSH execution.
• Validate the target and test noninteractive access once.
• Record current user, groups, root status, and availability of sudo -n.
• Set umask 077 for local evidence files.
• Create a sanitized evidence directory.
• Stop cleanly if the target cannot be accessed; do not loop on authentication failures.

2. Detect the platform

Identify before selecting commands:

• Distribution and family
• Kernel and architecture
• Physical, VM, VPS, container, or unknown platform
• Init and service manager
• Package manager
• Logging system
• Firewall implementation
• Container runtime
• Filesystem technologies
• Available commands and privilege level

Use references/portability.md for detection and fallbacks.

3. Collect host evidence

Load references/core-host-checks.md. Collect identity, hardware, memory, storage, processes, tuning, packages, logs, and backup evidence.

4. Collect network and security evidence

Load references/network-security-checks.md. Collect interfaces, routes, DNS, listeners, firewall, SSH, login activity, and TLS metadata.

5. Collect services and application evidence

Load references/services-containers-checks.md. Execute only detected or applicable modules for init services, cron, containers, Compose, environment-file metadata, mail, web, databases, monitoring, and VPNs.

6. Correlate evidence

Build a normalized inventory:

• Every listening TCP and UDP port mapped to a process and, where applicable, a container or service
• Every running container documented
• Every detected Compose project documented
• Every significant running or enabled host service documented
• Every scheduled task documented
• Every detected certificate documented
• Every secret or environment file represented by metadata only
• Every backup mechanism documented
• Service URLs and dependencies labelled with high, medium, or low confidence

Do not invent relationships. Mark inferences explicitly.

7. Analyse and report

Use references/report-template.md. Prioritize findings as Critical, High, Medium, or Low and include evidence, impact, recommendation, confidence, and false-positive considerations.

Do not claim software is end-of-life from memory alone. Mark lifecycle Not evaluated unless current authoritative evidence is available and external lookups are allowed.

Modes

Standard

Use low-impact, bounded checks. Avoid broad filesystem traversal, large log reads, recursive usage scans, and per-file content inspection.

Deep

Add scoped filesystem searches, longer bounded logs, per-container inspection, detailed dependency mapping, and storage-specific health data. Still avoid unrestricted find /, remote filesystems, active tests, or configuration changes.

Result statuses

Use only:

ok
warning
critical
not-installed
not-configured
not-detected
unsupported
permission-denied
partial
timeout
failed
not-evaluated

Completion requirements

Before finishing, verify that the report accounts for all locally visible listeners, running containers, detected Compose projects, significant services, scheduled tasks, firewall implementations, certificates, secret-file paths, backup mechanisms, incomplete checks, and Critical or High findings.

If a domain is absent, retain its report section and write Status: Not detected or not applicable. If evidence is incomplete, write Status: Partial — <reason>.