heinzel-security
SolidRun a heinzel security audit on a server — SSH hardening (password auth, weak algos, root login), firewall, user account hygiene, listening services, kernel hardening (ASLR, IP forwarding), file permissions, SUID/SGID audit, fail2ban. Use when the user asks for a "security audit", "security review", "hardening check", or to "audit security on <host>". Do NOT auto-invoke on generic phrases like "check server <host>". Covers Linux (Debian, Ubuntu, RHEL, CentOS, Fedora, SUSE) and macOS (SIP, FileVault, Gatekeeper).
Install
Quality Score: 88/100
Skill Content
Details
- Author
- wintermeyer
- Repository
- wintermeyer/heinzel
- Created
- 5 months ago
- Last Updated
- today
- Language
- Shell
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
heinzel-housekeeping
Run a heinzel housekeeping (health) inspection on a server — disk, memory, load, pending updates, firewall, SSL certs, failed systemd units, logs, kernel reboot status, and service-specific checks. Use when the user asks to "run housekeeping", "housekeeping report", "run a health check on <host>", or "do routine inspection". Do NOT auto-invoke for ambiguous requests like "check server <host>" — that's reserved for quick queries. Covers Linux (Debian, Ubuntu, RHEL, CentOS, Fedora, SUSE) and macOS.
security-audit
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.
infra-audit
Server / infrastructure security audit of LIVE hosts over SSH (12 dimensions IS1-IS12: SSH hardening, accounts, network exposure, TLS, firewall, patch posture, logging, web services, Docker, databases, filesystem, host secrets). Deterministic collector + parallel LLM analysts; dual-vantage (internal SSH + external via proxy); per-target authorization gate; consent-gated tool installs; read-only with one consented exception. Flags: --host user@addr[:port] (single ad-hoc host), --quick (IS1+IS3+IS4, <3 min/host), --dimensions IS1,IS3,… (explicit subset), --no-install (hard read-only), --dry-run (print commands, no connections), --resume <run-dir> (continue interrupted run), --proxy <url> (external-scan proxy), --external direct (proxyless external scan, polite timing), --skip-external (internal vantage only), --deep-scan (nmap -p- full port sweep), --confirm-targets <sha256> (non-interactive authorization).