Linux应急响应小记

背景

公司不调薪,应急响应的同事都离职了,没有一技之长的我选择继续卧薪尝胆。

客户的监控系统发现有异常行为,让我们进行分析并给出分析报告,领导分配任务给我,只能硬着头皮上了。

连接到服务器,首先通过ps auxef 和 netstat -tulnp两个命令查看异常进程信息,果然发现了两个异常进程 xmp 和 [atd]

通过 ls -al /proc/[pid]/exe 查看这两个进程的程序位置,其中[pid]为xmp 和 [atd]两个进程的进程id

最后确认xmp在 /lib/PROXY/ 目录下,该目录下有两个文件,一个是xmp,一个是config.json [atd]在 /var/spool/at/.sqe/ 目录下,该目录下有很多文件,包括 [atd], cyc.acc, seed, stealth, randfiles 等

把两个进程上传到virustotal,均超过一半的杀毒软件报毒

执行stat /lib/PROXY/xmp, stat /var/spool/at/.sqe/[atd], 发现这两个文件的Change time都是在23,24这两天

所以怀疑应该是23日左右被入侵了,查看 history, /var/log/secure 发现文件都被清空了,查看 /root/.ssh/known_hosts 发现600多条记录。 找不到蛛丝马迹,只能以为是ssh暴破登录了。

重启服务器后,发现[atd]进程依然存在,应该是加入了开机启动,我采用了比较粗暴的方式定位开机启动,在根目录执行

grep -rn '\[atd\]' *

皇天不负苦心人,果然被我找到,在/bin/seed 中有启动[atd]的代码,这个脚本非常简单,只是cd到/var/spool/at/.sqe/然后执行[atd]

接下来我去/etc目录,继续执行 grep -rn seed *, 这条命令执行结果很多行,逐个过滤后,发现在/etc/rc.sysinit 某一行,新增了一个命令seed,这样就能解释为什么[atd]能开机启动了,然而并没有找到xmp的开机启动项,xmp也不会随着服务器重启自启动

看[atd]的进程名,猜测这是一个执行定时任务进程,这个进程监听udp端口,猜测应该是攻击者通过这个进程控制服务器,执行命令,包括启动xmp

再回过头来看xmp,通过config.json文件可以知道这是一个门罗币挖矿病毒

    "pools": [
        {
            "algo": null,
            "coin": "monero",
            "url": "pool.supportxmr.com:80",
            "user": "44wuEu1F6UMDzAu2ByHjKGRR4WiU33zJW6bdHPrHaHbLWYHTyqJUiqG47yvaJof8gfd1HbMR1WhmsDJcX7yhVx8bU8PHRtBx",
            "pass": "HERCULE",
            "rig-id": null,
            "keepalive": true,
            "enabled": true,
            "tls": false,
            "tls-fingerprint": null,
            "daemon": false
        }
    ],

最后清除过程很简单,删除/etc/rc.sysinit seed那一行,删除/bin/seed,删除/lib/PROXY,删除/var/spool/at/.sqe/

加固方法为把一些不必要的端口配置iptables拒绝所有连接请求,修改ssh密码为不常见的强密码。

应急响应流程

言归正传,应急响应的标准流程应该如何? Security+给出了一套流程:
Preparation –> Identification –> Containment –> Eradication –> Recovery –> Lessons learned

以上面的背景里的例子来说,Preparation就是一线人员提供我接入服务器的渠道。Identification就是我发现xmp和[atd]确认服务器被感染病毒。Containment把所有可能受影响的系统都隔离,包括上述known_hosts 发现600多台主机。Eradication根据上面的清除清除所有受影响的主机。Recovery是在清除之后,解除隔离,让业务系统恢复。Lessons learned总结反思事件,一方面从源头上减小安全事件的发现,另一方面提升应急响应的效率。

上面的应急响应还是非常片面的,我搜罗了一系列网友分享的应急响应经验,整理成章方便以后查阅。

我把应急响应流程分为三个部分,分别是 【1】入侵现场,【2】攻击维持,【3】入侵原因,下面我将从这三个方面展开

入侵现场

所谓入侵现场,是指服务器被怀疑中毒的现场环境,一般来说,服务器被怀疑中毒都有异常现象,比如异常的网络流量,异常的端口,cpu/内存占用率异常等等。

准备busysbox

为了避免系统命令被替换,预加载动态库等问题,下载静态链接版本的 busybox 来执行调查。或者下载源码编译 busybox源码,注意编译的时候采用静态链接编译。

网络状态

查看网络监听的tcp和udp端口及对应的进程信息:busybox netstat -tulnp

查看网络所有的网络连接:busybox netstat -anp

通过网络监听及网络连接来辅助定位异常进程

注意如果攻击者获取到了Root权限,被植入内核或者系统层Rootkit的话,连接是可以被隐藏的。

进程信息

如果系统被发现异常,那很大概率是有异常进程在执行

通过ps查看进程信息

busybox ps / ps -aux / ps -ef

通过grep -v 过滤掉一些正常进程,再逐个排查异常进程

通过top命令查看cpu/内存占用异常的进程

busybox top

查找ps中隐藏的进程,通过对比proc中的进程id和ps中的进程id,判断是否有些进程在proc中但不在ps中显示

ps -ef | awk '{print $2}' | sort -n | uniq > ps.p
ls /proc | sort -n |uniq > proc.p
diff ps.p proc.p

执行pstree查看进程树:pstree -p

注意如果攻击者获取到了Root权限,被植入内核或者系统层Rootkit的话,可以把进程隐藏的更彻底。参考文献[1]做了部分的扩展,供读者参考。

定位恶意文件

首先执行busybox stat /usr/bin/ls, busybox stat /usr/bin/lsof, busybox stat /usr/bin/stat, 确认这几个文件没有被修改过

ls
排查 可读写执行目录

ls –alt /tmp/; ls -alt /var/tmp; ls -alt /dev/shm

排序 $PATH 环境变量下的目录的文件,比如

ls -alt /bin, ls -alt /sbin, ls -alt /usr/bin, ls -alt /usr/sbin 等

递归查看所有文件

ls -aR

stat
针对任何的可以文件,都通过stat命令查看各个时间点。

lsof
另外可以通过lsof命令联合查看,lsof常用options如下

find
通过find命令来查找近期新增/修改文件

​例如要查找24小时内被修改的JSP文件

最后一次修改发生在距离当前时间n24小时至(n+1)24 小时
find ./ -mtime 0 -name "*.jsp"

​查找72小时内新增的文件

find / -ctime -2

​查找特殊权限的文件

find / *.jsp -perm 4777

diff
用diff命令把重要的目录做对比,分别对比入侵环境和纯净环境下的不同

比如把连个环境的重要目录都拷贝到PC-x中,利用下面的命令对比两个目录

diff -r {dir 1} {dir 2} 

分析恶意程序

若发现有非法进程,运行ls -l /proc/$PID/exe或file /proc/$PID/exe($PID 为异常进程的pid),查看下 pid 所对应的进程文件路径。

运行cat /proc/$PID/cmdline查看进程执行的命令及参数

通过file命令查看恶意程序文件类型,比如:file /tmp/.sh

如果是ELF文件,可以通过strings查看ELF里带的字符串,可能会泄露一些信息,比如 stirngs /tmp/.elf

如果碰到恶意程序被删除,可以通过内存转储的方式从内存中导出恶意程序

从内存拷贝恢复被删除文件
cp /proc/[pid]/exe /tmp/malware.dump

导出进程内存
cat /proc/[pid]/maps
7ff48bb5d000-7ff48bb5e000

gdb --pid [pid]
dump memory /tmp/malware.dump 0x7ff48bb5d000 0x7ff48bb5e000

通过 stat命令查看恶意程序的Access,Modify,Change时间,了解系统大概是什么时间被入侵。

可以把可疑的恶意程序或内存转储的程序上传到virustotal进行病毒扫描

其他可能用到的命令,比如strings, strace, lsattr, chattr -i, getfacl,setfacl等。

rootkit自动化查杀

chkrootkit
使用方法:

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
tar zxvf chkrootkit.tar.gz
cd chkrootkit-0.53
make sense
./chkrootkit

rkhunter
使用方法:

wget https://nchc.dl.sourceforge.net/project/rkhunter/rkhunter/1.4.4/rkhunter-1.4.4.tar.gz
我测试的时候发现上面链接无法下载了,所以换了下面的链接
wget https://fossies.org/linux/privat/rkhunter-1.4.6.tar.gz
tar -zxvf rkhunter-1.4.6.tar.gz
cd rkhunter-1.4.6
./installer.sh --install
rkhunter -c

攻击维持

查看历史命令

busybox cat ~/.bash_history

检测动态库劫持

查看环境变量动态库劫持

busybox echo $LD_PRELOAD

查看配置文件动态库劫持

busybox cat /etc/ld.so.preload

如果不确定动态库是不是恶意的,可以把动态库上传到virustotal检测。

查看Linux帐户

busybox cat /etc/passwd | grep -v nologin

busybox cat /etc/shadow

busybox stat /etc/passwd

busybox cat /etc/sudoers

查看服务器近期登录的帐户记录:last

开机启动

遍历查看 /etc/ 目录下的init开始的系列目录及文件,以及rc开头的系列目录及文件

查看 /etc/init.d/目录下的文件

查询系统服务,特别是开机自启动的服务
chkconfig –list

service –status-all

定时任务

重点查看以下罗列的目录及文件内容

通过crontab -l罗列当前用户的定时任务

内核驱动

查看内核模块加载情况:lsmod

ssh排查

到 /root/.ssh 目录下查看是否有公钥,以及查看known_hosts文件,看本机通过ssh连接过哪些主机,很可能这些主机有一部分也被入侵了。

入侵原因

弱密码/默认密码

首先通过netstat查看对外开放的服务,确认这些服务(比如mysql,redis,zookeeper,tomcat等)是否有配置认证,认证使用的是否为弱密码或者默认密码。

查看这些服务的日志信息,看是否有入侵记录。

查看日志

日志包括系统日志和应用程序日志,系统日志存放在 /var/log 目录下,应用程序日志需要看应用程序的具体配置

系统日志包括

查看ssh登录记录

less /var/log/secure | grep 'Accepted'

恶意进程关联

大多数情况恶意进程的父进程都是1,而有些情况下恶意进程的父进程可能不是1,比如父进程是httpd,这种情况下,就可以大胆猜测攻击者是通过利用父进程的漏洞达成攻击。

通过命令ps -ef 查看进程的父进程pid也就是ppid

通过 ps auxef 查看恶意进程启动的用户,如果发现比如是mysql用户启动,那么就可以推断是通过mysql服务入侵。

系统加固

修改各个对我开放的服务密码

限制对外开放的服务,如果不方便操作,则通过iptables限制可访问的主机

升级系统组件或者服务使用到的中间件

由于笔者水平有限,文章难免会有错误的,欢迎读者批评指正。笔者个人邮箱:kafrocyang@gmail.com

参考文献

[1] https://www.freebuf.com/articles/system/186012.html
[2] https://cloud.tencent.com/document/product/296/9604
[3] https://xz.aliyun.com/t/1140
[4] https://www.freebuf.com/column/162604.html
[5] https://www.freebuf.com/articles/system/218407.html
[6] https://xz.aliyun.com/t/48#toc-0
[7] https://www.secrss.com/articles/7374

Table of Contents