以下是我们在应急过程中的一些心得和一些深入的研究过程。本文兼顾新手和一些像我们在安全中摸爬滚打了一段时间的小白们。LMM级别的RootKit应急由于知识深度有限,暂时不在本文中体现。本文中提到的RootKit为应用级别的RootKit,一些文章介绍的检测方法可能发现不了所存在的问题。
- 传说中的三板斧:ps、netstat、top
这三条命令及其有用,简单一点的应急问题基本这三条命令就搞定了,我们逐条来说。
1
2
|
ps -ef ps aux 两条命令就搞定了 |
但至于那些是恶意进程和反弹shell的特征需要看经验喽。
1
|
netstat -pantu 显示所有网络链接 |
-pantu有一个最大的好处就是可以看到进程的PID和进程名称。可以检查非法外联
1
|
top |
一个动态检查进程状态的命令,对一些僵尸网络恶意程序,暴力破解程序啥的能看出一些端倪。
- 一些容易忽略的小经验点和奇淫技巧
1.在没有Tripwire或者没有安装完系统备份重要命令的情况下检查MD5
先感谢漏洞盒子的旺角扛把子同学,教给了我这个方法,起初没领会到意义何在,后来发现是神器,在rpm命令没有被替换的条件下:
1
2
|
rpm -Va 与官方源进行比对 rpm -qf 检查列出的文件是哪个安装包 |
对于应急响应而言,许多工程师面临和我一样的问题,系统命令是否被替换,OpenSSH安装被替换植入了后门。比如在这次应急响应中,我们面临了这样的问题。例如我们在这次极其复杂的应急中通过方法成功找到了SSHD后门。
可以看到ls和ssh的MD5值与官方都不一致,sshd_config由于个人定制MD5与官方有出入是不正常的,然而SSHD就说不过去吧。立刻用rpm -qf检查了一下usr/bi/ssh属于哪个rpm数据包。
果不其然被替换了,同是ls也是使用的极其别扭,上图也验证的ls被替换过了。
2.文件的属性和权限往往对于同步溯源有重要意义
很多时候我们系统发现了恶意文件,我们很头疼,怎么上来的。如果存在Web接口直接被入侵的情况还比较乐观,然而如果服务器开着NFS、Rsync、FTP呢?这时候问题就来了,往往我们在做应急的时候忽略了文件权限。
这是一次黑帽SEO行为,我们发现传上来的文件的uid和gid分别是xxx和nobody。我们往往关注的是恶意文件的本身而非文件的权限。我们可以做一个判断,如果这台日志不全,相关命令被清的情况下,我们可以做如下的分析。如果机器被root了通过寄生虫繁殖的话很明显,权限应该是root:root。如果是拿到了某个低权限的账户shell应该不会是xxxx,nobody。为什么是xxxx.nobody毫无疑问,这时我发现在Rsync的conf里面配置了文件,正好和权限对上了。说明推送文件上来的机器被黑的概率远大于这台机器被黑的概率。果不其然在那台机器上发现了反弹shell。
3.抓出应用层rootkit的尾巴
一部分应用层的rootkit经过笔者实验,考虑的并不是那么周全,主要是替换相关命令来进行隐蔽自身的目的。系统中有几个命令想通过应用级rootkit进行劫持比较困难比如:lsof strace等。在应急响应的过程中,大多数lsof命令是比较安全的命令,当然LKM级别的除外。所以通过:
1
|
lsof | grep :* |
有时候在Netstat被替换的情况下,仍能抓出可疑的端口和外联信息。
4.加密Webshell的查杀
这其实是笔者在曾经妄想去狼厂被面试时候被难住的一道面试题,后来想了一下时间是个好方法,上一篇文章中讲述了通过mtime结合find进行相关的查找。然而我又熟悉了一下find命令发现还可以这样找:
touch
-t oldfile1 newfile1 把老文件时间戳赋给新文件时间戳
touch
-t oldfile2 newfile2
find
.-
type
f -name
"*.php"
-newer newfile1 -
exec
ls
-l {} \; 查找比老文件晚的
find
.-
type
f -name
"*.php"
-newer newfile1 ! newfile2 -
exec
ls
-l {} \;查找介于12文件时间之间的文件
5.把/proc/exe 成功的dump出来也许会发生一些有意思的事儿
这个是基于真实案例,这位小黑客写的一个应用级后门,有自己独立的进程号xxx,于是我们:
1
2
|
cat /proc/xxx/exe >~ /test strings ~ /test |
你猜我们发现了啥,黑客的测试BLOG,说实话我的内心也是崩溃的。不管你们怎么想,我是惊了。
6.如何以正确的方法审计Web日志
刚入行的时候,各种accesslog啥的好多个G,当年技术比较渣,看得自己眼睛快瞎了。于是祭出的Linux3大宝之一的awk命令。对准确时间的筛选能让我们更关注的分析相关日志,这里抛砖引玉的说下如何通过正则和一些命令进行日志分析:
1
2
|
cat access_log | awk '{if($4~/^\[13/) {print $1"\t"$7}}' | awk '{print $1}' | sort | uniq -c 我们可以编写正则判断,统计13号一天的IP访问频度。 cat access_log | awk '{if($4>="[13/Mar/2017:10:00:00"&&$4<="[13/Mar/2017:11:00:00") {print $1"\t"$4"\t"$7}}' | cat 统计13号10-14点之间的日志信息 |
好吧,也许有人说正则或者awk命令学习起来有门槛,我的小伙伴还给我推荐了这么一款工具。https://www.goaccess.io/download
- 浅谈一下应用启动引导
想写这块的原因还是这次应急,我们发现了一个隐藏成mysql进程名的进程,我一直纳闷一个后门是怎么隐藏成mysql进程的。发现坑在这里:/etc/init.d被修改过,一般应用图方便会把启动项写进init.d中。在/etc/init.d/mysql中,存在了一行代码:
这样成功后门伴随着mysql进行了启动,并且名称为mysql有一定的隐藏效果。
同时笔者在处理过一起的僵尸网络流量中存在写到了/etc/rc.*的情况也能实现开启自启动的效果。
- 总结
写这篇文章仅仅是自己在工作中发现的一些小技巧和坑,因为应急响应的文章在网上很难找,大多数靠自己摸索,希望同行的小伙伴们少走弯路,一起共同提高。
文章评论