防火墙为什么要对多连接协议进行特殊处理

无忧老猪 2011-01-10

本文档的Copyleft归yfydz所有,使用GPL发布,可以自由拷贝,转载,转载时请保持文档的完整性,严禁用于任何商业用途。

msn:yfydz_no1@hotmail.com

来源:http://yfydz.cublog.cn

1. 多连接协议
 
所谓多连接协议是指在协议完成过程中,除了一个主的通信通道(主连接)外,还会动态打开一些通道(子连接)进行通信,防火墙对这些协议需要特别处理才能保证安全。
多连接协议也可分为强制子连接和非强制子连接,强制子连接是指子连接的建立是必须的,不建立子连接通信将无法正常进行,如FTP;非强制子连接是指子连接的建立不是必须的,主连接先尝试用动态端口打开子连接,如果子连接打不开,则数据依旧在主连接中传输,这样不影响总体协议通信的完成,如 MMS、MSN传递文件等。对防火墙来说,处理的重点前者,因为后者在防火墙上可以不用作特殊处理。本文若不特殊说明,都是指前者。
 
2. 多连接协议的特殊处理
 
多连接协议的特殊之处就在于其之连接的端口通常是动态的,具体值是在协议内容中协商确定,而一般防火墙的策略中只允许有限的端口通过,端口全部开放是很危险的,所以早期的包过滤防火墙,对于FTP协议的支持只能支持主动模式,也就是服务器端数据端口固定为20时的情况,被动模式不支持或只能通过打开全部端口来支持。
 
在状态检测防火墙中,防火墙不仅对IP/TCP头信息进行处理,对多连接协议这种特殊协议进一步进行了内容级跟踪处理,能够自动查找协议通信数据中关于端口协商的部分,提取出具体的端口值,然后动态打开防火墙上的端口,使子连接数据能顺利通过防火墙,当子连接结束时,防火墙相应端口又自动关闭,保证了网络的安全性。
 
3. NAT模式下的处理
 
在NAT模式下,防火墙需要作的工作要更多一些,不仅要找到关于子连接端口的描述字段,还需要根据情况修改数据内容,但有些情况又不需要,如 FTP协议,内部网络通过源地址转换访问外部FTP服务器,但使用主动模式传数据时,子连接是从服务器连向客户端,这时需要对数据内容进行修改;而使用被动模式时,子连接是从客户端连向服务器,此时防火墙只需要跟踪而不需要修改数据。
 
进行数据修改时,防火墙先要找到自身一个空闲的端口代替数据描述中的端口值,然后如果数据中包括IP地址地址信息的话,将IP地址信息换自己的地址,修改后的数据长度可能和原来的数据长度不同。
 
对于UDP协议,数据内容修改后,如果数据长度变化,需要修改UDP头部中的数据长度,UDP端口,IP包总长,然后重新计算UDP校验和,IP头校验和,基本和后续包无关。
 
对于TCP协议,情况就麻烦得多,如果数据长度变化,需要修改TCP端口,IP包总长,然后重新计算TCP校验和,IP头校验和,最麻烦的是对该TCP连接的所有后续包都要修改TCP包头中的序号号或确认号,所有校验和也需要重新计算,如果后续包继续有数据长度变化,这种变化也要累加。只有数据长度不改变的情况下才和后续包无关,只要修改当前包的数据就行。
 
4. Linux内核中的实现
 
在linux内核的netfilter架构中,实现了对特殊协议的跟踪和NAT功能,并可以任意扩展,代码在net/ipv4 /netfilter目录下,ip_conntrack_core.c, ip_conntrack_helper.c, ip_conntrack_standalone.c为基本的连接跟踪程序,ip_nat_core.c, ip_nat_helper.c, ip_nat_standalone.c中为NAT的基本处理程序,对于特定协议,由ip_conntrack_*.c和ip_nat_*.c构成,“*”可以为ftp, tftp, irc等,程序构架都是类似的,可以扩展新的协议。
 
5. 安全性
 
这种打开动态端口的处理在安全性方面已经提高了很多,但如果不注意还是会有些问题,如在连接信息中如果有IP地址信息,一定要验证此IP地址就是数据包发送方的地址,否则可能会打开的是到其他机器的端口,相当的危险,netfilter早期的FTP代码中就有这个问题。在phrack63的 0x13号文件中,描述了如果防火墙同时跟踪FTP和IRC服务时穿透防火墙的一种方法,因此跟踪程序一定要区分关于数据端口的描述是否是在主连接中还是在子连接中,只在主连接中进行解析,如果是子连接,这种数据模式是不解析的。
 
6. 总结
 
多连接协议的支持对状态检测防火墙来说需要特别处理,对于公开的协议,可以根据其协议规范来定制专门的支持模块,而如果协议是保密,对防火墙来说就无法处理了。现在很多新的协议也考虑到了这个问题,在子连接不能打开的情况下还用主连接来传输数据,从而避免了该协议不能被防火墙支持。

相关推荐

老谢的自留地 / 0评论 2020-05-31
yshlovelx / 0评论 2020-04-18