容器可追溯到1979年的chroot命令,但Docker的出现让该技术的流行度和可用性有了指数级增长。任何技术一旦流传开来,必然也就成了攻击的目标。
容器旨在提供非完整虚拟机之外的隔离环境,但因为往往不像IT环境中其他资产一样受到监视,容器也就成为了攻击者眼中的肥肉。
公司企业有必要对容器进行漏洞评估,就像对环境中其他任何资产所做的那样。有那么几个漏洞扫描器可以扫描运行中的容器并报告漏洞,旦那只是整个评估的一部分。
容器并非全时段运行,只有完成特定任务时调用一下,然后就是暂停挂起或关机,直到下一次需要的时候再运行。如果扫描的时候容器没在运行,传统扫描器就可能会错过漏洞。
我们可以做个类比以更好地理解这种情况。大多数公司都用笔记本电脑,也会对笔记本电脑进行漏洞扫描。如果扫描的时候笔记本电脑正好接入网络,那么其中存在的漏洞就会被扫到并上报,但如果电脑正好关机或休眠了,漏洞扫描就无法评估这台电脑的情况(假设没有局域网唤醒功能)。
容器的情况与之类似:必须正在运行,才可以被漏洞管理产品评估。
不过,如今,情况改变了。
Tripwire漏洞与暴露研究团队(VERT)发布了ASPL-736,增加了非运行Docker容器扫描功能(暂停、停止、创建、退出等等状态均可)。该功能作为运行容器扫描的补充,对生产中的容器状态有了全面的视图。
有人可能会觉得,“好酷!不过,如果在进入生产前就全都扫描过了,为什么我还需要扫描非运行容器呢?”
可以再用笔记本电脑的类比来回答这个问题。公司或许会对所有笔记本电脑采用通用镜像,里面是已知完好的操作系统和经批准的App。在发给员工的时候,确实是在一个良好的状态。然后,员工可以通过安装软件,甚或暴露在恶意软件之下,让该电脑状态发生改变。因为在漏洞扫描的时候,该电脑未必接入网络,因而这些威胁很可能就被漏掉了。
不建议对生产容器进行修改/修复。相反,你应该修复父镜像,测试之,并用已更新的镜像替换掉生产容器。对笔记本电脑或许不会这么做,但我们仍可应用相同的类比,因为正如企业会有很多同样的笔记本电脑,拥有很多同样的容器或容器间共享的组件并不奇怪。
影响笔记本电脑的漏洞有补丁可用时,会执行漏洞扫描以确保所有系统都被更新。那么有大量容器需要打上OpenSSL补丁时呢?
基础镜像会被更新,更新过的容器再被重新部署进生产中。如果漏洞管理解决方案只能扫描运行中的容器,便无法确保所有容器都被更新。这就留下了盲点,容器可能在缺乏真实漏洞状态可见性的情况下被唤醒或启动。
非运行容器扫描功能,赋予了安全管理员超级X光透视能力,可以看清容器状态,清除这些盲点。
相关阅读
Docker推出漏洞容器扫描工具
在Docker上部署容器时应考虑的安全风险