Openstack中伪造源地址攻击的防御

背景：Openstack在H版之前的时候，租户可以租用虚拟机发动DoS攻击，很多攻击的方式是伪造源地址。还有别的攻击，如ARP攻击等等，都是通过伪造源MAC或IP地址实现的。本文简单介绍一下openstack中抵御虚假源地址的攻击。

这种攻击的特点是攻击者从虚拟化系统内部发起，攻击目标可能是公网主机，或者是内网的主机。对于前者的防御比较容易，只需要在物理网络边界就可以部署安全设施进行检测和清洗；但是后者的攻击流量大部分是存在于虚拟网络和虚拟网络设备中，物理的安全设备是无法观测或理解物理网络中的流量，无法进行有效的防护，所以对于始于内部的DoS攻击，应该在虚拟化环境中将检测并抵御。
在Openstack的架构下，预计一种检测DoS攻击的方式是依靠检测模块Ceilometer，等它成熟之后，就可及时通知管理员或系统，通过Ceilometer与Neutron协作堵住这种攻击。
不过现在Ceilometer还在初级阶段，所以还是需要依靠网络虚拟化模块Neutron进行防护，好在IaaS系统知道VM的真实IP和MAC，所以可以直接在L2防火墙上对数据包进行过滤，H版已经引入了这部分特性。

下面以一台vm为例：
# neutron port-list|grep 100.0.0.16
| 368d35e1-4db7-405f-af26-1f2b6f224bd8 | | fa:16:3e:34:c8:f8 | {“subnet_id”: “57b30eb5-e9ee-489f-85ea-77bcaa6249e5”, “ip_address”: “100.0.0.16”} |

2013.2.1引入了基于IPTABLES的过滤方案
iptables -L -nvx 可以看到：
Chain neutron-openvswi-s368d35e1-4 (1 references)
pkts bytes target prot opt in out source destination
212 29180 RETURN all — * * 100.0.0.16 0.0.0.0/0 MAC FA:16:3E:34:C8:F8
0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0
此处允许真实IP和mac的数据包经过，对其他数据包抛弃

2013.2.2 引入了基于EBTABLES的过滤方案
ebtables -t nat -L 可以发现下面项
Bridge chain: libvirt-I-tap368d35e1-4d, entries: 6, policy: ACCEPT
-j I-tap368d35e1-4d-mac
-p IPv4 -j I-tap368d35e1-4d-ipv4-ip
-p IPv4 -j I-tap368d35e1-4d-ipv4
-p ARP -j I-tap368d35e1-4d-arp-mac
-p ARP -j I-tap368d35e1-4d-arp-ip
Bridge chain: I-tap368d35e1-4d-mac, entries: 2, policy: ACCEPT
-s fa:16:3e:34:c8:f8 -j RETURN
-j DROP
Bridge chain: I-tap368d35e1-4d-ipv4-ip, entries: 3, policy: ACCEPT
-p IPv4 –ip-src 0.0.0.0 –ip-proto udp -j RETURN
-p IPv4 –ip-src 100.0.0.16 -j RETURN
-j DROP
Bridge chain: I-tap368d35e1-4d-arp-mac, entries: 2, policy: ACCEPT
-p ARP –arp-mac-src fa:16:3e:34:c8:f8 -j RETURN
-j DROP
Bridge chain: I-tap368d35e1-4d-arp-ip, entries: 2, policy: ACCEPT
-p ARP –arp-ip-src 100.0.0.16 -j RETURN
-j DROP
可见确实将VM的mac和ip进行了过滤，防止其他ip和mac的数据包经过

虽然这种防护可以抵御伪造源地址的攻击，但是无法抵御使用真实源地址的DoS攻击,遇到这种情况，还是采用ceilometer或是SDN的流检测的方式较好。

p.s.1 为什么我会知道这些Openstack版本的防护特性，我会告诉你这些特性让我不能测试DDoS攻击吗…
p.s.2 除了IPTABLES和EBTABLES之外，还有没有其他方法？当然有，设想一下这个场景，VM启动之后，neutron在建立port之后向SDN网络控制器发送通知，网络控制器向OVS发送流指令，允许IP、MAC绑定数据流通过VM所在的交换机端口，然后禁止其他数据流从该端口通过。那为什么不这么做呢，原因1：需要SDN控制器，原因2：数据流先经过Linux bridge，所以不如直接在Linux bridge上应用IPTABLES和EBTABLES。
p.s.4 在SDN+Openstack环境下，租户发起的DoS的第一个受害者将是网络控制器，所以Floodlight在流量控制中做了一些工作，可参见这篇文章。