作者介绍 林伟壕，网络安全DevOps新司机，先后在中国电信和网易游戏从事数据网络、网络安全和游戏运维工作。对Linux运维、虚拟化和网络安全防护等研究颇多，目前专注于网络安全自动化检测、防御系统构建。 导读： 遇到服务器被黑，很多人会采用拔网线、封iptables或者关掉所有服务的方式应急，但如果是线上服务器就不能立即采用任何影响业务的手段了，需要根据服务器业务情况分类处理。 下面我们看一个标准的服务器安全应急影响应该怎么做，也算是笔者从事安全事件应急近5年以来的一些经验之谈，借此抛砖引玉，希望大神们不吝赐教。 图1将服务器安全应急响应流程分为发现安全事件（核实）、现场保护、服务器保护、影响范围评估、在线分析、数据备份、深入分析、事件报告整理等8个环节。接下来我们将每个环节分解，看看需要如何断开异常连接、排查入侵源头、避免二次入侵等。
处理思路 一、核实信息（运维/安全人员） 根据安全事件通知源的不同，分为两种：
二、现场保护（运维） 我们很多人看过大陆的电视剧《重案六组》，每次接到刑事案件，刑警们第一时间就是封锁现场、保存现场原状。同样道理，安全事件发生现场，跟刑事案件发生现场一样，需要保存第一现场重要信息，方便后面入侵检测和取证。
相关信息采集命令如下： 进程信息：ps axu 网络信息：netstat a 网络 进程：lsof / netstat -p
相关信息采集命令如下： 查看当前登录用户：w 或 who -a 三、服务器保护（运维/机房） 这里的现场保护和服务器保护是两个不同的环节，前者注重取证，后者注重环境隔离。 核实机器被入侵后，应当尽快将机器保护起来，避免被二次入侵或者当成跳板扩大攻击面。此时，为保护服务器和业务，避免服务器被攻击者继续利用，应尽快歉意业务，立即下线机器。 如果不能立即处理，应当通过配置网络ACL等方式，封掉该服务器对网络的双向连接。 四、影响范围评估（运维/开发） 一般是运维或者程序确认影响范围，需要运维通过日志或者监控图表确认数据库或者敏感文件是否泄露，如果是代码或者数据库泄露了，则需要程序评估危害情况与处置方法。 影响访问评估一般从下面几点入手来：
由此确定检查影响范围，确认所有受到影响的网段和机器。 五、在线分析（安全人员/运维） 这时需要根据个人经验快速在线分析，一般是安全人员和运维同时在线处理，不过会涉及多人协作的问题，需要避免多人操作机器时破坏服务器现场，造成分析困扰，之前笔者遇到一个类似的问题，就是运维排查时敲错了iptables的命令，将iptables -L敲成iptables -i导致iptables-save时出现异常记录，结果安全人员上来检查时就被这条记录迷惑了，导致处理思路受到一定干扰。 1、所有用户History日志检测
可以执行以下命令检查： grep -v -E "^#" /etc/passwd | awk -F： '$3 == 0 { print $1}' 2、反连木马判断
3、可疑进程判断
4、Crontab检测 不要用crontab l查看crontab（绕过检测），也有通过写crontab配置文件反弹shell的，笔者接触过几次，一般都是使用的bash -i |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
