2、环境准备与基线检查：操作系统安全基线、Commissioner版本选择、依赖组件安全

说实话，很多人在部署 Commissioner 的时候，上来就装软件、配参数。结果呢？跑了两周出问题了，一查是操作系统没加固，或者依赖组件版本有漏洞。我见过太多这样的案例了。

所以这一章，咱们把地基打牢。环境准备做扎实了，后面才能睡得着觉。

2.1 操作系统安全基线——别让系统成为突破口

操作系统是 Commissioner 的载体。它不安全，Commissioner 再安全也没用。我个人习惯，拿到一台新服务器，第一件事不是装软件，而是做基线检查。

2.1.1 账号与权限

• 禁用 root 远程登录：修改 /etc/ssh/sshd_config，设置 PermitRootLogin no。我曾经在一个项目里发现，对方所有服务器都开着 root 远程，密码还是 123456……嗯，不说了。
• 创建专用运行账户：不要用 root 跑 Commissioner。创建一个 commissioner 用户，权限最小化。
• sudo 授权精细化：只给必要的命令授权，别给 ALL。

2.1.2 内核参数与网络加固

有些参数默认是宽松的，需要收紧。我建议你检查以下几个关键项：

2.1.3 日志与审计

• 开启 auditd：记录关键操作，比如文件变更、用户切换。
• 日志轮转：配置 logrotate，防止日志撑爆磁盘。Commissioner 的日志量不小，我见过有人没配轮转，结果 /var 分区满了，服务直接挂掉。
• 远程日志：有条件的话，把日志发到集中式日志服务器。出事了好溯源。

2.2 Commissioner 版本选择——不是越新越好

很多人觉得，软件版本肯定越新越好。其实不一定。Commissioner 的版本选择，我建议遵循一个原则：稳定优先，功能其次。

2.2.1 版本生命周期

Commissioner 的版本号通常遵循 主版本.次版本.补丁 的格式。你需要关注的是：

• LTS 版本：长期支持版，推荐生产环境使用。一般有 3-5 年的安全更新。
• 最新稳定版：功能最新，但可能有一些未暴露的坑。适合测试环境尝鲜。
• EOL 版本：已经停止维护的版本。千万别用，出了漏洞没人修。

2.2.2 版本兼容性检查清单

选版本之前，先确认三件事：

1. 操作系统兼容性：Commissioner 3.x 要求 glibc 2.28 以上，CentOS 7 默认是 2.17，需要额外处理。
2. 依赖组件版本：比如 OpenSSL、Python、Java 等。后面会细说。
3. 硬件架构：x86_64 是主流，但如果你用 ARM 服务器，得确认有对应的二进制包。

2.3 依赖组件安全——木桶最短的那块板

Commissioner 本身很安全，但它的依赖组件可能不安全。你想想看，攻击者不一定要打穿 Commissioner，他只要打穿一个依赖组件，就能拿到系统权限。

2.3.1 关键依赖组件清单

2.3.2 依赖组件加固实操

拿 Redis 举个例子。默认配置下，Redis 没有密码，监听所有接口。这简直是给攻击者开后门。我建议你这样加固：

# 修改 redis.conf
bind 127.0.0.1
requirepass YourStrongPassword123!
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

为什么要禁用 FLUSHALL 和 CONFIG？因为攻击者一旦连上 Redis，可以用这些命令清空数据或修改配置。我在一个渗透测试项目里，就靠这个漏洞拿到了目标服务器的 root 权限。

2.3.3 依赖组件版本锁定

别用 latest 标签。生产环境一定要锁定具体版本号。比如：

# Dockerfile 示例
FROM openjdk:11.0.18-jre-slim
COPY commissioner.jar /app/

这样做的好处是，你的环境是可复现的。不会因为某天 latest 标签指向了一个有问题的版本，导致你的服务出问题。

2.4 知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当作环境准备的检查清单。