freeBuf
主站

分类

云安全 AI安全 开发安全 终端安全 数据安全 Web安全 基础安全 企业安全 关基安全 移动安全 系统安全 其他安全

特色

热点 工具 漏洞 人物志 活动 安全招聘 攻防演练 政策法规

点我创作

试试在FreeBuf发布您的第一篇文章 让安全圈留下您的足迹
我知道了

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

Linux应急响应笔记
2020-09-01 09:12:32

背景

客户的监控系统发现有异常行为,我临时顶替应急的同事处理一下。

连接到服务器,首先通过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如下

  • lsof 列出所有进程调用
  • lsof abc.txt 显示开启文件abc.txt的进程
  • lsof -c abc 显示abc进程现在打开的文件
  • lsof -p 1234 列出进程号为1234的进程所打开的文件
  • lsof -g gid 显示归属gid的进程情况
  • lsof +d /usr/local/ 显示目录下被进程开启的文件
  • lsof +D /usr/local/ 同上,但是会搜索目录下的目录,时间较长
  • lsof -d 4 显示使用fd为4的进程
  • lsof -i :port 检查哪个进程使用这个端口
  • lsof -i 用以显示符合条件的进程情况

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

定时任务

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

  • /etc/crontab
  • /etc/cron.d/*
  • /etc/cron.daily/*
  • /etc/cron.hourly/*
  • /etc/cron.monthly/*
  • /etc/cron.weekly/
  • /etc/anacrontab
  • /var/spool/cron/*
  • /var/spool/anacron/*

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

内核驱动

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

ssh排查

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

入侵原因

弱密码/默认密码

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

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

查看日志

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

系统日志包括

  • /var/log/cron 记录了系统定时任务相关的日志
  • /var/log/cups 记录打印信息的日志
  • /var/log/dmesg 记录了系统在开机时内核自检的信息
  • /var/log/mailog 记录邮件信息
  • /var/log/message 记录系统重要信息的日志
  • /var/log/btmp 记录错误登录日志。 要使用lastb命令查看
  • /var/log/lastlog 记录系统中所有用户最后一次登录时间的日志。 要使用lastlog命令查看
  • /var/log/wtmp 永久记录所有用户的登录、注销信息,同时记录系统的启动、重启、关机事件。 要使用last命令查看
  • /var/log/utmp 记录当前已经登录的用户信息。要使用w,who,users命令查看
  • /var/log/secure 记录验证和授权方面的信息,比如SSH登录,su切换用户,sudo授权

查看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

# 应急响应
本文为 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
  • 0 文章数
  • 0 关注者
文章目录