Linux应急响应自动化检查脚本：快速定位入侵痕迹与安全威胁

1. 项目概述

最近在复盘一些应急响应和蓝队防守的案例，发现很多朋友在接到告警后，面对一台陌生的Linux服务器，常常会感到无从下手。该查哪些文件？哪些命令能快速定位异常？日志怎么看？这些问题如果全靠手动一条条敲命令，不仅效率低下，还容易遗漏关键线索。今天分享一个我用了很久的“瑞士军刀”——linuxcheckshoot，一个开源的Linux应急响应检查脚本。它不是什么高深莫测的武器，但绝对是蓝队和应急响应工程师手边最趁手的工具，能帮你把繁琐的检查流程自动化、标准化，在争分夺秒的应急响应中抢得先机。

简单来说，linuxcheckshoot就是一个Bash脚本，它集成了数十条常用的系统检查命令，一键运行后，会自动收集系统信息、用户登录、进程、网络、服务、计划任务、关键文件等十几个维度的数据，并输出一份结构化的报告。它的核心价值在于“快”和“全”，让你在最短时间内对服务器的安全状态有一个全景式的了解，快速定位入侵痕迹。无论是护网期间的防守、日常的安全巡检，还是处理安全事件后的溯源分析，这个脚本都能极大地提升你的工作效率。

2. 脚本核心功能与设计思路拆解

2.1 为什么需要这样一个脚本？

在真实的应急响应场景中，时间就是一切。攻击者可能正在横向移动，可能正在窃取数据，每一秒的延迟都可能带来更大的损失。手动检查面临几个痛点：一是命令繁多易遗漏，资深工程师可能记得住几十条命令，但新手或紧张状态下难免丢三落四；二是输出格式杂乱，不同命令的输出混在一起，分析起来费时费力；三是缺乏时间基线，单次检查的结果是孤立的，难以判断哪些变化是正常的系统更新，哪些是恶意行为。

linuxcheckshoot的设计思路正是为了解决这些问题。它采用“采集-分析”分离的模式。脚本本身只负责标准化地采集数据，将所有命令的输出重定向到以时间戳命名的目录中。这样做的好处是，原始数据被完整保存，你可以随时回头查看，也可以将多次检查的结果进行对比，快速发现差异点。脚本不做过多的实时分析判断，因为分析工作往往需要结合上下文和威胁情报，这部分更适合由工程师在拿到报告后，利用自己的经验来完成。这种设计保证了工具的通用性和灵活性。

2.2 脚本功能模块全景

这个脚本的检查范围覆盖了Linux系统安全的绝大多数关键点，我们可以将其功能模块分解如下：

1. 系统信息概览：采集主机名、内核版本、系统运行时间、当前时间等基础信息，这是了解系统环境的起点。
2. 用户与认证安全：检查当前登录用户、历史登录记录（last、lastb）、/etc/passwd和/etc/shadow文件的完整性、sudo权限分配以及空口令账户。这是排查账户被冒用的核心。
3. 进程与资源监控：列出所有正在运行的进程（ps auxf）、查看占用资源（CPU、内存）最高的进程，并特别关注网络监听进程。隐藏的恶意进程往往在这里露出马脚。
4. 网络连接与配置：显示所有网络连接（netstat或ss）、分析监听端口、检查路由表和ARP缓存，并抓取/etc/hosts文件。用于发现异常外连、后门端口和ARP欺骗。
5. 系统服务与启动项：枚举所有运行中的服务（systemctl或service）、检查系统启动项（rc.local、/etc/init.d/等）。攻击者常通过添加服务或启动项实现持久化。
6. 计划任务排查：检查系统级（/etc/cron*）和用户级（crontab -l）的计划任务。这是攻击者最常用的持久化手段之一。
7. 关键文件与目录监控：检查/tmp、/dev/shm等可写临时目录中的可疑文件，列出SUID/SGID特殊权限文件，并统计最近被修改的系统关键文件（如/bin、/sbin下的二进制文件）。
8. 日志文件快速审查：自动提取/var/log/目录下关键日志（如secure、auth.log、messages、syslog）的最近若干条记录，或根据时间过滤。这是追溯攻击链的主要依据。

脚本通过将这些检查点模块化，确保了一次执行就能覆盖大部分检查面，输出一份可供深度分析的“数据快照”。

3. 脚本的获取、部署与核心使用详解

3.1 获取与初步检查

通常，你可以从GitHub等开源平台获取linuxcheckshoot脚本。在下载和运行任何外部脚本前，有一个至关重要的安全习惯：检查源代码。尤其是作为安全从业者，更应如此。

# 1. 下载脚本（假设使用wget） wget https://raw.githubusercontent.com/某仓库/linuxcheckshoot/main/linuxcheckshoot.sh # 2. 赋予执行权限 chmod +x linuxcheckshoot.sh # 3. （关键步骤）查看脚本内容 cat linuxcheckshoot.sh | head -100

注意：在真实环境中，务必花几分钟快速浏览脚本内容。确认它没有包含rm -rf /、wget | bash这类危险命令，也没有向不明地址发送数据的行为。这是一个基本的信任但验证的原则。

3.2 运行脚本与报告生成

脚本的使用非常简单，通常直接运行即可。它会自动创建输出目录。

# 以root权限运行，因为很多检查项需要root权限才能获取完整信息 sudo ./linuxcheckshoot.sh

运行后，你会在当前目录下看到一个以时间戳命名的文件夹，例如linux_checks_20231027_143022。所有检查结果都按模块分类，存储在这个文件夹内的各个文本文件中。

3.3 报告目录结构解析

理解输出报告的结构，能帮你高效地找到所需信息。一个典型的报告目录如下：

linux_checks_20231027_143022/ ├── 00_system_info.txt # 系统基本信息 ├── 01_user_auth.txt # 用户与认证信息 ├── 02_processes.txt # 进程列表与资源占用 ├── 03_network.txt # 网络连接与配置 ├── 04_services.txt # 系统服务与启动项 ├── 05_cron_jobs.txt # 计划任务 ├── 06_files_dirs.txt # 关键文件与目录检查 ├── 07_logs.txt # 关键日志摘要 └── command_history.txt # （可能包含）当前用户的命令历史

你可以使用grep、less等工具快速检索。例如，想快速查看所有监听在非标准端口的进程：

grep -i “listen” 03_network.txt

或者，想对比两次应急响应检查中进程列表的差异（假设有两次检查报告report1和report2）：

diff report1/02_processes.txt report2/02_processes.txt

4. 基于脚本输出的深度分析与排查实战

脚本提供了原材料，真正的价值在于工程师如何分析这些材料。下面结合几个典型入侵场景，演示如何利用脚本报告进行深度排查。

4.1 场景一：排查挖矿木马

挖矿木马最显著的特征是持续消耗大量CPU资源，并且可能有异常的网络连接（连接矿池）。

分析步骤：

1. 定位高CPU进程：首先打开02_processes.txt，查看顶部哪些进程占用了最高的CPU。一个陌生的、名字可能伪装成kthreadd、xmr、minerd的进程值得高度怀疑。
2. 关联网络连接：记下可疑进程的PID，然后在03_network.txt中搜索该PID。查看它是否建立了对外连接，连接的IP和端口是否常见矿池地址（如3333、4444、5555端口）。
3. 追溯来源与持久化：
   • 在04_services.txt和05_cron_jobs.txt中搜索该进程名或它的路径，看它是否被注册为服务或定时任务。
   • 在06_files_dirs.txt中，查看SUID文件列表和最近修改的系统文件，木马可能通过修改系统二进制文件或设置特殊权限来隐藏自己。
   • 检查07_logs.txt，看是否有关于该进程启动或崩溃的日志记录。

4.2 场景二：排查Webshell后门

Webshell通常通过Web漏洞上传，存在于Web目录中，并可能伴随有异常进程和网络监听。

分析步骤：

1. 查找可疑监听端口：查看03_network.txt中所有LISTEN状态的连接。除了常见的80、443、22、3306端口，需要特别关注那些高位的、不常见的监听端口，这可能是Webshell开启的后门端口。
2. 关联进程与文件：找到监听异常端口的进程PID和程序路径。检查该路径是否在Web目录（如/var/www/html，/tmp）下，文件修改时间是否异常。
3. 检查计划任务和启动项：攻击者可能会通过cron来定期访问Webshell以保持访问。仔细检查05_cron_jobs.txt，寻找包含curl、wget访问本机异常URL的任务。
4. 审查Web日志：虽然脚本可能只抓取了系统日志摘要，但你可以根据发现的可疑Webshell文件路径和时间，去手动分析/var/log/apache2/access.log或/var/log/nginx/access.log，找到文件上传的源头IP和漏洞利用痕迹。

4.3 场景三：排查横向移动与权限提升痕迹

攻击者在获取一台主机权限后，往往会尝试收集密码、密钥，并向内网其他机器扩散。

分析步骤：

1. 检查用户与登录：查看01_user_auth.txt中的历史登录记录（last），寻找异常IP地址的登录（尤其是非办公时间的远程登录）。检查是否有新增的、具有sudo权限的陌生用户。
2. 分析命令历史：如果脚本收集了command_history.txt，仔细审查其中是否有敏感命令，如ssh到内网其他IP、nmap扫描、cat /etc/shadow、find命令搜索敏感文件等。
3. 查看SSH相关文件：检查~/.ssh/目录下的authorized_keys文件是否被添加了攻击者的公钥（这是一种常见的后门）。脚本的06_files_dirs.txt可能会列出最近修改的文件，可以从中发现线索。
4. 关注网络连接：在03_network.txt中，除了对外连接，也要关注大量的对内网其他IP的ESTABLISHED连接，这可能是横向移动的迹象。

5. 脚本的定制化与高级使用技巧

原版脚本已经很强大了，但真正的威力在于你能根据自身环境和需求对它进行定制。

5.1 添加自定义检查项

假设你的业务服务器上有一个特定的应用程序日志/opt/myapp/logs/app.log需要监控，你可以轻松地修改脚本，添加一个检查模块。

编辑linuxcheckshoot.sh，在合适的位置（例如在日志检查部分附近）添加：

echo “=== 5.8 自定义应用日志检查 ===” >> $LOG_DIR/07_logs.txt echo “最近50条应用日志：” >> $LOG_DIR/07_logs.txt tail -n 50 /opt/myapp/logs/app.log 2>/dev/null || echo “应用日志文件不存在” >> $LOG_DIR/07_logs.txt echo -e “\n” >> $LOG_DIR/07_logs.txt

这样，每次运行脚本，你的应用日志摘要也会被包含在报告中。

5.2 实现基线比对功能

脚本本身不直接做比对，但我们可以通过简单的Shell脚本，利用diff命令来实现两次检查报告的自动比对。

创建一个名为compare_reports.sh的脚本：

#!/bin/bash # 用法：./compare_reports.sh 旧报告目录 新报告目录 OLD_DIR=$1 NEW_DIR=$2 OUTPUT_DIR=“comparison_$(date +%Y%m%d_%H%M%S)” mkdir -p $OUTPUT_DIR for file in $(ls $OLD_DIR/*.txt); do basefile=$(basename $file) diff -u $OLD_DIR/$basefile $NEW_DIR/$basefile > $OUTPUT_DIR/diff_${basefile} 2>&1 done echo “比对完成，结果保存在 $OUTPUT_DIR/ 目录下。重点关注有变化的文件。”

运行./compare_reports.sh linux_checks_20231026_090000 linux_checks_20231027_140000，它会生成一系列.diff文件，清晰地标出了新增、删除和修改的内容，让你快速聚焦于系统的变化点。

5.3 与威胁情报联动（思路）

对于高级蓝队，可以将脚本的输出与威胁情报进行初步关联。例如，将03_network.txt中提取到的所有对外连接IP，通过一个本地化的IOC（入侵指标）列表进行快速匹配。

# 假设你有一个恶意IP列表文件 ioc_ips.txt grep -oE ‘([0-9]{1,3}\.){3}[0-9]{1,3}’ 03_network.txt | sort -u | while read ip; do if grep -q $ip ioc_ips.txt; then echo “[!] 警报：发现与威胁情报匹配的IP连接：$ip” fi done

这只是一个简单的例子，实际中可以集成更复杂的API查询。

6. 使用中的注意事项与避坑指南

即使工具再好，使用不当也会事倍功半，甚至产生误导。

1. 权限问题：务必使用root或sudo运行脚本。许多关键信息（如所有用户的进程、部分日志、系统文件属性）需要最高权限才能访问。以普通用户运行会导致报告残缺，遗漏重要线索。
2. 环境干扰：脚本会执行大量命令，可能会被攻击者植入的恶意命令别名或函数（通过修改.bashrc等）所干扰。一个变通的方法是使用命令的绝对路径（如/bin/ps）来编写脚本，或者在一个已知干净的环境（如从救援镜像启动）中运行。
3. 结果误判：脚本输出的是“现状”和“线索”，而非“结论”。报告里一个陌生的进程、一个高位的端口，不一定就是恶意的。可能是业务部门新上的服务，也可能是运维留下的管理工具。必须结合业务上下文进行研判，避免误报。在采取隔离、杀进程等处置动作前，尽量与相关系统负责人确认。
4. 覆盖范围限制：脚本主要针对文件系统、进程、网络等常见持久化点。对于高级的Rootkit（如内核级Rootkit）、内存马（如Java Web内存Shell），它的检测能力有限。这类深度隐藏的威胁需要借助专业的内存取证工具（如Volatility）或EDR（端点检测与响应）产品来发现。
5. 不要完全依赖自动化：linuxcheckshoot是辅助工具，不能替代工程师的分析思维。它帮你完成了繁琐的“收集”工作，但“分析”和“决策”必须由人来完成。培养自己对系统行为的深刻理解，比熟练使用任何工具都重要。

我个人在多次护网和应急响应中，习惯在排查初期就运行一遍这个脚本，它能让我在几分钟内建立起对目标服务器的整体认知，快速缩小排查范围。它的输出报告也成为了我撰写事件分析报告时最有力的数据支撑。记住，工具的价值在于延伸人的能力，而不是取代人的思考。把linuxcheckshoot纳入你的应急响应工具箱，然后带着你的经验和判断力，去解决真正的问题。