今天又一次应急做的特别失败，这已经第二次应急特别失败的案例了。在回家的路上自己反思了一下这两次失败的一些需要反思的点，特此记录，以做警示。
现象
两次应急都有一个共同点就是客户认为这个机器被攻击了，但是机器上并没有明显的痕迹，利用一些主机入侵检测软件也没有发现任何的问题。客户需要确认这个机器是否真的被攻击了。自己接入机器之后排查机器中遗留的信息，但是登录机器按照常见的思路排查一遍之后发现没有找到任何的蛛丝马迹,之后内心便开始产生这个机器没有问题的结论，并开始进入乱查一气的节奏。这就导致本来毫无头绪的事情变得更加毫无头绪。然后慢慢的耐心耗尽，进入磨洋工阶段，最后会给客户一个没问题的结论，然后结束排查。
项目
接到一个项目应该跟客户了解清楚该项目的一个基本信息，明确客户的需求。而不是上来就蛮干瞎干,倒腾一通,结果与客户希望的事情相反，这样就会产生费力不讨好的结果。
客户
客户因该是最了解主机环境的人(即使他不了解，应该也能找到了确认的人)，因此应该去找客户确认机器所处的基本环境。如机器所处的位置（云/IDC机房/自建机房）、网络环境(机器在网络中的位置，上下联的机器)、机器的作用(正常对外提供的服务)。通过这些信息来初步推测下受攻击的机器可能会存在的问题，找到一个排查问题的基本入手点。但是还需要记住一点客户所说的不一定是真的,在排查问题时，不应该想当然的跟着客户的思路去走，而去省略一些排查的步骤，这样在某一些情况会排查不出问题来。要相信在计算机科学中没有神话故事，只有事实。如果排查出来的事实与客户的描述有出入，那么极有可能就是客户记错了。
耐心，耐心，耐心
有时候可能会因为自身知识局限等原因导致一直排查不出结果，但是仍要耐心做好各个方面基本的信息收集，可以参考后面的信息排查章节进行信息的排查。这样即使失败了，在后面做复盘或请教他人时，能够快速的找到问题。
信息排查
下面的排查需要根据主机的实际情况进行排查，排查问题时一定要仔细有耐心，并且要善用系统中自带且常见的工具。
命令校验
确保系统中使用的命令是正常且未被修改过的。
- linux:
rpm -Va
运行进程
进程的版本、是否已经爆出漏洞
环境变量
envld.so.preload:so劫持
用户登录情况
- lastlog
- who
- who /var/log/wtmp
- last
用户操作记录
.bash_history
最近修改文件
根据排查到遗留文件的信息查找某个时间段内被修改的文件。
常用命令
- stat
- ls
- find
find / -ctime -xx - awk
- uniq
- sort
- grep
- xargs