security-audit

---
name: security-audit
description: Run a structured security audit of Linux servers and self-hosted stacks, then harden what's found. Covers Ubuntu/Debian hardening (SSH, sudo, firewall, kernel sysctls, systemd isolation, patching), Docker and container escape paths, exposed datastores (Redis, Postgres, Qdrant, MongoDB), secrets handling, and AI agent risks such as webhook authentication, tool permissions, and prompt injection reaching real tool calls. Use whenever the user asks to audit, review, harden, or lock down a server, VPS, container stack, or agent deployment — and for narrower questions that are really audit questions, like "is my Redis exposed", "is this server safe", "чи безпечний мій сервер", "проведи аудит серверів", "закрий вразливості", or "why is this port open" — or when they paste a docker-compose.yml, sshd_config, or firewall ruleset and ask whether it looks right. Prefer this over ad-hoc checking, since it enforces read-only diagnostics, consistent severity ratings, and a repeatable report.
---

# Security Audit

A repeatable method for auditing a Linux server or self-hosted stack and fixing what's found.

The goal is not to produce a long list of theoretical weaknesses. It's to find the handful of things that would actually let someone in, rank them honestly, and close them without breaking the system that's running.

## Non-negotiables

**Authorization first.** Audit only infrastructure the user owns or is explicitly authorized to test. If scope is ambiguous — a shared host, a client's server, a third-party SaaS — ask before touching anything. Never scan or probe systems outside the agreed scope.

**Read-only by default.** Phases 1–7 are diagnostics only. Do not change configs, restart services, kill processes, install packages, or modify firewall rules during the audit. Discovery and remediation are separate steps for a reason: a half-finished audit that already broke SSH is worse than no audit.

**Remediation is opt-in and incremental.** After the report, propose fixes ranked by severity. Apply them only with explicit confirmation, one logical group at a time, and verify after each group. Never batch a firewall change with an SSH change — if connectivity dies you won't know which one did it.

**Never lock yourself out.** Before touching SSH config, firewall rules, or user accounts: confirm a second access path exists (console/rescue mode at the provider, a second session held open). Keep an open session while testing changes in a new one.

**Record findings as you go.** Write to a findings file after each phase rather than holding everything in context. Long audits produce a lot of output and details get lost.

## Workflow

### Phase 0 — Scope

Establish before running anything:

- Which hosts, and how you reach them (SSH, local, Docker exec)
- Whether these are production systems and what downtime is acceptable
- Whether an inventory already exists or you're discovering from scratch
- What the user is actually worried about — a specific incident, compliance, or general hygiene

An audit driven by a real concern ("I think someone hit my n8n instance") should follow that thread first, then broaden.

### Phase 1 — Inventory

You cannot secure what you haven't enumerated. Establish: OS version and patch level, running services, listening sockets, containers, users with shell access, and what's published to the internet.

See `references/commands.md` for the diagnostic command set. Run the inventory block first — everything downstream depends on it.

### Phase 2 — Network surface

The single highest-yield phase. Most real compromises of self-hosted stacks come from a service that was never meant to be public.

Compare what's listening on `0.0.0.0` against what the firewall claims to allow, and verify from outside the host — a firewall that looks correct locally can be bypassed entirely by Docker's iptables handling. Details in `references/agent-stack.md` (Docker section) and `references/ubuntu.md` (firewall section).

### Phase 3 — Access and authentication

SSH configuration, user accounts, sudo rules, key hygiene, brute-force protection. See `references/ubuntu.md`.

### Phase 4 — Secrets

Where credentials live and who can read them: environment files, compose files, systemd unit files, shell history, git history, log output, backups. See `references/agent-stack.md` (secrets section).

### Phase 5 — Datastores and containers

Default-open databases and container escape paths. Redis, Postgres, Qdrant and friends ship with defaults that assume a trusted network; Docker adds its own set of foot-guns. See `references/agent-stack.md`.

### Phase 6 — Agent-specific risk

Applies when the stack runs LLM agents. Untrusted text reaching a model that holds real tools is a genuine attack surface, and it isn't addressed by any amount of network hardening. See `references/agent-stack.md` (agent section).

### Phase 7 — Patching, logging, monitoring

Unattended upgrades, package currency, log retention, whether anything would actually notice an intrusion. See `references/ubuntu.md`.

### Phase 8 — Report

Write the report before proposing any fix. The user needs the whole picture to decide what matters.

### Phase 9 — Remediation

Work down from Critical. For each fix: state what changes, what could break, how to roll back. Apply, verify, move on.

## Severity

Rate by real exploitability on this host, not by CVSS in the abstract. A theoretical flaw behind three layers of protection is not Critical, and calling it Critical trains the user to ignore the label.

| Severity | Meaning |
|---|---|
| **Critical** | Remotely exploitable now, no authentication needed, leads to data access or code execution. Unauthenticated Redis on a public IP. Exposed admin UI with default credentials. |
| **High** | Exploitable with one additional step or requires a credential likely to leak. Password SSH open to the internet. Secrets world-readable on a multi-user host. Agent with shell access reading untrusted input. |
| **Medium** | Meaningful weakening of defence, needs a chained condition. Missing fail2ban. Container running as root without escape path. Missing security headers. |
| **Low** | Hygiene and defence-in-depth. Verbose version banners. Absent sysctl hardening. Log retention too short. |

Split findings the user cannot act on yet into a separate "Accepted risk / needs decision" section rather than padding the main list.

## Report format

Use this structure:

```markdown
# Security audit — <host or stack> — <date>

## Scope
Hosts audited, method of access, what was deliberately excluded.

## Summary
Three to five sentences. Overall posture, the single most urgent item,
and whether anything suggests an active compromise.

## Findings

### [CRITICAL] Short descriptive title
**What:** the specific misconfiguration, with evidence (command output, config line, file path).
**Why it matters:** the concrete path from this to damage. No generic risk language.
**Fix:** exact change, plus what it might break.

### [HIGH] ...

## Verified good
What was checked and found correctly configured. This matters — it tells the
user what they don't need to worry about and shows the audit's coverage.

## Recommended order of work
Numbered, most urgent first, with rough effort per item.
```

Ground every finding in evidence you actually collected. If something couldn't be verified, say so explicitly rather than assuming either way — "could not confirm whether Qdrant requires an API key; the container wasn't reachable from the audit host" is a useful sentence.

## Signs of active compromise

If any of these turn up, stop the routine audit and tell the user immediately — the priority shifts from hardening to incident response, and evidence gets destroyed by careless remediation:

- Unexpected SSH keys in any `authorized_keys`
- Unknown users, or existing users with a shell they shouldn't have
- Unexplained cron jobs, systemd timers, or units in `/etc/systemd/system/`
- Outbound connections to unknown hosts, especially from database or agent containers
- Processes running from `/tmp`, `/dev/shm`, or with names mimicking kernel threads
- Gaps in logs, or `auth.log` truncated
- Unexpected files in web roots or container volumes
- Sudden resource use consistent with cryptomining

Advise preserving state (snapshot the disk before changes) and treating credentials on that host as burned.

## Reference files

- `references/ubuntu.md` — Ubuntu/Debian host hardening: SSH, users and sudo, firewall, kernel sysctls, systemd service isolation, AppArmor, patching, logging
- `references/agent-stack.md` — Docker, datastores (Redis, Postgres, Qdrant), reverse proxies, webhooks, secrets, and AI-agent-specific risk
- `references/commands.md` — the read-only diagnostic command set, grouped by phase