agentleFS
NikoxkxNikoxkx/Agent-Skills/skills/devops/security-hardening/SKILL.md

security-hardening

Skill1 starsChanged 5 months agoApache-2.0View on GitHub

Hardens server, container, and cloud infrastructure against common attacks. Use when preparing infrastructure for production or after a security audit.

25 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use coordinate, incident-response and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • swyxioSkill

    coordinate

    Coordinate focused Luna helpers for bounded work and Astra advisers for difficult design questions while doing the main work yourself.

    Also in 3 projects that use this

  • AnthropicSkill

    incident-response

    Run an incident response workflow — triage, communicate, and write postmortem. Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution.

    Also in 5 projects that use this

  • OpenAISkill

    observability

    Vercel Observability expert guidance — Drains (logs, traces, speed insights, web analytics), Web Analytics, Speed Insights, runtime logs, custom events, OpenTelemetry integration, and monitoring dashboards. Use when instrumenting, debugging, or optimizing application performance and user experience on Vercel.

    Also in 4 projects that use this

  • barisariburnuSkill

    performance-optimization

    Complete performance optimization guide for Next.js applications including frontend, backend, database, caching, and general optimization strategies. Use when improving performance, reducing bundle size, optimizing queries, or implementing caching.

    Also in 4 projects that use this

  • GitHubSkill

    accessibility-audit

    Audits actual components and routes against applicable WCAG 2.2 A/AA criteria using consumer-owned design-system evidence and repository tools. Use when asked for an accessibility audit, a11y check, keyboard or focus review, contrast check, or screen-reader verification.

    Also in 3 projects that use this

  • MicrosoftSkill

    api-design

    Guide for designing and documenting RESTful APIs. Use when asked to design an API, create endpoints, or document an API.

    Also in 5 projects that use this

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 22 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After a penetration test or vulnerability scan highlights infrastructure issues.

    line 20
  2. Very specific:

    Run as non-root user (create user in Dockerfile, USER instruction).

    line 37
  3. Distinctive:

    Read-only root filesystem + tmpfs for writable dirs.

    line 38
  4. Distinctive:

    Use distroless or minimal base images.

    line 41
  5. Distinctive:

    Use IAM roles for EC2 / service accounts instead of long-lived keys.

    line 45
  6. Distinctive:

    Never in env vars or code.

    line 50
  7. Distinctive:

    Use AWS Secrets Manager / Parameter Store / GCP Secret Manager / HashiCorp Vault.

    line 51
  8. Distinctive:

    Legacy apps that require root: Document the risk and isolate them as much as possible.

    line 72
  9. Distinctive:

    Run CIS benchmarks or a scanner (Lynis, Docker Bench, Prowler, ScoutSuite).

    line 77

“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Overview

Provides a prioritized hardening checklist and implementation guide for OS, containers, and cloud accounts. Covers unattended upgrades, SSH key-only access + fail2ban, firewall (ufw or security groups), Docker non-root + read-only FS + no privileged, cloud IAM least-privilege + SCPs, secret management, network segmentation, and a severity-based checklist.

When to Use This Skill

  • Preparing infrastructure for production or a security review.
  • After a penetration test or vulnerability scan highlights infrastructure issues.
  • Onboarding a new cloud account or server.

Prerequisites

  • Servers or containers you control.
  • Cloud account (AWS/GCP/Azure) admin access for IAM work.
  • Ability to rebuild or update existing infrastructure.

Steps

  1. OS hardening (Linux):
    • Automatic security updates (unattended-upgrades on Debian/Ubuntu, dnf-automatic on RHEL).
    • SSH: key-only auth, disable password, disable root login, change port or use fail2ban.
    • Firewall: ufw or firewalld — allow only necessary ports from specific sources.
  2. Docker / container hardening:
    • Run as non-root user (create user in Dockerfile, USER instruction).
    • Read-only root filesystem + tmpfs for writable dirs.
    • Drop all capabilities, add only needed ones.
    • No --privileged, no --network host unless absolutely required.
    • Use distroless or minimal base images.
  3. Cloud IAM:
    • Least privilege: start with zero and grant only required actions/resources.
    • Use IAM roles for EC2 / service accounts instead of long-lived keys.
    • Enable MFA for all human users.
    • Service control policies (SCPs) / organization policies to prevent dangerous actions at scale.
  4. Secrets:
    • Never in env vars or code.
    • Use AWS Secrets Manager / Parameter Store / GCP Secret Manager / HashiCorp Vault.
    • Rotate regularly.
  5. Network:
    • Private subnets for app/DB tiers.
    • Security groups / NACLs / firewall rules with least exposure.
    • WAF in front of public endpoints.
  6. Output:
    • Hardening checklist by severity (Critical / High / Medium).
    • Dockerfile snippet showing hardened user + read-only.
    • Terraform / cloudformation snippets for IAM roles and security groups.
    • Ansible / cloud-init for OS hardening.
    • Verification commands (ss -tuln, docker inspect, aws iam simulate-principal-policy).

Examples

A hardened Dockerfile, ufw + SSH config, least-privilege IAM role for a web app, and a full checklist with commands are included.

Edge Cases & Error Handling

  • Legacy apps that require root: Document the risk and isolate them as much as possible.
  • Break-glass access: Maintain emergency procedures with additional approvals.

Verification

  1. Run CIS benchmarks or a scanner (Lynis, Docker Bench, Prowler, ScoutSuite).
  2. Attempt SSH with password — denied.
  3. Container runs as non-root and read-only FS (test by trying to write to /).
  4. IAM policy simulation shows only allowed actions.
  5. Success: Infrastructure passes automated hardening scanners with minimal or no critical findings, and manual tests confirm reduced attack surface.

References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.