人物介绍：
直寻：IT老兵，干过运维，码过代码。UNIX old school guy，每天在Emacs里敲着命令行，折腾着代码。目前负责问诊Linux的疑难杂症，赤脚医生是也。
骇客：此案例中，骇客在其攻击的系统上架设了“后门”，还替换掉了正牌门卫，安插了自己的奸细，从手段来看超出了普通“炫技攻击”的范畴，达到了中级以上骇客水准。
都说系统诊断就像医生看病，说“你身体有毛病”很容易，病人都疼的打滚了，谁不知道是有毛病？就像ssh登陆停滞了，谁都知道系统的安全出问题了。
但好的医生，一定能看出症状的背后是什么病，还能看出这个病症是怎么来的，而且，根本用不上核磁共振、基因检测，用最简单的b超和化验就能定案。下面给大家分享这个案例中的“医生”，从一个ssh登陆停滞入手，不仅发现了骇客攻击，还一路顺藤摸瓜，从蛛丝马迹入手，发现了骇客是如何把后门架到系统上，如何偷梁换柱隐藏流量的，而用到的都是大家都习以为常的工具——strace、tcpdump，grep以及文本编辑器。
下面，我们就从一个
Linux系统被黑的排查和确认案例，来看看“医生”和“骇客”过招的故事：
一、问题现象
- ssh客户端登录时停滞，使用debug模式可以看到下面的情形
1.
bash# ssh -vv root@XXX.XXX.XXX.XXX
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
- 而服务器端可以看到如下日志记录
1.
Feb 11 00:00:11 localhost sshd[22619]: Did not receive identification string from XXX.XXX.XXX.XXX
- 而把sshd在前台启动，可以看到如下的报错
1.
: command not foundH-2.0-OpenSSH_6.6.1
二、排查环境
除有问题的实例外，我们还准备了另外一台实例， 其ssh登录正常，用来作对比。两台实例都可以从VNC登录。这样我们可以先停掉init系统启动的sshd守护进程，而把sshd手工启动到前台，并且保证只有一个ssh客户端登录它们。
三、问题排查
既然sshd抱怨没有收到identification string（为方便记，下面我们称之为id字符串），那我们就抓包看看客户端有没有发送id字符串。在开始此之前，我们先简单介绍一下id字符串。
在客户端连接上SSH服务器之后，客户端和服务端都向对方发送一个ssh版本字符串。字符串的格式如下
1.
SSH-protoversion-softwareversion SP comments CR LF
具体id字符串的例子见抓包结果。
- 抓包排查
为了便于比较，我们也抓一下正常的sshd，并且在转包结果上做上标记。
首先看正常sshd的抓包结果
再看看登录停滞sshd的抓包结果
很明显，ssh客户端发送了id字符串，反倒是sshd没有发送自己的id字符串。这样为什么sshd还抱怨没有收到id字符串呢？
- 探究sshd的执行路径
进一步追查为什么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 root@XXX.XXX.XXX.XXX:/tmp/strace-centos6.7-bad* .
3.
348 scp nerd@XXX.XXX.XXX.XXX:/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
6.
bash$
所以可以断定，登录停滞的sshd的strace日志文件结果是异常的。
四、初步结论
正如了解一个人是否健康很容易，判定系统是否被黑也很容易。系统上的结果要么是人造成的，要么是进程造成的。只要了解到一个异常结果，而且这个结果不是明确授权的人和进程造成的，那就是被黑了。基于此，因为登录停滞的sshd的strace日志文件结果是异常的，所以可以判定，其系统被黑了。
除此之外，我们还可以凭借这个异常结果进一步推论。很明显，登录停滞的sshd的controller进程是作为一个子进程运行的（所以这个进程的strace日志文件才是strace-centos6.7-bad.log.23840，而不是strace-centos6.7-bad.log）。那就意味着strace还启动了一个进程，这个进程是登录停滞sshd的controller进程的父进程。这个父进程和其strace日志都被隐藏了。这也是一个异常的结果。而且大家都清楚，隐藏进程和修改日志输出是常见的骇客伎俩。
基于以上分析，可以判定，系统一定是被黑了。可是这样的事实和推理过程，恐怕不易说服客户。况且我们还有一个问题没有回答。那就是为什么sshd在前端启动时有下面的输出
1.
: command not foundH-2.0-OpenSSH_6.6.1
五、确认系统被黑
为了让客户了解系统被黑的事实，接受我们的判断，我们要简单做一下系统如何被黑的诊断。
- 搜寻诊断线索
首先对比登录停滞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就是骇客后门的一部分，这就是我们要找的线索。
- 按图索骥
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在前台启动时，客户端一连，我们看到的那个报错。只是终端显示的不太完整而已。
- 我们发现了什么
到此为止，我们简单、粗疏的诊断就告一段落了。那么我们发现了什么？
1.
客户系统上的sshd程序肯定被替换了。否则我们执行strace抓取sshd的执行路径时，sshd的controller进程不应该是一个子进程。
2.
替换掉客户系统上sshd的程序会从网络流量中自动分离骇客的控命令和sshd的流量，并且启动真实的sshd应答ssh访问。
3.
系统工具，比如strace，被修改过了，以便隐藏进程和过滤日志，应该是Rootkit攻击。
六、结论
这次排查过程，我们只使用了大家都习以为常的工具，诸如strace、tcpdump，grep以及文本编辑器，就解决了问题，客户也接受我们的解释。所以建议大家多熟悉常见的工具。通过熟悉工具来更好的理解软件的架构与执行路径。
因为生产系统上几乎不会安装调试符号，所以探究sshd之类的执行路径、排查问题，往往要借助*trace类的工具。如果大家对于C库API和系统调用比较熟悉的话，对于排查问题将大有益处。
