<b>人物介绍：</b>
<b></b>
<b>直寻：</b>it老兵，干过运维，码过代码。unix old school guy，每天在emacs里敲着命令行，折腾着代码。目前负责问诊linux的疑难杂症，赤脚医生是也。
<b>骇客：</b>此案例中，骇客在其攻击的系统上架设了“后门”，还替换掉了正牌门卫，安插了自己的奸细，从手段来看超出了普通“炫技攻击”的范畴，达到了中级以上骇客水准。
都说系统诊断就像医生看病，说“你身体有毛病”很容易，病人都疼的打滚了，谁不知道是有毛病？就像ssh登陆停滞了，谁都知道系统的安全出问题了。
但好的医生，一定能看出症状的背后是什么病，还能看出这个病症是怎么来的，而且，根本用不上核磁共振、基因检测，用最简单的b超和化验就能定案。下面给大家分享这个案例中的“医生”，从一个ssh登陆停滞入手，不仅发现了骇客攻击，还一路顺藤摸瓜，从蛛丝马迹入手，发现了骇客是如何把后门架到系统上，如何偷梁换柱隐藏流量的，而用到的都是大家都习以为常的工具——strace、tcpdump，grep以及文本编辑器。
<b>下面，我们就从一个</b><b>linux系统被黑的排查和确认案例，来看看“医生”和“骇客”过招的故事：</b>
<b>一、问题现象</b>
<b>ssh客户端登录时停滞，使用debug模式可以看到下面的情形</b>
1. bash# ssh -vv [email protected]
2. openssh_7.2p2, libressl 2.4.1
3. debug1: reading configuration data /etc/ssh/ssh_config
4. debug1: /etc/ssh/ssh_config line 20: applying options for *
5. debug1: /etc/ssh/ssh_config line 56: applying options for *
6. debug2: resolving "xxx.xxx.xxx.xx" port 22
7. debug2: ssh_connect_direct: needpriv 0
8. debug1: connecting to xxx.xxx.xxx.xxx … port 22.
9. debug1: connection established.
10. debug1: permanently_set_uid: 0/0
11. debug1: key_load_public: no such file or directory
12. debug1: identity file /var/root/.ssh/id_rsa type -1
13. ... ...
14. debug1: identity file /var/root/.ssh/id_ed25519-cert type -1
15. debug1: enabling compatibility mode for protocol 2.0
16. debug1: local version string ssh-2.0-openssh_7.2
<b>而服务器端可以看到如下日志记录</b>
1. feb 11 00:00:11 localhost sshd[22619]: did not receive identification string from xxx.xxx.xxx.xxx
<b>而把sshd在前台启动，可以看到如下的报错</b>
1. : command not foundh-2.0-openssh_6.6.1
<b>二、排查环境</b>
除有问题的实例外，我们还准备了另外一台实例， 其ssh登录正常，用来作对比。两台实例都可以从vnc登录。这样我们可以先停掉init系统启动的sshd守护进程，而把sshd手工启动到前台，并且保证只有一个ssh客户端登录它们。
<b>三、问题排查</b>
既然sshd抱怨没有收到identification string（为方便记，下面我们称之为id字符串），那我们就抓包看看客户端有没有发送id字符串。在开始此之前，我们先简单介绍一下id字符串。
在客户端连接上ssh服务器之后，客户端和服务端都向对方发送一个ssh版本字符串。字符串的格式如下
1. ssh-protoversion-softwareversion sp comments cr lf
具体id字符串的例子见抓包结果。
<b>抓包排查</b>
为了便于比较，我们也抓一下正常的sshd，并且在转包结果上做上标记。
首先看正常sshd的抓包结果
再看看登录停滞sshd的抓包结果
很明显，ssh客户端发送了id字符串，反倒是sshd没有发送自己的id字符串。这样为什么sshd还抱怨没有收到id字符串呢？
<b>探究sshd的执行路径</b>
进一步追查为什么sshd抱怨没有收到客户端已经发来的id字符串。selinux和防火墙都快速查看了一下，没有发现可疑迹象。所以祭出strace工具。因为sshd是fork子进程处理客户端连接的，而且我们还要追踪id字符串的处理过程，所以我们这样使用strace
1. strace -s 256 -ff -o /tmp/strace-centos6.7-bad.log $(which sshd) -d
结果我们拿到了下面这些文件
1. bash$ ls strace-centos6.7-bad.log*
2. strace-centos6.7-bad.log.23840 strace-centos6.7-bad.log.23936
3. strace-centos6.7-bad.log.23900 strace-centos6.7-bad.log.23937
4. strace-centos6.7-bad.log.23901 strace-centos6.7-bad.log.23938
5. strace-centos6.7-bad.log.23902
6. bash$
通过检索clone调用，我们很容易理清结果里进程间的父子关系
1. bash$ grep -e '^clone\(' strace-centos6.7-bad.log*
2. strace-centos6.7-bad.log.23840:clone(...) = 23900
3. strace-centos6.7-bad.log.23840:clone(...) = 23936
4. strace-centos6.7-bad.log.23900:clone(...) = 23901
5. strace-centos6.7-bad.log.23901:clone(...) = 23902
6. strace-centos6.7-bad.log.23936:clone(...) = 23937
7. strace-centos6.7-bad.log.23937:clone(...) = 23938
8. bash$
明显日志文件结果是有猫腻的。因为sshd是fork子进程处理用户连接的。在我们启动sshd（这个我们称之为controller进程）后，客户端连接时，sshd会fork一个子进程（这个我们称之为worker进程），由子进程负责处理用户连接。在启用-ff选项的情况下，controller进程的strace日志文件应该是strace-centos6.7-bad.log。我们用如下命令抓取的正常sshd的执行路径，用正常sshd的strace日志文件结果来验证我们的推断
1. strace -s 256 -ff -o /tmp/strace-centos6.8-ok.log $(which sshd) -d
如下结果是我们拿到的结果
1. bash$ ls strace-centos6.8-ok.log*
2. strace-centos6.8-ok.log strace-centos6.8-ok.log.1605
3. strace-centos6.8-ok.log.1606 strace-centos6.8-ok.log.1607
4. bash$
同样通过检索clone调用，理清结果里进程间的父子关系。很容易确认正常sshd的controller进程的日志文件是strace-centos6.8-ok.log
1. bash$ grep -e '^clone\(' strace-centos6.8-ok.log*
2. strace-centos6.8-ok.log:clone(...) = 1640
3. strace-centos6.8-ok.log.1605:clone(...) = 1606
4. strace-centos6.8-ok.log.1606:clone(...) = 1607
5. bash$
为防止是从服务器上下载时遗漏了日志文件，检查下载方法
1. bash$ history|grep scp|grep strace-centos6.7-bad|grep -v grep
2. 347 scp [email protected]:/tmp/strace-centos6.7-bad* .
3. 348 scp [email protected]:/tmp/strace-centos6.7-bad* .
4. bash$
很明显，我们不可能遗漏什么文件。而且，进一步检查strace-centos6.7-bad.log.23840的内容，也可以确认进程23840的确执行了我们的命令
1. bash$ head -4 strace-centos6.7-bad.log.23840
2. execve("/usr/sbin/sshd", ["/usr/sbin/sshd", "-d"],…) = 0
3. brk(0) = 0x7f2e57230000
4. mmap(null, 4096, ...) = 0x7f2e553a7000
5. access("/etc/ld.so.preload", r_ok) = 0
所以可以断定，登录停滞的sshd的strace日志文件结果是异常的。
<b>四、初步结论</b>
正如了解一个人是否健康很容易，判定系统是否被黑也很容易。系统上的结果要么是人造成的，要么是进程造成的。只要了解到一个异常结果，而且这个结果不是明确授权的人和进程造成的，那就是被黑了。基于此，因为登录停滞的sshd的strace日志文件结果是异常的，所以可以判定，其系统被黑了。
除此之外，我们还可以凭借这个异常结果进一步推论。很明显，登录停滞的sshd的controller进程是作为一个子进程运行的（所以这个进程的strace日志文件才是strace-centos6.7-bad.log.23840，而不是strace-centos6.7-bad.log）。那就意味着strace还启动了一个进程，这个进程是登录停滞sshd的controller进程的父进程。这个父进程和其strace日志都被隐藏了。这也是一个异常的结果。而且大家都清楚，隐藏进程和修改日志输出是常见的骇客伎俩。
基于以上分析，可以判定，系统一定是被黑了。可是这样的事实和推理过程，恐怕不易说服客户。况且我们还有一个问题没有回答。那就是为什么sshd在前端启动时有下面的输出
<b>五、确认系统被黑</b>
为了让客户了解系统被黑的事实，接受我们的判断，我们要简单做一下系统如何被黑的诊断。
<b>搜寻诊断线索</b>
首先对比登录停滞sshd和正常sshd的congtroller进程的执行路径。
这是正常sshd的执行路径
这是登录停滞sshd的执行路径
可以明显的看到，登录停滞的sshd额外调用了recvfrom syscall。除此之外，正常sshd只fork了一个子进程，而登录停滞的sshd则fork了2个子进程。
既然系统被黑，那骇客肯定是要留后门的。所以这个额外的recvfrom调用和多出的这个子进程很可能就是后门的一部分。
检索openssh-server的源码，很快可以定位到sshd对id字符串的处理的函数
从源码可以看出，sshd会使用一个256字节的buffer来处理客户端发来的id字符串，而且每次是读1个字节。但是recvfrom却是使用一个9字节的buffer，一次读了9个字节。而且使用了msg_peek标志。根据recvfrom(2)对msg_peek标志的解释：
“the msg_peek flag causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue.”
从网络连接上读取数据却不消费之，正是骇客常用的把控制流隐藏在正常流量中的伎俩。可以百分百确认，这个recvfrom就是骇客后门的一部分，这就是我们要找的线索。
<b>按图索骥</b>
recvfrom操作的描述符是4，这个文件描述符被子进程23900继承了。如下图所示
通过下图可以进一步确认，这个文件描述4，又被进程23900的子进程23901继承了。除此之外，进程23900还创建了新的会话。
通过下图可以进一步确认，进程23901把文件描述4复制为它的标准输入和标准输出（shell常见技巧&骇客伎俩），并且启动了shell。
进一步分析进程23901，可以看到它从标准输入上也就是网络连接上接受了字符串“ssh-2.0-openssh_6.6.1\r\n”。它就去掉末尾的换行符，在各个可能的路径（猜测是根据path变量来的）下搜索可执行程序“ssh-2.0-openssh_6.6.1\r”。这是sshd需要的id字符串，不是程序名称。所以搜索失败了。 所以它启动一个子进程报错，而自己继续执行read，等待来自网络的新指令。
那么，这个报错的子进程的执行路径是什么样的呢？
这就是把sshd在前台启动时，客户端一连，我们看到的那个报错。只是终端显示的不太完整而已。
<b>我们发现了什么</b>
到此为止，我们简单、粗疏的诊断就告一段落了。那么我们发现了什么？
1. 客户系统上的sshd程序肯定被替换了。否则我们执行strace抓取sshd的执行路径时，sshd的controller进程不应该是一个子进程。
2. 替换掉客户系统上sshd的程序会从网络流量中自动分离骇客的控命令和sshd的流量，并且启动真实的sshd应答ssh访问。
3. 系统工具，比如strace，被修改过了，以便隐藏进程和过滤日志，应该是rootkit攻击。
<b>六、结论</b>
这次排查过程，我们只使用了大家都习以为常的工具，诸如strace、tcpdump，grep以及文本编辑器，就解决了问题，客户也接受我们的解释。所以建议大家多熟悉常见的工具。通过熟悉工具来更好的理解软件的架构与执行路径。
因为生产系统上几乎不会安装调试符号，所以探究sshd之类的执行路径、排查问题，往往要借助*trace类的工具。如果大家对于c库api和系统调用比较熟悉的话，对于排查问题将大有益处。