使用Anthos防止容器恶意软件

TL;DR there is a fairly new attack campaign using the Kinsing malware targeted at container platforms like Docker and GKE. This post will show you how to protect your infrastructure with Google Cloud’s Anthos both on prem and in the cloud.

TL; DR出现了一个针对Kinsing恶意软件的相当新的攻击活动，该恶意软件针对Docker和GKE等容器平台。 这篇文章将向您展示如何在本地和云端使用Google Cloud的Anthos保护您的基础架构。

Last Friday, research from Aqua Security came out showing that the Kinsing malware has been used recently in a campaign against Docker Daemon APIs to the end of launching a Bitcoin miner and self-propagating. Anthos GKE offers several security features that can be used to protect your enterprise from such threats. We’ll start by analyzing the attack tree for this campaign, taken from the linked Aqua blog.

上周五， 来自Aqua Security的研究表明，最近在针对Docker Daemon API的运动中使用了Kinsing恶意软件，直到启动比特币矿工和自我传播结束。 Anthos GKE提供了多种安全功能，可用于保护您的企业免受此类威胁。 我们将从分析此活动的攻击树开始，该攻击树取自链接的Aqua博客。

Source: https://blog.aquasec.com/threat-alert-kinsing-malware-container-vulnerability

资料来源： https : //blog.aquasec.com/threat-alert-kinsing-malware-container-vulnerability

背景 (Background)

The attack tree shows a few basic steps that we’ll address, as well as some other vectors that are not used in this attack.

攻击树显示了我们将要解决的一些基本步骤，以及此攻击中未使用的其他一些媒介。

1. Bypass API Security
   绕过API安全性
2. Download, launch and run a script
   下载，启动并运行脚本
3. Add itself to cron job for persistence
   将自己添加到cron作业中以保持持久性
4. Lateral movement via SSH
   通过SSH横向移动
5. Command & Control
   命令与控制
6. Crypto mining
   加密采矿

保护容器API (Protecting Container APIs)

While there are specific protections that Docker customers can use to protect their APIs, our goal will be to talk about the protections Anthos GKE can offer. In the top node, the attacker first makes use of an open control plane. The research does not go into details as to whether these were actually authenticated or not, but let’s assume they were at best weakly authenticated. Anthos GKE allows admins and users to authenticate with Google Identity or GSuite on top of the traditional means of authentication into Kubernetes. This is strong authentication that can not only be configured to require MFA but also audited using Cloud Operations (formerly Stackdriver). GKE’s control plane can also be configured to be completely private to your internal VPC or on-prem network. This is highly recommended on top of authentication with Cloud Identity to reduce the attack surface.

尽管Docker客户可以使用特定的保护措施来保护其API，但我们的目标是谈论Anthos GKE可以提供的保护措施。 在顶层节点，攻击者首先利用开放式控制平面。 该研究没有详细介绍这些认证是否真正经过验证，而是让我们假设它们充其量是经过弱认证的。 Anthos GKE允许管理员和用户在对Kubernetes进行身份验证的传统方式之上，通过Google Identity或GSuite进行身份验证。 这是一种强身份验证，不仅可以配置为需要MFA ，还可以使用Cloud Operations(以前称为Stackdriver)进行审核。 还可以将GKE的控制平面配置为内部VPC或本地网络完全私有。 强烈建议使用Cloud Identity进行身份验证，以减少攻击面。

保护运行时 (Protecting the Runtime)

In Anthos Config Management (ACM), there is the concept of a Policy Controller which can limit the properties of the pods that run in your GKE environment using constraints. These constraints use a policy as code language call Rego which is highly extensible and testable to allow full control over the privileges your pods have. The Gatekeeper policy library is shipped with ACM to give you a baseline to start working with. Specifically this malware searched bash history, known hosts, etc. to find hosts that the compromised container has SSH’d to. Using the host-network-ports policy you could enforce that containers of a particular type are only accessible by certain ports, and SSH port 22 should not be one of them. The idea here is to scope each container to the least privilege it needs to function.

在Anthos Config Management(ACM)中，有一个策略控制器的概念，它可以使用约束来限制在GKE环境中运行的Pod的属性。 这些限制使用作为代码语言调用Rego的策略，该策略具有高度可扩展性和可测试性，可以完全控制您的pod所拥有的特权。 Gatekeeper策略库随ACM一起提供，为您提供开始使用的基准。 具体来说，此恶意软件搜索了bash历史记录，已知主机等，以查找受感染的容器已通过SSH发送至的主机。 使用host-network-ports策略，您可以强制特定类型的容器只能通过某些端口访问，而SSH端口22不应是其中之一。 此处的想法是将每个容器的作用域限定为运行所需的最小特权。

While these policies ensure host-level control, it is also recommended to scope network access to other containers using the principle of least privilege as well. Kubernetes provides Network Policies for precisely this purpose. On top of that Anthos Service Mesh gives the ability to mutually authenticate and encrypt all data in transit and create application-level policies. What this means is even if a pod is compromised and runs a script to access other pods, it would not matter since access to other Service Mesh resources would be at the HTTP/Application level, not the network level. At the network level you can also configure a whitelist of allowed IPs to egress to within your service mesh so contacting command and control servers would not be possible. To be clear you can use both application/HTTP-level and network-level controls within Anthos GKE, but if you must choose between the two, application-level provides more control.

虽然这些策略确保了主机级别的控制，但也建议使用最小特权原则将网络访问范围限制到其他容器。 Kubernetes为此提供了网络策略 。 最重要的是， Anthos Service Mesh能够相互认证和加密传输中的所有数据并创建应用程序级策略 。 这意味着即使某个Pod被入侵并运行脚本来访问其他Pod，也没关系，因为对其他Service Mesh资源的访问将是HTTP / Application级别，而不是网络级别。 在网络级别，您还可以配置允许的IP白名单，以将其发送到服务网格内，这样就无法联系命令和控制服务器。 为了清楚起见，您可以在Anthos GKE中同时使用应用程序/ HTTP级别和网络级别的控件，但是如果必须在两者之间进行选择，则应用程序级别可以提供更多的控件。

While this particular malware did not specifically use cloud resources, following the principle of least privilege means we also downscope access to cloud resources as well as network resources. In Anthos GKE, Workload Identity allows each pod to connect to their own individual Google service account for fine-grained access to GCP resources.

尽管此特定恶意软件没有专门使用云资源，但遵循最小特权原则意味着我们还缩小了对云资源以及网络资源的访问范围。 在Anthos GKE中， Workload Identity允许每个Pod连接到各自的Google服务帐户，以实现对GCP资源的细粒度访问。

保护供应链 (Protecting the Supply Chain)

Even if the Kubernetes Master API is secured from direct access by malicious actors launching containers, there is still the threat of compromise to the supply chain. That is, if the container repository was compromised and someone pushed a malicious image that passed some policies that are in place, that container could still be deployed to a pod. Using Anthos GKE BinAuthz, you have the option to sign containers with Grafeas after they pass automated tests in the CI/CD pipeline and verify those signatures before deploying them to your clusters. This control dramatically reduces risk combined with ACM policies that can enforce the host-level abilities of the container.

即使Kubernetes Master API受到防止恶意行为者启动容器直接访问的保护，仍然存在威胁供应链的威胁。 也就是说，如果容器存储库遭到破坏，并且有人推送了恶意镜像，该恶意镜像通过了一些适当的策略，则该容器仍可以部署到Pod。 使用Anthos GKE BinAuthz时 ，您可以选择在Grafeas通过CI / CD管道中的自动测试之后，使用Grafeas对容器进行签名，并在将这些签名部署到您的集群之前验证这些签名。 该控制与可强制执行容器的主机级功能的ACM策略相结合，可大大降低风险。

In many cases, third party containers must be used where you cannot necessarily control the patch management or have deep insight into the potential vulnerabilities. In cases like this, GKE Sandboxes can be used to launch pods into an effectively jailed environment where kernel calls are limited.

在许多情况下，必须使用第三方容器才能避免必须控制补丁程序管理或对潜在漏洞的深入了解。 在这种情况下，可以使用GKE沙箱将Pod启动到内核调用受到限制的有效监禁环境中。

确保可观察性 (Ensuring Observability)

We would be remiss to not mention that these controls may protect your environment from known threats, but attackers are constantly becoming more sophisticated. A robust strategy for observability within your clusters is paramount. Within Anthos GKE, data is shipped to Cloud Logging and Cloud Monitoring for making informed decisions about potential novel threats in your infrastructure. With proper logging and monitoring, teams can be alerted to attempts at Bitcoin mining or other malicious activities based on anomalous CPU utilization and other indicators. The combinations of these controls create a defense in depth strategy that can mitigate the threat of external or even internal malicious activity.

不用说这些控件可以保护您的环境免受已知威胁的影响，但我们会感到遗憾，但是攻击者正在变得越来越复杂。 群集中的可观察性的可靠策略至关重要。 在Anthos GKE中，数据被传送到Cloud Logging和Cloud Monitoring，以就基础架构中潜在的新型威胁做出明智的决策。 通过适当的日志记录和监控，可以根据异常的CPU使用率和其他指标向团队发出警报，提醒他们尝试进行比特币挖矿或其他恶意活动。 这些控件的组合可创建深度防御策略，可以减轻外部甚至内部恶意活动的威胁。

下一步： (Next Steps:)

• Read more about Anthos GKE

  阅读有关Anthos GKE的更多信息

• Anthos Service Mesh

  Anthos服务网

• Anthos Config Management

  Anthos配置管理

• Spin up an Anthos Deployment in GCP

  在GCP中启动Anthos部署

翻译自: https://medium.com/@jryancanty/protection-from-container-malware-with-anthos-d035b5818eac