2023云原生安全威胁分析报告.docx

《2023云原生安全威胁分析报告.docx》由会员分享，可在线阅读，更多相关《2023云原生安全威胁分析报告.docx（49页珍藏版）》请在三一办公上搜索。

1、2023云原生安全威胁分析报告目录一、前言4二、云原生安全威胁分析4（一）容器化基础设施的威胁风险4（二）容器编排平台的风险分析7（三）云原生应用的威胁风险8（四）无服务的威胁风险9（五）服务网格的威胁风险10三、云原生安全近年威胁10（一）近年云原生安全事件风险10（二）近年云原生安全漏洞风险16四、云原生威胁检测技术13（一）容器镜像安全检测技术13（二）容器运行时安全检测技术15（三）容器网络安全检测技术16（四）云原生可观测性17（五）宿主机威胁检测技术19（六）容器ATT&CK矩阵22五、云原生漏洞风险检测模型23（一）CClCA云原生安全模型介绍23（二）CCICA云原生安全模型漏

2、洞检测方法概述25六、云原生入侵风险检测模型27（一）AKDA模型28（二）模拟红队攻击29（三）攻防知识图谱31（四）数据源32（五）威胁检测算法32（六）AKDA模型与ATT&CK之间的关系32七、女原生威胁检:则实战场景33（一）镜像安全34（二）应用安全36“t爸号.38（四）主机安全42八、云原生安全实践与技术展望45（一）云原生安全实践45（二）云原生未来展望46参考资料50一、月IJm随着云计算技术的蓬勃发展，传统上云实践中的应用升级缓慢、架构臃肿、无法快速迭代等“痛点”日益明显。能够有效解决这些“痛点”的云原生技术正蓬勃发展，成为赋能业务创新的重要推动力，并已经应用到企业核心业

3、务。然而，云原生技术在创造效益的同时，却也面临着严峻的安全问题。本报告基于安全狗“云原生安全团队”近儿年的研究成果，以及近年来对云原生安全领域的观察编制而成.我们期望通过我们对以“云原生威胁检测”为主要视角的总结分析，能够为各个行业/企业/单位对云原生安全技术开展后续的云原生安全建设提供进一步的参考建议。本报告的主要内容如下：第一部分，从容器化基础设施、容器编排平台、云原生应用以及无服务等方面分析云原生安全威胁；第二部分，从云原生安全事件风险、云原生安全漏洞风险等方面介绍近年来一些重要的云原生安全威胁；第三部分，从容器镜像、容器运行时、容器网络、云原生可观测性、宿主机威胁检测以及容器ATT&C

4、K矩阵等角度介绍云原生威胁检测技术：第四部分，介绍基于我司实践经验提出的五层云原生漏洞风险检测模型“CCICA”；第五部分，介绍基于实践经验提出的一种基于ATT&CK容器矩阵的可应用于提取检测规则，提升产品检测能力的模型方法论“AKDA”；第六部分，介绍基于CCICAAKDA的理论基础的云原生威胁检测实战场景、案例；第七部分，从云原生未来发展趋势、云原生安全未来发展趋势以及云原生攻防对抗未来发展趋势三个角度进行云原生安全实践与技术展望。二、云原生安全威胁分析云原生技术逐渐成为云计算市场发展的新趋势之一。随着越来越多的云原生应用落地和使用，其相关的安全风险与威胁也不断涌现。云原生安全事件频频发生

5、也直接影响了整个云原生系统的安全性。以下章节将围绕云原生环境中存在的威胁展开分析。（一）容器化基础设施的威胁风险在实现云原生的主要技术中，容器作为支撑应用运行的重要载体为应用的运行提供了隔离和封装，因此成为云原生应用的基础设施底座。云原生架构的安全风险包含容器化基础设施自身的安全风险，容器化部署则成为云原生计算环境风险的输入源。1.容器全生命周期的威胁风险容器的秒级启动或消失的特性以及持续频繁的动态变化，极大程度地缩短了生命周期，但也增加了安全保护的难度和挑战。容器的安全问题，在容器全生命周期(创建、分发、运行、停止)的各个阶段都存在相应的风险和威胁隐患，如图2-1所示。镜像仓库运行环境(Ru

6、n)持续集成/部署 (Build)镜像安全容器安全 网络安全配置安全图27容器全生命周期的威胁风险(1)容器镜像构建阶段存在的风险随着容器技术的普及，容器镜像也成为了软件供应链中重要的一环。因此，当业务依赖的基础镜像存在安全漏洞或者包含恶意代码时，其潜在危害比黑客从外部发起攻击要严重得多。镜像CVE漏洞利用“镜像漏洞利用”指的是镜像本身存在漏洞时，依据镜像创建并运行的容器通常也会存在相同漏洞，镜像中存在的漏洞会被攻击者用以攻击容器的情况。这种行为往往会对容器造成严重影响。密受开发者青睐的Alpine镜像曾曝出过一个漏洞，编号为CVE-2019-5021。在3.3到3.9版本的AIPine镜像中

7、，root用户密码被设置为空，攻击者在攻入容器后获得容器内部root权限的机会增大。镜像投毒镜像投毒是一个宽泛的话题。指的是攻击者通过某些方式，如上传镜像到公开仓库、入侵系统后上传镜像到受害者本地仓库以及修改镜像名称假冒正常镜像等，欺骗、诱导受害者使用攻击者指定的恶意镜像创建并运行容器，从而实现入侵或利用受害者的主机进行恶意活动的行为。根据目的不同，常见的镜像投毒有三种类型：投放恶意挖矿镜像、投放恶意后门镜像和投放恶意exploit镜像。投递恶意挖矿镜像。这种投毒行为主要是通过欺骗受害者在机器上部署容器的方式获得经济收益。2018年6月，一份研究报告指出，一个名为docker123321的账号

8、向DockerHub上陆续上传了17个包含挖矿代码的恶意镜像。截至DockerHub官方移除这些镜像时，它们已经累计被下载超过500万次。据统计，黑客借助这一行为获得了市值约9万美元的门罗币。投放恶意后门镜像。这种投毒行为的主要目的是控制容器。通常，受害者在机器上部署容器后，攻击者会收到容器反弹过来的Shello在2017年9月，有用户在DockerHub的反馈页面中反馈前述dockerl23321账号上传的Tomcat镜像包含了后门程序。结合该账号上传的其他恶意镜像的挖矿行为可推测出攻击者在连接上述后门后会部署挖矿程序以此获得经济收益的可能性。投放恶意exploit镜像。这种投毒行为是为了在

9、受害者部署容器后尝试寻找宿主机上的各种漏洞来实现容器逃逸，以实现对受害者机器更强控制。从攻防对抗的角度来看，恶意exploit镜像只不过是一种攻击载荷投递方式，其特点在于具有隐蔽性和可能产生巨大的影响范围。试想，如果DockerHub上某一热门镜像包含了某个Iday甚至Oday漏洞的利用程序，理论上，攻击者将一下子获取上百万台计算机的控制权限。(2)容器镜像分发阶段存在的风险镜像的安全需要重点建设。镜像的安全性会直接影响容器安全，因为容器镜像在存储和使用的过程中，可能会被植入恶意程序或修改内容以此篡改。一旦使用被恶意篡改的镜像创建容器后，将会影响容器和应用程序的安全。(3)容器运行时存在的风险

10、在容器运行时存在的安全问题中，“容器逃逸”是最具代表性的高风险安全问题。攻击者可通过利用漏洞“逃逸”出自身拥有的权限，实现对宿主机或者宿主机上其他容器的访问，同时带来进行时资源耗尽的风险。容器逃逸与其他虚拟化技术类似，逃逸是最为严重的安全风险。无论是Docker容器、还是Kata类安全容器，都暴露过各类逃逸漏洞。逃逸风险对于容器化的云原生场景是一个不可避免的风险面，因为其直接危害了底层宿主机和整个云计算系统的安全。根据层次的不同，可以进一步展开为：危险配置导致的容器逃逸、危险挂载导致的容器逃逸、相关程序漏洞导致的容器逃逸、内核漏洞导致的容器逃逸、安全容器逃逸风险。危险配置导致的容器逃逸。用户可

11、以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性，主要包括未授权访问带来的容器逃逸风险，特权模式运行带来的容器逃逸风险。危险挂载导致的容器逃逸。将宿主机上的敏感文件或目录挂载到容器内部，尤其是那些不完全受控的容器内部，往往会带来安全问题。在某些特定场景下，为了实现特定功能或方便操作，人们会选择将外部敏感卷挂载入容器。随着应用的逐渐深化，挂载操作变得愈加广泛，由此而来的安全问题也呈现上升趋势。例如：挂载DockerSocket引入的容器逃逸风险、挂载宿主机proofs引入的容器逃逸风险等。相关程

12、序漏洞导致的容器逃逸。所谓相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的漏洞。CVE-2019-5736正是这样一个存在于runC的容器逃逸漏洞，它由波兰CTF战队DragonSector在35C3CTF赛后基于赛中一道沙盒逃逸题目获得的启发，对runC进行漏洞挖掘，成功发现能够覆盖宿主机runC程序的容器逃逸漏洞。内核漏洞导致的容器逃逸。Linux内核漏洞的危害之大、影响范围之广，使得它在各种攻防话题下都占有一席之地。近年来，Linux系统曝出过无数内核漏洞，其中能够用来提权的也不少，脏牛(CVE-2016-5195)大概是其中最有名气的漏洞之一。事实上，脏牛漏洞也能

13、用来进行容器逃逸，一种利用方法的核心思路是向vDSO内写入shellcode并劫持正常函数的调用过程。在成功触发湍防，攻击者可以获得宿主机上反弹过来的Shel1,实现容器逃逸。安全容器逃逸风险。无论是理论上，还是实践中，安全容器都具有非常高的安全性。然而，在2020年BlaCkHat北美会议上，YUVaIAVrahami分享了利用多个漏洞成功从KataCOntainerS逃逸的议题，安全容器首次被发现存在逃逸可能性，他使用发现的三个漏洞（CVE-2020-2023、CVE-2020-2025和CVE-2020-2026）组成漏洞利用链先后进行容器逃逸和虚拟机逃逸，成功从容满内部逃逸到宿主机上。

14、资源耗尽容器在运行时默认情况下并未对容器内进程在资源使用上做任何限制，以Pod为基本单位的容器编排管理系统也是类似的。Kubernetes在默认情况下同样未对用户创建的Pod做任何CPU、内存用限制。限制的缺失使得云原生环境面临资源耗尽型攻击风险。（4）容器网络存在的风险在网络安全方面，由于K8S默认不做网络隔离，传统物理网络的攻击手段依然有效（如ARP欺骗、DNS劫持、广播风暴等）。同时，攻击者可利用失陷的容器进行针对K8s集群内部、内网主机的横向渗透；容器网络环境也面临着“访问关系梳理难，控制难”的痛点。比如：东西向访问流量庞大，无法感知业务间访问关系；业务访问关系错综复杂，无法制定精细化

15、的访问控制策略；静态策略无法跟随虚拟机自动迁移；容器平台体量巨大，上下线周期短，容器IP地址变化频繁，难以适配容器环境等等。2 .宿主机的威胁风险容器与宿主机共享操作系统内核，因此宿主机的配置对容器运行的安全有着重要的影响，比如宿主机中安装有漏洞的软件可能会导致任意代码执行风险，端口无限制开放可能会导致任意用户访问风险，防火墙未正确配置会降低主机的安全性，没有按照密钥的认证方式登录可能会导致暴力破解并登录宿主机等。安全是一个整体，任何一个环节出问题，都会影响到其他环节。应用安全可影响到容器安全，容器逃逸可影响到虚拟主机及容器集群的安全，虚拟主机逃逸会影响到虚拟化基础设施的安全。3 .容器化开发

16、测试过程的威胁风险DevOps所倡导的理念是追求敏捷、协作与快速迭代。开发人员往往为了追求便捷的开发环境与快速的迭代节奏选择将安全系统配置（如权限管理、访问控制等）的优先级降低，为效率与敏捷让步，最终可能使敏感数据权限管理不当而在容易发生泄露、系统资源无防护的内部开放。若研发环境采用传统安全防护措施，一旦边界防御措施被突破，内部数据与资源将会对外部攻击者完全开放，产生不可估量的损失与影响。（二）容器编排平台的风险分析在云原生环境中，编排系统无疑处于重中之重的地位。任何编排系统都会受到一些攻击，这些攻击会影响部署的整体安全性和运行时的持续安全性。而Kubernetes早已成为容器编排系统的“事实

17、标准”，下面对容器编排平台的风险进行分析。1. Kubernetes组件不安全配置Kubernetes编排工具组件众多、各组件配置复杂，配置复杂度的提升增加了不安全配置的概率。不安全配置引起的风险不容小觑，比如KubernetesAPIServer的未授权访问,KubernetesDashboard的未授权访问，Kubelet的未授权访问等，都可能会导致编排工具中帐户管理薄弱，或部分帐户在编排工具中享有很高特权，入侵这些账户可能会导致整个系统遭到入侵。2. Kubernetes提权Kubernetes非法提权，是指普通用户获得管理员权限或Web用户直接提权成管理员用户。编排工具可能存在多种漏洞

18、导致此类攻击,Kubernetes权限提升。以CVE-2018-1002105漏洞为例,这是一个Kubernetes的权限提升漏洞,允许攻击者在拥有集群内低权限的情况下提升至KubernetesAPIServer权限；通过构造一个对KubernetesAPIServer的特殊请求，攻击者能够借助其作为代理，建立一个到后端服务器的连接，攻击者就能以KubernetesAPIServer的身份向后端服务器发送任意请求，实现权限提升。3. Kubernetes拒绝服务传统虚拟化技术设定明确的CPU、内存和磁盘资源使用阈值，而容器在默认状态下并未对容器内进程的资源使用阈值做限制，以Pod为单位的容器编

19、排管理工具也是如此。资源使用限制的缺失使得云原生环境面临资源耗尽的攻击风险，攻击者可以通过在容器内运行恶意程序，或对容器服务发起拒绝服务攻击占用大量宿主机资源，从而影响宿主机和宿主机上其他容器的正常运行。4. Kubernetes中间人攻击默认情况下，Kubernetes集群中所有pod组成了一个小型的局域网络，那么就可能发生像中间人攻击这样针对局域网的攻击行为。假如攻击者借助Web渗透等方式攻破了某个Pod,就有可能针对集群内的其他Pod发起中间人攻击，进而进行DNS劫持等。攻击者能够潜伏在集群中，不断对其他Pod的网络流量进行窃听，甚至可以悄无声息地劫持、篡改集群其他Pod的网络通信，危害

20、极大。（三）云原生应用的威胁风险云原生化应用主要包括微服务、Serverless；同时云原生基础设施和云原生应用也会在原有云计算场景下显著扩大API的应用规模，新的安全风险也不容忽视。1 .微服务的威胁风险首先，随着微服务的增多，暴露的端口数量也急剧增加，进而扩大了攻击面，且微服务间的网络流量多为东西向流量，网络安全防护维度发生了改变；其次，不同于单体应用只需解决用户或外部服务与应用的认证授权，微服务间的相互认证授权机制更为复杂，人为因素导致认证授权配置错误成为了一大未知风险。并且微服务通信依赖于APb随着业务规模的增大，微服务APl数量激增，恶意的APl操作可能会引发数据泄漏、越权访问、中间

21、人攻击、注入攻击、拒绝服务等风险；最后，微服务治理框架采用了大量开源组件，会引入框架自身的漏洞以及开源治理的风险。微服务入口点增加导致攻击面增大。单体应用的场景下，入口点只有一个，所有的请求都会从这个入口点进来。在这个入口点建立一组Filter或者Interceptor,就可以控制所有的风险。微服务场景下，业务逻辑并不在一个单一的进程里，而是分散在很多进程里。每一个进程都有自己的入口点，导致需要防范的攻击面比原来更大，风险也会更高。微服务调度复杂增加访问控制难度带来越权风险。在单体应用架构下，应用作为一个整体对用户进行授权；而在微服务场景下，所有服务均需对各自的访问进行授权，明确当前用户的访问

22、控制权限。传统的单体应用访问来源相对单一，基本为浏览器，而微服务的访问来源还包括内部的其它微服务。因此，微服务授权除了服务对用户的授权，还增加了服务对服务的授权。默认情况下，容器网络间以白名单模式出现，如果不对Pod间访问进行显式授权，一旦某一Pod失陷，将极速扩展至整个集群的Podo微服务治理框架漏洞引入应用风险。常用的微服务治理框架，例如SpringCloud.Dubbo等都是基于社区的模式运作，虽然内置了许多安全机制，但默认值通常并不安全，常常引入不可预料的漏洞，例如用户鉴权混乱、请求来源校验不到位等。这些漏洞将会导致微服务业务层面的攻击变得更加容易，为微服务的开发和使用者带来安全隐患。

23、比如SpringCloudconfig存在CVE-2019-3799、CVE-2020-5405漏洞，有的社区对这些漏洞进行了及时修复，需要软件及时更新到新版本；但也有的漏洞长期缺乏修复，需要微服务开发厂商自行修复，这类漏洞通常修复比较复杂、修复成本较高。2 .API的威胁风险云原生带来API爆发式增长增加滥用风险。云原生化之后，从基础架构层、到上面的微服务业务层都会有很多标准或非标准的APL因为APl既充当外部与应用的访问入口，也充当应用内部服务间的访问入口，所以数量急剧增加、调用异常频繁。爆发式的增长导致API在身份认证、访问控制、通信加密、以及攻击防御等方面的问题更加明显，面临更多潜在的

24、风险。与此同时，企业面对大量的API设计需求，其相应的APl安全方案往往不够成熟，从而引起滥用的风险，API的主要安全风险如表2-1所示。风险类型风险引入途径未授权访问API管理不当API设计存在缺陷数据泄露安全措施不足DDoS风险资源和速率没有限制表2TAPI主要安全风险（四）无服务的威胁风险Serverless（无服务器运算）又被称为函数即服务（FUnCtiOn-as-a-Service,缩写为FaaS）,是云计算的一种模型。以平台即服务（PaaS）为基础，无服务器运算提供一个微型的架构，终端客户不需要部署、配置或管理服务器服务，9代码运行所需要的服务器服务皆由云端平台来提供，Sorver

25、less使得底层运维工作量进一步降低，业务上线后，也无需担忧服务器运维，而是全部交给了云平台或云厂商。对应Serverless的安全风险，一方面包含应用本身固有的安全风险，另一方面包含Serverless模型以及平台的安全风险。应用程序固有的安全风险，总体上类似传统应用程序的安全风险内容，包括：应用程序漏洞带来的安全风险、第三方依赖库漏洞引入的安全风险、权限控制缺陷带来的安全风险等。erverless模型以及平台的安全风险，主要包括以下几类：(1)函数多源输入导致供应链安全风险资源权限管控不当带来函数使用风险(2)设计使用不规范引入数据泄露风险(3)FaaS平台自身漏洞带来入侵风险(4)平台设

26、计机制缺陷引入账户拒绝服务风险(5)缺乏Serverless专有安全解决方案导致风险应对能力不足(五)服务网格的威胁风险服务网格作为一种云原生应用的体系结构模式，应对了微服务架构在网络和管理上的挑战，也推动了技术堆栈分层架构的发展。从分布式负载均衡、防火墙的服务的可见性，服务网格通过在各个架构层提供通信层来避免服务碎片化，以安全隔离的方式解决了跨集群的工作负载问题，并超越了Kubernetes容器集群，拓展到运行在裸机上的服务。服务网格与微服务在云原生技术栈中是相辅相成的两部分，前者更关注应用的交付和运行时，后者更关注应用的设计与开发。若未在服务网格中采用双向TLS认证，服务间容易受到中间人攻

27、击。若未做东西向、南北向的认证鉴权，服务间容易受到越权攻击。三、云原生安全近年威胁(一)近年云原生安全事件风险1 .近年来云原生安全问题分布根据StackRox在2021年发布的容器和Kubernetes安全态势报告显示，针对云原生应用的威胁数量呈现上升趋势。在过去的12个月里，有94%的组织在其容器环境中遇到过安全问题，其中69%的组织检测到错误配置，27%的组织在运行时遇到安全事件，还有24%的组织发现了严重的安全漏洞，如图3-1所示。图3T2021年云原生安全问题分布在看到惊人的数字之余，进一步考虑到安全事件带来的影响，以及可能会给组织带来灾难性的后果。在云原生环境，一旦没有实施全面有效

28、的安全防护，黑客可利用漏洞攻击容器上的服务，或可进一步利用容器漏洞，直接访问容器云上的敏感信息，获取服务器特权，对容器云进行修改并最终完全控制服务器，造成恶劣影响和重大损失。所以必须综合考虑云原生环境下的Docker.Kubernetes等组件的整体安全性，分析研究它们的漏洞特征，进而才能构建一条完整防线。2 .典型的云原生安全事件(1)攻击团伙TeamTNT入侵KUBERNETES集群植入挖矿木马TeamTNT是一个主要入侵在线容器并通过挖矿和DDoS进行牟利的攻击团伙。2021年年初，该团伙被发现入侵了某Kubernetes集群，通过结合脚本和现有工具，最终在容器内植入挖矿木马。研究人员已

29、经发现并确认将近50000个IP在TeamTNT对多个集群实施攻击中被攻击到。在3月至5月发生的事件期间，TeamTNT反复使用了多个IP。大多数被攻击的节点来自中国和美国。(2)第一个已知的针对WIndows容器的恶意软件2021年3月，研究人员发现了第一个已知的针对Windows容器的恶意软件，恶意软件命名为Siloscape0其主要目标是逃离容器。通过Windows容器针对KUbemeteS集群的严重混淆恶意软件。其主要目的是为配置不当的Kubernetes集群打开一个后门，以运行恶意容器。该恶意软件可以利用Kubernetes集群中的计算资源进行加密劫持，并可能从受感染集群中运行的数百

30、个应用程序中窃取敏感数据。(3)下载2000万次的DockerHub镜像来自加密矿工研究人员发现有基于云的加密货币挖矿攻击活动，其中矿工通过DockerHub中的镜像进行部署。研究人员分析发现DockerHub中存在用于加密货币挖矿攻击活动的恶意镜像文件，并发现了来自10个不同DOCkerHUb账户的30个镜像以牛。多个容器映像文件幽徽件蝴了至少两年之久，且已被下载了趟12000万次。其中主要进行门罗币挖矿，保守估计加密货币挖矿活动获利20万美元。(4)安全公司Rapid7遭到COdeCOV供应链攻击，源码泄露网络安全公司RaPid7透露，2021年4月1日，程序审计平台Codecov遭黑客攻

31、击，该事件可能影响其2.9万名客户，并且引发大量公司连锁数据泄露，造成又一起“供应链”重大安全危机。Codecov表示从1月31日开始，黑客就已经对Codecov发起了攻击，利用Codecov的DOCker镜像创建过程中出现的错误，非法获得了其BashUploacler脚本的访问权限并且进行了修改。这意味着攻击者艮有可能导出存储在CodeCOv用户的持续集成(CI)环境中的信息，最后将信息发送到Codecov基础架构之外的第三方服务器。(二)近年云原生安全漏洞风险1 .近年云原生安全漏洞统计截至2021年12月末，我们通过对CVND漏洞数据统计分析了云原生基础设施的漏洞分布情况。首先，其中Do

32、cker相关的漏洞共174个，2021年38个。与过去几年相比，在漏洞数量上并没有明显减少的趋势，一旦黑客突破Docher,如容器逃逸，将会对主机造成巨大威胁；其次，Kubernetes的安全是整个项目安全生产运行的重要保障。但是与Kubernetes相关的漏洞数量达到106个。2021年则有10个，主要漏洞类型包括：拒绝服务、非法提权、容器逃逸等。云原生基础设施相关的漏洞数量变化趋势统计图如图3-2所示。云原生基础设施相关漏洞数量变化趋势Docker,*Kubernetes图3-2云原生基础设施相关漏洞数量变化趋势统计图近年来，随着容器云广泛应用，容器云安全漏洞频繁被发现，漏洞影响越来越严重

33、。如果没有采取及时、有效的防范措施，一旦攻击者利用这些漏洞，可轻易对云原生基础设施造成致命攻击。2 .典型的云原生安全漏洞针对近年来出现的众多云原生安全漏洞，一些值得关注的漏洞如下。(1) CVE-2021-30465OpenContainers社区披露了runC相关的漏洞，攻击者通过创建恶意Pod,利用符号链接以及条件竞争漏洞将宿主机目录挂载至容器中，最终可能导致容器逃逸问题。当Pod中启动多个容器时，攻击者可以利用条件竞争，构造一个恶意Pod并挂载包含了软链接的目标路径，在特定条件下可以逃逸并获取容器rootfs之外的主机文件系统访问权限。(2) CVE-2021-41103Contain

34、erd社区公布了安全漏洞CVE-20241103,该漏洞源于Containerd中的缺陷。当容器根目录和一些系统插件中缺少必要的权限约束时，可使一个非特权的主机Linux用户拥有遍历容器文件系统并执行目标程序的权限。在多租户场景下，如果集群节点中的容器包含扩展权限(例如SetUid),非特权的LinUX用户可能发现并执行该程序。如果非特权的主机Linux用户UID碰撞到了容器中执行程序的所属用户或组，这个非特权的Linux用户可以读写该文件从而导致越权访问。(3) CVE-2021-25735Kubernetes官方披露了kube-apiserver组件的安全漏洞，攻击者可以在某些场景下绕过V

35、alidatingAdmissionWebhook的准入机制更新节点。如果集群中存在使用ValidatingAdmission机制进行节点更新准入校验的Webhook,并且该Webook的准入依赖节点原状态的某些字段，则攻击者可以通过某些手段绕过准入校验完成对节点实例模型的修改。(4) CVE-2021-25741Kubernetes社区公布了安全漏洞CVE-2021-25741,该漏洞可使攻击者使用软链接的方式在容器中挂载指定subPath配置的目录逃逸到主机敏感目录。在多租户场景E拥有以Root用户启动容器权限的恶意攻击者可以利用该漏洞逃逸至主机文件系统，获取主机敏感目录的读写权限。、云原

36、生威胁检测技术(一)容器镜像安全检测技术1 .容器镜像安全现状据SySdig的2022云原生安全和使用报告的数据显示：在运行于生产环境的镜像中，至少包含一个可修织漏洞的镜像占比高达85%。此外，包含严重程度为“高”或“严重”的可修复漏洞占比高达75%,如图4-1所示。PatchableVulnerabilitiesinRuntimeVulnerable85%None15%75%highorcriticalvulnerabilities4-1运行时环境的容器可修复漏洞分布情况除此之外，攻击者还可以投放恶意镜像到DockerHub中，如果这些恶意镜像被下载以后，就等同于引狼入室。总体而言，容器镜像

37、安全现状不容乐观。2 .容器镜像安全检测容器是从本地的镜像仓库中拉取来的，因此镜像的安全性直接关系到容器安全。并且，在实际环境中，本地构建的镜像还会引入第三方库，所以对引入的第三方库和本地构建的镜像进行安全检测就尤为重要。这里的镜像安全检测主要分为三个层级，第一级是静态检测，基于已知CVE漏洞进行安全扫描和检测；第二级是供应链检测，通过供应链的威胁情报作为数据支持，并通过自动化测试技术方法来检测镜像中的漏洞；第三级是动态检测，结合已知CVE和威胁情报,并在此基础之上，构建容器沙箱，进行实时动态检测。三个层级层层递进，目前最为基础的是“静态检测”。正在不断提升和优化的是“供应链检测”。未来，“动

38、态检测”技术将可能得到广泛的应用。(1)静态检测静态检测的核心是检测镜像中是否存在CVE漏洞。通过扫描获取的镜像信息，与CVE规则库中的名称和版本进行比对，从而判断是否存在漏洞。目前，比较典型的镜像扫描引擎有Clai八TriVy等。(2)供应链检测现代的应用78%-90%都融入了开源的组件，平均每个应用包含147个开源组件，且67%的应用采用了带有已知漏洞的开源组件，供应链安全不容乐观。基于对上述两点的考量，业界普遍按照“安全左移”理念采用自动化解决方案帮助开发人员和安全人员左移测试，摒除耗时手动过程。但该方法也使得开发和安全团队应对的最明显挑战就是冗长的漏洞列表，这需要找到恰当的方法高效处置

39、漏洞结果。在安全运营工作中，想修复所有的漏洞几乎不可能，为了应对此类问题给镜像带来的安全风险，我们可以结合相关威胁情报，发现应用中用到的开源软件，并分析相关代码版本，将其与威胁情报比对，检测出真正需要修复的高风险漏洞隐患进行告警，安全狗漏洞运营团队关注的高风险漏洞如表4-1所示。1属于ODay或在野漏洞2云服务器关键应用，比如中间件、数据库、容器编排、软件成分等关注对象清单3具备以下特点：可远程利用、攻击且杂度低、权限要求低、影响范围广、具备POC.EXP类型评判依据表4-1安全狗漏洞运营团队关注的高风险漏洞比如：安全狗采用基于漏洞运营情报的漏洞管理方法和流程，动态地将需要修复的漏洞进行优先级

40、排序和流程优化，提高修复效率，以达到用最少的时间实现最好的效果。图4-2为安全狗漏洞运营团队的漏洞情报运营体系总体设计图的局部。安全狗漏洞运营团队对从CVE,NVD.CNVD.CNNVD,安全社区、高质量头部安全厂商等渠道获取的漏洞情报进行研判、研究，输出高质量的高风险漏洞情报研究成果赋能产品，缓解客户“海量漏洞无从下手，无法聚焦重点的高危漏洞”的痛点漏洞情报库洞造洞拟丁车 漏储 漏虚补库胁数级 威指评人工研判洞工判补全 漏人研及全利Oc取 漏Po茨洞Xp取 渊Ex获应急漏洞规则ODay或在野秦洞自动标识录入原厂漏洞补丁安全狗虚拟补丁管理曾理4-2安今狗需潸通号团跳（怖做郴犍樗膝熟林俵神图砧雨

41、（3）动态检测基于静态检测和威胁情报，增加基于eBPF内核构建容器沙箱。结合自动化渗透测试和模糊测试，使用eBPF内核技术构建容器沙箱，对针对镜像文件的可疑访问进行动态检测，对系统的可疑调用、容器之间的可疑互访、检测异常进程、对可疑行为进行取证。该技术是未来发展方向，目前市面上暂无成熟的产品，处于研究或试用阶段。（二）容器运行时安全检测技术1 .基于规则的已知威胁检测基于规则的异常检测方法一直是最为经典的方案，容器环境下也依然适用。与传统威胁检测不同的是，容器环境下出现了许多新的威胁场景，如容器逃逸、容器应用漏洞利用，相关的规则和检测引擎也发生了新的变化。2 .基于行为的未知威胁检测大多数未知

42、行为是无法通过规则匹配检测出来的，因而可通过行为分析来发现未知威胁。一般来说，不同应用的业务场景是不同的，但在生产运营时间内，业务依赖的程序和模块的行为是能确定、可预测的。基于上述分析，收集内部业务正常运行期间的进程集合及进程行为、属性集合，采用自学习、无监督的方式，可自动构建出合理的镜像、容器进程行为基线。在自学习结束后，可以利用这些行为基线对容器内的未知威胁进行检测。（三）容器网络安全检测技术1 .微隔离微隔离是一种细粒度的网络隔离技术，其核心能力聚焦于东西向流量，对容器、主机的东西向流量进行隔离和控制，阻止当攻击者进入云原生网络后进行横向移动。（1）基于NetworkPolicy实现微隔

43、离NetworkPolicy是KUbemeteS的一种资源，可用来说明一组Pocl之间是如何被允许互相通信，以及如何与其他网络端点进行通信。NetworkPolicy使用标签选择Pod,并定义选定Pod所允许的通信规则。每个Pod的网络流量包含流入（IngreSS）和流出（Egress）两个方向。在默认的情况下，所有的Pod之间都是非隔离的、完全可以互相通信，也就是采用了一种黑名单的通信模式。当为Pod定义了NetworkPolicy之后，只有允许的流量才能与对应的Pod进行通信。在通常情况下，为了实现更有效、更精准的隔离效果，会将这种默认的黑名单机制更改为白名单机制，也就是在Pod初始化的时

44、候，就将其NetworkP。IiCy设置为denyall,然后根据服务间通信的需求，制定细粒度的策略，精确地选择可以通信的网络流量。（2）基于Sidecar实现微隔离另外一.种微隔离的实现方式就是采用ServiceMesh架构中的Sidecar方式。ServiceMesh（比如IStio）的流量管理模型通常与SideCar代理（比如Envoy）一同部署，网格内服务发送和接收的所有流量都经由Sidecar代理，这让控制网格内的流量变得异常简单，而且不需要对服务做任何的更改，再配合网格外部的控制平面，可以很容易地实现微隔离。（3）云原生网络入侵检测由于云原生环境下，传统的IDS无法监控和检测到云原

45、生环境的的入侵行为，所以云原生网络入侵检测机制需要实现对Kubernetes集群中每个节点上Pod相关的东西及南北向流量进行实时监控，并对命中规则的流量进行告警。告警能够定位到哪一个节点、哪一个命名空间内的哪一个Podo针对云原生环境下的微隔离需求，一些厂商参考了NetworkPolicy以及SideCar方案等微隔离实施标准，结合其在主机微隔离上的技术积累。提出了同时支持主机工作负载与容器工作负载的微隔离解决方案。安全狗“云隙”微隔离产品就是这种技术路线的代表。具体来说，就是使用Kubernetes集群中已经提供的NetworkPolicy基础设施进行白名单的网络管控，并使用产品InCont

46、ainerFirewall的功能对集群中Pod实施黑名单的网络管控。这样不仅有效利用了KUberneteS已有的成熟基础设施，同时也利用了产品在主机微隔离体系的成熟积累。（四）云原生可观测性在云原生时代，容器化的基础设施使得应用自身变得更快、更轻。一台主机上可以同时承载上百个容器的部署运行，主机上应用的部署密度以及变化频率，较传统环境，有着巨大的变化。因此，需要可观测性来清晰地发现和记录主机快速变化的应用行为。正所谓“未知攻，焉知防”，面对云原生架构下的大规模集群以及海量灵活的微服务应用，只有知道集群中应用的具体操作、行为，才能够进行高效的安全防护。全面的云原生可观测性，包括了系统日志、应用日

47、志等一整套完善的日志审计，还包括了各类运行指标的高性能监控，以及进程行为追踪、服务调用链追踪等，使我们能够清晰地了解系统详细的运行状况，进而快速高效地进行威胁的检测、追踪与溯源。2 .日志日志记录是应用程序执行过程中对操作系统、服务程序等软硬件设备在运行中所产生动作的描述，包括发生时间、动作发起者以及执行过程等详细信息。日志在服务调试、错误或异常定位和数据分析中的作用不言而喻。合理地使用日志可以帮助用户在定位问题和决策分析时做到有理可循、有据可依。随着安全技术的不断进步，日志分析在安全检测中的应用也日趋广泛，日志在容器安全领域发挥极大的作用。（1）漏洞分析与系统加固据已有研究显示，容器化漏洞隐藏在云原生应用的方方面面，如文件系统隔离、进程与通信隔离、设备管理与主机资源限制、网络隔离和镜像传输等。可以通过日志记录来回溯攻击的入门与方式、定位漏洞详情、判断业务影响面，进而及时地进行漏洞修复与针对性的系统加固。（2）安全监测和趋势预判日志审计是检测安全事件的不可或缺的重要手段之一。通过对业务内部的各项安全日志数据（如集群控制组件产生的攻击日志、应用操作日志等）进行关联分析，实现不同维度的容器安全风险检测和安全趋势的预判。（3）制定应急响应机制相比较传统虚拟技术，容器化应用的安全防御技术仍有待提高。一旦遭受恶意攻击，可