Hardening OpenStack Cloud Platforms against Compute NodeCompromises, AsiaCCS’16 (C类), 2016年5月[1] 

1. 背景

美国石溪大学和AT&T实验室的研究人员针对OpenStack云平台的安全性进行了研究。OpenStack云平台主要由Controller节点和Compute节点组成。由于Compute节点数目众多，并且上面运行虚拟机（可能是恶意的），难以保证其中某些Compute节点不被攻击者攻破。本文发现，一旦攻击者拿到一个Compute节点的权限（如通过VM Escape攻击），则相当于拿到整个云平台的Admin权限。为了克服这个问题，文章提出了一个称为SOS（Secure OpenStack）的安全策略框架。SOS采用基于权能和MAC策略来限制不同OpenStack模块之间的交互。本文架构适用于不同版本的OpenStack平台（Havana, IceHouse, Juno），并且时间开销在可接受的范围内。

SELinux也是一个著名的安全策略框架，但是它需要人工编写策略，并且很容易产生误报。而OpenStack是个快速迭代的开源项目，组件众多，人工编写策略不易。因此SELinux不适用于本文场景。本文提出的SOS框架利用训练和静态分析的技术可以自动生成策略，并保持较低的误报率（在20次Tempest训练后，误报率低于0.02%）。

2. 贡献

本文提出了一种OpenStack攻击方法。通过攻破一个Compute节点，能实现对所有Tenant访问Token的窃取，甚至窃取管理员Token，从而获得整个云的权限。

本文同时提出了SOS的安全策略框架，可以防御上面提到的攻击。

3. 场景

本文采用3节点模式，部署了4台机器。分别是controller，network，compute1和compute2。安装的OpenStack服务是Keystone，Nova，Glance，Neutron，Cinder，采用QEMU作为虚拟机管理器。OpenStack云平台里有两个租户：tenant1和tenant2。Compute1节点是被攻破的节点。

1）  首先攻击者所在的Compute1节点上是可以访问消息队列MQ的，上面默认没有很好的访问控制。攻击者可以创建一个routing-key为#的队列，从而使整个MQ服务器上所有的RPC消息全部都转发到compute1节点上。这些消息上可以提取出token和customer-id。利用这个tenant1的token，则可以以tenant1的身份进行其所拥有资源（虚拟机、磁盘、网络）的CRUD操作。更严重的是，管理员Admin的token也是可以被监听的，这样攻击者就拥有了管理员权限。

2）  RPC消息本身是key-value对，在RPC消息中，key是方法名，而value是方法参数。攻击者通过在Compute1人工构造RPC消息，如：routing- key=compute.compute2and method=reboot_instance，uuid=VM1 on compute2，则不需要任何token，即可重启Compute2节点上的VM1。

3）  更严重的是，如果攻击者在RPC消息中指定_context_is_admin=true，则直接可以以Admin的身份发送RPC消息，而无须提供任何Admin token。

4. SOS框架

1）本文对MQ的安全加固方案如下图所示。

增加了PolicyEnforcer和Private MQ Server来对RPC消息进行过滤。

 

2）本文对Rest API的安全加固方案如下图所示。

将Token进行了权限的限制，高权限Token可以生成低权限Token。这样Controller节点就可以只把低权限Token提供给Compute节点，进行具体操作。即使被攻击者拿到，也不会造成太大损害。

5. 实验

本文对SOS框架进行了实验，实验结果表明，SOS框架引入的时间开销不到1.3%。并且其在20次Tempest训练后，误报率低于0.02%

 

 

6. 专家观点

本文的实用价值比较高，提出了一种切实可行的OpenStack云平台的攻击方式，并同时提供了防御框架。不足之处在于，其攻击的门槛较高，需要提前攻破一个Compute节点，因此无法直接用来攻击。总体来说，是一个较为完整的工作。

7. 参考文献

[1] Sze, Wai Kit, Abhinav Srivastava, and R. Sekar."Hardening OpenStack Cloud Platforms against Compute NodeCompromises." (2016).