← 返回 Skills 市场
discovery219

Linux Firewall Hardening

作者 discovery219 · GitHub ↗ · v1.0.0 · MIT-0
cross-platform ✓ 安全检测通过
55
总下载
1
收藏
0
当前安装
1
版本数
在 OpenClaw 中安装
/install linux-firewall-hardening
功能描述
Safe Linux firewall hardening with backend detection, idempotent atomic rules, rollback protection, and AI-executable state-machine workflows. Covers ufw, fi...
使用说明 (SKILL.md)

Linux Firewall Hardening

When to Use

  • Check if a Linux server has active firewall protection.
  • Enable and configure a firewall without locking yourself out of SSH.
  • Audit existing rules, troubleshoot connectivity, or apply a security profile.
  • Automate firewall hardening via an AI agent or CI/CD pipeline.

When NOT to Use

Condition Alternative
Kubernetes worker node Use NetworkPolicies / CiliumNetworkPolicy
Firewall managed by Terraform/Ansible/Puppet/Chef Update IaC source of truth
Cloud workload with Security Group / NSG only Use cloud provider's firewall API
Inside a container Escalate to host operator
WSL2, macOS, or shared/managed hosting See references/special-environments.md

Support files: scripts/audit-firewall.sh (run first), scripts/firewall-plan.sh (dry-run), scripts/firewall-verify.sh (post-apply). Detailed backend guides, Docker/K8s policies, observability, compliance, and recovery are in references/.


Prerequisites

  • Root or sudo access.
  • An active SSH session (risk of lockout).
  • Know which ports your services use.

NEVER DO (14 Rules)

  1. Never flush iptables/nftables on Kubernetes nodes. CNI plugins manage netfilter.
  2. Never run iptables -F or nft flush ruleset without a verified backup. Docker/K8s networking will break.
  3. Never disable firewalld and use raw iptables simultaneously. Undefined behavior.
  4. Never set DROP policy on INPUT before allowing your current SSH port. Immediate lockout.
  5. Never disable Docker's iptables management without replacement NAT/routing rules.
  6. Never restart networking.service or NetworkManager remotely without console access.
  7. Never apply cloud SG and host firewall changes simultaneously without testing.
  8. Never enable logging on high-traffic DROP rules without limit rate. Disk flood.
  9. Never manage nftables/iptables directly when ufw or firewalld owns the policy. Split-brain state.
  10. Never apply outbound default-deny without explicitly allowing DNS, NTP, package mirrors.
  11. Never restore firewall backups from a different host, kernel version, or backend mode.
  12. Never assume IPv4 rules protect IPv6. Verify both stacks separately.
  13. Never change sysctl hardening values on K8s/CNI hosts without explicit CNI profile support.
  14. Never enable verbose packet logging without rate limits and log rotation.

State Machine

Follow states in order. Do not skip.

DETECT → SELECT → PLAN → VALIDATE → APPLY → VERIFY

State: DETECT

Run the audit script:

bash scripts/audit-firewall.sh           # Human-readable
bash scripts/audit-firewall.sh --json    # Machine-readable

Key outputs: confidence, risk_tier, recommended_backend, halt_reasons, k8s_node, iac_owner.

Risk Tiers & Confidence Gating

Tier Confidence Agent Behavior
auto ≥ 90% Proceed automatically to PLAN
confirmed 70–89% Proceed but require human confirmation before APPLY
manual 50–69% Audit-only mode. Generate recommendations, do not apply.
halt \x3C 50% Stop immediately. Escalate findings to operator.

Additional halt triggers (regardless of confidence): containerized, K8s node, IaC managed, no rollback mechanism available.

Decision Tree

Condition Path Detail
Risk tier = halt STOP Resolve blockers first
Inside container STOP Escalate to host operator
K8s node detected STOP references/k8s-policy.md
Ubuntu/Debian + ufw active Phase: UFW references/backend-ufw.md
ufw + firewalld both active STOP Resolve conflict
RHEL/Rocky/Alma + firewalld active Phase: firewalld references/backend-firewalld.md
nftables active, no frontend Phase: nftables references/backend-nftables.md
iptables only Phase: iptables references/backend-iptables.md
Docker host Apply Docker Hardening after phase above references/docker-hardening.md

Ownership Boundary

Before modifying rules, verify no IaC tool manages the firewall. If Terraform/Ansible/Puppet/Chef/cloud-init is detected → do not mutate. Update the source of truth instead. Full detection logic is in scripts/audit-firewall.sh.


State: SELECT

Optionally load a pre-built security profile (references/security-profiles.md):

Profile Use Case
public-web-server Open 22, 80, 443. Rate-limit SSH.
internal-database SSH from mgmt subnet only. DB port from app subnet only.
bastion-host SSH only. Aggressive rate limiting.
zero-trust-node Default deny all inbound and outbound.

Or use declarative YAML (references/declarative-policy.md):

Imperative (state machine) → Ad-hoc hardening, incident response
Declarative (YAML)        → GitOps, multi-host, reproducible
Mixed                     → YAML as source-of-truth, state machine for verification

State: PLAN (NEW)

Generate a dry-run diff before applying:

bash scripts/firewall-plan.sh --profile public-web-server
bash scripts/firewall-plan.sh --ports 22,80,443
bash scripts/firewall-plan.sh --json     # Machine-readable diff

Review the output. If risk_tier is confirmed, present the plan and wait for human confirmation before APPLY.


State: VALIDATE

1. Create Backup (Mandatory)

BACKUP_DIR="$HOME/firewall-backup-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"

sudo iptables-save > "$BACKUP_DIR/iptables-v4.rules" 2>/dev/null || true
sudo ip6tables-save > "$BACKUP_DIR/iptables-v6.rules" 2>/dev/null || true
sudo nft list ruleset > "$BACKUP_DIR/nftables.rules" 2>/dev/null || true
sudo ufw status verbose > "$BACKUP_DIR/ufw-status.txt" 2>/dev/null || true
sudo firewall-cmd --list-all --zone=$(sudo firewall-cmd --get-default-zone) > "$BACKUP_DIR/firewalld-default.txt" 2>/dev/null || true

echo "Backup saved to $BACKUP_DIR"

2. Schedule Rollback (Mandatory for Remote)

The rollback restores from backup — not just disables the firewall — so Docker NAT and pre-existing rules are preserved. Dual-backend: at preferred, systemd-run fallback. Full script in SKILL.md under Validate state (see previous version), also summarized in references/recovery.md.

3. Pre-Flight Checklist

  • Backup created successfully
  • Rollback scheduled (verify with atq or systemctl --user list-units)
  • Second SSH session open and idle
  • Real SSH port identified
  • Confidence ≥ 70% and risk_tier is auto or confirmed
  • Ownership verified — no IaC managing firewall
  • Change window appropriate (maintenance window or low traffic)
  • PLAN output reviewed and approved

State: APPLY

All commands use idempotent patterns: check-before-set. Safe to run repeatedly.

Backend Pattern
ufw sudo ufw status | awk '{print $1}' | grep -qx "22/tcp" || sudo ufw allow 22/tcp
firewalld sudo firewall-cmd --query-service=ssh || sudo firewall-cmd --permanent --add-service=ssh
iptables sudo iptables -C INPUT -p tcp --dport 22 -j ACCEPT 2>/dev/null || sudo iptables -A ...
nftables Atomic ruleset: nft -c -f /etc/nftables.conf.new && nft -f /etc/nftables.conf.new

Full step-by-step commands per backend: references/backend-ufw.md, references/backend-firewalld.md, references/backend-nftables.md, references/backend-iptables.md.

Docker Hosts

Docker bypasses ufw by default. Use DOCKER-USER chain. Full guide: references/docker-hardening.md.

Kubernetes Nodes

Default: AUDIT-ONLY. Never modify host firewall. Full policy: references/k8s-policy.md.


State: VERIFY

Run post-hardening checks:

bash scripts/firewall-verify.sh

Success criteria (all must pass):

  1. SSH remains reachable from current and second session
  2. Only intended ports are externally reachable
  3. Rules survive reboot (verified via service persistence)
  4. IPv6 exposure matches IPv4 policy
  5. Docker-published ports are intentional (no accidental 0.0.0.0)
  6. fail2ban jails active (if installed) with correct backend
  7. Rollback timer cancelled after successful verification

fail2ban Integration

If fail2ban is installed:

Host Firewall Recommended backend
ufw ufw or systemd
firewalld firewalld
nftables nftables
iptables auto (default)

After changing backend: sudo fail2ban-client restart && sudo fail2ban-client status sshd.


Recovery

If you lose connectivity, priority order:

  1. Wait for auto-rollback (scheduled during VALIDATE)
  2. Use second SSH session
  3. Cloud serial console / hypervisor console
  4. Restore from backup
  5. Emergency ACCEPT (last resort — exposes host completely)

Full procedures: references/recovery.md.


Cloud Security Group Reminder

The host firewall is your second layer. Verify cloud SGs are aligned:

Cloud Outer Firewall
AWS Security Groups
GCP VPC Firewall Rules
Azure Network Security Groups
DigitalOcean/Linode/Vultr Cloud Firewall

Observability

Establish baselines after hardening: conntrack usage, dropped packet rates, fail2ban ban rate. Monitor for anomalies. Full guide: references/observability.md.

Compliance

Practices map to CIS, PCI-DSS, and SOC2 controls. Full mapping: references/compliance.md.

Quick Reference

Task Command
Audit environment bash scripts/audit-firewall.sh --json
Plan changes bash scripts/firewall-plan.sh --profile web
Verify after apply bash scripts/firewall-verify.sh
Allow port (ufw, idempotent) sudo ufw status | awk '{print $1}' | grep -qx "80/tcp" || sudo ufw allow 80/tcp
View ufw rules sudo ufw status numbered
View nft rules sudo nft list ruleset
View iptables rules sudo iptables -L -n -v
View ip6tables rules sudo ip6tables -L -n -v
Atomic iptables replace sudo iptables-restore \x3C /tmp/rules.v4
Dry-run nftables sudo nft -c -f /etc/nftables.conf
Backup rules sudo iptables-save > ~/iptables.backup
fail2ban status sudo fail2ban-client status sshd
Cancel rollback (at) atrm \x3Cjobid>
Cancel rollback (systemd-run) systemctl --user stop firewall-rollback-\x3Cpid>

See Also

  • references/backend-ufw.md — Full UFW phase
  • references/backend-firewalld.md — Full firewalld phase
  • references/backend-nftables.md — Full nftables phase
  • references/backend-iptables.md — Full iptables phase
  • references/docker-hardening.md — Docker firewall hardening
  • references/k8s-policy.md — Kubernetes node policy
  • references/security-profiles.md — Pre-built configurations
  • references/declarative-policy.md — YAML policy schema
  • references/observability.md — Monitoring and baselines
  • references/compliance.md — CIS/PCI-DSS/SOC2 mapping
  • references/recovery.md — Recovery procedures
  • references/special-environments.md — WSL2, containers, exit codes
  • scripts/audit-firewall.sh — Environment detection
  • scripts/firewall-plan.sh — Dry-run diff
  • scripts/firewall-verify.sh — Post-apply verification
安全使用建议
Install only if you intend to let an agent help audit or change Linux firewall settings. Run the audit and plan steps first, review the generated changes, keep console or second-SSH recovery access, and confirm rollback is scheduled before applying persistent firewall rules.
功能分析
Type: OpenClaw Skill Name: linux-firewall-hardening Version: 1.0.0 The linux-firewall-hardening skill bundle is a comprehensive and safety-focused toolkit for managing Linux firewalls across multiple backends (ufw, firewalld, nftables, iptables). It features a robust state-machine workflow with built-in risk-tier gating and environment detection via 'scripts/audit-firewall.sh' to prevent accidental disruption of Kubernetes, Docker, or IaC-managed environments. The bundle includes mandatory rollback mechanisms using 'at' or 'systemd-run' and dry-run planning ('scripts/firewall-plan.sh') to ensure administrative access is preserved. No malicious logic, data exfiltration, or prompt-injection attempts were detected; the code and instructions strictly adhere to the stated purpose of secure system hardening.
能力评估
Purpose & Capability
The artifacts consistently describe firewall auditing, planning, applying, verification, and recovery. The capabilities are high-impact but match the stated purpose.
Instruction Scope
The state-machine workflow includes detection, dry-run planning, validation, rollback, and verification, with explicit stop conditions for Kubernetes, containers, and IaC-managed hosts.
Install Mechanism
There is no install spec, but bundled shell scripts are referenced for user execution. Metadata does not declare OS or binary requirements even though the documentation clearly requires Linux, sudo/root, and firewall tools.
Credentials
The skill changes host firewall rules, system services, and optionally sysctl settings. These are proportionate to firewall hardening but can disrupt access if applied incorrectly.
Persistence & Privilege
The instructions include persistent firewall configuration and short-lived rollback timers. This is disclosed and safety-oriented, but users should verify and cancel rollback jobs after successful verification.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install linux-firewall-hardening
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /linux-firewall-hardening 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v1.0.0
Phase 5: risk-tier gating, PLAN state, split SKILL.md to 305 lines, 12 reference files, standardized exit codes
元数据
Slug linux-firewall-hardening
版本 1.0.0
许可证 MIT-0
累计安装 0
当前安装数 0
历史版本数 1
常见问题

Linux Firewall Hardening 是什么?

Safe Linux firewall hardening with backend detection, idempotent atomic rules, rollback protection, and AI-executable state-machine workflows. Covers ufw, fi... 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 55 次。

如何安装 Linux Firewall Hardening?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install linux-firewall-hardening」即可一键安装,无需额外配置。

Linux Firewall Hardening 是免费的吗?

是的,Linux Firewall Hardening 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。

Linux Firewall Hardening 支持哪些平台?

Linux Firewall Hardening 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。

谁开发了 Linux Firewall Hardening?

由 discovery219(@discovery219)开发并维护,当前版本 v1.0.0。

💬 留言讨论