Host Hardening Audit

The problem

Exposing a server to the internet without a verified security baseline invites automated brute-force attacks and lateral movement. Manually checking SSH configs, firewall rules, and listening ports is error-prone and often leads to accidental lockouts.

What it does

• Performs a non-destructive, read-only audit of OS versions, listening services, and firewall states.
• Categorizes findings into critical, important, and advisory risk buckets based on exposure.
• Implements hardening steps in a reversible order, prioritizing connectivity persistence.
• Verifies every change with before-and-after command diffs to ensure the intended posture.
• Generates a final report with actions taken, rollback instructions, and remaining risks.

Frameworks & tools

Linux distributions (Ubuntu, Debian, RHEL, CentOS), SSH, UFW, Firewall-cmd, nftables, systemd, and fail2ban.

Why this beats prompting it yourself

A standard LLM might suggest dangerous firewall commands that drop your current session. This skill enforces a "test-before-lock" workflow, requiring verification of new SSH keys and admin IP whitelisting before disabling legacy access or applying default-deny rules.

Use cases

• Preparing a fresh VPS or bare-metal server for its first public IP exposure.
• Conducting a post-incident review to identify stale users or unauthorized listeners.
• Performing periodic security hygiene passes on a fleet of small servers.
• Hardening a development box before deploying a reverse proxy or tunnel.

Known limitations

Not a replacement for full CIS or STIG compliance suites. Requires read-only shell access to execute audit commands.