Web3应急响应实战：Linux服务器入侵排查与取证全流程解析

1. 项目概述：一次真实的Web3应急响应实战复盘

最近在知攻善防实验室的应急响应靶场里，把Web3这个靶机从头到尾盘了一遍。这玩意儿挺有意思，它不像传统的CTF靶机那样给你一堆显眼的漏洞去利用，而是模拟了一个已经被攻击者“光顾”过的服务器现场。你的角色不是攻击者，而是那个在凌晨三点被电话叫醒、需要立刻搞清楚“发生了什么”、“谁干的”、“损失多大”以及“怎么擦屁股”的安全工程师。Web3这个靶机，从名字看似乎和区块链、智能合约有点关系，但实际场景更偏向于一个传统的Web服务器被入侵后的应急响应流程，考验的是你排查、分析和取证的硬功夫。对于想从事安全运维、应急响应或者蓝队工作的朋友来说，这种靶机训练的价值，远比单纯打几个漏洞注入点要大得多，因为它练的就是你面对真实安全事件时的那套肌肉记忆和思维流程。

靶机给出的挑战目标非常明确：找到攻击者的两个IP地址、揪出系统里隐藏的用户名、以及拿到黑客留下的三个flag。这基本上对应了一次安全事件应急响应的核心任务：溯源攻击源（IP）、评估入侵程度（隐藏后门/用户）、确认攻击意图或获取攻击证据（Flag）。整个过程，你需要像侦探一样，在庞大的系统日志、文件痕迹和进程信息中，寻找那些不寻常的“蛛丝马迹”。下面，我就结合这次实战，把整个应急响应的流程、用到的工具、关键的排查点以及踩过的坑，系统地梳理一遍，希望能给你提供一个清晰的“作战地图”。

2. 应急响应核心流程与前期准备

应急响应切忌无头苍蝇似的乱翻。一个高效的流程能帮你节省大量时间，避免遗漏关键证据。我的习惯是遵循一个标准的“四步法”：信息收集、痕迹分析、入侵判定、报告整理。在开始操作之前，还有两件至关重要的事情：环境准备和证据保全。

2.1 环境准备与操作原则

拿到靶机权限（通常是给了你一个低权限用户shell或者直接就是root）后，别急着满世界grep。首先，确保你的操作环境是可靠的。

第一，建立备份与隔离意识。虽然靶机是虚拟环境，但这个习惯必须养成。在真实场景中，你的第一个操作应该是尽可能对受害系统做内存镜像和磁盘快照，以防后续调查动作破坏现场。在靶机里，我们可以通过简单复制关键日志文件来模拟。我通常会立刻创建一个工作目录，比如/tmp/ir_work/，然后把所有后续分析用的文件都扔进去。

mkdir -p /tmp/ir_work/logs /tmp/ir_work/config /tmp/ir_work/artifacts

第二，开启会话记录。使用script命令记录你所有的终端操作。这既是给你的调查过程留底，方便回溯，也能作为最终报告的一部分，证明你的操作是规范、可审计的。

script -a /tmp/ir_work/audit_trail.log

第三，收集系统基础信息。快速给系统拍一张“全身照”。这能帮你了解系统的整体状况，也为后续的异常对比建立基线。

# 系统信息 uname -a > /tmp/ir_work/system_info.txt cat /etc/*release >> /tmp/ir_work/system_info.txt # 网络连接（ESTABLISHED状态很重要） netstat -tunap > /tmp/ir_work/netstat.txt ss -tunap >> /tmp/ir_work/netstat.txt # 进程树 ps auxf > /tmp/ir_work/ps_auxf.txt pstree -p > /tmp/ir_work/pstree.txt # 已安装软件包（看是否有异常或后门版本） dpkg -l | head -50 > /tmp/ir_work/packages.txt # Debian/Ubuntu # 或者 rpm -qa | head -50 # CentOS/RHEL

做完这些，你的/tmp/ir_work目录下就有了初步的素材，心里也踏实了不少。记住，应急响应中，冷静和条理比技术炫技更重要。

2.2 核心排查思路：由外而内，由近及远

面对一个被入侵的系统，从哪里入手？我的思路是“由外而内，由近及远”。

• 由外而内：先看网络、再看进程、最后看文件和日志。攻击者要进来，必然有网络连接；要维持访问，必然有进程在跑；要留下痕迹，必然动过文件或产生了日志。
• 由近及远：先看当前正在发生的（网络连接、活跃进程），再看近期发生的（最近修改的文件、今天的日志），最后看历史记录。

这个思路能帮你快速定位到最活跃的攻击痕迹。对于Web3靶机，我们已知目标是找IP和隐藏用户，那么网络连接和用户/认证日志就是首要目标。

注意：靶机环境可能清理过一些活跃攻击痕迹，所以“当前”的连接和进程可能看不到什么。这时候，“由近及远”中的“近期”日志和文件变更记录就成了突破口。

3. 关键痕迹分析与取证实操

按照上述思路，我们开始深入挖掘。以下是我在Web3靶机中实际采用的分析步骤和发现的线索。

3.1 攻击者IP地址溯源

攻击者的IP通常藏在日志文件里。Web服务器被入侵，首先应该检查Web访问日志和认证日志。

第一步：定位Web访问日志。常见的路径有/var/log/apache2/access.log、/var/log/apache2/access_log、/var/log/nginx/access.log等。用find命令快速定位。

find /var/log -name "*access*log" 2>/dev/null find /var/log -name "*error*log" 2>/dev/null

在Web3靶机中，我找到了Apache的日志。直接看全部日志太乱，我们需要过滤可疑请求。攻击行为往往伴随着扫描、漏洞利用尝试，其URL路径或User-Agent会显得很“扎眼”。

# 查看日志最后部分，也许有近期攻击记录 tail -100 /var/log/apache2/access.log # 搜索包含常见攻击关键词的条目，如sql, union, select, eval, system, passwd等 grep -i "union\|select\|eval\|system\|passwd\|etc/passwd\|\.\./" /var/log/apache2/access.log | head -20 # 统计访问最频繁的IP地址（前10个），攻击扫描可能来自少数IP awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -10

第二步：分析认证与授权日志。攻击者可能尝试了暴力破解或利用了认证漏洞。重点查看/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（CentOS/RHEL）。

# 查看认证日志中的失败登录尝试 grep "Failed password" /var/log/auth.log # 查看认证日志中的成功登录记录（特别是非正常时间的） grep "Accepted password" /var/log/auth.log grep "session opened" /var/log/auth.log | grep -v "systemd"

第三步：结合上下文找到关键IP。在Web3靶机中，通过仔细分析auth.log，我发现有大量针对特定用户（如www-data,admin，甚至是一些不常见的用户名）的SSH失败登录尝试，这些尝试集中来自一两个IP地址。这很可能就是攻击者的入口点之一。第一个IP通常就藏在这里。此外，在access.log中，寻找那些访问了明显不存在或敏感路径（如/admin.php,/wp-admin,/backup.zip）的请求，其源IP也值得高度怀疑，这可能是攻击者在进行目录扫描或探测，这可能会引出第二个IP。

实操心得：不要只看失败记录，成功的登录记录更关键。攻击者一旦成功，其登录IP、时间和使用的用户账号就是直接证据。同时，注意日志的时间戳是否被攻击者篡改过（/var/log目录下文件的时间属性是否异常），这本身也是一个入侵迹象。

3.2 隐藏用户发现与排查

攻击者为了维持持久化访问，常常会创建隐藏用户或给现有用户添加后门。Linux系统中，用户信息主要存储在/etc/passwd和/etc/shadow中，但隐藏用户可能有多种形式。

方法一：检查/etc/passwd文件中的异常。这是最基础的一步。使用cat或less查看，关注点在于：

1. UID为0的用户：除了root，还有没有其他用户UID是0？这是超级用户。
2. 异常的用户名：是否有看起来像随机字符串（如x7f8g9）或伪装成系统用户（如sync1,halt1）的用户？
3. 异常的登录shell：用户的shell字段（最后一列）通常是/bin/bash或/bin/sh。如果某个用户的shell是/bin/false或/sbin/nologin，理论上不能登录。但如果攻击者将其改为/bin/bash，就给了这个“服务账户”登录的能力。反过来，一个本该能登录的用户shell被改成了/nologin，也值得怀疑。

# 查看所有用户，重点关注UID和shell cat /etc/passwd # 查找UID为0的用户 awk -F: '$3==0 {print $1}' /etc/passwd # 查找可以登录的用户（shell为/bin/bash, /bin/sh等） awk -F: '$7 ~ /\/bin\/(bash|sh)/ {print $1}' /etc/passwd

方法二：检查/etc/shadow文件权限与内容。/etc/shadow保存了加密后的密码。首先检查其权限是否被篡改（正常应为640，root只读，shadow组可读）。

ls -l /etc/shadow

如果权限变成了644或777，那极有可能被攻击者修改过，以便添加密码或清空root密码。

方法三：查找authorized_keys文件。攻击者可能将自己的公钥添加到某个用户的~/.ssh/authorized_keys文件中，实现免密登录。需要全局搜索。

# 在根目录及用户目录下查找authorized_keys文件 find / -name "authorized_keys" -type f 2>/dev/null find /home -name "authorized_keys" -type f 2>/dev/null find /root -name "authorized_keys" -type f 2>/dev/null

找到后，仔细检查文件内容，看是否有不属于管理员或该用户本人的公钥。一个常见的隐藏技巧是将公钥添加到/etc/ssh/sshd_config中通过AuthorizedKeysFile指定的其他路径，或者像/var/www/.ssh/authorized_keys这种web用户目录下。

方法四：检查最近被修改的用户相关文件。使用find命令查找近期被修改的passwd、shadow、group文件或/home目录下的用户配置文件。

# 查找过去7天内被修改的passwd或shadow文件（可能备份或副本） find / -name "*passwd*" -o -name "*shadow*" -mtime -7 2>/dev/null # 查找/home目录下最近变动的文件 find /home -type f -mtime -3 2>/dev/null | head -20

在Web3靶机中，我通过对比/etc/passwd和/etc/shadow的条目数，发现了一个微妙的差异，或者通过检查/home目录下是否存在/etc/passwd中列出的但目录很隐蔽（如点号开头）的用户文件夹，最终定位到了那个“隐藏用户”。这个用户可能UID很高（如65534以上），或者其家目录设置在了/dev/null、/tmp等非常规位置。

3.3 Flag搜寻与深入取证

找到Flag是确认攻击者行为的关键。靶机中的Flag通常被放在攻击者访问或修改过的地方。根据之前找到的IP和用户线索，我们可以有针对性地搜索。

策略一：基于Web日志的路径搜索。从access.log中，提取攻击者访问过的独特URL路径。这些路径可能直接指向了上传的Webshell或留下的Flag文件。

# 假设从日志中发现攻击者IP 192.168.1.100访问了奇怪路径 grep '192.168.1.100' /var/log/apache2/access.log | awk '{print $7}' | sort -u # 输出可能是 /index.php, /admin/, /uploads/shell.php, /backdoor.txt # 那么就去检查 /var/www/html/uploads/shell.php 或 /var/www/html/backdoor.txt

策略二：查找近期创建或修改的可疑文件。攻击者上传的工具、留下的标语（Flag）文件，其修改时间（mtime）或访问时间（atime）会很近。

# 在Web根目录查找最近24小时内修改的文件 find /var/www/html -type f -mtime -1 2>/dev/null # 在/tmp目录查找可疑文件（攻击者常用） find /tmp -type f -name "*.php" -o -name "*.sh" -o -name "*.py" -o -name "*.txt" 2>/dev/null | head -20 # 查找全盘范围内，文件名中包含flag、root、secret、backdoor等关键词的文件 find / -type f -name "*flag*" -o -name "*root*" -o -name "*secret*" 2>/dev/null 2>/dev/null | grep -v "/proc/" | grep -v "/sys/"

策略三：检查计划任务（Cron）和系统服务。攻击者为了实现持久化，会添加计划任务或系统服务。Flag有时就藏在任务脚本的注释里，或者服务配置文件中。

# 检查系统级计划任务 ls -la /etc/cron* /etc/anacrontab cat /etc/crontab # 检查各用户的计划任务 ls -la /var/spool/cron/crontabs/ # 检查新增的系统服务 systemctl list-unit-files --type=service --state=enabled ls -la /etc/systemd/system/*.service /lib/systemd/system/*.service 2>/dev/null | grep -E '^(lrwx|-)' | head -30

策略四：检查历史命令与用户配置文件。如果攻击者使用了某个用户shell，其操作历史可能被记录在~/.bash_history中。检查root和可疑用户的历史记录。

# 检查root历史命令 cat /root/.bash_history 2>/dev/null | tail -50 # 检查其他用户，比如www-data（Apache用户常被利用） cat /home/www-data/.bash_history 2>/dev/null 2>/dev/null # 或者尝试所有/home下的用户 for user in $(ls /home); do echo "=== History for $user ==="; cat /home/$user/.bash_history 2>/dev/null | tail -10; done

在Web3靶机中，三个Flag可能分别对应了攻击者的三个不同动作：第一个Flag可能在Webshell文件里；第二个Flag可能在隐藏用户的家目录或SSH密钥文件中；第三个Flag可能藏在被篡改的系统文件（如/etc/passwd的注释字段）或一个隐蔽的计划任务脚本里。需要结合前面找到的IP和用户线索，耐心地逐一排查这些位置。

4. 工具链使用与命令技巧实录

工欲善其事，必先利其器。除了系统自带的命令，一些强大的工具能极大提升应急响应的效率。下面分享我在实战中高频使用的命令组合和一些小技巧。

4.1 日志分析“三板斧”：grep, awk, sed

日志分析是应急响应的基本功，grep,awk,sed这三剑客必须熟练。

• grep的进阶用法：

  # 显示匹配行及其前后各3行，方便看上下文 grep -B3 -A3 "Failed password" /var/log/auth.log # 忽略大小写，并统计匹配行数 grep -ci "error" /var/log/syslog # 使用正则表达式匹配IP地址 grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" /var/log/apache2/access.log | sort -u # 在多个文件中递归搜索 grep -r "eval(" /var/www/html/ 2>/dev/null

• awk的数据提取能力：

  # 从access.log中提取访问量最大的10个IP和其访问次数 awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -10 # 提取特定时间段的日志（比如攻击发生时间） awk '$4">="[30/Jun/2023:10:00:00" && $4"<="[30/Jun/2023:11:00:00"' /var/log/apache2/access.log # 以冒号分隔，打印/etc/passwd的第一列（用户名）和第三列（UID） awk -F: '{print $1, $3}' /etc/passwd | sort -k2 -n

• sed的流编辑（在快速清理数据或提取特定部分时有用）：

  # 只查看日志文件中的日期和IP（假设格式为 IP - - [日期] ...） sed -n 's/^\([0-9.]*\).*\[\(.*\)\].*/\1 \2/p' /var/log/apache2/access.log | head -5

4.2 文件与进程排查神器：find 与 lsof

• find命令的精准定位：

  # 找到7天内被修改过，且大于1MB的PHP文件 find /var/www/html -type f -name "*.php" -size +1M -mtime -7 2>/dev/null # 找到SUID权限的文件（攻击者可能利用） find / -type f -perm -4000 2>/dev/null | head -20 # 找到任何人都有写权限的目录（危险！） find / -type d -perm -o=w 2>/dev/null | grep -v "/proc/" | grep -v "/sys/" # 结合`-exec`对找到的文件进行操作，例如计算MD5 find /tmp -type f -name "*.sh" -exec md5sum {} \;

• lsof查看进程打开的文件：

  # 查看哪个进程在监听80端口 lsof -i :80 # 查看某个可疑进程（PID 1234）打开了哪些文件 lsof -p 1234 # 查看被删除但仍被进程占用的文件（常用于发现隐藏的后门） lsof | grep deleted

  最后一个命令非常有用。攻击者有时会运行一个后门程序，然后删除磁盘上的可执行文件，但进程还在内存中运行，这样文件就“消失”了，但lsof | grep deleted能把它揪出来。

4.3 网络与状态检查

• netstat/ss：查看网络连接和监听端口。ss通常更快更详细。

  # 查看所有TCP/UDP监听端口和已建立连接 ss -tulnp # 等价于 netstat -tulnp # 查看所有已建立的连接 ss -tunp state established

• last与lastb：查看成功登录和失败登录的历史记录。这是排查入侵时间线和攻击源的重要依据。

  # 查看所有用户登录历史 last # 查看失败登录尝试 lastb

4.4 实用小技巧与注意事项

1. 时间线分析：将所有关键事件（文件修改、日志条目、用户登录）按时间排序，能清晰还原攻击链条。可以用awk提取时间戳，或者简单地将相关命令输出按时间排序后重定向到文件。
2. 善用/proc文件系统：/proc/[PID]/目录下包含了进程的详细信息，如cmdline（启动命令）、exe（执行文件链接）、cwd（当前目录）、environ（环境变量）。当发现可疑进程时，这里是深入分析的宝库。
3. 不要相信一切：攻击者会篡改日志、替换系统命令（如ps,netstat,ls）。如果发现命令行为异常，尝试使用静态编译的工具（如busybox）或者从干净的系统拷贝一份命令过来使用。在靶机中，这通常不是问题，但真实环境中必须警惕。
4. 记录一切：把你执行的命令、看到的输出、得出的结论，及时记录到你的工作日志（/tmp/ir_work/下的文件）中。这能帮助你理清思路，也是最终撰写报告的基础。

5. 常见问题排查与避坑指南

在应急响应过程中，尤其是新手，很容易遇到一些困惑或走入误区。这里总结几个典型问题和我的解决思路。

5.1 问题一：日志里找不到攻击者IP

• 可能原因1：日志被清空或轮转（rotate）。检查日志文件大小，如果异常小（如只有几KB），可能被> logfile方式清空。查看是否有归档日志（如access.log.1,access.log.2.gz）。使用logrotate的配置通常在/etc/logrotate.d/下。
• 可能原因2：攻击来自内网或通过代理。IP可能是内网地址（如10.x.x.x,192.168.x.x）。这并不影响它作为“攻击源”的判定，在报告中仍需记录。
• 可能原因3：攻击者使用了Web应用漏洞，而未在访问日志中留下明显恶意特征。尝试查看错误日志（error.log），里面可能有PHP警告、数据库错误等，结合时间戳也能定位异常。
• 排查技巧：扩大时间范围搜索。不要只盯着最近几小时。使用awk或grep结合日期过滤，查看攻击可能发生时间段的所有日志。也可以尝试搜索一些通用攻击载荷，如../,eval(,system(等。

5.2 问题二：找不到隐藏用户或后门

• 可能原因1：用户隐藏在/etc/passwd的末尾或中间，但用户名看起来正常。仔细检查每个用户的UID、GID和shell。特别关注UID为0，或者UID/GID与附近用户不连续的用户。
• 可能原因2：后门以计划任务（cron）形式存在，但不在常规目录。检查/etc/cron.hourly/,/etc/cron.daily/等目录下的脚本。同时，用crontab -l -u [username]检查特定用户的cron任务。
• 可能原因3：后门是一个内核模块或感染了系统命令。使用lsmod查看已加载内核模块。使用rpm -Va或debsums（如果系统安装了这个工具）校验重要系统命令的完整性，看MD5是否匹配。
• 排查技巧：使用find命令全局搜索包含“反弹shell”典型字符串的文件，如bash -i,nc -e,python -c,perl -e等。同时，检查网络连接中是否有到外部可疑IP和端口的出向连接。

5.3 问题三：Flag位置极其隐蔽

• 可能原因1：Flag不在文件内容里，而在文件属性中。比如使用lsattr命令查看文件的扩展属性，Flag可能藏在文件的注释（使用getfattr）或者通过setcap设置的 capabilities 属性描述中。
• 可能原因2：Flag被编码或加密。找到的文件内容可能是一串Base64、Hex编码，或者看起来是乱码。准备好常用的解码命令，如base64 -d,xxd -r -p,echo “<hex>” | xxd -r -p。
• 可能原因3：Flag需要特定条件触发。比如一个计划任务脚本，只在特定时间或满足某个条件时才输出Flag。仔细阅读脚本逻辑。
• 排查技巧：养成用file命令查看文件类型的习惯。一个看起来是文本的文件，file命令可能告诉你它其实是个ELF可执行文件或者数据文件。对于可疑文件，用strings命令提取所有可打印字符串，Flag可能就在里面。

5.4 避坑指南：新手常犯的错误

1. 盲目操作，破坏现场：在未备份关键日志和文件前，就进行“修复”操作，如删除可疑文件、停止可疑进程。这可能会销毁证据。先取证，后处置。
2. 只盯着一个点：找到一个IP或一个后门就以为结束了。攻击往往是多步骤的（杀链），需要串联所有发现，绘制完整的攻击路径图。
3. 忽略时间线：不记录操作时间，不统一分析日志时间（注意时区！）。时间线是还原事件顺序的关键。
4. 不写报告或记录混乱：调查过程中不记录命令和输出，最后凭记忆写报告，导致遗漏或错误。从打开script记录的那一刻起，你的每一步都应该是有目的的、可追溯的。

应急响应就像破案，讲究的是细心、耐心和逻辑性。Web3这个靶机很好地模拟了这种场景。通过这样一次完整的训练，你收获的不仅仅是几个命令的使用技巧，更是一套应对安全事件的思维方法和操作流程。真正的挑战往往不在于工具多强大，而在于你是否能在一片混乱的“现场”中，保持清晰的头脑，有条不紊地找到那条通往真相的线索。