XenServer dom0 被黑案例分享

今天是周末轮班 on call 碰到一个非常有意思的 case 分享一下。

症状

本周某天起 XenServer Pool Master 的 management interface 严重丢包，以至于管理员用 XenCenter 都连上去管理都有困难，更别提进行操作了。该 management interface 是两块 10GbE 网卡组成的 bond 第一感觉是网络基础架构里可能存在问题。

故障诊断过程

接手之前美国时区的工程师（其实是在印度的工程师倒班伪装的）已经检查过 10GbE 网卡驱动，确定用的是最新版本。还怀疑是 bond 的问题，所以还特意 break 了 bond 来排查，不过问题依旧。接手时被告知即使是 ping 都 master 都会丢包，而且是有规律的一会儿行一会儿不行，上一个工程师抓过 tcpdump 发现有诡异的 outbound 网络流量，目标域名含 love xxx 之类的关键字，呃？ What the fuck? 已经有预感不是有 P2P 就是被种了木马。

接手之后看到的症状是 ping Pool Master IP 严重丢包，所以 SSH 过去操作都不可能。好在每个 XenServer 都有 iLO 连接。

用 iLO 登录 Pool Master 后第一件事就是看 Open vSwitch 的运行状况，用 ovs-dpctl show 发现 xenbr0 （第一块物理网卡 eth0 所插入的虚拟交换机） flows 高达 7k+ 超过默认的 flow eviction threshold 上限好几倍，丢包是必然的。

接下去下意识地用 top 看 dom0 的负载，发现当时系统的 load average 竟然有4（通常情况下生产环境下都低于1）！发现 CPU 占用最高的三个进程里有 ovs-vswitchd 和一个可疑的进程（可执行文件名是随机生成的），联想到之前同事之前抓的 tcpdump 里的可疑流量，基本确定是被黑了。

通过 /proc 看了下该进程的特征，发现可疑进程的二进制 ELF 是 /boot/zndltcllrx 该进程使用了近10个 Unix domain socket 试图杀掉该进程后立刻删除其可执行二进制文件，但马上就 respawn 出了新的随机名进程，典型的 virus / trojan 特征。它还试图伪装成 uptime / netstat -an 等常用系统命令（看 /proc/pid/cmdline 发现的）。用 chkrootkit 扫了一下什么都没发现，还有误报，呵呵。

幸运的是发现 resource pool 里有一个新装的服务器还没有被黑（但是迟早的事），把它指派成 master 之后把剩下的三个全部 eject 掉（因为本地存储上无数据，所有虚拟磁盘都在 SAN 上），用安装 CD 重装之后重新加入到 pool 中，搞定！

建议该牛奶牧场做一次彻底的网络安全审察，感觉公司的网络被渗透了，肯定还有后门。被黑是因为大部分服务器共享简单 root 密码（简单的英文单词），还用了很多年，囧

总结

说起来，这还是自2001年来我第一次在生产环境中的 Linux 服务器上看到木马 / rootkit （自己主动获取，拿来在虚拟机里测试的不算）。

自己的桌面和服务器因为安全意识尚可未中招过，或者说中了却不知道，呵呵。

在我之前的两个工程师折腾了几个小时，把注意力都放在了 10GbE 网卡驱动 / bond / Open vSwitch 等 XenServer 组件上，没有从基本的 Linux 系统管理/运维角度去分析和诊断问题，以至于如此显而易见的木马都没有发现（可能是技能上的缺失，班加罗尔的印度人，懂的），无语 -_-z Think out of the box ;-D

最后有一个败笔，就是忘记收集一份样本拿来研究，同时提交给 chkrootkit ;-D