针对 Docker API 的新型攻击

近期,有网络安全研究团队发现了一项针对容器基础设施的新型攻击:攻击者利用配置错误的 Docker API 端口在主机上直接构建并运行恶意容器镜像。据安全团队称,和以往从公共注册表中提取镜像不同,这次是攻击者首次在主机中构建镜像进行攻击。

在以前观察到的攻击情形中,攻击者通常试图通过运行加密货币矿工程序,对其他主机发起网络拒绝服务攻击,或进一步将攻击从容器扩展到主机的网络,从主机上劫持资源。对此,防御者可以扫描镜像,根据结果做出反应,从而限制与可疑来源或注册表的通信。

但这次,攻击者没有从注册表中提取镜像,而是直接在目标主机上构建镜像,这样就绕过了这些防御机制。此外,攻击者通过在主机上构建基础结构来增加其持久性,镜像的名称及 ID 可能是随机生成的,并且对每个主机都是唯一的,这使防御者很难将镜像添加到受限列表中。在这种情况下,对恶意镜像的初步情报是无效的,不过基于行为模式的动态威胁分析(DTA)扫描程序可以帮助防御者检测这类攻击。

通常,针对配置错误的 Docker API 的攻击是通过从公共注册表(即 Docker Hub)中提取镜像并在目标主机环境上运行容器来发起的。该镜像通常是以下 3 个类型之一:

  • 由第三方建立的专用镜像。此镜像是为特定目的设计的,例如 xmrig/xmrig:latest 或 douglasslow/slowhttptest:latest,它们的目的是挖掘加密货币或在应用程序层中进行拒绝服务测试。
  • 攻击者构建的专用镜像。通常攻击者会通过使用一定的技术来隐藏镜像的恶意代码,但隐藏不是主要目的,攻击者会根据自己的需要设计攻击专用镜像。
  • 原始镜像。攻击者使用合法的原始镜像(例如 Alpine 或 Ubuntu)并在用户运行时使其下载恶意元素。

但在这次攻击中,攻击者使用 Docker SDK for Python 软件包将命令发送给配置错误的 Docker API,其攻击顺序如下:

  • 向 Docker 服务器发送 ping GET 请求,以检查 API 服务器是否公开。
  • 发送 GET 请求以接收主机上正在运行的容器列表。
  • 发送带有 Docker Build 命令的 POST 请求,以便在目标主机上创建镜像。
  • 发送 GET 请求以验证镜像是否已在目标主机上成功创建。
  • 发送 POST 请求以根据攻击者刚刚构建的新镜像创建一个容器。
  • 发送 GET 请求以接收主机上正在运行的容器列表。
  • 发送 POST 请求以运行容器。

这次恶意攻击说明了过去几年来针对云原生环境攻击的快速发展,也意味着我们需要更好也更强大的安全解决方案。据安全团队介绍,针对此类威胁的最佳解决方案是持续的动态威胁分析扫描,在 Docker Hub 和组织的服务器上动态扫描所有镜像,那些隐藏在云中的潜在威胁将会无所遁形。

https://blog.aquasec.com/

Istio 快速发展的 5 个理由

2017 年 5 月 24 日,IBM 和 Google 宣布推出 Istio,这是一种开源技术,使开发人员能够无缝连接、管理和保护不同微服务的网络。这里重点介绍 Istio 未来会继续快速发展的 5 个理由:

持续的可用性改进

在每个发行版中,社区都会听取用户的反馈并进行更改以简化 Istio 的使用。Istio 主要目标之一是:简单的场景应该简单明了,但复杂的场景也要能够使用。未来用户能够快速使用 Istio 服务网格:首先安装 Istio,再将其微服务加载到网格,然后加强微服务通信的安全策略,最后安全地大规模运行服务网格。现在,随着每个版本中可用性的不断提高,我们已经可以使用单个命令来安装 Istio,描述给定的 Kubernetes 服务或为 Istio 资源分析整个集群。现在使用 Istio v1.6,我们甚至不需要到istio.io去了解如何安装它。

社区内优秀的合作

Istio 项目提供强大的协作能力,在这种协作中,会有源源不断的创意涌出,为用户创建更好、更简单的解决方案。在社区的多元化发展下,Istio 可以得到更好的发展。现在,Istio 在 300 多家公司的 500 多个贡献者的共同支持下,持续在服务网格领域进行创新。

持续的创新

该项目的创新非常迅速,每周都有很多事情要做。例如,社区在 Istio v1.3 和 v1.4 中针对入站和出站流量实施了智能协议检测,尽管这个功能很棒,但会造成某些用户的性能问题,现在 Istio v1.6 直接使用 Kubernetes v1.18 Service 对象中的 appProtocol 字段来解决这个问题。

丰富的生态系统

Istio 生态系统十分丰富,多家厂商创建了基于 Istio 的最佳方案,多家云提供商提供了托管的 Istio 服务,以简化 Istio 控制平面的安装和维护。

Istio 美好的未来

Istio 社区致力于 Istio 的易于使用,并尽可能减少配置,最好是很少或零配置,最终使得用户能够将其服务部署到网格中,并在无干扰的情况下尽情享受 Istio 的好处。随着开发人员和运营商转向使用微服务的云原生平台,Istio 的采用率将会继续增加,用户也将突破 Istio 的界限,从在单个集群中采用 Istio,到跨多个集群或虚拟机运行服务。

https://sdtimes.com/softwaredev/guest-view-5-reasons-to-be-excited-about-istios-future/

常见的 5 个 K8s RBAC 错误

多年来,Kubernetes 社区已经提供了许多有效的安全功能,其中包括用于 Kubernetes API 的基于角色的访问控制(RBAC)。RBAC 是一项关键安全功能,它控制谁可以访问特定的 API 资源,从而保护集群。但在使用 RBAC 时,我们最好注意是否在在 RBAC 配置设置中,犯了以下五个最常见的错误。

授予了不必要的集群管理员角色

内置的集群管理员角色有效地授予了集群的无限访问权限。在从旧版 ABAC 控制器过渡到 RBAC 的过程中,一些管理员和用户可能通过 cluster-admin 广泛授予权限,忽略了相关文档中的复制 ABAC 许可配置的警告。如果和之前一样授予用户或组集群管理员权限,可能会成帐户泄露或错误,最终造成难以预料的风险。因此,我们应该仅将管理员权限授予真正需要的特定用户。

角色聚合使用不当

在 Kubernetes v1.9 和更高版本中,我们可以通过将新权限组合到现有角色中进行角色聚合以简化权限授予。但如果不仔细检查这些聚合,它们可能会更改角色的预期用途。

角色授予重复

角色定义可能会相互重叠,从而以多种方式为主体提供相同的访问权限。这种配置会使我们难以了解某个角色拥有哪些访问权限,而且如果管理员没有意识到多个角色被授予了相同的特权,会使访问撤销更加困难。

角色未使用

创建但未授予任何权限的角色会增加 RBAC 管理的复杂性,最好删除这些未使用或不活动的角色,将注意力集中在活动的角色上。

授予角色缺失

角色绑定可以引用不存在的角色。如果将来把具有相同名称的角色重新用于其他目的,那这些角色可能会突然向其他角色创建者授予特权。

8 个容器安全挑战

当前很多企业将应用程序部署在虚拟机(VM)或裸机服务器上,虽然容器基础结构的安全性在一定程度上保护了运行的主机和应用程序,但容器化也带来了一些必须解决的新挑战:

  • 容器启用微服务,增加了数据流量以及网络和访问控制的复杂性。
  • 容器依赖于基础镜像,因此要知道镜像是否安全。如果镜像包含漏洞,这些漏洞会传播到所有使用该漏洞镜像的容器。
  • 容器的寿命很短,因此监视它们(尤其是在运行时的容器)会非常困难,另外容器由于环境不断变化,也会缺乏相应的可见性。
  • 与 VM 不同,容器没有彼此隔离,单个受损容器可能导致其他容器受损。
  • 容器化环境具有比传统 VM 更多的组件。我们需要知道哪些部署或集群会受到高严重性漏洞影响;它们有没有暴露在互联网下;如果出现了漏洞,影响范围是多少;容器是在生产环境中还是在开发、测试环境中运行。
  • 容器配置是另一个会带来安全风险的因素。容器是否应该以高特权的身份运行?镜像是否启动了不必要的服务,从而增加了攻击面?Secret 是否存储在镜像中?
  • 合规性是一个特殊的挑战,在 Docker 环境中,许多用于合规性的传统组件(例如防火墙规则)会截然不同。
  • 最后,现有服务器工作负载安全解决方案并不完美,还无法完全应对容器安全挑战和风险。

本周开源项目推荐

Kubeletctl

  • 这是实现 kubelet API 的命令行工具,该工具涵盖所有已记录和未记录的 API,可以通过其查看 kubelet API 的完整列表。
  • github.com/cyberark/kubeletctl

kip

  • 这是一个虚拟 Kubelet 提供程序,它允许 Kubernetes 集群在云实例上启动 Pod。
  • github.com/elotl/kip

KubiScan

  • 它可以在 Kubernetes 的基于角色的访问控制(RBAC)授权模型中扫描 Kubernetes 集群以获取相应权限。
  • github.com/cyberark/KubiScan

ThreatMapper

  • 它可以用于识别正在运行的容器、镜像、主机和存储库中的漏洞。
  • github.com/deepfence/ThreatMapper

sinker

  • 它可以将容器镜像从一个注册表同步到另一个。
  • github.com/plexsystems/sinker

operator-lifecycle-manager

  • 这是用于通过 Operators 扩展 Kubernetes 管理框架的工具包。
  • github.com/operator-framework/operator-lifecycle-manager

推特被黑,数百人受骗

7 月 15 日,微软创始人比尔·盖茨的推特“发布”了一则消息:“到了我回馈社会的时候了。接下来的半小时内,我比特币账户收到的钱,都会双倍返还。”不光是他,美国前总统奥巴马、前副总统乔·拜登、全球首富杰夫·贝索斯、说唱歌手“侃爷”,以及巴菲特、埃隆·马斯克等亿万富豪的推特都发了类似消息。

在发布推文后的短短几分钟内,这些比特币帐户产生了 320 笔交易,收到了价值超 12 万美元的比特币。推特公司赶紧发布声明,承认检测到大范围内的推特被黑事件,并限制了认证账号的发推功能,以进一步调查。

虽然此次黑客入侵的动机和来源尚不清楚,但入侵世界领导人、名人和大公司已认证账户的做法令人不寒而栗。推特作为全球知名通讯机构,甚至会被各国政府用于官方信息往来,在紧急情况下,如果出现这样大规模的黑客攻击,必然会造成极大破坏性的后果。

原文请点击:https://mp.weixin.qq.com/s/Fx8ToBq3Vy46__vNrN9Khw