UC切换用户

从日志来看，UCMonitor 账户频繁尝试 su 切换其他用户（如 root、mysql）并失败，这并非正常现象，很可能是 U-Center 监控系统在尝试采集数据时，因账户权限或密码问题导致的异常行为。

🔍 为什么会发生？

这很可能是 U-Center 的监控机制导致的。为了采集系统或数据库的深度指标，监控进程（以 UCMonitor 账户运行）有时需要通过 su 命令临时切换到目标用户（如 root 或 mysql）来执行命令。

日志中反复出现 FAILED SU，说明这个过程失败了，可能的原因有：

• 密码错误或已过期：UCMonitor 账户尝试切换时使用的密码不正确，或者目标账户（如 root、mysql）的密码已过期。

• UCMonitor 账户权限不足：该账户可能没有被赋予使用 su 命令的权限（例如，不在 wheel 组中）。

• PAM (可插拔认证模块) 限制：系统的 PAM 配置可能限制了 UCMonitor 账户的切换行为。

• 监控任务配置错误：U-Center 上配置的某个监控模板或任务，可能错误地指定了需要切换的用户或密码。

⚙️ 如何处理？

针对这个问题，你可以按以下步骤排查和处理：

1. 检查并修正密码或权限

   • 确认密码：检查 UCMonitor 账户用于切换的密码是否正确，并确认目标账户（如 root）的密码是否过期。如有需要，可以在 U-Center 后台更新相关凭证。

   • 授予权限：如果需要 UCMonitor 执行这些操作，可以考虑将其加入 wheel 组，使其拥有 su 权限。

2. 配置免密切换（推荐，如果必须保留切换操作）
   如果必须保留切换操作，可以配置 sudo 免密，这是更安全的做法。

   • 以 root 身份执行 visudo 命令，添加如下配置：

     text

     UCMonitor ALL=(ALL) NOPASSWD: ALL

   • 这样，UCMonitor 就可以通过 sudo -u <目标用户> 的方式执行命令，而无需密码。

3. 调整或禁用相关监控任务（可以选择取消）

   • 调整监控模板：登录 U-Center Web 界面 (http://ip_address:30000)，进入监控配置，检查并修改需要高权限的监控模板。

   • 禁用特定监控：如果某些需要 su 切换的监控项不是必需的，可以直接在 U-Center 中将其禁用。

   • 改用 Agent 监控：如果条件允许，可以考虑在目标服务器上部署 U-Center Agent。Agent 方式通常不依赖 root 密码进行远程切换，可能更稳定。

一、先给核心结论
这个现象本身属于 U-Center Agent 采集机制触发，日志行为是 Agent 主动产生，但【频繁 FAILED SU 认证失败属于异常，不建议放任不管；不能直接屏蔽日志，需要根治】。
原理说明
被监控服务器上安装了 U-Center IOM Agent，运行账户为UCMonitor。
Agent 内置数据库探测脚本：为采集 Oracle、MySQL 数据库深度指标、部分系统高级指标，会周期性尝试su - 数据库用户(root/mysql/oracle/wacos)，尝试切换身份执行数据库查询命令。
日志特征完全匹配：
plaintext
su: FAILED SU (to root) UCMonitor
su: FAILED SU (to mysql) UCMonitor
su: FAILED SU (to oracle) UCMonitor
失败原因：UCMonitor 普通监控账号没有目标用户 su 密码，无法切换身份，持续抛出认证失败日志。
二、风险评估（重点，政务 / 等保环境敏感）
安全审计层面隐患
持续大量su认证失败日志，等保、日志审计平台会判定为暴力破解账号行为，触发安全告警；运维核查时无法区分是正常采集还是真实入侵行为。
日志风暴问题
周期性批量产生大量 secure 日志，占用磁盘、syslog 转发带宽，淹没真正的入侵告警。
不存在系统宕机、业务中断风险，仅日志层面骚扰。
区分：不是黑客爆破，是监控 Agent 自身探测行为；但审计系统无法自动识别，必须处理。
三、4 种解决方案（按推荐优先级排序）
🥇方案 1：平台侧精简监控模板（根治，首选）
登录 U-Center 平台 → 基础资源监控 → 操作系统监控模板
编辑该服务器绑定的监控模板
禁用【Oracle/MySQL 深度采集指标组】
深度指标依赖 su 切换数据库账号；仅保留基础操作系统指标（CPU、内存、磁盘、进程），不再执行 su 探测。
生效后 Agent 不再发起 su 切换尝试，日志彻底消失。
🥈方案 2：给 UCMonitor 配置免密 su（需要数据库运维同意）
如果确实需要保留数据库深度监控指标：
在被监控主机配置 sudo 免密，或者 su 免密，允许 UCMonitor 切换 mysql/oracle。
⚠️安全风险：扩大 UCMonitor 权限，数据库服务器谨慎使用。
🥉方案 3：系统日志过滤（临时过渡，治标不治本）
在 /etc/rsyslog.conf 增加过滤规则，丢弃 UCMonitor 的 su 失败日志。
缺陷：只是不打印日志，Agent 依然在后台持续执行 su 探测，审计溯源存在漏洞，不推荐等保环境长期使用。
❌禁止方案：直接删除 / 停止 UCMonitor 账号
会导致 U-Center 主机监控全部失效。
四、快速验证方法
在 bi-db01 服务器抓进程，确认周期性触发 su 命令
bash
watch -n 1 ps -ef | grep su
可以看到UCMonitor周期性拉起 su 进程。
2. 在 U-Center 平台临时取消该主机【数据库相关监控指标】，观察 /var/log/secure 日志是否不再产生 FAILED SU 记录。
五、常见误区澄清
误区：“这是入侵行为，需要立即封 IP”
✅ 源进程是本地 UCMonitor Agent，本机内部行为，不是外部黑客入侵；
误区：不用管，只是日志而已
✅ 等保审计场景，大量连续 su 失败告警属于重大可疑行为，测评会提出整改项；
误区：升级 U-Center 版本彻底修复
✅ 老版本 Agent 默认开启数据库自动探测，新版模板可以关闭探测，无法单纯靠升级根除，需要调整监控模板。
六、极简总结
日志来源：U-Center Agent (UCMonitor) 周期性尝试 su 切换数据库用户采集深度指标，缺少密码所以持续失败。
最优处理：U-Center 平台修改监控模板，关闭 Oracle/MySQL 深度采集指标，停止 su 探测；
临时方案：日志过滤（不建议生产长期使用）。