端口开了一大片、账号还留着离职同事的，这类问题在核查里出现得最多。服务器加固的难点从来不是不知道该配什么，而是改完之后守不守得住：基线核查只回答「当前偏离了多少」，权限收敛才决定偏离会不会长回来。把加固拆成盘点、收敛、复核三个动作，每个动作留下可查的记录，事情才算落地。
一次季度核查里出现过很典型的一幕。一台对内提供接口服务的主机开放了二十多个监听端口，逐个核对业务归属时，运维同事只能确认其中六个，其余的都是历史业务下线后没关掉的残留。同一台机器上的可登录账号里，混着试用账号、外包账号和两名已离职人员的账号，其中外包账号还有可用的登录密钥。加固方案在那次之后改了三版，真正起作用的并不是加了多少条规则，而是把核查结果接进了变更流程：新开端口要登记归属人，账号到期要有回收动作。
五类高频坑的共同点
这五类坑的共同点是把安全配置当成一次性动作，配完就算完成，没人负责它在业务变化后是否仍然成立。下面按「坑 → 原因 → 收敛方向」把它们列在一起，后面的小节再逐个展开。
| 维度 | 常见坑 | 典型表现 | 收敛方向 |
|---|---|---|---|
| 网络暴露面 | 端口与服务只开不关 | 监听端口多于业务实际所需 | 建立端口台账，绑定业务与归属人 |
| 身份管理 | 账号只加不减 | 离职、外包、试用账号仍可登录 | 账号到期时间与回收动作成对出现 |
| 授权模型 | 权限一次到位后不复查 | 积累了大量长期高权限账号 | 按职责范围重排，收紧 sudo 范围 |
| 审计能力 | 日志开了却留不住 | 留存周期短、关键操作未记录 | 明确留存周期，覆盖特权操作 |
| 流程闭环 | 核查报告无后续动作 | 报告读完即归档，未形成工单 | 每个风险项对应责任人与期限 |
这五类问题的修复难度并不相同。端口与账号属于配置层面的清理，改完即可验证；权限模型和审计能力涉及流程与制度，改动周期更长，通常要跨部门确认。
坑一：端口和服务只开不关
这个坑的根源在于开通端口有审批流程，关闭端口却没有对应的触发条件，业务下线时没人想起来回头处理防火墙规则。加固实践里常见的做法是先做一次全量盘点，把每个监听端口和运行中的服务对回业务归属，找不到归属的一律进入待关闭清单。
核查动作可以做成只读采集，不改动任何配置，跑完之后拿着结果去和业务方确认。
# 基线核查：只读采集，不做任何修改
echo "== 监听端口 =="
ss -lntup
echo "== 运行中的服务 =="
systemctl list-units --type=service --state=running --no-pager
echo "== 防火墙当前规则 =="
firewall-cmd --list-all 2>/dev/null || iptables -S
echo "== 关键文件权限 =="
stat -c '%a %U:%G %n' /etc/passwd /etc/shadow /etc/ssh/sshd_config采集结果要和防火墙的实际放行规则对照看，两边不一致才是问题：服务已经停掉但规则还在，或者服务在跑但规则缺失导致业务侧绕过预期路径。收敛顺序建议先把确认无归属的端口从放行规则里摘掉，观察一个业务周期，确认没有调用方受影响后再停用对应服务。这个顺序能避免「先停服务导致业务中断」这类返工。
CIS 一类基线把配置项分成基础级和高级级两档，基础级多数不破坏功能，高级级会牺牲部分便利换取更强限制。生产环境的收敛节奏可以按这个思路分层：基础级全量执行，高级级先在一台非核心机器上验证，确认业务无感后再推广。
坑二：账号只加不减，生命周期无人管
账号问题几乎都出在生命周期上，入职、转岗、外包进场时创建账号很顺畅，离场时却缺少触发回收的动作。核查时用一条命令就能看出问题规模：筛出所有可登录账号，逐个核对身份与最后登录时间，长期未登录且无业务归属的账号应当先禁用再删除。
账号收敛的动作可以固化成下面三步，避免直接删除带来的追溯风险。
- 盘点可登录账号并标注归属业务。
- 核对登录时间，标记长期未使用的账号。
- 先锁定账号观察一个周期，无异常再删除。
先锁定再删除的顺序很关键。直接 userdel 会连同家目录一起清掉，如果该账号仍在某个定时任务或服务配置中被引用，删除后问题会在下一个调度周期才暴露。锁定账号、观察、再删除，能把这类问题提前暴露在可控范围内。
同时要限制高权限账号的直接远程登录。允许管理员账号直接通过密码远程登录是常见的攻击起点，改用普通账号登录、再通过受控方式提权，能留下操作记录，也让权限回收变得简单——收掉一条 sudo 规则即可，不必逐个改密码。
坑三：权限收敛被做成「改一遍」
权限收敛失效的原因通常不是改得不对，而是改完没有复查机制，随着新需求不断加白名单，几个月后又回到收敛前的状态。有效的做法是把权限变更纳入同一套审批与复核流程，每次新增都要求写明用途和有效期。
关键文件的权限是第一道要确认的，很多系统在安装或迁移后权限被放宽过。下面这段脚本先备份再收紧，最后立刻复核，避免改完不知道是否生效。
# 权限收敛：先备份，再按基线收紧，最后复核
cp -a /etc/passwd /etc/shadow /etc/ssh/sshd_config /root/backup-$(date +%F)/
chmod 644 /etc/passwd
chmod 600 /etc/shadow
chmod 600 /etc/ssh/sshd_config
stat -c '%a %U:%G %n' /etc/passwd /etc/shadow /etc/ssh/sshd_config改完之后要留意服务是否需要重载才能读取新权限，特别是修改了服务配置文件权限的场合。备份目录本身也要限制访问范围，否则备份文件反而成了新的泄漏点。
sudo 收敛同样强调可追溯。与其给多个账号配置全量提权，不如按职责拆分命令白名单：只允许重启指定服务、只允许查看日志、只允许执行备份脚本。这样即使某个账号凭据失效，影响范围也被限制在职责边界内。
坑四：审计日志开了却留不住
日志的常见问题是「开了但不完整」，记录内容只覆盖登录事件，特权命令的执行、关键配置文件的修改都没有留下痕迹。审计能力的标准不是有没有日志，而是出事时能否还原谁在什么时间做了哪次变更。
收敛时先确认审计服务是否处于启用状态并设置了开机自启，再补齐需要记录的事件类型：特权命令执行、账号与权限变更、关键配置文件读写。留存周期方面，合规场景通常会提出明确的保存时长要求，实践中常见的是不少于六个月，具体口径要按所在行业的监管要求确定，不能照搬。
日志本身也需要防篡改。把审计日志实时投递到独立的日志接收端，或者对本地日志文件增加追加属性限制，都能让事后修改变得困难。日志权限同样要收紧，避免普通账号可以读取或覆盖。
坑五：基线报告跑完没有闭环
核查报告没有闭环，等于加固只做了一半。判断闭环的标准很具体：每一项风险都能查到责任人、处理状态和完成时间；忽略项要写明忽略理由和复核时间，不能只留一个「已忽略」的标记。
落地时可以把这五类坑的收敛动作合并进同一张治理表，按季度复核。复核不是重新跑一遍扫描就结束，而是逐项确认上次的整改是否仍然有效——端口台账有没有新增未登记项，账号清单里有没有出现新的长期未使用账号。基线核查工具如 OpenSCAP、Lynis 能自动完成采集与比对，但归属确认和整改排期仍然需要人来推进。
到这里，从端口、账号、权限到日志与流程的收敛链路就完整了。加固的价值不体现在某一次扫描的通过率上，而体现在下一次扫描时偏离有没有变少。
常见问题（FAQ）
Q1：怎么判断一台服务器还差哪些加固项？
先跑只读基线核查，再按端口、账号、权限、日志四类逐项与业务归属核对。
Q2：基线核查多久跑一次比较合适？
建议至少每季度一次，重大变更后追加一次，合规场景按监管要求的周期执行。
Q3：哪些账号应该被停用或删除？
离职人员、过期外包、长期未登录且无业务归属的账号，先锁定观察再删除。
