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在流量控制中做了一些工作,可参见这篇文章

Leave a Comment

Your email address will not be published. Required fields are marked *