将持续安全植入容器部署的4步指南

2017 年 10 月 25 日

本文要点

  • 容器风险有多种形式:勒索软件、应用层 DDoS、容器感染或逃逸等。
  • 每一次成功地攻击都包含一个事件“杀伤链”,要抑制这些活动,就需要在整个栈及部署过程的每一个阶段引入一种分层安全策略。
  • 不只是在生产阶段,在前三个阶段(构建、传输、生产准备)也有具体的安全措施可以采取。
  • 容器构建、传输和生产准备阶段的持续安全应该包括:代码分析、加固、镜像扫描、镜像签名 & 用户访问控制、主机 & 内核安全、系统 &Docker 守护进程安全、秘密管理、审计和编排安全 & 网络。
  • 生产准备和生产运行阶段应该包括:网络检查 & 可视化、7 层应用隔离、威胁检测、权限提升检测、容器隔离、运行时漏洞扫描、数据包捕获 & 事件日志。

从构建阶段到传输至生产运行阶段,容器在每个阶段都面临着安全风险。为应对这些威胁,保证容器的一致性和安全性,实现持续安全至关重要。然而,在繁忙的时候,为了使 CI/CD 管道可以更快地流动,这些安全措施都被跳过或忽略了。现如今,许多企业都在为多年前实现的糟糕的安全措施买单。但愿这些错误不会在迁移到容器化环境时再重复一次。

容器和主机风险有多种形式:勒索软件、应用层 DDoS、跨站点脚本攻击,受感染的容器额外下载恶意代码或寻猎内部系统敏感数据或漏洞,容器逃逸允许不经授权访问系统,迫使容器消耗系统资源,导致其他容器崩溃,等等。

这些攻击有许多是始于潜伏多年但之前没有发现的漏洞。攻击者利用这些漏洞获得一个据点,然后扩展到其他主机或容器。

导致 Equifax 数据泄露的 Apache Struts 漏洞

Apache Struts 是一个在使用 Java 创建 Web 应用程序时广泛应用的框架。人们最初认为,新发布的 Struts 漏洞 CVE-2017-9805 是 Equifax 数据泄露的原因。然而,Equifax 最新发布的公告显示,是3 月份发现的漏洞CVE-2017-5638 导致了 Equifax 数据泄露

CVE-2017-9805 的漏洞代码位于 Struts 框架的 REST 插件中。该插件未能安全地验证并反序列化 HTTP 请求中用户上传的数据。这让攻击者可以将任意二进制代码写到 Web 服务器上并远程执行。3 月份,Jakarta multi-part 解析器的漏洞 CVE-2017-5638 被曝了出来。此外,通过在一个精心设计的 Content-Type HTTP 头中注入“#cmd=”字符串,攻击者可以在 Web 服务器上执行任意命令。

勒索软件

近日,勒索软件攻击利用了各种漏洞,包括开放端口、远程代码执行和其他应用程序缺陷。

_WannaCry/WannaCrypt_ 主要是在 SMB、RDP 和 IIS 服务端口如 445 上攻击微软Windows 漏洞。和大多数攻击一样,是一个事件“杀伤链”导致了最终的勒索要求。

一旦攻击者进入一个网络,他们就横向扩散。由于容器中的横向流量不可见,所以在容器化环境中更容易扩散了。

_SambaCry_ 是 7 年前在 Samba 网络软件中发现的一个危险的远程代码执行漏洞( CVE-2017-7494 )。该漏洞让远程攻击者可以控制受感染的 Linux 系统。现在,如果 CVE 数据库更新及时,那么漏洞扫描软件可以帮忙从容器镜像中找出这个 CVE。也有其他工具可以帮忙检测权限提升或容器逃逸。

ElasticSearch MongoDB 是 Docker Hub 上其中两个下载最多的应用程序容器。出人意料,包括开放端口和密码在内的简单攻击都可以被用于勒索软件。基本的容器安全措施就可以预防这样的攻击。经常审计并测试主机和容器的安全设置,发现最近的应用程序升级或主机部署引入的风险。

Dirty Cow

Dirty Cow( CVE-2016-5195 )内核漏洞被攻击者用于改写系统中的 setuid 程序。通过替换 setuid 程序,攻击者可以在程序执行时获得 root 访问权限,然后就可以做任何他们想做的事。由于攻击者可以采取破坏性行动,他们更可能在这个时候偷偷地扩散到其他系统或应用程序。甚至,受感染的容器被销毁了,漏洞利用者仍然可能留在容器环境中

Linux Stack Clash

近日,Qualys 的安全研究人员发现了 Linux Stack Clash 漏洞 CVE-2010-2240 ),之所以命名为“Stack Clash”,是因为它会使其他内存区域(如堆)和栈发生“冲突”。由于这是用户空间的本地漏洞利用,这也在操作系统或内核中为攻击者提供了一个据点。Stack Clash 可以和其他漏洞一起利用,对系统造成更严重的破坏,并可能横向扩散。例如,最近发现的 sudo 漏洞( CVE-2017-100367 )结合 Stack Clash 就可以使用 root 权限执行任何代码。

攻击检测

每一次成功地攻击都包含一个事件“杀伤链”,我们可以使用各种技术在多个点上进行检测。通常,为了降低容器环境中的风险,应该采取以下安全措施:

  1. 扫描主机和容器(在进入运行环境之前或期间)漏洞,升级易受攻击的系统;
  2. 监控主机和容器的可疑进程,如 root 权限提升和端口扫描;
  3. 检测使用可疑网络连接连接其他主机或容器的横向运动和逃逸;
  4. 如果没有严格规定,则封锁容器的外部访问;
  5. 不断升级容器、主机和平台工具的安全设置。

为了减少威胁,需要引入并实现一种分层安全策略,在整个栈和部署过程的每个阶段预防这些问题。为了检测和解决攻击及其他问题,正确的安全控制和自动化测试是确保应用程序安全有效必不可少的组件。

为了实现持续安全,下面是可以在容器部署过程中采取的措施:

第一步——构建阶段

持续安全始于构建安全的应用程序。开发人员必须懂得利用恰当的技术最小化应用程序代码本身的风险。这些技术包括:

  • 代码分析——开发人员应该使用代码分析工具,识别并报告所有潜在的漏洞;
  • 加固——删除所有不需要的库和程序包,限制不必要的功能,缩小容器镜像的攻击面;
  • 镜像扫描——为了在应用程序构建之前发现问题,应该在传输阶段之前对容器镜像进行漏洞扫描。还应该定期扫描注册中心,以便发现现有镜像里的新问题。

在实际实行这些措施的时候,应该使用恰当的工具把它们自动化并加入交付过程 / 管道,这样才能确保不断地执行,而不会出现不执行的情况。

第二步——传输阶段

在准备部署镜像时,为了确保信任,安全需要恰当的控制和验证。这包括:

  • 镜像签名——这可以确保作者 / 发布者经过验证,没有发生镜像篡改。例如, Docker 的内容信任特性提供了这种安全。
  • 用户访问控制——敏感系统和部署工具(注册中心、编排工具等)应该有机制可以有效地限制和监控用户访问。

为了自动化这些安全特性,促成持续安全,用于生产环境的镜像应该自动签名和打标签。敏感工具的访问控制应该集成活动目录或 LADP 目录。 Docker Bench for Security 可以作为一个自动化过程来运行,测试内容信任和访问控制问题。

第三部——运行阶段:准备

在生产环境中运行应用程序容器之前,需要确保运行时环境的安全,包括主机、内核、Docker 守护进程以及所有的网络和系统服务。

  • 主机及内核安全——这可以通过使用 AppArmor SELinux seccomp 等安全模块或者同等的主机安全设置来保证。
  • 系统及 Docker 守护进程安全——确保只有经过授权的用户才能访问敏感系统及 Docker 命令和设置。
  • 安全管理——利用加密保护与应用程序及 API 访问有关的秘密。
  • 审计——在进入运行时之前或运行期间执行安全设置审计。这可以使用之前提到过的 Docker Bench for Security、 Kubernetes CIS Benchmark 及其他工具来实现。同时,这还有额外的好处,就是有助于满足容器合规性需求。
  • 编排安全 & 网络——使用能够控制访问、设置网络策略、恰当的名称及标签的容器管理和编排工具来保证容器环境安全。此外,这些工具能确保安全的容器运行在每一台主机上。

这些编排及集成的安全工具可以提供自动化安全测试,根据标准基准进行检查,并自动更新策略,适应配置变化,更清晰地可视化应用程序和容器内的行为。

第四步——运行阶段:生产

谈到容器安全,在生产环境中运行时是最关键的阶段。这是战场,黑客会设法利用他们发现的一切漏洞,而安全工作必须检测并阻止那些尝试。黑客的行为会包含一个“杀伤链”,黑客从一台主机或另一台容器转移到目标漏洞攻击点时会产生一系列的事件。通常,在这一系列事件发生的过程中,我们会有多次机会发现并阻止黑客的活动。下面是可以使用的技术:

  • 网络检查 & 可视化——检查网络行为是最可能监控并识别出可疑活动的防御据点。务必检查所有容器到容器的连接以及容器和主机进程,可视化应用程序栈的行为。如果攻击扩散,实时响应是必要的,这些能力让安全团队可以看到攻击来了并作出响应。
  • 7 层应用程序隔离——不局限于 L3/4 网络分割,还要根据应用程序协议和容器元数据检查实现隔离和防护。必要的时候,可以在不影响容器的情况下阻塞应用程序活动。
  • 威胁检测——监控应用程序,时刻留意 DDoS、DNS 或者其他各种基于网络的应用程序攻击。
  • 权限提升检测——黑客行为可能会设法为未经授权的入侵者提供更大的管理权限。检测主机及容器上的权限提升,可以预知逃逸,免受此类攻击。
  • 容器隔离——当容器显示出可疑行为时,调查期间,为了安全起见,有能力隔离容器。
  • 运行时漏洞扫描——应该对所有运行中的容器都进行漏洞扫描;所有新建的容器也应该立即进行漏洞扫描。
  • 数据包捕获 & 事件日志——捕获数据包,创建事件日志,便于取证分析。

实现这些安全措施的工具应该自动部署到每一台主机,新建容器的行为应该可以自动获知或者通过编程加入安全策略。运行时监控和预警管理既可以通过本地控制台,也可以通过导出到 SIEM 系统的日志。

小结

正确规划,统筹安排,整合安全工具和自动化策略,就可以实现持续的容器安全,保护整个容器部署过程。

关于作者

Fei Huang NeuVector 联合创始人兼首席执行官。NeuVector 是一个 Docker 容器网络安全解决方案,使用行为学习来保证容器的运行时安全。Fei 在企业安全、可视化、云、嵌入式软件方面有 20 多年的经验。他是 Cloudvolumes(被 VMware 收购)创始团队的成员,同时也是 DLP 安全公司(被 TrendMicro 收购)Provilla 的联合创始人。Fei 持有安全、可视化及软件架构方面的多项专利。

查看英文原文 A 4-Step Guide to Building Continuous Security into Container Deployment

2017 年 10 月 25 日 18:083058
用户头像

发布了 1008 篇内容, 共 307.1 次阅读, 收获喜欢 272 次。

关注

评论

发布
暂无评论
发现更多内容

食堂就餐卡系统设计文档

JUN

架构师训练营第1周作业

无名氏

架构师-第一课总结

free[啤酒]

week1《作业二:根据当周学习情况,完成一篇学习总结》

任鑫

架构师训练营-Week 01 命题作业

华乐彬

极客大学架构师训练营 架构文档 作业

第一周作业

Jeremy

第一周-学习总结

molly

极客大学架构师训练营

架构师训练营-Week 01 学习总结

华乐彬

学习 架构 架构师 极客大学架构师训练营

架构师第一周总结

suke

极客大学架构师训练营

第一周学习总结

G小调

架构师训练营第一周总结

草原上的奔跑

极客大学架构师训练营

第一周感想

数字

食堂就餐卡系统设计

G小调

食堂就餐卡系统架构设计文档

AIK

极客大学架构师训练营

【架构训练营】第一期

云064

关于架构设计的学习记录

imicode

食堂就餐卡系统设计

olderwei

初识架构师

eazonshaw

极客大学架构师训练营

架构师如何去编写设计文档?

阿飞

架构 架构是训练营

架构师0期 | 食堂就餐卡系统架构设计文档

刁架构

极客大学架构师训练营

如何开始成为一名架构师

Ph0rse

极客大学架构师训练营

食堂就餐卡系统设计

chinsun1

架构文档

架构师训练营第一周学习总结

a晖

食堂就餐卡系统设计

imicode

架构师如何做架构(训练营第一课)

看山是山

学习 极客大学架构师训练营 UML

课后总结1-架构师训练营

进击的炮灰

第一周作业

qqq

极客大学架构师训练营

第一周培训心得

史慧君

【架构师训练营-作业-1】食堂就餐卡系统设计

Andy

「架构师训练营」作业1:食堂就餐卡系统设计

Amy

极客大学架构师训练营 作业

架构师如何做架构(第1周学习总结)

李德政

极客大学架构师训练营

将持续安全植入容器部署的4步指南-InfoQ