前言
近年来,云原生架构被广泛的部署和使用,业务容器化部署的比例逐年提高,对于突发重大漏洞等0day安全事件,往往给安全的应急带来重大的挑战。例如前段时间广受影响的重大漏洞的爆发,可以说是云原生架构下安全建设和安全运营面临的一次大考。
本文将以该高危任意代码执行漏洞作为案例,分享云原生架构下的安全建设和安全运营的思考。
漏洞处置回顾
漏洞爆发后,第一时间关注的一定是攻击者能否利用漏洞攻击业务系统,可以通过哪些方式实施攻击。对于容器环境,从攻击视角来看,通常可以有以下几种入侵途径。
图1
1)通过容器主机实施攻击。这种通常是由于主机配置问题引起,例如对公网开放并且未开启认证的Docker RemoteAPI,或者是未开启认证的Kubernetes API Server。
2)通过脆弱的容器实施攻击。这种类型攻击主要以容器环境中部署应用程序的脆弱性作为攻击突破口。
3)通过投毒的镜像实施攻击。主要通过对公共仓库中的镜像进行投毒,当镜像被拉取运行时,即可执行相关的攻击操作。
攻击者可以做什么?
本次log4j2漏洞的影响,主要是体现在第二种攻击方式上,也就是攻击者会通过受影响的应用程序,利用漏洞对容器化的应用实施攻击。
一旦第一步漏洞利用成功,接下来就会按照通常的渗透攻击逻辑,一方面在主机执行恶意程序;另一方面通过横向移动,扩大攻击范围,这里的横向移动既会涉及主机层面的容器逃逸,也包括东西向网络层面的移动攻击。
如何快速响应处置?
云原生架构下,在漏洞的应急响应上,总体思路和传统安全事件的应急是一致的。首先需要对漏洞的原理以及可能被利用的方式进行分析,确定修复和缓解方案,同时制定相关安全产品的防护规则,实现对漏洞利用的检测和拦截,最后就是有条不紊的进行漏洞的修复和处置。
在容器环境中,具体可以梳理出如下的一些关键操作步骤:
首先,需要确定现有业务的受影响范围。例如:确定仓库中所有受漏洞影响的镜像,确定受影响的线上业务;
其次,升级相关安全产品的防护策略。例如通过WAF规则以及防火墙规则等实现对漏洞利用的攻击进行一定程度的暂时性拦截;必要时升级运行时检测策略,一旦入侵成功,可以快速的发现并进行处置。
最后,就是修复漏洞,升级到官方发布的修复版本。