Question

安全总是相对的，再安全的服务器也有可能遭受到攻击。作为一名安全运维人员，要把握的原则是：尽量做好系统安全防护，修复所有已知的危险行为，同时，在系统遭受攻击后能够迅速有效地处理攻击行为，最大限度地降低攻击对系统产生的影响。

1.6.1 处理服务器遭受攻击的一般思路

系统遭受攻击并不可怕，可怕的是面对攻击束手无策，下面就详细介绍下在服务器遭受攻击后的一般处理思路。

1.切断网络

所有的攻击都来自于网络，因此，在得知系统正遭受黑客的攻击后，首先要做的就是断开服务器的网络连接，这样除了能切断攻击源之外，也能保护服务器所在网络的其他主机。

2.查找攻击源

可以通过分析系统日志或登录日志文件，查看可疑信息，同时也要查看系统都打开了哪些端口，运行哪些进程，并通过这些进程分析哪些是可疑的程序。这个过程要根据经验和综合判断能力进行追查和分析。后面的章节会详细介绍这个过程的处理思路。

3.分析入侵原因和途径

既然系统遭到入侵，那么原因是多方面的，可能是系统漏洞，也可能是程序漏洞，一定要查清楚是哪个原因导致的，并且还要查清楚遭到攻击的途径，找到攻击源，因为只有知道了遭受攻击的原因和途径，才能在删除攻击源的同时进行漏洞的修复。

4.备份用户数据

在服务器遭受攻击后，需要立刻备份服务器上的用户数据，同时也要查看这些数据中是否隐藏着攻击源。如果攻击源在用户数据中，一定要彻底删除，然后将用户数据备份到一个安全的地方。

5.重新安装系统

永远不要认为自己能彻底清除攻击源，因为没有人能比黑客更了解攻击程序，在服务器遭到攻击后，最安全也最简单的方法就是重新安装系统，因为大部分攻击程序都会依附在系统文件或者内核中，所以重新安装系统才能彻底清除攻击源。

6.修复程序或系统漏洞

在发现系统漏洞或者应用程序漏洞后，首先要做的就是修复系统漏洞或者更改程序 bug，只有将程序的漏洞修复完毕才能正式在服务器上运行。

7.恢复数据和连接网络

将备份的数据重新复制到新安装的服务器上，然后开启服务，最后将服务器的网络连接开启，对外提供服务。

1.6.2 检查并锁定可疑用户

在发现服务器遭受攻击后，首先要切断网络连接，但是在有些情况下，比如无法马上切断网络连接时，就必须登录系统查看是否有可疑用户，如果有可疑用户登录了系统，那么需要马上将这个用户锁定，然后中断此用户的远程连接。

1.登录系统查看可疑用户

通过 root 用户登录，然后执行“w”命令即可列出所有登录过系统的用户，如图 1-11 所示。

图 1-11 查看所有登录过系统的用户

通过这个输出可以检查是否有可疑或者不熟悉的用户登录，同时还可以根据用户名以及用户登录的源地址和它们正在运行的进程来判断他们是否为非法用户。

2.锁定可疑用户

一旦发现可疑用户，就要马上将其锁定，例如上面执行“w”命令后发现 nobody 用户应该是个可疑用户（因为 nobody 默认情况下是没有登录权限的），于是首先锁定此用户，执行如下操作：

[root@server ~]# passwd -l nobody

锁定之后，有可能此用户还处于登录状态，因此还要将此用户踢下线，根据上面“w”命令的输出，即可获得此用户登录进行的 pid 值，操作如下：

[root@server ~]# ps -ef|grep @pts/3
531   6051  6049  0 19:23 ?  00:00:00 sshd: nobody@pts/3
[root@server ~]# kill -9 6051

这样就将可疑用户 nobody 从线上踢下去了。如果此用户再次试图登录，此时他已经无法登录了。

3.通过 last 命令查看用户登录事件

last 命令记录着所有用户登录系统的日志，可以用来查找非授权用户的登录事件，而 last 命令的输出结果来源于/var/log/wtmp 文件，稍有经验的入侵者都会删掉/var/log/wtmp 以清除自己行踪，但还是会在此文件中露出蛛丝马迹的。

1.6.3 查看系统日志

查看系统日志是查找攻击源最好的方法，可查看的系统日志有/var/log/messages、/var/log/secure 等，这两个日志文件可以记录软件的运行状态以及远程用户的登录状态，还可以查看每个用户目录下的.bash_history 文件，特别是/root 目录下的.bash_history 文件，这个文件中记录着用户执行的所有历史命令。

1.6.4 检查并关闭系统可疑进程

检查可疑进程的命令很多，例如 ps、top 等，但是有时候只知道进程的名称无法得知路径，此时可以通过如下方式查看。

首先通过 pidof 命令查找正在运行的进程 PID，例如，要查找 sshd 进程的 PID，执行如下命令：

[root@server ~]# pidof sshd
13276 12942 4284

然后进入内存目录，查看对应 PID 目录下 exe 文件的信息：

[root@server ~]# ls -al /proc/13276/exe 
lrwxrwxrwx 1 root root 0 Oct  4 22:09 /proc/13276/exe -> /usr/sbin/sshd

这样就找到了进程对应的完整执行路径。如果还有查看文件的句柄，可以查看如下目录：

[root@server ~]# ls -al /proc/13276/fd

通过这种方式基本可以找到任何进程的完整执行信息，此外还有很多类似的命令可以帮助系统运维人员查找可疑进程。例如，可以通过指定端口或者 tcp、udp 协议找到进程 PID，进而找到相关进程：

[root@server ~]# fuser -n tcp 111
111/tcp:              1579
[root@server ~]# fuser -n tcp 25
25/tcp:               2037
[root@server ~]# ps -ef|grep 2037
root      2037     1  0 Sep23 ?        00:00:05 /usr/libexec/postfix/master
postfix   2046  2037  0 Sep23 ?        00:00:01 qmgr -l -t fifo -u
postfix   9612  2037  0 20:34 ?        00:00:00 pickup -l -t fifo -u
root     14927 12944  0 21:11 pts/1    00:00:00 grep 2037

有些时候，攻击者的程序隐藏很深，例如 rootkit 后门程序，在这种情况下 ps、top、netstat 等命令也可能已经被替换，如果再通过系统自身的命令去检查可疑进程就变得毫不可信，此时，就需要借助于第三方工具来检查系统可疑程序，例如前面介绍过的 chkrootkit、RKHunter 等工具，通过这些工具可以很方便地发现系统被替换或篡改的程序。

1.6.5 检查文件系统的完好性

检查文件属性是否发生变化是验证文件系统完好性最简单、最直接的方法，例如，可以检查被入侵服务器上/bin/ls 文件的大小是否与正常系统上此文件的大小相同，以验证文件是否被替换，但是这种方法比较低级。此时可以借助于 Linux 下的 RPM 工具来完成验证，操作如下：

[root@server ~]# rpm -Va
....L...  c /etc/pam.d/system-auth
S.5.....  c /etc/security/limits.conf
S.5....T  c /etc/sysctl.conf
S.5....T    /etc/sgml/docbook-simple.cat
S.5....T  c /etc/login.defs
S.5.....  c /etc/openldap/ldap.conf
S.5....T  c /etc/sudoers
..5....T  c /usr/lib64/security/classpath.security
....L...  c /etc/pam.d/system-auth
S.5.....  c /etc/security/limits.conf
S.5.....  c /etc/ldap.conf
S.5....T  c /etc/ssh/sshd_config

对于输出中每个标记的含义介绍如下。

- S 表示文件长度发生了变化。

- M 表示文件的访问权限或文件类型发生了变化。

- 5 表示 MD5 校验和发生了变化。

- D 表示设备节点的属性发生了变化。

- L 表示文件的符号链接发生了变化。

- U 表示文件/子目录/设备节点的 owner 发生了变化。

- G 表示文件/子目录/设备节点的 group 发生了变化。

- T 表示文件最后一次的修改时间发生了变化。

如果在输出结果中有“M”标记出现，那么对应的文件可能已经遭到篡改或替换，此时可以通过卸载这个 RPM 包重新安装来清除受攻击的文件。

不过这个命令有个局限性，那就是只能检查通过 RPM 包方式安装的所有文件，对于通过非 RPM 包方式安装的文件就无能为力了。同时，如果 RPM 工具也遭到替换，就不能使用这种方法了，此时可以从正常的系统上复制一个 RPM 工具进行检测。当然，对文件系统的检查也可以通过 chkrootkit、RKHunter 这两个工具来完成，上面介绍的命令或工具可以作为辅助或者补充。