服务器安全加固

设计原则：最小开放 —— 能不开就不开，能只给一台就不给一个网段，能只给公钥就不留口令。

合规基线：默认等保一级 —— 用户没指定等级时，一律按《GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求》的
第一级安全要求（自主保护级） 做检查与留证（§2）；用户明确说「二级 / 三级 / 四级」才按对应等级叠加增量控制点（§2.3）。

一句话：先查清谁要访问、从哪个地址来、到底哪些端口真能从公网连上 → 备份防火墙并挂自动回滚保险 → 只按 /32 精确放行 + 兜底 drop → 验证 → 固化并撤保险 → 按等保口径逐项留证据。
全端口收口更激进：除 SSH 与 nginx 的 80/443 外一律不对外，远程访问改走 SSH 隧道。

> 本技能管主机的网络暴露面（谁能连哪个端口）、登录方式（口令 vs 公钥）与等保通用要求的自查留证。
> 不管应用层鉴权、证书、WAF，也不替代测评机构的测评结论。
> 可直接跑的脚本见 §11；等保逐条检查项与命令见 references/mlps-l1-checklist.md。

约定：本文示例里的 x.x.x.x / y.y.y.y 代表任意真实地址，1234 代表任意端口，
<主机A> / <主机B> 代表任意目标机，<构建机> 代表发起运维的跳板机。
落地时替换成你自己的值即可 —— 技能本身不含任何具体环境信息。

0. 五条原则

1. 优化项清单

> 本表只是待办列表，不带「已做/未做」状态 —— 每台机器做到哪一步、什么时候做的，
> 写进你自己的运维报告，不要回填进本技能。
> 顺序建议：1（白名单）→ 5（免密+关口令）→ 6（抗爆破）→ 7/8 → 2/3/4（收口）→ 9（等保自查出报告）。
> 白名单先做——它把绝大多数扫描挡在门外，之后的爆破审计才有意义。

默认交付流程（用户只说「做安全加固」也按这个走）：

2. 等保合规基线（默认等保一级）

依据 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（业界俗称「等保 2.0」）。
第一级即「自主保护级」：系统受破坏后仅损害公民、法人和其他组织的合法权益，不损害社会秩序和公共利益、不损害国家安全。
三个必须先对齐的认知：

• 无需备案、无需测评 ≠ 不用管：安全建设仍要按标准落实，且公安机关将其纳入监督检查——查的就是「有没有做、有没有记录」。
• 技术只到「安全计算环境」：集中管控/集中审计所在的安全管理中心是二级及以上才出现的控制点，一级明确记为不适用。
• 管理五项齐全但要求是「基本」：有制度、有人负责、有培训、有建设与运维管理即可；
  背景审查、外部人员访问权限清理属二级及以上要求，一级不因缺这两项判不符合。

2.1 等级怎么定：默认一级，除非用户指定

🔴 三条纪律：

1. 默认就是一级，不要因为「看着像生产环境」自行升到二级/三级，也不要因为「才一级」就把检查做浅；
2. 不许把没查的写成「符合」 —— 一级允许「部分符合 + 待整改」，如实记录比凑表更有用；
3. 报告里分清楚「主机可验证」与「需人工确认」，后者不要替人签字。

2.2 一级检查总表（技术 5 层面 + 管理 5 层面）

技术层面——主机上基本都能查到，逐条命令见 references/mlps-l1-checklist.md：

管理层面——非主机可验证，靠文档 + 访谈，本技能只给清单与判定口径：

> 一级无需备案：安全建设管理里的「定级和备案」按「已完成自主定级、留存定级过程材料」把握即可，不要去催备案回执。

2.3 等级差异：什么时候需要升级（要点，非逐条对照）

用户提到更高等级时，按这张表把增量补上；二级的逐条落法见 references/mlps-l2-delta.md（编号 L2-01…L2-17，
与 --level 2 的脚本输出一一对应）。正式定级/测评以标准原文与测评机构意见为准。

2.4 判定口径与报告怎么出

证据三件套：命令或文件 + 输出摘要（别贴几千行） + 主机标识与时间。
同一台机器重复排查时，用上次的证据做对比，才能证明「真的改了」。

2.5 加固动作 ↔ 等保控制点映射（做过的活别浪费）

2.6 逐条检查项

• 完整检查表（每条：检查内容 / 命令 / 符合判据 / 证据 / 常见不符）
• 一级 → references/mlps-l1-checklist.md
• 二级增量 → references/mlps-l2-delta.md（L2-01…L2-17，含「一级→二级 gap 清单」与二级报告模板）
• 一键只读自查（输出 符合/部分符合/不符合/不适用/待人工确认 + 证据行 + 汇总）→

bash scripts/mlps-l1-check.sh              # 只读，默认按一级
bash scripts/mlps-l1-check.sh --level 2    # 一级全量 + 二级增量，分别计分
bash scripts/mlps-l1-check.sh --strict     # 有「不符合」时退出码 2（可进 CI）

> 脚本只读（不改任何配置、不重启服务），覆盖主机可验证项；文档/访谈/现场类会标成「待人工确认」，不会替你判符合。
> 三级/四级只会列出尚未覆盖的增量项，不会假装查过。

3. 第一步：勘察（跳过这步必踩坑）

3.1 谁在连这个端口？——从日志反查，不要问「应该是谁」

lastb -a | head -20
lastb -a | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -rn | head
lastb -a | awk 'NF>2{print $1}' | sort | uniq -c | sort -rn | head   # 被爆破的用户名

journalctl -u sshd --no-pager | grep "Accepted" | tail -50          # 合法来源只有这里
journalctl -u sshd --no-pager | grep -c "Accepted password"          # >0 = 口令登录还开着

• lastb 读 /var/log/btmp，只保留当月；「最早一行」= 重装/轮转时间，不是攻击起点。
• 取 IP 用 grep -Eo 正则比 awk $N 稳（短行会报 field -2）。
• Accepted 的来源与 lastb 的攻击 IP 交集为空，才说明「被爆破但没破」。
• grep -c "Accepted password" > 0 就是关闭口令登录的收益点（§6）。

3.2 这台机器到底有没有「内网地址」？

ip -4 -o addr show; ip route
ip -6 -o addr show scope global; ip -6 route | head -3

🔴 「公网地址直配网卡」是最常见的误判：IDC 把公网段直接配在 eno1 上（如 x.x.x.x/25），
两台同段二层互通（0.1ms），看着像内网，其实没有任何私有地址。此时「只开放内网 IP」做不到：

IPv6 别想当然当替代通路：两端实测（ping -6 + /dev/tcp），常见结果是「有地址没路由」。

3.3 端口是「主机进程」还是「docker 发布」？

ss -tlnp | grep <端口>            # process 是 docker-proxy 即为发布端口
docker ps --format '{{.Names}}\t{{.Ports}}'

🔴 docker -p 0.0.0.0:1234:1234 完全绕过 firewalld（§5.6 有实测证据）。这类端口只能靠
-p 127.0.0.1:1234:1234 收口，zone 里的白名单/drop 对它无效。

3.4 防火墙栈确认

systemctl is-active firewalld ufw 2>/dev/null
firewall-cmd --version                              # ≥0.6 才支持 rich rule 的 priority
grep -i FirewallBackend /etc/firewalld/firewalld.conf
firewall-cmd --list-all                             # ports / services / rich rules

4. SSH 端口 IP 白名单

4.1 规则结构（rich rule + 优先级，不要 source-based zone）

priority=-10  源在白名单 → 该端口 accept
priority=-5   其余所有源 → 该端口 drop
（zone 的 ports/services 隐含 priority 0，永远排在上面两条之后）

• 负优先级保证白名单判定先于 zone 自身 ports/services；同优先级按添加顺序。
• 🔴 绝对不要用 source-based zone：--add-source 会把该源全部流量切进新 zone，
  连带 80 与其它已放行端口一起断。必须同 zone 内用「只针对该端口的 rich rule」。

4.2 实施

TS=$(date +%Y%m%d-%H%M%S); cp -a /etc/firewalld /root/firewalld.bak.$TS
systemd-run --on-active=600 --unit=sshwl-rollback firewall-cmd --reload   # 回滚保险

for ip in <本机出口>/32 <构建机出口>/32 <对端IP>/32 <自身IP>/32; do
  firewall-cmd --add-rich-rule="rule family=\"ipv4\" priority=-10 source address=\"$ip\" port port=\"<端口>\" protocol=\"tcp\" accept"
done
firewall-cmd --add-rich-rule="rule family=\"ipv4\" priority=-5 port port=\"<端口>\" protocol=\"tcp\" drop"
firewall-cmd --remove-port=<端口>/tcp      # 摘掉「全开」声明，纵深防御

4.3 IPv6 必须同步

ss 显示 [::]:<端口> 或 *:<端口>（双栈）时，只写 family="ipv4" 的 drop，v6 侧仍全开：

firewall-cmd --add-rich-rule='rule family="ipv6" priority=-10 source address="<v6对端>/128" port port="<端口>" protocol="tcp" accept'
firewall-cmd --add-rich-rule='rule family="ipv6" priority=-5 port port="<端口>" protocol="tcp" drop'

4.4 固化

systemctl stop sshwl-rollback.timer sshwl-rollback.service
firewall-cmd --runtime-to-permanent
# ❌ 不要 --permanent 逐条重加（易漂移）；❌ 不要 --reload（flush docker DNAT）

5. 端口分层管控（全开 / 白名单 / 仅环回）

目标态：三档并存，按需定档，不要一刀切全关。

> ②是主力档：不是「关掉」，而是「只给固定几台机器开」——运维不用天天开隧道，外网扫描也进不来。
> 一刀切全禁只在「这个端口没人远程用」时才成立，否则第二天就有人要求重新放行。

5.1 先定「每个端口属于哪一档」（唯一需要人拍板的事）

• 定档原则：能进③就别进②，能进②就别进①。同一台机三档并存是常态，但每个端口必须明确归档。
• 白名单地址通常复用 SSH 那几个 /32（本机出口、构建机、对端服务器、自身）；新增对端时两处一起加。
• 定完档再动手，别边改边想——改错档位等于把该锁的打开、或把该开的锁死。

5.2 为什么「应用在 0.0.0.0 监听」≠「外面能连」——默认拒绝机制

firewalld 是默认拒绝模型：流量进入 filter_IN_public 链后，只有命中
ports / services / rich rule accept 才放行，其余一律被 zone 的兜底动作丢掉（实测表现为 Timeout，
说明包根本没被接受，不是被应用拒绝）。

所以只要不 --add-port，应用绑 0.0.0.0 也是外面连不上的。实测：

# ① 临时起一个 0.0.0.0:11111 的监听，且 firewalld 不放行
python3 -m http.server 11111 --bind 0.0.0.0 &
ss -tlnp | grep 11111            # LISTEN 0.0.0.0:11111  ← 确实全接口监听
firewall-cmd --list-ports        # 里面没有 11111

# ② 从外部探测 → TimeoutError（防火墙挡住了，应用毫不知情）
# ③ firewall-cmd --add-port=11111/tcp --timeout=60 之后再探测 → OPEN
# ④ --remove-port=11111/tcp 后探测又回到 Timeout

这条结论的价值：收口的主力是「不放行」，不是「改应用」。应用绑不绑 0.0.0.0 只影响
「同机容器/进程能不能连」，不影响公网可达性。

🔴 但这个「默认拒绝」有 6 个失效例外，必须逐一排除：

5.3 三层清单分析法（监听 × 放行 × 外部实测）

只看 ss 会误判，只看 firewall-cmd 也会误判（docker DNAT、v6、绑特定 IP 都藏在缝里）：

# ① 监听层
ss -tlnp
#   0.0.0.0:X / *:X / [::]:X → 全接口（* 为双栈）
#   x.x.x.x:X               → 只绑公网单地址（同样对外）
#   127.0.0.1:X / [::1]:X   → 仅本机（合规）

# ② 放行层
firewall-cmd --list-ports; firewall-cmd --list-services
docker ps --format '{{.Names}}\t{{.Ports}}'    # 0.0.0.0 发布的容器端口

# ③ 实测层（从另一台机器，别看配置看连通性）
python -c "
import socket
h='<目标IP>'; ports=[<端口列表>]
for p in ports:
    s=socket.socket(); s.settimeout(4)
    try: s.connect((h,p)); print(p,'OPEN'); s.close()
    except Exception as e: print(p,type(e).__name__)
"

结论分三类：

> ⚠️ B 类别漏：「今天没暴露」只说明防火墙恰好没开，不代表配置到位。
> 收口价值一半在 A（止血），一半在 B（消除「误放行即裸奔」）。

5.4 收口手段优先级

各服务绑环回写法：

5.5 🔴 人工确认闸门（必须）

① 跑审计（只读）→ 输出 A/B/C 三层清单
② 把 A 类清单交给用户/业务方确认：哪些端口有人在用？保留哪些？
③ 用户明确回复「关哪些、留哪些」→ 才执行
④ 执行前挂回滚保险；执行后逐端口从外部复验

• 审计与执行分成两个动作，脚本也分两个模式（审计只读，--close 还需 --confirm）。
• 确认时逐端口问「谁在用」，不要一次「全关」。典型踩坑：CI 从外网调数据库 HTTP 口灌数、
  监控探针调采集口、同事浏览器直连调度后台。
• 关闭前查连接来源：

ss -tn state established '( sport = :<端口> )' | head
journalctl --no-pager --since -24h | grep -c ':<端口>'

5.6 docker 端口绕过 firewalld —— 现象、证据与四种应对

现象：容器用 -p 1234:1234 发布，firewalld 明明没放行，外面照样能连。

原因：包进入主机后先走 nat PREROUTING，docker 的规则把目的地址 DNAT 成容器 IP，
之后才进 filter。filter_IN_public 只对「目的是本机地址」的包生效，被 DNAT 的包早已不是本机目的地址，
于是 zone 的 accept/drop 全部轮不到。在 filter 层做白名单对 docker 发布端口天然无效。

实测（docker 25.0.3 / nftables 后端）：

> 判读要点：Timeout = 被防火墙丢掉；Connection refused = 包已经到达了目标协议栈。
> 看到 refused 就说明「外层防护没生效」，这是识别 docker 绕过的关键信号。

四种应对（按推荐度）：

> 检查清单：docker ps --format '{{.Names}}\t{{.Ports}}' 里凡是以 0.0.0.0: 开头的一律视为
> 「firewalld 管不到」，必须按上面 1~4 处理，别指望 zone 规则。

5.7 收口前先把业务端口收进 nginx 反代

收口的正确姿势不是「关掉就不管」，而是先给它留正规入口（nginx 的 80/443），再关掉直连端口。
否则页面打不开、API 调不通，业务方第二天就来要求重新放行。

典型：调度中心类后台（监听某个业务端口），要能从浏览器访问，但不该暴露那个端口。

# nginx.conf  ->  server { listen 80; ... }
location = /admin {                          # 无尾斜杠必须 301，否则静态资源相对路径算错
    return 301 /admin/;
}
location /admin/ {
    proxy_pass http://127.0.0.1:1234;        # ⚠️ 不带 URI 部分，保留 /admin 前缀
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 300s;                 # 后台常有长请求（触发任务、拉日志）
}

三条硬规矩：

验证（从外部、不经直连）：

curl -sI http://<host>/admin          # 302 → /admin/
curl -sI http://<host>/admin/         # 302 → 登录页
curl -s  http://<host>/admin/login | head -3    # 应返回登录页 HTML

🔴 改 nginx 前必须 nginx -t，但它常常「本来就失败」。实测报
cannot load certificate "..."（有人在配 443，证书还没放上去）。处置顺序：

1. 先修前提（补证书，或把 listen 443 ssl 的 server 块注释掉）→ 再 -t；
2. -t 通过后才 -s reload；-t 不通过绝不能 reload（reload 会加载失败，旧 worker 还在跑，
   你无法确认新配置到底生效没有）；
3. nginx 可能是手工启动（源码安装、无 systemd 单元）——
   systemctl is-active nginx 会说 inactive，别被误导；reload 用 <nginx前缀>/sbin/nginx -s reload。

反代确认可用后再收口直连端口。若该端口落在端口段放行内（如 8080-8090/tcp），段是摘不掉的，
用 priority=-5 的 drop 单独挡住它即可（drop 不受段放行影响，段内其他端口不受影响）。

5.8 远程访问改用 SSH 隧道

ssh -N -L 11234:127.0.0.1:1234 <目标主机>                      # 单端口
ssh -N -L 11234:127.0.0.1:1234 -L 15678:127.0.0.1:5678 <目标主机>   # 多端口
ssh -N -J <跳板> -L 11234:127.0.0.1:1234 <user>@<目标>            # 走跳板
# 之后本地访问 127.0.0.1:11234 即为远端 1234

前置：sshd AllowTcpForwarding local（重装系统默认常为 no，报 ChannelException: Administratively prohibited 就是它）；
GatewayPorts no 保持默认，别把隧道对外开。

5.9 执行（按档位二选一）

② 白名单档（主力，等同 SSH 的规则结构）：

firewall-cmd --list-ports                          # 记下原始状态
firewall-cmd --remove-port=<端口>/tcp              # 先摘掉「对全网放行」的声明
for ip in <白名单1> <白名单2> <白名单3> <自身IP>; do
  firewall-cmd --add-rich-rule="rule family=\"ipv4\" priority=-10 source address=\"$ip/32\" port port=\"<端口>\" protocol=\"tcp\" accept"
done
firewall-cmd --add-rich-rule="rule family=\"ipv4\" priority=-5 port port=\"<端口>\" protocol=\"tcp\" drop"
firewall-cmd --add-rich-rule="rule family=\"ipv6\" priority=-5 port port=\"<端口>\" protocol=\"tcp\" drop"
firewall-cmd --runtime-to-permanent                # 验完再固化

③ 仅环回档：连 firewalld 都可以不加——把服务绑 127.0.0.1 才是根治（§5.4）。若要防「配置被改回去」，
再补一条 drop 兜底即可（此时白名单 accept 没有意义，因为进程不听公网地址）。

> 为什么摘了 --add-port 还要加 drop？前者只是「不再放行」，后者是不受其他放行影响的一道独立护栏
> （防手抖、防别的 zone/service/端口段再放开）。端口段放行（如 8080-8090/tcp）尤其只能靠 drop 单独挡。
> 但对 docker 发布端口这套无效，必须按 §5.6 处理。

5.10 ②+③ 叠加 = 双重保护（可选，取决于要不要让白名单机器直连）

同一端口可以同时吃两道防线：firewalld 只放白名单 + 服务只听 127.0.0.1。
叠加后的实测特征：

怎么选：

> 判读口诀：白名单内 refused = 双重保护生效（服务没听公网），不是配置错了。

6. 公钥免密登录 + 关闭口令登录（带自动回滚守卫）

目标态：PasswordAuthentication no + KbdInteractiveAuthentication no + PermitRootLogin prohibit-password，
只允许公钥进来。爆破在口令层面直接失效（口令不再是一把可猜的钥匙）。

🔴 这是本技能里唯一「关错了就再也进不去」的动作 —— 防火墙关错了还能等 timer 回滚/走控制台，
口令关错了且公钥有问题，远端机器就只能进机房。所以必须同时满足两件事：

1. 关之前：所有需要进来的人的公钥都已装好，且每条链路都用 BatchMode 实测通过（§6.1 准入清单）；
2. 关的时候：挂一个跑在服务器本地的回滚守卫 —— 窗口内没人成功登录就自动把口令登录打开（§6.3）。

> 顺序不可颠倒：先配免密实测通过 → 再关口令。反了就是自锁。

6.1 前置：免密公钥部署与准入清单

bash scripts/ssh-key-deploy.sh --host <主机A> --user root          # 预演：看将做什么 + 现有指纹
bash scripts/ssh-key-deploy.sh --host <主机A> --user root --apply  # 执行：备份 → 追加 → BatchMode 实测

为什么不用 ssh-copy-id（踩过）：目标机常带 MaxAuthTries 3（§6.4 抗爆破），
而来源机往往有多把私钥（id_rsa + id_ed25519 + agent），ssh 握手会先试无效的钥匙，
3 次即被踢 → 报 Too many authentication failures。看着像密码错，其实是认证次数被卡住。
对策：直接从已通的链路 append 公钥，或强制 -o IdentitiesOnly=yes -i <指定私钥>。

关口令前的准入清单（逐条确认，缺一不可）：

• 🔴 authorized_keys 里他人的钥匙别动（同事、备份机的）。逐条对指纹，删的只有拼错的无效行。
• ⚠️ authorized_keys 是「每账号一份」：非 root 账号有自己的
  /home/<user>/.ssh/authorized_keys，只顾 root 会让该账号直接失联。
  但也要注意：那份钥匙的私钥可能就在目标机自己身上（自生成），外部拿不到 = 等于没配。
• ⚠️ 出口 IP 一变全体进不去：白名单只有 /32 时，办公网换出口即全体失联，确认有控制台/VNC 兜底。

6.2 关闭动作

bash scripts/nopasswd-login.sh                                  # 预演
bash scripts/nopasswd-login.sh --apply --window 300             # 执行：备份 → 先起守卫 → 写 drop-in → reload

写下的 drop-in（/etc/ssh/sshd_config.d/99-no-password.conf）：

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

• drop-in 优先，不改主文件：现代发行版的 sshd_config 多有 Include /etc/ssh/sshd_config.d/*.conf，
  且若无 Match 块 → 一条 drop-in 全局覆盖。先确认这两个前提（脚本会自动探测）；
  无 Include 的老机器脚本会自动降级为改主文件 + 注释原位 yes。
• PermitRootLogin 生效值可能显示 without-password —— 那是 prohibit-password 的等价写法，非笔误。
• 只 reload 不 restart：不中断已建立的会话（当前会话是你最后的退路，别关）。
• 改完必看生效值，不看文件：sshd -T | grep -iE '^passwordauthentication'。
  只改文件不够 —— 主文件里残留的 PasswordAuthentication yes 会抢先命中。

6.3 回滚守卫（本技能的核心设计）

关之前 ──▶ systemd-run 起守卫（transient 单元，跑在服务器本地，脱离一切 SSH 会话）
              │
              └─ ① 备份 sshd 配置        ② 【先】起守卫        ③ 再写 drop-in 并 reload
                                                                    │
                    N 分钟窗口后 ◀──────────────────────────────────┘
                        │
              <marker> 在窗口内被创建？
                 ├─ 是 → verdict=keep    ，保持关闭（= 固化成功）
                 └─ 否 → verdict=rollback，自动删 drop-in + reload → 口令登录恢复

🔴 绝对不要用「sshd 日志出现 Accepted publickey」当判据 —— 这是实测踩到的致命缺陷：
关闭动作本身就是经 ssh 触发的，那次登录必然落在窗口内，判据永远命中 → 守卫永远判 keep、永不回滚。
（实测：窗口内明明只有发起关闭的 1 次连接，计数 =1，守卫却判了 keep。）
> 通用教训：兜底判据若与「触发动作自身」耦合，必须剔除，否则守卫等于没装。

6.4 验证（关口令后必做）

手工回滚（任何时候）：rm -f /etc/ssh/sshd_config.d/99-no-password.conf && systemctl reload sshd

6.5 定时执行（可选）

想「约定时间自动关」，别用外部调度器（agents 掉线就没人做窗口内登录）：把关闭动作交给服务器本地 systemd timer。

# /etc/systemd/system/sshd-nopasswd-close.service
[Service]
Type=oneshot
ExecStart=/root/bin/nopasswd-login.sh --apply --window 300
RemainAfterExit=yes

# /etc/systemd/system/sshd-nopasswd-close.timer
[Timer]
OnCalendar=YYYY-MM-DD HH:MM:SS
Persistent=false
AccuracySec=1s
Unit=sshd-nopasswd-close.service

• OnCalendar 到点即触发，不依赖发起方在线；守卫同样跑在本地，闭环自洽。
• ⚠️ 窗口内仍需有人登录建标记 —— timer 不会替你登录。若完全无人值守，
  守卫会在窗口后回滚（这是设计的正确行为：没证据就认为免密不可靠）。
• 取消：systemctl disable --now sshd-nopasswd-close.timer。

7. 验证（改完必验）

> ①②③④ 证明「关掉了」，⑤ 证明「关掉之后还能干活」，⑦ 证明「改完确实更合规了」——
> 只做前四项，第二天业务就会来找你；漏掉 ⑦，检查时还是拿不出证据。

8. 锁死后自救

1. 永远先挂自动回滚：systemd-run --on-active=600 --unit=<名> firewall-cmd --reload（§6 的守卫同类思路）。
2. 别用 --reload 主动应用改动：它会 flush docker 的 nat 链（见 §5.6）。
3. 固化后再撤 timer，否则 10 分钟后被打回原形。
4. 被锁死的兜底顺序：控制台/VNC → 云商安全组/串口 → 同网段已放行的机器跳进来。
   所以放行清单必须包含自己当前出口 IP，最好再加一台对端/跳板。
5. 收口前先确认 nginx 真在跑并能反代——把 80 关了才发现 nginx 没起，等于全站下线。
6. 若锁死原因是关了口令登录（§6）：等守卫窗口自动回滚；或从仍持有公钥且在白名单内的机器进来
   执行 §6.4 的手工回滚命令。

9. 常见坑速查

10. 落地记录（模板）

> ⚠️ 本技能不记录任何具体环境信息（真实 IP / 端口 / 主机名 / 时间 / 业务名）。
> 每台机器的实际执行状态，写进你自己的运维报告。下面这份表是报告里该怎么记的格式：

11. 脚本用法

11.1 SSH 端口白名单

bash scripts/ssh-port-whitelist.sh --port 1234 \
  --allow <ip,ip,...>                      # 预演
bash scripts/ssh-port-whitelist.sh --port 1234 --allow <ip,ip,...> --apply
firewall-cmd --runtime-to-permanent && systemctl stop sshwl-rollback.timer

11.2 暴露面审计 / 档位管控

# ① 审计（只读，任何时候都能跑）：A/B/C 三层清单 + docker 告警 + 端口段放行告警
bash scripts/public-ports-guard.sh --keep 1234,80,443

# ② 白名单档（推荐）：这些端口只放列出的源（缺 --confirm 会拒绝）
bash scripts/public-ports-guard.sh --keep 1234,80,443 \
     --open 1235,1236,1237 \
     --allow <ip,ip,...> --confirm

# ③ 全禁档（该端口确实无人远程用）
bash scripts/public-ports-guard.sh --keep 1234,80,443 --close 5678 --confirm

# ④ 验完固化
firewall-cmd --runtime-to-permanent && systemctl stop portguard-rollback.timer

脚本刻意不做：不改服务配置（绑环回要人手动改 + 重启）、不 --reload、不自动固化、
不在没有 --confirm 时改动任何端口。审计里会显式标出「docker 0.0.0.0 发布」和
「端口段放行」两类高危项——前者 firewalld 关不掉，后者人工审计最容易漏。

11.3 免密登录 / 关闭口令登录

# ① 部署公钥免密（先预演看现有指纹，再执行）
bash scripts/ssh-key-deploy.sh --host <主机A> --user root
bash scripts/ssh-key-deploy.sh --host <主机A> --user root --apply

# ② 关闭口令登录（带 N 秒自动回滚守卫；守卫跑在目标机本地）
bash scripts/nopasswd-login.sh
bash scripts/nopasswd-login.sh --apply --window 300

# ③ 窗口内：从另一条链路免密登录并建标记（守卫认这个凭据）
ssh <主机A> 'touch /root/i_am_here; ls -l /root/i_am_here'

# ④ 窗口后：看判定
cat /root/sshd-nopasswd/$(cat /root/sshd-nopasswd/latest)/verdict   # keep / rollback

# ⑤ 手工回滚（任何时候）
rm -f /etc/ssh/sshd_config.d/99-no-password.conf && systemctl reload sshd

nopasswd-guard.sh 是守卫本体，由 nopasswd-login.sh 自动装到目标机 /root/bin/ 并由 systemd-run 拉起，
一般不需要手工调用（手工调用可用于测试回滚分支）。

11.4 等保自查（只读）

# ① 默认：按等保一级跑完全部主机可验证项，输出结论 + 证据 + 汇总
bash scripts/mlps-l1-check.sh

# ② 二级：一级全量 + 二级增量项（L2-01…L2-17），两套分数分开算
bash scripts/mlps-l1-check.sh --level 2

# ③ 除终端输出外，把报告另存（建议放运维档案，和 §10 的落地记录放一起）
bash scripts/mlps-l1-check.sh --level 2 --report /root/audit/mlps-l2-$(date +%F).txt

# ④ CI / 巡检用：出现「不符合」时退出码 2
bash scripts/mlps-l1-check.sh --strict

脚本行为约定：

> 报告首行会打印基线等级、主机标识与时间——这三样是等保证据的必备项，别删。
> 二级材料还要补 references/mlps-l2-delta.md §4 的「二级增量结论 / 备案与测评状态 / 差距与整改计划」三节。
> 该脚本只覆盖等保；网络暴露面与登录方式仍走 §11.1～§11.3。