云服务器反黑客入侵攻防实录（一）

1、引言

网络安全是互联网永不过时的主题，尤其是在云计算时代，大量的计算机应用迁移到云端，庞大的IT资产集结在云数据中心，一旦云数据中心爆发安全险情，轻则大量服务停摆，重则敏感数据丢失、系统遭到破坏，损失不可估量。国内几大头部云服务提供商，近一年都发生过网络运行或安全事故，抛开经济损失不提，作为顶级IT巨头出现安全问题难免尴尬，授人以柄、影响声誉。

本文讲述今天发生的一起黑客入侵事件，网络红客与黑客攻防对战。作者带您一步步揭开黑客攻击计算系统的内幕，也讲述网络红客如何绝地反击。

黑客身手不俗，深夜凌晨悄然侵入云服务器，步步为营，沿路设置重重障碍，就像冷兵器时代的铁蒺藜、铁拒马洒满一路，设下重重机关，牵一发而动全身，维系木马程序存在。

然并卵非也，魔高一尺，道高一丈。我们想象中，网络红客高举网安利剑，直入特洛伊城，层层深入，抽丝剥茧，把黑客设下铁蒺藜一根根拔出，轻松拆解隐秘机关，最后堵上城防漏洞，恢复城市的健康和生机。这里的特洛伊城就是中招的云服务器。还可能留下一具木马僵尸标本，以供将来拆解、把玩。哈哈！

事实果真如此吗？

闲话少叙，我们直奔主题，欣赏一场红客、黑客攻防战的来龙去脉和惊险场景。

从这个例子也感悟到，我们以为的真相其实只是表象，看到的表象是更浅显的表象。就像俄罗斯套娃，一层套一层，不到最后一刻永远不知道是否抵达真相。

2、云机见疑云

2.1 遭遇半瘫机

最近一个月，同事们抱怨公司JIRA服务器变慢了，而且越来越慢，点击页面几秒才有响应，几个人同时点页面，圆圈能不能转出来看运气。最近我忙着做K3s系统迁移，对JIRA没有太在意，也没有关注PR和缺陷报告。

直到昨天，发现软件产品的有个页面不符合我带有洁癖的审美，小伙伴们怂恿我提交一条PR，我才去打开久违了的JIRA首页。没想到JIRA不给力，点登录后圆圈转啊转啊，就是不出来工作台。还不给面子，报告账号密码错。换Chrome浏览器登录，还是账号、密码错。我的账号、密码是记在电子本本上的，排除人为因素，仅仅拷贝是不可能出错的。

那个无限旋转的圆圈，一点点消磨我的耐心。圆圈能不能求得圆满，以至于怀疑人生。哈哈。

此路不通，能否择歧路而行？用安全邮箱修改JIRA密码后，再登录圆圈消失了，正常登录进去。然后，一波未平一波又起，新建PR页面，出现白屏几分钟无响应。

此间不明一定有暗鬼。

小伙伴们的无助和我的切肤之痛，激发了我的好奇心和正义感。

明知山有虎，偏向虎山行。我不入地狱谁入地狱。

人不可雀语，语雀愿助人。语雀耳语于我，告知JIRA的账号密码和访问路径。JIRA服务 器架设在阿里云数据中心，云端SSH直连通道关闭，只能用堡垒主机作跳板二次登录才能访问JIRA服务器。架设JIRA的人士用心于安全可谓良苦。

前奏有点慢节奏，不过某国大片不经常是这样的开头的吗，平静的生活危机四伏。

2.2 初探噬心兽

系统响应慢，习惯性地先看系统资源利用情况。输入top命令，一看吓一跳，有一个sd-pam进程占用CPU接近400%。

图 JIRA服务器系统资源利用情况

入htop命令进一步查看详情。

图 JIRA服务器系统资源利用详情

从详情页可见，这台云服务器一共有4个CPU核心，4个核心利用率全是100%。可怜的JIRA（Java）进程挤到不知道哪个犄角旮旯里去了，分配的CPU连1%都不到，难怪JIRA会慢得像蜗牛。

CPU利用率排在前5位（1 4）的进程无一例外是sd-pam，第1个进程CPU利用率是396%，紧接着4个进程CPU利用率在99%左右。

大家可能会问，4个核心的主机，5个进程CPU利用率加起来将近800%，怎么像8个核心呢？

Linux是多进程多线程的操作系统，以进程模拟线程，5个进程ID（PID），其实只有一个主进程，其余4个是进程模拟出来的线程，从属于主进程，4个线程的CPU利用率合计等于第1个线程的CPU利用率396%，不要重复计算。

sd-pam进程像疯狂的野兽吞噬着CPU。去研发大群里询问，没有人能说清楚sd-pam进程是什么来头。疑云骤起，关注点向sd-pam进程聚焦。

2.3 举手解内困

提交PR还得仰仗JIRA服务，JIRA服务是运行在Docker容器内的。登录到JIRA容器，查看Java虚拟机参数，堆空间最大可用缺省值是768MB，对于JIRA服务来说显然偏低。

而云服务器16GB内存还有10GB以上的空闲，闲着也是闲着，堆空间最大可用值拟修改为2GB。因为运行环境和文件权限问题，在容器内不好修改文件，所以用docker cp命令把环境设置文件setenv.sh拷贝到宿主机，修改后拷贝回JIRA容器。

在大群里喊一嗓子，要重启JIRA服务了，没人理（反对），过几分钟就reboot云服务器了。

重启后，JIRA服务的配置会生效，JVM堆空间会扩大，对改善JIRA服务会有帮助。我也想看看云服务器重启后，sd-pam进程会不会还在。

修改JIRA配置与黑客对战没啥关系，不过是举手解JIRA之困境。

3、循迹清木马

3.1 初识两点疑

重启云服务器后，sd-pam进程依然顽固地存在，撒着欢一样把CPU利用率拱到满格400%。

“你来或不来我都在这里，不多不少，4个CPU全是我的菜。” 清哥哥感觉被挑衅了，看来得好好伺候这位爷了。

思绪开始往木马、蠕虫方向去想了。但凡木马都不是孤立的，要与外界联系，云服务器联系外界唯一的通道是网络通信。我想看看sd-pam都联系了哪些网络地址。实用工具lsof能查看进程打开的所有文件描述符。文件描述符有点抽象，但是说建立的TCP连接、打开的文件/目录、建立的管道都是文件描述符，就不难理解了。而进程打开的文件和建立的TCP连接正是我想知道的，以后有妙用。

在CentOS上，缺省地没有安装实用命令lsof，通过yum自动下载安装。

# yum install -y lsof

安装好以后迫不及待想看看sd-pam都干了啥。输入lsof命令，带参数-p PID，PID是进程ID。

# lsof -p 11320

图 sd-pam进程打开的文件描述符

分析命令输出，发现两个疑点：

第一个疑点是被删除的文件：

/var/tmp/dbus/.sd-pam/sd-pam(deleted)。

第二个疑点是从本机连接到未知远端IP的TCP连接：

jira-wiki-nexus:55916->128.199.136.211:http。

3.2 浅析外连接

连接外网的TCP连接很常见，先从第二个未知TCP连接下手。这个TCP连接指向HTTP端口，用浏览器打开网址，页面显示Mining Proxy Online。Mining，不是Mine，不就是挖矿吗？它自我暴露了。

换一个Google Chrome访问网址看看，输出还是Mining Proxy Online。

再试一试curl命令，都说在挖矿，很诚实的样子。

上午怼黑客时，并没有注意到Mining这个词，只是猜测可能是挖矿，要不然找个“肉鸡”干嘛呢？

百度一下，看看IP来自何方。百度虽然有很多槽点，但是引入的IP查询工具还是实用的。查询结果显示远端IP来自新加坡，是部署在海外的主机。而重启主机前的一次lsof显示，远端IP来自美国。之后，杀死过sd-pam不下十次，它又顽固地出现，稳定地连接这个新加坡IP地址。

接着，我想知道进程sd-pam的可执行程序藏身在什么地方。用了find命令去找它，执行时间太长，一时没耐住性子，ctrl c掐断了。

好吧，先放过它。

3.3 调试失踪客

进程sd-pam是可执行的，那么就可以用gdb来跟踪调试，深入内部是不是可以窥探内幕。

CentOS缺省也没有安装程开源调试工具gdb，运行yum命令自动下载、安装gdb。

# yum install -y gdb

安装好以后，启动gdb，然后输入attach PID（PID需要替换为实际进程号），触碰sd-pam进程并挂载到gdb调试环境。输出显示/var/tmp/dbus/.sd-pam/sd-pam(deleted)，该进程的可执行文件不存在。

消失的可执行程序，难道是挥刀删掉自己了吗？很诡异的现象。正常情况下，从可执行文件启动进程后，可执行文件依然存在原处。因为操作系统创建进程时，未必完全加载可执行文件，可能分步加载，运行时仍可能从可执行文件读数据段。进程能否删除启动的可执行文件？此处存疑。

后续分析会揭露可执行文件消失的真相。

因为想要尽快定位故障、解决问题，gdb调试暂告一段落。

消失的可执行文件意味着sd-pam进程的主人不希望可执行文件被发现，那么可执行文件可能隐藏着不为人知的秘密。sd-pam是黑客进程的疑虑进一步加重。

3.4 解密怪脚本

通过百度或谷歌搜索关键字sd-pam，所得搜索结果很少，看起来有关联的搜索结果不过区区两三条，点进去看详情也毫不相干。如果黑客攻击一说成立的话，那么程序文件名是个性化量身定制的，同样的攻击程序在别的受攻击服务器，可能会使用别的程序文件名。或者，也许这个攻击程序刚出现，没有形成规模和气候，所以网上报告的信息较少。

可执行程序位于目录/var/tmp/dbus/.sd-pam/，这个目录有两个疑点：可执行目录包含tmp，在Windows安装程序时很常见，Linux 系统很少见；子目录.sd-pam是隐藏目录，命令ls -a才能显示出来，ls是看不出来的。目录的两个疑点都指向，sd-pam程序的主人试图掩盖什么，不想让所寄居的云服务器的管理人员发现。

尝试进入目录/var/tmp/dbus，有了新的发现：

# cd /var/tmp/dbus

ls -ltra

more sd-pam}}}

居然看到了sd-pam，不过sd-pam是一小段Shell脚本，用more命令查看文件内容：

这个脚本做了4件事：

S1、创建隐藏子目录.sd-pam。子目录与前面发现的可疑路径吻合。

S2、复制文件x86_64到隐藏子目录.sd-pam，并改名为sd-pam。与前面发现消失的可执行文件完全一致。

S3、启动新复制的sd-pam程序，带有参数-h sd-pam -c。怀疑是以父子进程监控的方式启动：万一子进程死亡，父进程依然能fork出新的子进程。这样大大增加sd-pam程序存活的几率。

S4、删除S1创建的子目录.sd-pam，连同子目录下可执行文件sd-pam也一并删除。这就解释了前面的谜团：sd-pam进程存在，而进程的可执行程序文件却神秘地消失了。

因为脚本sd-pam是以root用户身份运行的，删除jira用户运行进程的可执行文件毫无压力，无需提权。虽无根，仍运行。

注意：这里的sd-pam有两个同名版本：一个是Shell脚本sd-pam；另一个是可执行文件sd-pam，由可执行文件x86_64复制、改名而来，不能混淆。

x86_64适用于64位的X86架构芯片，可以想象该程序可能还有x86（32位X86架构芯片）、ARM32、ARM64和SPARC64等多种版本。

**3.5 斩断无形手**

前面提到，JIRA云服务器重新启动后，sd-pam进程像幽灵一样存在，挥之不去，牢牢占据CPU排行榜的首位。应该是有某一种机制能够自动启动sd-pam。

已知的第一种机制是Linux后台服务管理，在系统重新引导后会自动运行，这是Linux内部机制，潜伏的进程只要不被发现，完全可以长期潜伏、定期送出有价值的信息。

第二种机制就要复杂得多，来自互联网的漏洞扫描程序，定时扫描云服务器的漏洞，发现漏洞后重新植入木马。第二种机制容易受到网络安全屏障的阻隔，频繁的扫描也容易被网络安全嗅探器发现，主要的云计算中心都提供免费或收费的服务，嗅探、发现漏洞和外部攻击。所以第二种机制/方法，不适合监控已植入木马云服务器，更适合于初次寻找漏洞，或者地毯式搜索云服务器漏洞。

在不重启云服务器时，直接杀死sd-pam进程能快速的停止木马进程。Linux命令kill传递信号参数SIGKILL或者9能立即杀死进程。

{{{# kill -9 11320

杀死进程后，CPU利用率立即下降到个位数。遗憾的是一两分钟后，sd-pam幽灵又出现在top命令输出榜首。

一两分钟内重启进程，Linux Service服务监控管理能做到，但又不符合其行为方式。因为杀死sd-pam进程后，服务监控进程立即能感知到，不会等待，而会立即重启新的sd-pam进程。

有另一种Linux定时任务机制，能做到精准到时分，重启后台任务。Linux后台服务crond，定时被唤醒，按照crontab表定义的时间表启动后台任务。

先看看crontab的时间表：

# crontab -l

…

* * * * * /var/tmp/dbus/./x86_64

图 Crontab定时启动、检查进程sd-pam

又发现了x86_64的踪迹。前面说到，x86_64就是sd-pam的化身和前身，sd-pam是x86_64的拷贝。自动忽略crontab表的第一条时间任务。

定时任务crontab的任务项由五个时间列和一个命令列组成。五个时间列分别是分钟、小时、星期、日、月，如果是数字表示具体时点，如果是*表示所有的时间点。

五个时间列都是 ，表示每月每日每星期每时每分，都会运行命令列的程序。翻译过来就是：7 24小时的每一分每一秒都在运行，榨干云服务器的每一分计算力。够狠的吧，比996厉害吧，669也不过如此。

x86_64能干什么，我有点好奇，忍不住手欠，运行了一把。反正CPU已经4个100了，也不会更坏了。

# x86_64

提示程序已经在运行。x86_64有自我监控的功能，只运行一份sd-pam进程副本。Crontab里的x86_64应该就是监控sd-pam存活状态的幕后推手。

先在最前面添加#号，注释掉crontab定时任务。斩断一双幕后黑手，那么木马程序sd-pam就会像孤儿一样。再杀了孤儿sd-pam，预期木马就会清除了。

# crontab -e

编辑并保存crontab，立即生效。

然后，执行kill -9 PID，果然sd-pam幽灵消失了好一会儿。好一会儿是多久，没读秒，没数数，我也不知道是多久。哈哈。

在彻底击败敌人之前，欢乐的日子总是短暂的。过了好一会儿，sd-pam幽灵又出现了。有些气馁了，怎么办？不过，还没有动绝杀之前，怎么能轻言失败呢？！

3.6 拔除木马根

回顾一下，不管是Linux服务管理还是Linux Crontab，都要调用/var/tmp/dbus/目录下的程序，那么让它们找不到这个目录，是不是它们就抓瞎了呢？说干就干，斩草要除根，dbus就是sd-pam的根。

{{{# cd /var/tmp

mv dbus dbus_bak

kill -9 PID ## PID替换为sd-pam进程的进程号}}}

这里没有直接删除dbus目录，而是给目录改名，使之找不到dbus目录，与删除目录效果是一样的。黑客攻击现场留下活证据，可作为呈堂证供。哈哈。

如此操作之后，幽灵进程再也没有出现过。又重启了云服务器，幽灵进程也没有出现了，空闲时CPU利用率稳定在个位数。

图 清除木马后云服务器进程列表

从浏览器点击JIRA控制台，在后台监控云服务器，看着JIRA（Java）进程欢快地吞噬CPU，我也长舒了一口，心里的石头落地了。

木马程序是被根除了，但是黑客是怎么攻进来的，云服务器漏洞在哪里，黑客会不会轻车熟路开始下一波攻击，我们一无所知。如果您对此感兴趣，请看下一节。

未完待续。

下文预告：

4、探秘黑客踪

4.1 寓言公寓楼

4.2 查询访客志

4.3 孜孜找不同

4.4 惊现无秘码

4.5 紧锁失密门

4.6 探寻黑客踪

4.7 解读黑客术

4.8 还原入侵图

5、修复云主机

6、安全警示钟

7、详解木马源

8、小结

原文链接：

https://mp.weixin.qq.com/s/DLGHw3wLUgzd_2XhQ3oVzA

关于睿云智合

深圳睿云智合科技有限公司成立于2012年，总部位于深圳，并分别在成都、深圳设立了研发中心，北京、上海设立了分支机构，核心骨干人员全部为来自金融、科技行业知名企业资深业务专家、技术专家。早期专注于为中国金融保险等大型企业提供创新技术、电子商务、CRM等领域专业咨询服务。

自2016年始，在率先将容器技术引进到中国保险行业客户后，公司组建了专业的容器技术产品研发和实施服务团队，旨在帮助中国金融行业客户将容器创新技术应用于企业信息技术支持业务发展的基础能力改善与提升，成为中国金融保险行业容器技术服务领导品牌。

此外，凭借多年来在呼叫中心领域的业务经验与技术积累，睿云智合率先在业界推出基于开源软交换平台FreeSwitch的微服务架构多媒体数字化业务平台，将语音、视频、webchat、微信、微博等多种客户接触渠道集成，实现客户统一接入、精准识别、智能路由的CRM策略，并以容器化治理来支持平台的全应用生命周期管理，显著提升了数字化业务处理的灵活、高效、弹性、稳定等特性，为帮助传统企业向“以客户为中心”的数字化业务转型提供完美的一站式整体解决方案。