一台刚装好的 Linux 服务器，默认配置追求的是”开箱能用”，而不是”开箱安全”：root 允许远程密码登录、旧密码可以无限期使用、全局可写目录散落在系统各处。攻击者扫描互联网时找的正是这些默认值。如何用一套公认的标准，把一台普通服务器逐条加固到可接受的安全水位？本文以业界广泛引用的 CIS Benchmark（互联网安全中心发布的安全配置基线标准）为参照，挑出其中命中率最高的检查项，把每一项都翻译成可以直接复制执行的命令和配置，帮助你完成一次系统性的安全基线自查。
在动手之前，先说明方法论。CIS Benchmark 为每个 Linux 发行版维护一份几百页的检查清单，按 1 分（必须）到 2 分（建议）标注优先级；全量执行既不现实也不经济。我们的做法是聚焦 audit 工具报告中最常失败的高频项：认证入口、密码策略、文件权限、日志审计四大类，每项都遵循”先自查、再加固、后验证”的闭环。更多服务器侧的运维基础，可以参考我们此前整理的服务器运维专题。
第一步：用官方工具跑出你的基线得分
CIS 官方提供免费的 cis-cat 自动化核查工具，另有各发行版生态的等价工具（如 Ubuntu 的 usg、OpenSCAP 中的 CIS 配置集），原理相同：逐条比对本机配置与基线要求，输出通过、失败与未审计三类结果。以 Ubuntu 为例：
sudo apt install ubuntu-security-tools -y sudo usg fixcis --level 1 --dry-run # 先模拟，查看将修改哪些项 sudo usg audit cis_level1_server # 正式核查并生成报告
第一次跑报告不必被几十条失败吓到。经验上，一台默认安装的服务器，Level 1（必做项）的失败集中在 15 到 25 条之间，其中约八成落在认证、密码、权限和日志四个类别——这正是下面要逐条处理的对象。把报告保存好，全部加固完成后重跑一次，对比得分变化，这就是你的”加固前后”证据。
第二步：锁紧 SSH，服务器的大门只有一把钥匙
SSH（远程登录服务器的加密通道）是公网上被爆破最多的入口，也是 CIS 清单里 1 分项最密集的地方。先自查现状：
sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries|permitemptypasswords'
四项的期望值分别是 no、no、4 以内、no。在 /etc/ssh/sshd_config（或 /etc/ssh/sshd_config.d/ 下新建 hardening.conf）中写入：
PermitRootLogin no PasswordAuthentication no PermitEmptyPasswords no MaxAuthTries 4 ClientAliveInterval 300 ClientAliveCountMax 2
关键在操作顺序：先确认普通用户的密钥登录已经可用，再重启 sshd（sudo systemctl restart sshd），否则会把自己锁在门外。改完后开一个新终端验证登录，原会话保持不动。CIS 同时要求禁用过时的 SSH 协议 1（Protocol 2，现代版本默认已移除）并限制每用户的并发会话。密钥的生成与加固细节，可以参考我们之前的SSH 服务加固清单。
第三步：让弱密码在任何入口都无效
即使 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
写入后务必开新终端测试一次错误密码 5 次的效果，确认第 6 次被拒绝、且你自己的正常会话不受影响——PAM（Linux 的可插拔认证模块框架）配置写错是最容易导致”无法登录”的事故点。已有账户的旧策略不会自动更新，可执行 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 同时点名几类高敏文件的权限：/etc/passwd 应为 644、/etc/shadow 应为 640 或 600、/etc/gshadow- 应为 600，用 ls -l 逐个核对，错了直接 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 回读验证。
第五步：让日志开口说话，审计规则落地
没有日志的服务器等于没有黑匣子。CIS 要求 auditd（内核审计框架）处于运行状态、日志集中保存且不可被普通用户读取。先确认基础组件：sudo systemctl status auditd 应为 active；/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 会列出所有针对身份文件的改动，包含时间、用户和结果，事后追责时这就是第一手证据。同时检查 rsyslog 是否把关键日志转发到独立服务器——本机日志在被入侵后可能被清除，异地副本才是可靠的审计来源。
第六步：把自查变成例行公事
一次加固并不一劳永逸：系统更新会带回默认值，新装软件会引入新的 SUID 文件，人员变动会留下陈旧账户。让基线检查进入日常节奏，比任何单次大扫除都更有价值。落地方式不必复杂：把 usg audit（或 cis-cat）放进每月执行的 cron 任务，输出报告存档比对；把 SUID 清单命令做成每周差异对比脚本；把”新服务器上线必须先跑一次基线核查”写进团队的交付流程。维护层面，CIS 基线每年会随发行版更新发布新版本，订阅官方变更通知、评估新增条目是否适用，是保持基线有效性的低成本做法。如果你的业务跑在 Hostease 的独立服务器或 VPS（虚拟专用服务器）上，主机侧的加固责任就在你自己手里——这套流程同样完全适用。
总结：一份可以直接照做的行动清单
回顾整个过程，安全基线自查的本质是三件事：用标准工具量化现状（usg/cis-cat 报告）、按优先级逐项修复（认证、密码、权限、日志）、用复核和例行化防止回退。给你的建议是按这个顺序执行，风险收益比最高：
- 先做锁死类：SSH 禁 root 与密码登录、密码策略与 faillock、auditd 运行——三小时内可完成，直接消灭最常见的爆破路径
- 再做收敛类：全局可写目录、敏感文件权限、SUID 清单、sysctl 内核参数——一次性收口，之后靠差异比对维护
- 最后做例行化：每月跑一次 audit 报告存档、每周对比 SUID 清单、新机上线强制基线核查
如果你需要更系统的加固思路，可以考虑把本文的命令整理成 Ansible（自动化配置管理工具）playbook，配合我们之前关于用 Ansible Vault 管理服务器敏感配置的实践，把”逐台手敲”升级为”一键全量核查”，同时用加密方式保管 playbook 里的密钥与口令。安全基线不是一次考试，而是一套需要持续维护的纪律——从今天的第一份 audit 报告开始。