服务审计要回答两个问题
服务收敛的第一步是全量盘点，而盘点要回答两个问题：这台机器上为什么有这些服务在跑，以及为什么它们被设置为开机自启。运行中的服务决定当前暴露面，自启的服务决定重启后的暴露面，两者必须分别核对。判断标准不是「标准模板里该不该有」，而是「以这台机器的职责，它是否必要」。
基本信息
| 加固项 | 服务最小化 |
|---|---|
| 适用平台 | Linux（systemd 发行版） |
| 风险等级 | 中 |
| 基线 | 无未授权运行或自启的服务 |
| 盘点维度 | 运行状态、自启状态、监听端口三个视角交叉 |
典型使用场景
- 新机交付：确认默认开启的服务清单并逐项判断必要性
- 等保最小服务：要求关闭与业务无关的服务与端口
- 容量与性能排查：找出占用资源但无人认领的服务
- 事件排查：陌生服务可能是攻击者留下的驻留点
- 模板固化：把收敛结果写进标准镜像，新机不再重复治理
运行态与自启清单
运行态与自启清单
systemctl list-units --type=service --state=running
systemctl list-unit-files --state=enabled | head -50
systemctl --failed # 失败单元也值得看一眼
systemctl list-sockets --state=listening | head -20 # 套接字激活的服务
ss -tulnp | awk '{print $1, $5, $7}' | sort -u | head -40 # 按监听端口反查三个视角对照
| 视角 | 命令 | 说明 |
|---|---|---|
| 运行态 | 列出运行中的服务单元 | 反映当前暴露面，重启后可能变化 |
| 自启态 | 列出已启用的单元文件 | 决定重启后的状态，常被忽略 |
| 监听态 | 列出监听中的套接字 | 从端口反推服务，能发现未被记录的服务 |
| 失败单元 | 列出运行失败的单元 | 异常失败可能意味着配置被改动过 |
新装机器常出现「默认开着一堆服务」的情况：审计应以这台机器的职责为基准逐项判断必要，而不是照抄某份通用模板。判断结论要写成可复查的形式，例如服务名、用途、是否必要、处置动作，便于下一轮复核时直接比对。
两个容易漏的点：已启用不等于正在运行，反之亦然，两份清单都要看；另外由套接字激活的服务，在主服务列表中可能看不到常驻进程，排查时要连带查看套接字单元，否则会得出「没有这个服务」的错误结论。
从盘点到收敛
盘点之后按三类处置：与业务无关的直接停用并禁用自启；用途不明但无法确认的先限制其监听来源；必要的服务保持现状并纳入基线记录。收敛后把结果固化到镜像与配置管理中，同时保留一份清单作为比对基准，这样后续出现的差异都能被快速识别，而不是每次重新判断一遍。