对OpenStack安全加固以应对来自Compute节点的攻击

本文链接：https://blog.csdn.net/hsluoyc/article/details/51596646

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。