📚 课程目录第3章 XClarity Controller初始安全配置

3. XClarity Controller初始安全配置

XClarity Controller（XCC）是 Lenovo ThinkSystem 服务器带外管理的核心组件，它独立于操作系统运行，即使主机断电，只要服务器接入管理电源，XCC 就处于可访问状态。正因如此，XCC 一旦被攻破，攻击者可以在操作系统层面毫无察觉的情况下完成固件植入、虚拟介质挂载、开关机控制甚至重装系统。初始安全配置的目标，就是在服务器正式承载业务之前，把 XCC 从"出厂可用"状态收敛到"受控可审计"状态。

本节围绕六个动作展开：默认凭据修改、网络隔离、服务端口最小化、证书替换、安全日志启用，以及一份可执行的基线检查清单。它们不是彼此独立的选项，而是一条从"谁能进"到"进来做了什么能否被追溯"的完整链条。

默认凭据：第一道也是最容易被忽略的门

ThinkSystem 服务器出厂时 XCC 通常带有默认用户名 USERID 和出厂密码，密码一般印在服务器正面的信息标签（Info Tag）或随机附带的标签上。这个密码是"每台唯一"还是"批次相同"，取决于机型与出厂批次，不能想当然认为它足够安全。初始配置的第一步应当是：登录 XCC Web 界面或通过 XCC 命令行，立即修改 USERID 的密码，并检查是否存在其他内置账户。

推荐做法不是简单改一个强密码，而是建立账户分层：保留一个应急管理账户，密码存放在受控的密码库中；为日常运维人员创建独立账户，按角色分配权限。XCC 支持的角色通常包括 Administrator、Operator、ReadOnly 等，遵循最小权限原则，只读账户不应被授予电源控制或虚拟介质权限。示例配置如下：

# 通过 XCC CLI 修改账户密码（示例）
XCC_USERID=USERID
XCC_IP=192.168.10.21

# 修改 USERID 密码
python xcc.py --host $XCC_IP --user $XCC_USERID \
  --set-password --new-password 'St0ng#Passw0rd!2024'

# 创建只读运维账户
python xcc.py --host $XCC_IP --user $XCC_USERID \
  --create-user ops_ro --role ReadOnly \
  --password 'Ops#Read0nly!2024'

需要强调的是，密码策略应在 XCC 中同步收紧：设置最小长度、复杂度要求、登录失败锁定阈值与空闲超时。很多环境只改了密码，却保留了"失败 100 次才锁定"的默认值，等于给暴力破解留了充足窗口。

网络隔离：让管理口只出现在该出现的地方

XCC 的管理流量与业务流量混跑，是带外管理最常见的安全隐患。正确做法是让 XCC 使用独立的管理 VLAN 或专用管理交换机，与业务网络在二层或三层上隔离。若服务器支持专用管理口（Dedicated Management Port），应优先使用该口，而不是与业务口共享（Shared Port）模式。

在 XCC 网络配置中，需要明确几个关键点：静态 IP 而非 DHCP，避免地址漂移导致管理失联；关闭不必要的 IPv6 或按需启用；配置正确的网关与 DNS，但不要让 XCC 直接暴露在互联网。若必须远程访问，应通过跳板机、VPN 或管理网关代理，而不是在防火墙上为 XCC 开放公网端口。

下面这张图展示了 XCC 初始安全配置中"网络隔离 + 服务收敛 + 日志外送"三者的关系，以及管理流量与业务流量在拓扑上的分离方式：

服务端口最小化：关掉不用的，只留必要的

XCC 默认会启用多种管理服务，包括 Web（HTTP/HTTPS）、SSH、Telnet、SNMP、IPMI、虚拟介质、远程控制台等。初始配置时应逐项审视：哪些是业务真正需要的，哪些只是"出厂默认开着"。典型的最小化策略是：保留 HTTPS 443 用于 Web 管理，按需保留 SSH 22 用于命令行运维，禁用 Telnet 23 和 HTTP 80（明文协议），禁用 SNMP v1/v2c（若必须用 SNMP，改用 v3 并配置认证与加密），IPMI/RMCP+ 若不需要带外监控则关闭。

虚拟介质和远程控制台是高风险功能，它们允许远程挂载 ISO 和操作键盘鼠标。若日常运维不需要，应关闭；若需要，应限制来源 IP 并记录使用日志。端口最小化的判断依据不是"能不能用"，而是"当前业务是否必须用"。

证书替换：从自签名到受信任

XCC 出厂使用自签名证书，浏览器访问时会提示不受信任。这不只是体验问题：自签名证书无法防止中间人攻击，也无法与企业的证书管理体系对接。正确做法是生成证书签名请求（CSR），由企业内部 CA 或受信任的公共 CA 签发，再将证书与私钥导入 XCC。

替换时需要注意：证书的 Common Name 或 SAN 必须与运维人员实际访问的地址一致（IP 或 FQDN），否则仍会报错；私钥导入后应确认 XCC 已重启 Web 服务；替换完成后用浏览器或 openssl s_client 验证证书链与有效期。示例验证命令如下：

# 验证 XCC HTTPS 证书（示例）
openssl s_client -connect 192.168.10.21:443 -servername xcc01.mgmt.local \
  -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

# 预期输出示例：
# subject=CN = xcc01.mgmt.local
# issuer=C = CN, O = Example Corp, CN = Example Internal CA
# notBefore=Jan 15 00:00:00 2025 GMT
# notAfter=Jan 15 00:00:00 2027 GMT

安全日志启用：让每一次访问都留下痕迹

日志是事后追溯的唯一依据。XCC 的 Event Log 会记录登录成功与失败、账户变更、配置修改、电源操作、虚拟介质挂载等事件。初始配置时应确认日志功能已启用，并配置 Syslog 外送，将日志实时发送到企业 SIEM 或日志服务器。原因很简单：如果攻击者获得了 XCC 权限，本地日志可能被清除，而外送日志已经离开设备。

外送配置需要关注三点：Syslog 服务器地址与端口（UDP/TCP 514 或 TLS 6514）；日志级别（建议至少记录 Warning 及以上，安全审计场景可记录 Information）；时间同步（通过 NTP 确保 XCC 时间与日志服务器一致，否则时间戳错乱会让关联分析失效）。

基线检查清单

以下清单可直接用于服务器上线前的 XCC 安全基线核查。每项都对应一个可观察、可验证的状态，而不是笼统的"已配置"。

检查项	合规标准	验证方式
默认账户密码	USERID 密码已修改，无默认密码账户	登录 XCC → 用户管理，确认无默认凭据
账户权限	按角色分配，无多余 Administrator	用户列表核对角色与人员对应关系
登录策略	失败锁定 ≤ 5 次，空闲超时 ≤ 15 分钟	XCC → 安全 → 登录策略
网络隔离	XCC 位于独立管理 VLAN，静态 IP	查看网络配置与交换机 VLAN 划分
服务端口	Telnet/HTTP/SNMP v1v2c 已禁用	XCC → 网络 → 服务，逐项核对
证书	已替换为企业 CA 签发证书，未过期	浏览器查看证书链，或 openssl 验证
安全日志	Event Log 启用，Syslog 外送正常	触发一次登录，确认日志服务器收到记录
时间同步	NTP 已配置，时间与日志服务器一致	对比 XCC 时间与 NTP 源时间

提示：基线检查不是一次性动作。固件升级、人员变动、网络调整后，都应重新核对上述项目。建议将清单固化为上线检查表，由执行人和复核人分别签字确认。

注意：修改网络配置或禁用服务端口前，务必确认当前管理通道不会中断。若通过 XCC 远程操作，错误的 VLAN 或 IP 变更可能导致设备失联，届时只能到机房通过本地 KVM 或前面板恢复。

把以上六项做完，XCC 才算真正进入"可管理、可审计、可追溯"的状态。默认凭据解决"谁能进"，网络隔离解决"从哪进"，端口最小化解决"开哪些门"，证书替换解决"信不信"，日志启用解决"进来后干了什么"，而检查清单则确保这些动作不是凭记忆完成，而是有据可查、可复核。