日志取证实例解析怎么判断是否登上跳板机并追回访问来源

1. 概述：为什么要判定跳板机被利用

- 跳板机（bastion/jump host）常用于管理内网主机，若被利用会成为横向攻击跳板。
- 日志取证目标是还原攻击链、确认是否有未经授权的登录并找到上游来源。
- 取证同时要考虑 CDN、域名解析和 DDoS 防御日志来排除流量噪声。
- 成功判定有助于采取隔离、阻断来源并向 ISP/法律机构申报。
- 本文以真实案例与服务器配置举例，展示分析流程与数据演示。

2. 取证准备：采集哪些日志与系统信息

- 必须先保全证据：快照磁盘、导出 /var/log/auth.log、/var/log/syslog、/var/log/nginx/access.log。
- 收集跳板机的 /var/log/secure（CentOS）或 auth.log（Ubuntu）、wtmp/utmp、lastlog。
- 开启并导出 auditd 日志（ausearch、aureport），记录 execve、connect、bind 等系统调用。
- 若使用 CDN（如 Cloudflare），请求其 Edge 日志（CF-Connecting-IP、Ray ID）并同步时间。
- 导出防火墙（iptables/nftables）、fail2ban 与 DDoS 防护设备的流量告警。

3. 日志分析方法与示例数据

- 先用时间线法：按时间排序所有登录、连接与进程记录，寻找时间重叠与异常。
- 关注 SSH 登录的 session id、PTY 分配与 agent-forwarding 行为（"Accepted publickey" 与 "agent forwarded"）。
- 对照 Nginx access.log 中 X-Forwarded-For 或 CF-Connecting-IP 字段，识别真实客户端 IP。
- 利用 geoip、whois 与 asn 查询对疑似源 IP 做上下文判断。
- 下表为示例合并日志片段，便于直观比对（时间采用 UTC）：

时间(UTC)	来源IP	跳板机	目标主机	用户/动作
2025-03-10 08:12:03	203.0.113.45	bastion.example.com	db01.internal	root/SSH Accepted publickey
2025-03-10 08:12:10	10.0.5.12	bastion.example.com	db01.internal	service mysql start (auditd)
2025-03-10 08:12:15	203.0.113.45	bastion.example.com	web01.internal	sudo su - (PTY)
2025-03-10 08:12:40	198.51.100.23	cdn.edge	web01	HTTP POST (CF-Connecting-IP: 203.0.113.45)

4. 案例实战：一次跳板机被利用的恢复过程

- 背景：运行环境为 Ubuntu 20.04，OpenSSH 8.2p1，Nginx 1.18，使用 Cloudflare CDN，跳板机IP为 198.51.100.10。
- 发现指标：auth.log 出现 203.0.113.45 的 Accepted publickey 与随后多次 sudo 记录，auditd 记录 execve 对 mysql 的 restart。
- 服务器配置示例：SSH config: PermitRootLogin no, AllowUsers admin ops, AllowAgentForwarding yes（此处为危险配置）。
- 取证动作：对 bastion 做磁盘快照、导出 /var/log/auth.log、使用 ausearch -ts 2025-03-10T08:12:00 -te 2025-03-10T08:13:00 查看相关事件。
- 结论：攻击者通过外部 IP 203.0.113.45 利用某用户公钥成功登录跳板机，随后横向访问内网主机并操控服务。

5. 如何判定是否“确实登上”跳板机：关键证据项

- 登录认证证据：auth.log 中的 Accepted publickey/Accepted password、SSH session start/stop 时间。
- 交互证据：wtmp/utmp（last/lastlog）、TTY/PTY 分配信息、bash_history（注意可能被清理）。
- 系统调用证据：auditd 的 execve、connect、open 等记录可证明执行过特权命令。
- 网络侧证据：跳板机的 tcpdump/pfsense 流量抓包显示来自可疑外部 IP 的 SSH 层三流量。
- 辅助证据：sudo 日志、/var/log/auth.log 中的 agent-forwarding 提示、失败/成功的 2FA 记录。

6. 追溯访问来源：从跳板机回溯到真实客户端

- 若直接 SSH：可从 auth.log 中的来源 IP 做 whois/geoip/AS 查询，联系 ISP 申请流量日志（需法律流程）。
- 若通过 CDN 或反向代理：查看 Edge 日志（CF-Connecting-IP 或 X-Forwarded-For）来获取真实客户端 IP。
- 若使用 NAT/代理/Tor：溯源有较大限制，需要结合多点日志（上游 CDN、边界防火墙、上游 ISP）。
- 结合时间窗口与会话特征（User-Agent、TLS 指纹、端口）做多维关联以增加置信度。
- 法律与合作：组织需与托管商、CDN 提供商和 ISP 合作，并保留链路证据以备司法程序。

7. 防御与恢复建议（跳板机与整体防护）

- 立刻隔离：下线受影响跳板机，变更所有受影响密钥，更新堡垒与内网访问凭据。
- 加固配置：关闭 AllowAgentForwarding、禁用 root 登录、启用 MFA、只允许指定管理网络访问。
- 日志与审计：启用 auditd、集中化日志收集（ELK/Graylog）、设置不可篡改的日志归档。
- DDoS 与 CDN 策略：使用 CDN 的速率限制、WAF 规则、和 DDoS 黑洞/速率限制策略保护边界。
- 恢复与总结：恢复前做完整取证、修补补丁和安全策略调整，并基于事件更新应急响应流程。

来源：日志取证实例解析怎么判断是否登上跳板机并追回访问来源