
1. 项目概述最近在复盘一些应急响应和蓝队防守的案例发现很多朋友在接到告警后面对一台陌生的Linux服务器常常会感到无从下手。该查哪些文件哪些命令能快速定位异常日志怎么看这些问题如果全靠手动一条条敲命令不仅效率低下还容易遗漏关键线索。今天分享一个我用了很久的“瑞士军刀”——linuxcheckshoot一个开源的Linux应急响应检查脚本。它不是什么高深莫测的武器但绝对是蓝队和应急响应工程师手边最趁手的工具能帮你把繁琐的检查流程自动化、标准化在争分夺秒的应急响应中抢得先机。简单来说linuxcheckshoot就是一个Bash脚本它集成了数十条常用的系统检查命令一键运行后会自动收集系统信息、用户登录、进程、网络、服务、计划任务、关键文件等十几个维度的数据并输出一份结构化的报告。它的核心价值在于“快”和“全”让你在最短时间内对服务器的安全状态有一个全景式的了解快速定位入侵痕迹。无论是护网期间的防守、日常的安全巡检还是处理安全事件后的溯源分析这个脚本都能极大地提升你的工作效率。2. 脚本核心功能与设计思路拆解2.1 为什么需要这样一个脚本在真实的应急响应场景中时间就是一切。攻击者可能正在横向移动可能正在窃取数据每一秒的延迟都可能带来更大的损失。手动检查面临几个痛点一是命令繁多易遗漏资深工程师可能记得住几十条命令但新手或紧张状态下难免丢三落四二是输出格式杂乱不同命令的输出混在一起分析起来费时费力三是缺乏时间基线单次检查的结果是孤立的难以判断哪些变化是正常的系统更新哪些是恶意行为。linuxcheckshoot的设计思路正是为了解决这些问题。它采用“采集-分析”分离的模式。脚本本身只负责标准化地采集数据将所有命令的输出重定向到以时间戳命名的目录中。这样做的好处是原始数据被完整保存你可以随时回头查看也可以将多次检查的结果进行对比快速发现差异点。脚本不做过多的实时分析判断因为分析工作往往需要结合上下文和威胁情报这部分更适合由工程师在拿到报告后利用自己的经验来完成。这种设计保证了工具的通用性和灵活性。2.2 脚本功能模块全景这个脚本的检查范围覆盖了Linux系统安全的绝大多数关键点我们可以将其功能模块分解如下系统信息概览采集主机名、内核版本、系统运行时间、当前时间等基础信息这是了解系统环境的起点。用户与认证安全检查当前登录用户、历史登录记录last、lastb、/etc/passwd和/etc/shadow文件的完整性、sudo权限分配以及空口令账户。这是排查账户被冒用的核心。进程与资源监控列出所有正在运行的进程ps auxf、查看占用资源CPU、内存最高的进程并特别关注网络监听进程。隐藏的恶意进程往往在这里露出马脚。网络连接与配置显示所有网络连接netstat或ss、分析监听端口、检查路由表和ARP缓存并抓取/etc/hosts文件。用于发现异常外连、后门端口和ARP欺骗。系统服务与启动项枚举所有运行中的服务systemctl或service、检查系统启动项rc.local、/etc/init.d/等。攻击者常通过添加服务或启动项实现持久化。计划任务排查检查系统级/etc/cron*和用户级crontab -l的计划任务。这是攻击者最常用的持久化手段之一。关键文件与目录监控检查/tmp、/dev/shm等可写临时目录中的可疑文件列出SUID/SGID特殊权限文件并统计最近被修改的系统关键文件如/bin、/sbin下的二进制文件。日志文件快速审查自动提取/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和report2diff report1/02_processes.txt report2/02_processes.txt4. 基于脚本输出的深度分析与排查实战脚本提供了原材料真正的价值在于工程师如何分析这些材料。下面结合几个典型入侵场景演示如何利用脚本报告进行深度排查。4.1 场景一排查挖矿木马挖矿木马最显著的特征是持续消耗大量CPU资源并且可能有异常的网络连接连接矿池。分析步骤定位高CPU进程首先打开02_processes.txt查看顶部哪些进程占用了最高的CPU。一个陌生的、名字可能伪装成kthreadd、xmr、minerd的进程值得高度怀疑。关联网络连接记下可疑进程的PID然后在03_network.txt中搜索该PID。查看它是否建立了对外连接连接的IP和端口是否常见矿池地址如3333、4444、5555端口。追溯来源与持久化在04_services.txt和05_cron_jobs.txt中搜索该进程名或它的路径看它是否被注册为服务或定时任务。在06_files_dirs.txt中查看SUID文件列表和最近修改的系统文件木马可能通过修改系统二进制文件或设置特殊权限来隐藏自己。检查07_logs.txt看是否有关于该进程启动或崩溃的日志记录。4.2 场景二排查Webshell后门Webshell通常通过Web漏洞上传存在于Web目录中并可能伴随有异常进程和网络监听。分析步骤查找可疑监听端口查看03_network.txt中所有LISTEN状态的连接。除了常见的80、443、22、3306端口需要特别关注那些高位的、不常见的监听端口这可能是Webshell开启的后门端口。关联进程与文件找到监听异常端口的进程PID和程序路径。检查该路径是否在Web目录如/var/www/html/tmp下文件修改时间是否异常。检查计划任务和启动项攻击者可能会通过cron来定期访问Webshell以保持访问。仔细检查05_cron_jobs.txt寻找包含curl、wget访问本机异常URL的任务。审查Web日志虽然脚本可能只抓取了系统日志摘要但你可以根据发现的可疑Webshell文件路径和时间去手动分析/var/log/apache2/access.log或/var/log/nginx/access.log找到文件上传的源头IP和漏洞利用痕迹。4.3 场景三排查横向移动与权限提升痕迹攻击者在获取一台主机权限后往往会尝试收集密码、密钥并向内网其他机器扩散。分析步骤检查用户与登录查看01_user_auth.txt中的历史登录记录last寻找异常IP地址的登录尤其是非办公时间的远程登录。检查是否有新增的、具有sudo权限的陌生用户。分析命令历史如果脚本收集了command_history.txt仔细审查其中是否有敏感命令如ssh到内网其他IP、nmap扫描、cat /etc/shadow、find命令搜索敏感文件等。查看SSH相关文件检查~/.ssh/目录下的authorized_keys文件是否被添加了攻击者的公钥这是一种常见的后门。脚本的06_files_dirs.txt可能会列出最近修改的文件可以从中发现线索。关注网络连接在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} 21 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. 使用中的注意事项与避坑指南即使工具再好使用不当也会事倍功半甚至产生误导。权限问题务必使用root或sudo运行脚本。许多关键信息如所有用户的进程、部分日志、系统文件属性需要最高权限才能访问。以普通用户运行会导致报告残缺遗漏重要线索。环境干扰脚本会执行大量命令可能会被攻击者植入的恶意命令别名或函数通过修改.bashrc等所干扰。一个变通的方法是使用命令的绝对路径如/bin/ps来编写脚本或者在一个已知干净的环境如从救援镜像启动中运行。结果误判脚本输出的是“现状”和“线索”而非“结论”。报告里一个陌生的进程、一个高位的端口不一定就是恶意的。可能是业务部门新上的服务也可能是运维留下的管理工具。必须结合业务上下文进行研判避免误报。在采取隔离、杀进程等处置动作前尽量与相关系统负责人确认。覆盖范围限制脚本主要针对文件系统、进程、网络等常见持久化点。对于高级的Rootkit如内核级Rootkit、内存马如Java Web内存Shell它的检测能力有限。这类深度隐藏的威胁需要借助专业的内存取证工具如Volatility或EDR端点检测与响应产品来发现。不要完全依赖自动化linuxcheckshoot是辅助工具不能替代工程师的分析思维。它帮你完成了繁琐的“收集”工作但“分析”和“决策”必须由人来完成。培养自己对系统行为的深刻理解比熟练使用任何工具都重要。我个人在多次护网和应急响应中习惯在排查初期就运行一遍这个脚本它能让我在几分钟内建立起对目标服务器的整体认知快速缩小排查范围。它的输出报告也成为了我撰写事件分析报告时最有力的数据支撑。记住工具的价值在于延伸人的能力而不是取代人的思考。把linuxcheckshoot纳入你的应急响应工具箱然后带着你的经验和判断力去解决真正的问题。