服务器遭受攻击后的处理流程

服务器遭受攻击后的处理流程

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

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

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

　1 切断网络

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

　2 查找攻击源

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

　3 分析入侵原因和途径

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

　4 备份用户数据

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

　5 重新安装系统

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

　6 修复程序或系统漏洞

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

　7 恢复数据和连接网络

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

　二、检查并锁定可疑用户

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

　1 登录系统查看可疑用户

　通过root用户登录，然后执行“w”命令即可列出所有登录过系统的用户，如图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以清除自己行踪，但是还是会露出蛛丝马迹在此文件中的。

　三、查看系统日志

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

　四、检查并关闭系统可疑进程

　检查可疑进程的命令很多，例如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

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

　五、检查文件系统的完好性

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

　[root@server ~]# rpm -Va

　L c /etc/pamd/system-auth

　S5 c /etc/security/limitsconf

　S5T c /etc/sysctlconf

　S5T /etc/sgml/docbook-simplecat

　S5T c /etc/logindefs

　S5 c /etc/openldap/ldapconf

　S5T c /etc/sudoers

　5T c /usr/lib64/security/classpathsecurity

　L c /etc/pamd/system-auth

　S5 c /etc/security/limitsconf

　S5 c /etc/ldapconf

　S5T c /etc/ssh/sshd_config

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

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

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

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

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

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

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

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

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

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

　不过这个命令有个局限性，那就是只能检查通过rpm包方式安装的所有文件，对于通过非rpm包方式安装的文件就无能为力了。同时，如果rpm工具也遭到替换，就不能通过这个方法了，此时可以从正常的系统上复制一个rpm工具进行检测。

;

1需求

了解服务端如何处理http请求，了解基本的处理流程

2实战

处理http请求分为7个步骤

21 Tcp连接

建立一条tcp链接，（若之前不存在持久链接keep-alive），把客户端的ip和port，服务端的ip和port数据放到web服务器连接表中。服务器随时监听链接表中的链接，看有没有数据变化

22 接收http请求

一旦我们发送http请求了，这条tcp链接就开始工作了。因为web服务器链接表中有许多链接需要被处理，处理的方式有单线程，多线程这些（这些涉及操作系统的知识）。

23 处理http请求

处理的过程大致是把请求的信息解析出来，如下图

 

24 访问资源

访问资源可以是访问静态资源，这个就直接根据url地址去服务器里找就好了。

访问动态资源的话要经过一个叫cgi的东西，再用服务端脚本处理，再返回给前端。如下图所示

25 构建响应

要是找到资源，则构建响应信息，包括响应的对象类型，长度，状态码。

另一个情况是重定向响应，就是直接返回一个重定向，客户端看到之后，立刻再向重定向的地址发起请求。重定向的响应的状态码一般是3xx。

26 发送响应

把构建的响应发送给客户端

27 记录日志

服务端对这个请求响应过程进行记录。（另外专门再讲）

 

3总结

以上是服务端处理http请求的大致过程。能让大家有个大致轮廓，当然里面有很多细节的知识没讲到，要另外查询资料并学习

信息化的发展离不开服务器，像我们访问的各类网站其背后都是有服务器支撑的。而作为网站运营方一般都会将服务器放置在专业的机房进行托管，而很少放在自家或者办公室中，因为专业机房里的环境及标准都是有一定要求的，比如说电力上的保障、带宽稳定性上都具备优势。

但是我们把服务器托管在远程机房后，若服务器出现了问题，有些是需要我们自己解决处理的，而有些只能由机房人员协助处理。下面我整理了服务器可能会出的一些异常及处理方案以供大家参考。

需要由机房处理的异常

1、电力、网络异常

机房的电力及网络都是商业性质的，比民用的要稳定。但也不排除会出现一些问题，比如BAT企业这几家都遇到过机房光缆被挖断的事故。

当我们发现服务器异常停机且没有自动启动、网络中断的时，就需要直接联系机房安排人员查看情况。

2、受到大流量DDoS攻击导致网站访问异常

当我们的站点受到大流量DDoS攻击后，可能会导致上行带宽被占满的情况，此时我们是不好处理的，需要联系机房安排进行流量清洗。

3、服务器硬件故障

服务器是长期不间断运行的，硬件损伤也是比较严重的。特别是那种传统机械硬件的服务器一旦被突然断电，很可能会导致磁盘故障。

需要由服务器运维人员处理的异常

1、网站受到攻击

首先需要确定攻击类型，是流量攻击还是漏洞提权，然后对应的溯源处理。

2、服务器负载较大，CPU及内存被占满

如果并发及流量较大，可能是正常的，这是由于访客激增导致的服务器负载较大；但如果当前访客不多，而CPU及内存都被占满了，则我们需要找到这些资源被哪个进程使用的，Windows系统使用任务管理器可以查看，Linux中使用top、ps等指令来查看。

3、服务器被黑

服务器被黑这个不在机房服务范围之内，需要服务器运维人员去解决。判断服务器是通过哪种途径被黑的，比如说：程序漏洞、系统漏洞、提权、SQL注入等。