Hostease 专区实测讨论：Linux 服务器安全基线自查——CIS Benchmark 高频项逐条落地要验证哪些指标

最近在 Hostease 专区看到不少朋友问同一类问题：服务器装好系统，除了改 root 密码、装防火墙还能做什么？为什么安全扫描总能报出一堆中危高危？这个帖把我按 CIS Benchmark（互联网安全中心发布的安全配置基线标准）逐条加固 Linux 服务器的实测过程摊开讲：每项验证哪些指标、结果怎么读。

先给结论（TL;DR）：默认安装的服务器，跑完基线核查后，Level 1 必做项通常失败 15 到 25 条，约八成集中在 SSH（远程登录服务器的加密通道）入口、密码策略、文件权限、日志审计四类。按这四类逐条落地，三天内能收掉大半攻击面。每节都是”自查命令 → 加固配置 → 验证指标”的闭环，可直接照抄。

我的测试环境：手上这台独服（独立服务器的简称，整机租用），Ubuntu 22.04 LTS 最小安装，纯公网暴露 SSH，核查工具用 usg。CIS 检查项跨发行版一致，思路通用。方法论一句话：CIS Benchmark 为每个发行版维护几百页清单，按 1 分（必须）到 2 分（建议）标优先级，全量执行不经济，实战只抓 audit 报告里最常失败的高频项，每项走完”自查、加固、验证”闭环。还没建立安全配置整体概念的朋友，先看站内fail2ban 与防火墙自查实录搭好框架，再回来抠 CIS 细项。

第一步：用官方工具跑出基线得分

CIS 官方提供免费的 cis-cat 核查工具，Ubuntu 的等价物是 usg，RHEL 系用 OpenSCAP 的 CIS 配置集，原理都是逐条比对配置与基线要求，输出通过、失败、未审计三类结果：

sudo apt install ubuntu-security-tools -y
sudo usg fix cis --level 1 --dry-run
sudo usg audit cis_level1_server

第一行装工具，第二行干跑模拟（只列出会改哪些项，不动系统），第三行正式核查并生成报告。第一次跑不必被几十条失败吓到，我这台最小安装失败 19 条，和社区常见的 15 到 25 条吻合。报告在 /var/lib/usg/ 下先存档，加固后重跑对比就是”前后”证据。

第二步：锁紧 SSH 大门，只留一把钥匙

SSH（远程登录服务器的加密通道）是公网被爆破最多的入口，也是 CIS 1 分项最密集的地方。先一条命令查四个关键参数：

sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries|permitemptypasswords'

期望对照：permitrootlogin 应为 no、passwordauthentication 应为 no、maxauthtries 应为 4 以内、permitemptypasswords 应为 no。在 /etc/ssh/sshd_config.d/ 下新建 hardening.conf：

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
MaxAuthTries 4
ClientAliveInterval 300
ClientAliveCountMax 2

这里有个血泪教训：顺序。先确认普通用户的密钥登录可用，再 sudo systemctl restart sshd，否则会把自己锁在门外——开两个终端，原会话不动，新终端验证成功再关旧会话。验证指标：重跑 sshd -T 四项达标，错误密码被拒、密钥登录成功。密钥登录的完整加固清单与常见坑，见站内SSH 服务器加固自查清单。CIS 还要求禁用过时的 SSH 协议 1 并限制每用户并发会话，最小安装一般已满足。

第三步：密码策略，让弱密码在任何入口都无效

即使 SSH 已切到密钥认证，密码体系仍保护着 sudo 和本地登录。CIS 核心参数：最长使用天数 365 以内、最短长度 14、失败 5 次锁定、加密算法 SHA512。先改 /etc/login.defs：

PASS_MAX_DAYS 365
PASS_MIN_DAYS 7
PASS_WARN_AGE 7

密码复杂度交给 pam_pwquality：sudo apt install libpam-pwquality 后，在 /etc/security/pwquality.conf 设 minlen = 14、minclass = 4（四类字符各含一个）。防爆破锁定交给 pam_faillock，在 /etc/pam.d/common-auth 追加：

auth required pam_faillock.so preauth deny=5 unlock_time=900
auth required pam_faillock.so authfail deny=5 unlock_time=900

这里必须按住所有人：PAM（Linux 的可插拔认证模块框架）配置写错是最容易导致”无法登录”的事故点。写入后开一个新终端故意输错密码 5 次，确认第 6 次被拒、正常会话不受影响，再关原会话。另一个坑：已有账户不会自动套用新策略，要 sudo chage -M 365 用户名 逐个刷新，chage -l 用户名 验证。

第四步：收掉文件系统里的全局可写目录

“任何人都能改”的目录是提权攻击的落脚点。用这条命令找出所有无粘滞位（sticky bit，限制目录内文件只有属主可删除的特殊权限）的全局可写目录：

df --local -P | awk '{if (NR!=1) print $6}' | xargs -I '{}' find '{}' -xdev -type d ( -perm -0002 -a ! -perm -1000 ) 2>/dev/null

对确实需要共享的目录（如 /var/tmp）补粘滞位：sudo chmod +t /var/tmp；不该开放的去掉其他用户写权限：sudo chmod o-w 目录。我这台跑出两条，都在应用数据目录，属于开发偷懒留的坑。

CIS 还点名几类高敏文件的权限，验证指标明确，逐个 ls -l 核对：/etc/passwd 应为 644、/etc/shadow 应为 640 或 600、/etc/gshadow- 应为 600，错了直接 chmod 改正。

另一条高频失败项是未授权的 SUID/SGID 二进制——系统更新后可能冒出新的，要定期清单化：

find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -exec ls -l {} \; 2>/dev/null

把输出存档，下次比对差异。出现计划外的 SUID 文件先查来源（哪个包装的），再决定是否 sudo chmod u-s 文件。内核参数的必改项：禁用 IP 转发与重定向（除非这台机器真是网关）、开启 SYN Cookie：

net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_syncookies = 1

写入 /etc/sysctl.d/99-cis.conf 后执行 sudo sysctl --system，用 sysctl net.ipv4.tcp_syncookies 回读，输出 1 即生效。

第五步：让日志开口说话，审计规则落地

没有日志的服务器等于没有黑匣子。CIS 要求 auditd（内核审计框架）运行、日志集中保存且普通用户不可读。先跑 sudo systemctl status auditd，期望 active (running)；再查 /etc/audit/auditd.conf 的 max_log_file_action，建议设为 keep_logs，避免轮转覆盖旧记录——取证时旧日志就是命。接着补最常用的审计规则：记录身份变更和登录事件，写入 /etc/audit/rules.d/50-cis.rules：

-w /etc/sudoers -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /var/log/faillog -p wa -k logins

执行 sudo augenrules --load 加载，验证指标：sudo auditctl -l 回读，五条规则都在输出里。查询用 ausearch：sudo ausearch -k identity -i 列出所有身份文件改动，含时间、用户和结果，事后追责的第一手证据。我故意改了一次 /etc/passwd 的备注字段，ausearch 立刻查到，闭环成立。

还有一条容易被忽略：rsyslog 是否把关键日志转发到独立日志服务器。本机日志被入侵后可能被清除，异地副本才可靠；单机站长至少定期把审计日志拉到本地。更系统的服务器安全视角，见站内DDoS 防护配置指南。

第六步：把自查变成例行公事，以及我建议的执行顺序

一次加固并不一劳永逸：系统更新会带回默认值，新软件会引入新的 SUID 文件，人员变动留下陈旧账户。让基线检查进入日常节奏，比单次大扫除更有价值，落地就三件事：usg audit 进每月 cron 存档比对；SUID 清单每周差异对比；新机上线先跑基线核查。CIS 基线每年随发行版更新，订阅官方变更通知评估新增条目即可。

给准备动手的朋友一个风险收益比最高的顺序，亲测三天走完：

• 先做锁死类：SSH 禁 root 与密码登录、密码策略与 faillock、auditd 运行——约三小时，消灭最常见的爆破路径
• 再做收敛类：全局可写目录、敏感文件权限、SUID 清单、sysctl 参数——一次性收口，之后靠差异比对维护
• 最后做例行化：每月 audit 报告存档、每周 SUID 差异对比、新机上线强制核查

全部做完别忘了：重跑 usg audit cis_level1_server 和第一步的基线对比。我从 19 条失败降到 3 条，剩下的是双因素认证、异地日志这类需要额外基础设施的项，属第二阶段目标。这个对比数字留存好，等保或客户尽调时能直接当证据。

如果你需要更系统的思路，可以把本文命令整理成 Ansible（自动化配置管理工具）playbook，配合 Ansible Vault 管理服务器敏感配置的实践，把”逐台手敲”升级为”一键全量核查”。总结一下：基线自查就是量化现状、逐项修复、例行复核防回退。欢迎在评论区交流你们的 audit 得分和踩过的 PAM 坑。