Board logo

标题: 有状态的防火墙与基于OVS流规则的防火墙 [打印本页]

作者: linda    时间: 2015-11-28 20:51     标题: 有状态的防火墙与基于OVS流规则的防火墙

作者:张华  发表于:2014-08-19
版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明
(http://blog.csdn.net/quqi99 )
理论部分
例:允许内网用户访问公网的web服务,如果采用包过滤的无状态的防火墙技术的话,应该是:
序号  动作   源地址    源端口   目标地址   目标端口   方向
1     允许     *         *         *         80                                  出
2     允许     *         80        *       1024-65535                进

因为本地的端口是随机生成的,所以要把1024到65535的端口都打开,多危险啊。
所以有一些防火墙又根据TCP连接中的ACL位值来决定数据包进出,但这容易引发拒绝服务DoS攻击,何况UDP还没有ACL标志位了。

有状态的防火墙是什么呢?
只需要上述的防火墙规则1, 不需要规则2(状态防火墙只定义出站规则就好,不需要定义入站规则)。当用户打开浏览器访问那个web服务时,当数据包到达防火墙时,状态检测引擎会检测到这是一个发起连接的初始数据包(由SYN标志),然后它就会把这个数据包中的信息与防火墙规则作比较,如果没有相应规则允许,防火墙就会拒绝这次连接,当然在这里它会发现有一条规则允许我访问外部WEB服务,于是它允许数据包外出并且在状态表中新建一条会话,通常这条会话会包括此连接的源地址、源端口、目标地址、目标端口、连接时间等信息,对于TCP连接(只针对TCP,对UDP创建模拟的虚拟连接, 对ICMP无效),它还应该会包含序列号和标志位等信息。当后续数据包到达时,如果这个数据包不含SYN标志,也就是说这个数据包不是发起一个新的连接时,状态检测引擎就会直接把它的信息与状态表中的会话条目进行比较,如果信息匹配,就直接允许数据包通过,这样不再去接受规则的检查,提高了效率,如果信息不匹配,数据包就会被丢弃或连接被拒绝,并且每个会话还有一个超时值,过了这个时间,相应会话条目就会被从状态表中删除掉(这也就是为什么有一些客户端软件去访问防火墙背后的服务端时,如果客户端不定时去发一条信息连一下服务器的话,服务器就无法再给客户端主动发消息了,因为状态会话已经超时被删除了)。
就上面外部WEB网站对我的响应包来说,由于状态检测引擎会检测到返回的数据包属于WEB连接的那个会话,所以它会动态打开端口以允许返回包进入,传输完毕后又动态地关闭这个端口,这样就避免了普通包过滤防火墙那种静态地开放所有高端端口的危险做法,同时由于有会话超时的限制,它也能够有效地避免外部的DoS攻击,并且外部伪造的ACK数据包也不会进入,因为它的数据包信息不会匹配状态表中的会话条目。

Iptables中的有状态
现在我们来解释一下状态
NEW:如果你的主机向远程机器发时一个连接请求,这个数据包状态是NEW.
ESTABLISHED:当联接建立之后,远程主机和你主机通信数据状态为ESTABLISHED
RELATED: 像ftp这样的服务,用21端口传送命令,而用20端口(port模式)或其他端口(PASV模式)传送数据。在已有21端口上建立好连接后发送命令,用20传送的数据,状态是RELATED

1, 默认规则,对所以进入你机器的数据都丢弃,iptables -P INPUT DROP
2, 禁止其他机器主动发起对你机器的连接,但你却可以主动的连接其他机器, 这条可以省去由默认规则处理,iptables -A INPUT -m state --state NEW -j DROP
3, 当你主动连接其他机器之后,再进来的数据就是ESTABLISHED状态了,iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
4, 接下来如果你的机器提供pasv模式的ftp服务(会使用动态的端口来传送数据,这对于有状态的防火墙轻易做到,甚至不用知道它用了哪些端口,因为它会认识到这些数据是RELATED的),
iptables -A INPUT -i ppp0 -p tcp -dport 21 -j ACCEPT
iptables -A INPUT -i ppp0 -p udp -dport 21 -j ACCEPT
两条命令就解决了内部用户上网收发E_mail、浏览网页、使用msn聊天等需求
#iptables –A FORWARD –i eth0 –p tcp –m multiport --dports 25,80,110,443,1863 –j ACCEPT
#iptables –A FORWARD –i eth0 –p udp --dport 53 –j ACCEPT


数据流向
1, 第一个出去的数据包,也就是SYN报文,会标记为NEW状态(cat /proc/net/ip_conntrack | grep tcp)
tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1
udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1
ICMP包有很多类型,但只有四种类型有应答包(因为它是无状态协议,只是用来控制而不是用来建立连接的),回显(如下面的[UNREPLIED])比较常用。
icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 type=0 code=0 id=33029 use=1
2, 服务端也有数据过的话,会收到SYN_RECV包。
tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1
注意,对于UDP包,将[UNREPLIED]删除就代表收到从服务端发过来的数据啦
udp 17 160 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1
3, 接下来,TCP三次握手后变成ESTABLISHED状态
tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1
UDP没有三次握手也就没有ESTABLISHED状态,但[ASSURED]表示数据正在传输
udp 17 179 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 [ASSURED] use=1

Openvswitch中的有状态流规则
Openvswitch目前不支持有状态流规则,要等到2015年ovs中才可能有connection tracking特性。所以现有使用ovs流规则防火墙代替iptables防火墙的话功能还不完善。
1, 对于TCP, 所以它现在可能临时通过为无状态的添加tcp_flags=ack来实现上述说的可能会造成QoS攻击的有状态方案。
2, 对于UDP和ICMP,通过无状态的流规则显示指定,使用—source-port-range-min, —source-port-range-max,—port-range-min, —port-range-max来减少流规则条目。
neutron中OVSFirewallDriver的实现流程:
* drop all packets by default
* prevent IP spoofing based on port's mac address (compatible with allowed_address_pairs extension)
* handles ARP, DHCP, ICMPv6 RA
* convert security group rules to OVS flows (IPv4, IPv6, TCP, UDP, ICMP, ICMPv6)
* single TCP/UDP port per OVS flow

参考:
[1], https://review.openstack.org/#/c/89712/6/specs/juno/ovs-firewall-driver.rst
[2], http://os.51cto.com/art/201108/285209.htm

原文:http://blog.csdn.net/quqi99/article/details/39401457




欢迎光临 中神通公司技术论坛 (http://trustcomputing.com.cn/bbs/) Powered by Discuz! 6.0.0