security-auditlisted

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.
art12slavik/skill-security-audit · ★ 0 · DevOps & Infrastructure · score 72

Install: claude install-skill art12slavik/skill-security-audit

# 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 yo