在云原生高速发展的今天，针对云环境的攻击方法也层出不穷。本文讲述了vesta对云原生后门检测的理念和实践。
Daemonset因为其特点能够在所有node节点上部署一个pod，因此成为了最受欢迎的后门入口。对Pod设置后门也有如下的几种方法:
因此，改持久化方法对pod的command和arg的内容进行输入检查即可。
从其他资源引入反弹代码到Pod中运行
此类型持久化中比较典型的外部资源一个是Secret，Secret拥有其天然特性Base64编码使得运维人员不能在第一时间看出端倪，但是又能够在Pod内部被ValueFrom调用的时候进行自动解码。亦或者从自制的恶意镜像上拉取进行持久化。
Sidecar
考虑到上述几个方案都有痕迹的产生，因此可以考虑k8s自带的kube-proxy，自带的privileged也是满足大多数的渗透要求。可以参考k0otkit脚本以及相关的文章，链接如下
在后门检测中，首先需要对各种权限和安全配置进行检测，因为持久化是后门的本质，攻击者需要长期控制宿主机。因此，需要检测特权权限、必要的capabilities以及相关的挂载。其次，需要检测与 Pod 相关的附加命令，因为现在有许多反向代理的命令和各种绕过的 shell，每次都精确检测都是不现实的。因此，采用对特殊符号和关键字的检查，并将其与字符串总数相除得到一个比率值，然后与相应的阈值进行比较，最后生成报告。
后门相关检测有：
Secret以及ConfigMap的内容以及解码，判断反代命令的同时也要判断是否是可执行文件
DaemonSet相关镜像的识别
Pod的权限以及相关配置检测，例如Privileged, volumeMounts, command, args, RBAC等
在完成上述检查的开发之后，又发现了另外一个问题。要对DaemonSet进行扫描必然扫描Kubernetes内部关键的namespaces，而这些namespaces又有相当一部分的DaemonSet以及DaemonSet启动的Pod会有特别高的权限，如果加上后期各种监控框架，那么检测出来的结果就会特别繁杂，导致运维人员每次会处理大量无关的安全事件，这是非常消耗时间的。
以一个简单的OpenShift架构以及11个node节点为例子，下列扫描出来的结果都是冗余的
并且正常的kube-system命名空间中的kube-proxy也会因为priveleged权限出现在运维人员眼中，出现次数一旦多就会导致对该pod关注度慢慢减少，以至于真正出现后门程序的时候会忽略该实例，导致错过最佳处置时间。
因此vesta对检测的Pod进行了剪枝。我们发现了如下几个参数
age
restarts
certification
age分为node的age以及pod的age，而restarts则是容器重启的次数以及最近一次重启的时间，如图
通过age我们能够直接观察到最近一次修改的时间，通过讲DaemonSet对应的pod中最近修改时间与其他pod的时间进行对比。同时restarts的数值也能够帮助我们一个Pod的正常情况，例如如果一个restarts的次数相对于其他Pod的来说异常地高，可能的行为是反弹的shell所连接的IP并没有连通，导致Pod一直重启尝试连接目标IP，而相对于其他的Pod的平均次数过低的重启次数又能够判断该容器在最近被replace替换过。如下图就是一个非常典型的被加入后门的场景
而node的age则能够帮助我们获取该node被启动的最早时间，kubernetes安装的证书也同样能够帮助我们拿到K8s最早启动的时间。因此通过目标pod修改时间与node启动最早时间以及其他Pod的修改时间做综合的对比来判断是否跳过该Pod的扫描。
实现的代码如下
至此为vesta对DaemonSet的扫描逻辑以及实现，项目地址为
