5000字解析:实战化场景下的容器安全攻防之道

2022-08-05 14:27:18 浏览数 (2)

在这个数字化转型关键时期,以容器为代表的云原生技术凭借自身的优势,正在逐渐成为核心IT基础设施。云原生已经不再是少部分“创新者”的特权,而是成为了市场主流选择,容器、容器云逐渐成为工作负载的主流形态。

与此相随,云原生大量的新技术,也带来了众多未知的风险敞口,安全防护对象也发生了颠覆性变化,容器正在逐渐成为黑客新的演练场。

一、容器成为重要的攻击目标

在容器时代,安全面临新旧威胁的双重挑战。一方面,那些传统旧的攻击手段依然有效,包括漏洞利用、暴力破解、权限提升等等。另一方面,新的攻击姿势也是层出不穷,例如投毒镜像、容器逃逸、集群API调用等等,让人防不胜防。

在过去的攻防演练中,就曾发现多起针对容器、集群攻击事件。容器带来新的风险暴露面,给了攻击者众多可乘之机。

为什么容器会成为黑客重点攻击目标?笔者认为核心原因有以下6个方面:

  • 容器的安全建设滞后

容器虽然可以实现更加灵活、更加低成本的软件开发和应用部署,但是对应的容器安全建设却远远滞后于业务发展速度,大量“裸奔”的容器成为了攻击者眼中“香饽饽”。

  • 容器的攻击价值高

在容器集群中,只要攻陷一个容器,就可以横向移动到其它容器上,或者逃逸到node节点上进行持久化,控制整个节点。下一步,攻击者还可以通过漏洞利用或者调用API SERVER控制整个集群。而集群作为集权类系统,一旦失陷,防守方“血条”减少一大截就不可避免了

  • 容器的攻击面庞大

除了应用本身的脆弱性引入的攻击外,集群、容器运行时本身的脆弱性问题也不容忽视。例如攻击者通过k8s、docker未授权访问长驱直入;集群权限配置不当,攻击者可创建高权容器进行逃逸;利用Linux内核cgroups模块(CVE-2022-0492)进行逃逸。

  • 容器的漏洞影响范围大

在传统操作模式中,所部署的软件在其运行的主机上更新,而容器则必须在上游的镜像中进行更新,然后重新部署。因此,若镜像或基础镜像存在问题,则将至少影响一个或多个集群。

  • 容器的防护难度高

容器安全防护需要覆盖容器构建、部署、运行整个生命周期,所涉及的环节和流程链路都非常复杂。例如,在构建阶段,可能会遇到的软件供应链攻击,包括基础镜像污染、CI工具攻击、制品库漏洞攻击等。在部署阶段也可能面临针对云原生基础设施平台攻击,包括开源组件编排工具等。在运行时阶段,还可能面临针对云原生应用的攻击,包括SQL注入、漏洞、弱口令等。

  • 容器的攻击溯源难

容器的生命周期短,动态变化快,超过50%容器从上线到下架的整个生命周期不超过1天。如何在检测到异常入侵事件之后,快速进行安全响应,把损失降到最低成为了一大安全难题。

二、容器缺乏有效的安全手段

在传统的安全防护范畴中,组织的“端点、网络、边界”,各个层级相对清晰,但是在云原生环境下这些边界消失了。

近年来,虽然企业组织的安全建设投入大幅度提升,企业组织都部署了基本的防火墙、漏扫、终端安全等常规的安全设备。

但是当容器面临攻击时,传统安全防护手段,无法有效保护容器安全。例如,在IT架构中,如果包含容器、K8S等新型的云原生基础设施时,攻击者可以通过多种方式轻松完成一次攻击。如下图所示,一个个小小的漏洞就有可能打穿容器节点,甚至整个集群。

图1:从攻击方视角看攻击路径

第一步:通过容器应用攻击容器

攻击者通过weblogic远程代码执行漏洞(CVE-2021-2382),获取了一个容器的控制权。

第二步:通过失陷容器攻击其它容器

获取容器控制权后,可通过nmap等网络探测方式发现可访问的容器端口。

第三步:通过容器攻击宿主机

若docker、containered等存在容器逃逸漏洞,可利用此漏洞获取宿主机的控制权。

第四步:通过容器攻击集群

若K8S存在8080、6443未授权访问,可通过容器访问K8S master api进行恶意调用。

试想,面对这样的攻击,不管是边界防火墙,还是终端的安全产品,都无法完成有效安全防护,也无法隔离容器或杀掉容器内恶意进程,更无法提供行之有效的溯源分析,只能通过下线业务的方式缓解影响,但是这无法从根上解决容器的安全问题。

三、为实战化定制容器安全方案

在这样的背景下,青藤基于多年实战化攻防演练的经验,不断升级迭代方案,正式推出升级版《容器安全实战化解决方案V2.0》

该方案覆盖了几个核心环节,包括攻击风险评估、风险收敛整改、攻击行为监控、攻击事件响应、溯源分析报告共五个环节,可实现容器全生命周期的主动防御效果。

图2:攻防演练5个核心环节

第一阶段:容器攻击风险评估

在攻防演习前期,最重要就是做好攻击风险评估,包括资产梳理、漏洞检查、基线检查、弱口令检查等等。其中最重要就是做好资产梳理。

根据过去攻防实战演练的经验,有不少组织机构对于自己的资产情况把控不够,导致部分资产未能纳入有效监测,形成了防护薄弱点。

攻击队在发起进攻前,会先收集这些薄弱点,并以此为跳板攻入企业关键系统。所以,提前对资产进行评估,收敛对外暴露的攻击面变得尤为重要。

  • 工作负载可视化,消除容器资产盲点

在云原生环境下,防守方在演习前期一定要对容器资产进行清点,尤其是梳理内网集群&非集群管理的系统资产,并且把资产对应到人。最重要的是要对核心业务资产进行深度透视,尤其是靶标系统、集权系统等。

有了上述详细的资产看板之后,在发生入侵事件时,就可以快速反查容器业务应用,协助定位入侵的入口点以及影响范围。例如,在攻击者利用0day/1day漏洞时,防守方可通过应用级别的资产排查,分析现有业务受漏洞影响范围。

图3:重点关注容器资产类别

此外,还需要梳理容器内的应用资产,发现边角系统和废弃资产、发现不合规的资产,为后续系统加固和应急响应做铺垫。这个过程需要重点关注三个方面:

(1)梳理集群与外部系统的边界

首先,梳理集群对外暴露服务,如使用主机网络暴露服务,使用nodeport暴露服务。其次,梳理集群内对外访问情况,发现不合规的对外访问行为。

(2)梳理高权、特权容器

主要包括Privileged 特权容器、高Capabilities的容器、挂载敏感目录的容器、Root账号的容器、Host模式运行的容器、共享主机namespace的容器 、共享主机设备的容器 、CPU/内存使用不设限的容器等。

(3)发现不合规应用

主要是针对容器中的ssh、sudo、ftp、vsftp等资产。

  • 细粒度梳理供应链软件成分,做好软件治理工作

通过资产细粒度清点,还能实现供应链的安全管控。对于企业组织来说,容器制品供应链环节的安全性也非常重要。尤其是随着云原生应用制品越来越多样化,像容器镜像、 helm charts 都是常见的制品格式。

一方面,需要在应用构建阶段保证制品的安全性;另一方面需要在制品入库;分发和部署时刻建立对应的合规检查、访问控制,安全扫描、审计和准入、准出的校验机制,保证制品源头的安全性。

因此,在攻防演习前,要做好软件供应链的资产台账,包括运行的应用、中间件、数据库、安装包、框架语言包(java、go、ruby、nodejs、python、php)等,发现其安装路径、版本信息和配置情况。

图4:青藤蜂巢可细粒度梳理供应链软件成分

第二阶段:容器风险收敛加固

在攻防演练中,前期的准备工作包括脆弱性整改、漏洞缓解、靶机加固整改、集权系统监控等。我们可以把这些技术性工作概括为风险收敛与安全加固两个方向。对防守方来说,针对云原生风险收敛加固,可以从梳理系统脆弱性&整改、微隔离加固等方面实现风险收敛与安全加固。

  • 容器脆弱性评估与整改

攻防演习前,需要全面排查内网安全隐患,发现并协助整改容器环境的脆弱性存留。通过各种不同的方法修复可能被攻击者利用的漏洞,加强系统安全配置,增加攻击者入侵的难度,提升安全防范水平。它与攻击面收敛、漏洞修复、安全策略优化等工作形成了完整的风险管理闭环。

图5:运行时脆弱性评估&整改

但是在攻防演练中高强度的攻击下,即便前期做了很好风险收敛加固工作,仍然有可能出现一些0day/1day的高危漏洞,导致被攻破的局面。

因此,企业组织需要那些具备专业的漏洞研究人员和漏洞应急响应流程的安全厂商,能够在24小时内,提供应急响应方案。一旦演习期间发现有高危漏洞的情报,需要第一时间跟进。青藤拥有非常健全的应急响应团队和完善的响应流程,可以很好应对实战化背景下容器安全应急处置。

图6:青藤漏洞应急响应和处置流程

  • 重点系统微隔离控制

在实战化对抗中,可以预见的是攻击者一定会对演习目标系统展开高强度的远程攻击。在不限制攻击路径的前提下,以控制业务系统、获取重要数据为最终目的,全面展开攻击。为此防守方需要在演习前期对重要系统进行微隔离控制,主要包括两个方面工作:

对外,需要梳理容器集群与外部系统的边界,梳理集群对外暴露的服务及集群内对外访问情况,进行合规控制。

对内,需要梳理容器内的重要系统(集群系统、靶标系统)在内网的访问模型,形成访问控制基线。

图7:重点系统微隔离控制

第三阶段:容器攻击行为监控

攻防演练开始之后,红队完全按照攻击者的思维,发起高强度、高水平的网络攻击。因此,对蓝队来说,监控是能够及时发现攻击至关重要的一步。青藤蜂巢能够提供多锚点的检测能力,能够实时、准确地感知入侵事件,发现失陷容器。

图8:覆盖攻击链路的多锚点监控

  • 容器攻击事件监测

虽然预防性安全技术能够应对已知的基于签名的威胁,但蓝队仍需要网络安全监控来识别更复杂的威胁。

因此,防守方需要利用前期部署的主机、容器攻击监控体系,实时发现攻击行为,并按照攻击告警监控流程进行上报。青藤蜂巢除了能够对已知特征威胁进行检测,也能对恶意行为进行检测,还能进行异常检测。

图9:青藤蜂巢立体入侵监测体系

(1)基于已知特征的威胁检测

青藤蜂巢可对容器内的文件、代码、脚本等进行已知特征的检测,可实时发现容器中的病毒、挖矿、webshell等已知威胁。以webshell检测为例,青藤雷火根据AI推理发现Webshell中存在的可疑内容,其Webshell检测率超越历史最强水平,高达99.99%,并且整个使用过程无需长期训练,可即插即用。

图10:已知威胁检测

(2)基于恶意行为的检测

青藤蜂巢,基于对恶意行为模式的定义,可对容器及编排工具的黑客攻击行为进行实时检测。

首先,可检测容器内无文件攻击,支持发现内存webshell、shellcode和加载动态链接库等多种内存码。

其次,可检测容器逃逸行为,支持发现K8S组件漏洞逃逸、内核漏洞逃逸、容器漏洞逃逸、敏感挂载逃逸等行为。

最后,可检测K8S API恶意行为,支持包括匿名用户登陆、secrets获取、API server可疑操作等。

图11:重点恶意行为检测

(3)基于异常行为的检测

青藤蜂巢,可对容器内进程、网络等行为进行学习建立模型,从而发现异常入侵。针对重要的容器靶机、集群系统进行提前学习,形成稳定的模型,一旦发现异常进程启动、异常端口监听、异常网络连接和异常文件操作就立即报警。

图12:未知威胁检测

  • 处理容器攻击事件

在检测到入侵事件之后,对于失陷容器需要进⾏快速的安全响应,把损失降到最低。青藤蜂巢能够实施不同细粒度的管控措施,在容器层面可以直接隔离、暂停、查杀容器,在容器行为层面可以阻断进程、隔离文件、封禁IP,不允许有问题的工作负载进行访问或被访问。

  • 入侵规则持续运营

青藤在收集到攻防过程中新型的入侵姿势等信息之后,会快速响应生成系统规则,通过规则更新的方式增强产品入侵检测能力。

目前,青藤蜂巢最新的产品功能,已经拥有自定义威胁情报和检测能力。例如,用户一线人员发现攻防演习过程中披露的入侵信息,可通过产品自定义锚点式检测规则和自定义威胁情报,增强补充产品入侵检测能力。

第四阶段:容器攻击事件响应

一旦确定了告警的真实性,安全专家要通过主机、容器上的日志以及系统告警等信息,对攻击事件进行调查,并生成《XXX事件调查报告》。最重要2个方面是:做失陷范围排查、攻击过程还原。

  • 容器攻击过程还原

通过对被攻击资产的分析与溯源,还原攻击路径与攻击手法,用户不仅能够有效提升攻防演练效果,还可增强常态化安全防御能力,将攻击事件转换为防御势能,避免二次攻击事件的发生。

图13:攻击过程还原

  • 容器失陷范围排查

根据现有信息找出一台确认失陷的主机/容器信息,然后以这台失陷主机的数据以及它的互联关系为线索,在用户系统中展开内网溯源,确认是否存在被横向渗透的主机/容器,并循环此过程,逐步找出所有失陷主机/容器,确认攻击影响面及具体的失陷范围,将攻击队彻底清除出内网。

图14:失陷范围排查

第五阶段:容器溯源分析报告

青藤蜂巢,可通过收集容器相关行为数据,包括API调用行为日志、容器进程事件、容器网络事件、容器文件事件、k8s审计日志事件等等,结合ATT&CK框架模型,通过大数据工具来进行安全威胁分析,确定攻击的影响范围和入侵路径,通过威胁狩猎主动发现内部潜在的其它威胁。

防守方在完成攻击确认到调查、还原的整个流程之后,需要整理出一份防守报告,阐述攻击的真实性、攻击的覆盖范围、攻击者的攻击路径及行为,并将报告提交给组织方。

图15:形成防守报告

四、写在最后

正如前文所述,容器已经成为黑客重要的攻击目标,但是目前非常缺乏有效的安全手段。可预见,未来容器、容器集群将成为最重要的IT基础设施。不管是在真实网络实战中,还是在相关的攻防演习中,以容器为代表云原生基础设施都将是攻防双方必争之地。

0 人点赞