服务清单要分两类看
服务收敛要区分运行中与开机自启两类：运行中的服务直接构成可达面，自启但启动失败的服务则是隐患——可能来自残留配置、缺失依赖，或有人注册后又改坏。清单要与业务清单逐项核对：不认识的服务先查归属（unit 内容、二进制文件所属软件包、服务日志），再决定保留、停用还是观察。注意区分 disabled 与 masked：前者只是不随开机启动，后者是彻底禁止启动，处置强度不同。
基本信息
| 加固项 | 服务最小化与归属确认 |
|---|---|
| 适用平台 | Linux（systemd 系发行版） |
| 权限要求 | root |
| 达标判据 | 运行与自启服务均有业务归属，无未授权服务 |
| 三种状态 | enabled 随开机启动、disabled 不随开机启动、masked 禁止启动 |
典型使用场景
- 新交付服务器的服务清点与收敛
- 等保“最小安装、最小服务”条款取证
- 排查资源占用异常，确认有没有多余服务常驻
- 安全事件排查中寻找新增的自启服务
- 变更后复核对服务状态的影响
核查命令
核查命令
systemctl list-units --type=service --state=running --no-pager | head -40 # 运行中的服务
systemctl list-unit-files --state=enabled --no-pager | head -40 # 开机自启的服务
systemctl list-units --type=socket --state=listening --no-pager | head -20 # socket 激活：服务可能由它按需拉起
systemctl --failed --no-pager | head -20 # 启动失败的服务
systemctl cat <服务名> | head -20 # unit 内容与来源路径确认归属后再处置
确认归属后再处置
systemctl status <服务名> --no-pager | head -10 # 描述、主进程与最近日志
rpm -qf $(which <可执行文件>) 2>/dev/null || dpkg -S $(which <可执行文件>) 2>/dev/null # 属于哪个软件包
systemctl list-dependencies <服务名> --reverse | head -10 # 被谁依赖，避免停错
systemctl stop <服务名> && systemctl disable <服务名> # 处置：先停再禁
systemctl mask <服务名> # 需要彻底禁止时使用状态区分与处置
| 状态 | 含义 | 处置建议 |
|---|---|---|
| running + enabled | 正在运行且随开机启动 | 核对业务必要性与来源 |
| dead + enabled | 自启但启动失败 | 排查失败原因，多为残留或配置错误 |
| running + disabled | 手动拉起后在运行 | 确认是谁启动的，排查自启来源 |
| disabled | 不随开机启动 | 业务不需要时可保持 |
| masked | 被禁止启动 | 多由加固或冲突处理设置，需记录原因 |
结论建议写成三段式：服务名、业务用途、处置（保留、停用、观察）。没有明确用途的服务默认进入“讨论停用”清单，而不是留在原地。记录里顺手写上对应软件包与责任人，后续变更时不必再从头查一遍归属。
“不认识就关”有风险：某些服务是安全软件、监控代理或存储客户端的组件，停用会影响防护与数据采集；也有服务被业务隐含依赖（例如由 socket 激活按需拉起）。处置前先看 unit 内容、依赖关系与服务日志，停用后观察一个业务周期再决定是否彻底禁用。