Linux应急响应怎么处理

这篇文章主要讲解了“Linux应急响应怎么处理”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“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如下

• 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限制可访问的主机

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

感谢各位的阅读，以上就是“Linux应急响应怎么处理”的内容了，经过本文的学习后，相信大家对Linux应急响应怎么处理这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是蜗牛博客，小编将为大家推送更多相关知识点的文章，欢迎关注！

免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：niceseo99@gmail.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。