使用netfiltiptables保护网络2.docx
- 文档编号:30574405
- 上传时间:2023-08-16
- 格式:DOCX
- 页数:11
- 大小:24.86KB
使用netfiltiptables保护网络2.docx
《使用netfiltiptables保护网络2.docx》由会员分享,可在线阅读,更多相关《使用netfiltiptables保护网络2.docx(11页珍藏版)》请在冰豆网上搜索。
使用netfiltiptables保护网络2
课程名称
更安全的LINUX网络
教学对象
网络工程师专业
教材
更安全的LINUX网络
授课内容
防火墙的基本概念
课时
3(37-39)
教学目的
与要求
•熟悉防火墙规则定义
•掌握入侵与防御的其他注意事项
重点、难点
•熟悉企业网内部与因特网
•Dmz与因特网
•企业网内部与DMZ
课型
教学方法
教学过程
设计
(包括讲授知识、演示内容及案例、提问及学生演示内容)
第五章使用Netfilter/lptables保护企业网络
5.3防火墙规则定义
构建防火墙的目的在于提升企业网络的安全,然而一个安全的防火墙系统除了防火墙本身的质量之外,还需一个有计划且全盘性思考而规划出来的防火墙系统,才能真正用以维护企业网络的安全,因此,了解防火墙的特性及正确的思考逻辑将有助于设计出更符合企业需求的防火墙系统,至于Linux防火墙特性的部分,相信你应该都已了解。
接下来所要讨论的是,如何正确编写出防火墙规则,在此将其分成3个部分说明
企业内部与因特网
DMZ与因特网
企业内部与DMZ
在考虑企业内部与因特网之间的规划时,请以下列几个方面来考虑。
5.3.1企业内部与因特网
1.NAT规划的考虑
在规划NAT时,首先要选好一个私网lP的区段,如果目前企业已有分点(分公司).最好是系统地安排这些分点的lP网段,例如,我们可以把中国台湾分成北、中、南、东4个区域,北区为192.168,0.0/24-192.168.49.0/24、中区为192.168.50.0/24~192.168.99.0/24、南区为192.168.100.0/24~192.168.149.0/24、东区为192.168.150.0/24~192.168.200.0/24,至于该如何划分并没有一定的标准,只要方便管理及记忆就好。
或许你会有所疑惑,为什么要这样划分lP网段呢?
如果将所有分公司的内部网段都设定成192.168.0.0/24不是很好记忆吗?
之所以这样建议的考虑是因为分点与分点之间会有很大的机会将其网络连接起来;
例如,台中分公司要访问台北总公司的FileServer时,通过因特网将两个PrivatelP的网段连接起来,这样即可让台中分公司的使用者跨越因特网来访问台北总公司内的FileServer,而这虚拟私人网络你可以暂且将其想象为两个PrivatelP的网络之间在逻辑上以一台Router连接起来,因此,如果Router两边的网段相同.Router就无法正常提供Routing的功能,所以为了长久企业网络规划的考虑,每一个分点内部网络的PrivatelP区段最好不要一样,否则,以后可能会有不可预知的麻烦。
在lP区段选择好之后,接下来就是选择NAT的类型,如果没有特殊的因素,“一对多NAT"可能是最佳的选择,因为我们可以借助“一对多NAT”来节省PubliclP的浪费,又可以借助“一对多NAT"的特性来达到保护企业内部主机的目的。
2.防火墙的考虑——因特网与企业内部网络的考虑
防火墙可以用来保护企业服务网络,但别忘了,防火墙也可以用来限制企业内使用者所能访问的因特网资源。
例如,我们可以限制企业内部的使用者不得连接至的网站、不能使用FTP、不能使用MSN等,又或许我们可以考虑是否该规划一个ProxyServer等,关于这个问题,我们将分成3个面来讨论。
在考虑企业内部与因特网之间的规划时,请以下列几个方面来考虑。
1)由因特网到企业内部的考虑
关于这个方向的连接管制应该没有什么太大的考虑因素,我们只需要允许RELATED及ESTABLISHED两种状态的封包可以正常送回企业内部即可,其余的封包则一律丢弃掉。
2)由企业内部到因特网的考虑
关于这个方向的连接管制应该就企业本身的管理政策来考虑,有些企业可能会完全允许使用者连接到任何地方,而有些企业可能连网页的浏览都会限制。
因此,如果你希望当个人缘好一点的防火墙管理员,或许可以选择不要限制;如果你希望当个没有人情压力的防火墙管理员,那么你可以选择依照公司的政策来执行;如果你希望当个尽忠职守的防火墙管理员,那你就应该严格管制由企业内“主动”向外建立的连接。
3)ProxyServer的规划及考虑
构建ProxyServer可以有效缓解企业的外网“下载”带宽,而且ProxyServer具备URL的过滤机制,这是Netfilter所不及的地方,可见ProxyServer的构建是有其必要性的。
我们通常会以Netflter加上Proxy,并采取严格管制的方式,也就是只开放一般正常情况下会使用到的协议,例如,HTTP、HTTPS及某些特殊会用到的服务,其余的协议则一律不开放,这样不但可以借助Netfilter及Proxy来执行深度“过滤”动作,又可以享受CacheProxy所带来的网络“下载加速”效果。
另外,还可以搭配Netfilter的recent模块,以防范因为病毒感染而耗尽防火墙所能承受的最大连接数量。
5.3.2DMZ与因特网
这部分由于牵扯到企业对外服务器的安全性,因此,我们必须格外谨慎去思考,我们将其分成两个方面来讨论.
1.NAT的需求
在以往的防火墙规划中,通常是将ISP所给的lP网段切割成两半,例如,切割成两个1/2个ClassC,然后将1/2个ClassC放在防火墙外面,另外的1/2个ClassC放在DMZ上,但以目前因特网的使用情况来看,不可能再使用以前的规划方式了,因为PubliclP数量已快不够使用了。
以目前的状况来看,DMZ在规划上大多都是使用私网lP。
然后再以“一对一NAT”或是“NAPT”的方式将DMZ上的主机对应到PublicIP。
至于我们应该选用“一对一NAT”还是“NAPT”。
就得看我们实际所拥有的公网lP数量,以及实际需要的服务器数量来衡量,如果真实需求的服务器数量比所拥有的PubliclP数量还多,那么唯一的选择就是NAPT,如果PubliclP的数量大于等于所需服务器数量,我们的建议是尽量使用“一对一NAT’’,因为这在管理上比较不容易因疏忽而导致错误。
2.防火墙的考虑
当我们将NAT规划好之后,就等同于把DMZ内的主机放置在因特网上,因此,一定要设定适当的防火墙规则来保护DMZ内的主机,关于防火墙的规则设定,我们以图为例,并将其分成两个部分讨论。
1)因特网对DMZ内主机的访问
图中在DMZ上有ReverseProxy、MailServer及FTP/DNSServer这3部分,下面为我们思考逻辑下的产物。
首先依服务类型分别建立HTTP_SRV、MAIL_SRV、FTP_SRV及DNS_SRV这4个UserDefineChain
(2),并且把FORWARD的DefaultPolicy设定为DROP(3),为了以后ServerlP变更上的便利性,又分别为3部Server设定了lP变量,如Web_IP、MAIL_IP及FTP_IP(4),因为在DMZ上有FTPServer,而且FTPServer是以NAT的方式对应到网际网络,因此,我们必须将Filter及NAT处理FTP协议专用的模块加载系统(5)。
在(6)的规则中,我们把任何由因特网送到DMZ内且为INVALID状态的封包丢弃掉,而(7)的规则则是允许ESTABLISHED及RELATED状态的封包可以正常在因特网及DMZ之间穿梭;(8.9.10.11)规则是将每一条连接中的第一个封包分别导引到各项服务专属的UserDefineChain,再依不同协议的特性来加以限制,
(12.13.14.15)规则为对各个不同协议的限制,(12)为对HTTP及HTTPS的限制、(13)为对SMTP及POP3的限制、(14)为对FTP的限制、(15)为对DNS的限制;5.3.2DMZ与因特网(12.13.14.15)规则为对各个不同协议的限制,我们的想法是HTTP及HTTPS应该不会有客户端在60秒内连续对WebServer提出30次以上的连接请求动作,因此,限定60秒内有30次以下的服务请求动作是合理的,不过这60秒30次的频率也未必会符合你的需求,因此,请自行统计一下,当浏览WebServer时,每浏览一页大概会需要建立几条连接,你可以试着以Netfilter的LogTarget来记录,因为网页写法不同时,浏览一个网页所会建立的连接数量就会不一样;在MailServer的部分,我们所设定的频率为60秒5次、FTP则为60秒2次、DNSServer因为在其他的DNSServer上会有Cache的存留,因此,我们指定的是60秒1次。
2)DMZ内主机对因特网的访问
对于这个方向的服务请求动作基本上还是建议以“较严格”的方式来进行控制,我们的想法如下:
1.iptables-AFORWARD-ieth1-oeth0-picmp-d168.95.192.1-mstate--stateNEW-jACCEPT
2.iptables-AFORWARD-iethl-oeth0-ptcp-s$HTTP_SRV–mmultiport--sports80,443mstate--stateESTABLISHED-jACCEPT
3.iptables-AFORWARD-ieth1-oeth0-ptcp-s$MAIL_SRVmstate--stateESTABLISHED--sports110-jACCEPT
4.iptables-AFORWARDieth1-oeth0-ptcp-s$MAILSRV--dports25-jACCEPT
5.iptables-AFORWARD-ieth1-oeth0-ptcp-s$FTP_SRV-mstate--stateESTABLISHED,RELATED--sports21-jACCEPT
6.iptables-AFORWARD-iethl-oeth0-pudp-s$FTP_SRV–mstate--stateESTABLISHEDsports53-jACCEPT
5.3.2DMZ与因特网
规则1:
限定由DMZ对因特网的ICMP封包仅能传送至168.95.192.1主机,而我们这样限定的理由是,大多数的使用者都会以ping命令来测试网络是否断线,但如果我们完全不限制ICMP封包,当DMZ主机被植入木马程序时,木马程序就很有可能以ICMP封包将系统重要的信息转送到Cracker的系统上,因此,我们限制从DMZ送出的ICMP封包只能送到168.95.192.1主机上。
规则2:
对于WebServer主机对外传送封包的部分,我们并没使用NEW的状态,这与第一条规则有点不同,因为ICMP封包是由DMZ内主机“主动”对外引发的连接,因此是以NEW的状态来匹配,而WebServer的部分一定是由用户端对WebServer提出服务请求,WebService才会被动响应客户端,所以应该是使用ESTABLISHED的状态来进行匹配。
此外,因为担心WebServer上被植入木马而导致主机上重要的信息被泄露,我们仅允许WebServer使用TCPPort80及443来响应客户端。
规则3:
对于MaII_Server的控制部分就有点不一样了,首先我们讨论POP3服务的部分,在此我们依然是限定POP3服务仅能被动响应客户端,至于这样的考虑就不再重复说明了。
规则4:
第4条规则也是用来限制MallServer的,但这部分的写法比较特殊,为什么是匹配DestinationPort呢?
以图为例来解说SMTPService的工作流程,我们假设A公司的客户端要发一封电子邮件给B公司的使用者,首先用户端主机连接至A公司邮件服务器的TCPPort25①,并且把邮件传递给SMTPService,SMTPService会先将这封电子邮件存储于/var/spool/mqueue/目录下②,接着SMTPService会派生出另外一个SMTPDaemon③,而此时这个SMTPDaemon将扮演SMTPClient的角色,并且以系统给予的一个TCPPort为其传输Port,将这封电子邮件传送给B公司的邮件服务器④⑤。
从以上的流程可以看到,负责将电子邮件传送出去的Port并非TCPPort25.而是我们在第1章“防火墙的基本概念”中所提到的Dynamic(动态)Ports,其范围会落在Port49152~65535之间,因此,并无法事先得知SMTPDaemon会使用哪一个Port将电子邮件传送出去,所以笔者的做法是:
限定从SMTPService送出去的封包只能送到其他主机的TCPPort25。
从以上的流程可以看到,负责将电子邮件传送出去的Port并非TCPPort25.而是我们在第1章“防火墙的基本概念”中所提到的DynamicPorts,其范围会落在Port49152~65535之间,因此,并无法事先得知SMTPDaemon会使用哪一个Port将电子邮件传送出去,所以我们的做法是:
限定从SMTPService送出去的封包只能送到其他主机的TCPPort250
规则5:
这条规则的作用是限制FTP服务,除了Filter的模块及NAT的模块需要安装之外,其他的部分大致与WebService-样。
规则6:
这条规则是限制DNS名称解析服务,因此,除了协议的部分之外,其他的考虑大致与TCP服务没有太大的差异。
最后对于DMZ内的主机对因特网的HTTP服务请求动作,我们可以借助CacheProxy的控制来限定DMZ内主机可以通过HTTP协议访问因特网上的些主机,例如WindowsUpdateServer等。
5.3.3企业内部与DMZ
企业内部与DMZ的部分在一般环境下没有太大的问题需要考虑,一般的做法是允许企业内部可以对DMZ完全访问,而不允许DMZ内的主机“主动”对企业内部网络做访问动作,但是在图的范例中,因为使用了ReverseProxy的架构,因此此,我们必须开放ReverseProxy可以正常访问企业内部的WebServer,但只要适度开放即可。
5.4入侵与防御的其他注意事项
虽然我们已经把防火墙设计时该考虑的问题都加进去了,但关于系统入侵及弱点攻击就不是防火墙一定有办法防御的,这个问题在前面章节“4.4.5常见的网络攻击手法及防护方式”中已解说过,如果忘记了不妨回头复习一下,接下来,我们要讨论实务上的防御技巧。
5.4.1更新套件
如果Cracker攻击的是系统存在的弱点,因而导致系统被入侵或是宕机,这就不是防火墙一定有办法防御的,因此,软件套件的实时更新是绝对必要的,这不会因为你使用的是Linux系统或是Windows系统而有所不同。
5.4.2SynFlooding攻击防御
某些安全性问题,我们可以通过套件的更新来解决,但某些问题是无法通过套件更新来解决的,例如,在4.4.5节“常见的网络攻击手法及防护方式”中所提到的SynFlooding攻击,关于这个问题,虽然在前面防火墙的规则中已经使用recent模块对各项服务进行SynFlooding攻击的防御动作,但这样的防御机制并无法防御SynFlooding加上DDOS的攻击模式,为了达成更有效的SynFlooding防御动作,我们可以朝向两个方向来进行。
调整核心参数:
我们在4.4.5节“常见的网络攻击手法及防护方式”中曾提到3个核心参数,分别为net.IPv4.tcp_synack_retries、net.IPv4.tcp_max_syn_backlog及net.IPv4.tcp_syncookies,如果你已经忘记这3个参数的用途,那么请你翻至前面章节再复习一下。
如果我们的服务器是使用Linux操作系统,那么就可以往其上把这些参数给设定起来,这样即可提升防火墙“后端”服务器的SynFlooding防御能力。
运用我们的独家秘方:
调整核心参数虽然可以提升服务器本身SynFlooding昀防御能力,但如果SYN封包的量真的很大时,以上方法所能呈现的效果也是有限的,因此,我们的做法是丢弃TCP连接中的第一个SYN封包,因为TCP协议的特性会确保传送中的数据不会遗失,所以如果我们故意将第一个syn封包丢弃,那么在一段时间后,发送端一定会再重送一次SYN封包,而这段时间约3—5秒。
在了解这个特性后,我们再来看看DDOS+SynFlooding的攻击特性,当此类攻击发生时,攻击者会不断地伪造来源端lP,并对我们的服务器送出含有SYN标志的封包,因此,如果足DDOS的攻击封包,当我们将某个lP所送来的第一个SYN封包丢弃时,它应该就不会重送第二个syn封包
集合以上两个特性之后,我们以HTTP服务为例,将防火墙规则设计如下:
1.#!
/bin/bash
2.iptables–tfilter-F
3.modprobeipt_recentip_list_tot=16384
4.iptables-AFORWARD-ieth0-oeth1-ptcp--syn--dport80–mrecent--nameSYN_FLOOD--update--second120--hitcout1-jACCEPT
5.iptables–AFORWARD-ieth0-0eth1-ptcp--syn--dport80-m--recent--nameSYN_FLOOD--set
6.iptables-AFORWARD-ieth0-oeth1-ptcp--syn--dport80–jDROP
从以上的规则中,我们假设防御主机的eth0连接在因特网,而ethl则连接到WebServer;我们先看第4条规则,在这条规则中,我们匹配送到WebServer的SYN封包,如果以目前这个时间点往前推120秒,某个lP在SYN_FLOOD数据库中没有被记载,那么这个封包将不会符合这条规则,因此,这个封包会被送到第5条规则中进行匹配。
接着,这个封包的发送端lP会被记载到SYN_FLOOD数据库中,但别忘了recent模块的--set参数仅会做记录的动作,并不会对封包进行任何的处理动作,因此,这个封包接着被送入到第6条规则中匹配,而第6条规则就将这个SYN封包给丢弃掉。
不过,这个SYN封包的发送端信息已经被记载到SYN_FLOOD的数据库之中,因此,当这个发送端重新传递第2个SYN封包进来时,其将会符合第4条规则而被系统接受。
最后提醒你别忘了recent模块预设只会存储100笔信息,而SynFlooding攻击发生时,我们会需要记录更庞大的客户端信息,因此,我们在第3条规则中把recent棋块的记录笔数调整为16384,当然,如果你的外网带宽很大,我们建议你再加大这个值。
以上这个方法确实可以更有效地防御SynFlooding的攻击,不过,却也造成了另外更为头疼的问题,因为在以上规则中,不管SynFlooding的攻击有没有发生,任何HTTP连接中的第一个封包都会被丢弃掉,因此,客户端在浏览网页时,一定得多等一段封包重送的时间,虽然这时间只有3—5秒,却让人感到相当不舒服,特别是像我们这种追求完美的技术人员,所以想了又想,最后把防火墙的规则改进如下:
1.#!
/bin/loash
2.modprobeipt_recentip_list_tot=16384
iptables-NSYN_FLOODING
iptables-tfilter-F
iptables-AFORWARD
#=============================#
5.4.2SynFlooding攻击防御
7.iptables-AFORWARD-ieth0–oeth1-ptcp--syn--dport80-m--limitl/m--limit-burst300-jACCEPT
8:
iptables--AFORWARD-ieth0–oeth1-ptcp--syndport80-jSYN_FLOODIN
9.#==============================#
10.iptables-ASYN_FLOODING-ieth0-oeth1-ptcp--syn–dport80-mrecent--nameSYN_FLOOD--update--second120--hitcountl-jACCEPT
11.iptables-ASYN_FLOODING-ieth0-oeth1-ptcp--syn--dport80-mrecent--nameSYN--set
12.iptables-ASYN_FLOODING-ieth0-oeth1-ptcp--syn-jDROP
在以上规则中,我们将SynFlooding的防御规则放到SYN_FLOODING的UserDefineChain中,并在第7条规则中运用limit模块来判别系统是否遭受SynFlooding的攻击,判别的方式如下。
如果在60秒内“没有超过”300个SYN封包进来,即表示系统并没有遭受SynFlooding的攻击。
如果在60秒内“超过”300个SYN封包进来,那么系统正遭受SynFlooding的攻击,此时进入的SYN封包并不会符合第7条规则,而是会符合第8条规则,所以这些SYN葑包将会被送入到SYN_FLOODING的UserDe6neChain进行匹配。
从以上规则来看,如果系统没有遭受SynFlooding攻击,所有的SYN封包将会符合第7条规则而送到WebServer但如果系统遭受SYNFlooding攻击,除了limit模块l/m参数部分每60秒可以进入一个SYN封包(由于limit模块语法的限制,不然0/m会更好),以及SynFlooding攻击刚开始发生的前300个SYN封包之外,其余的每个发送端所送来的第一个SYN封包都会被recent模块丢弃掉;我们可以发现,以上规则在平常情况下并不会延迟到任何的TCP连接时间,而在SynFlooding攻击发生时,又能实时地帮我们滤除掉SynFlooding的攻击行为。
以上为我们独家用来防御SynFlooding攻击的方式,如果你有兴趣,不妨将其加入到你的防火墙中,就算我们为你的防火墙尽份心力。
5.4.3lP欺骗防护
在设定防火墙规则时,经常忽略掉lP欺骗攻击的问题,什么是lP欺骗呢?
我们以图为例来说明lP欺骗攻击。
首先请教你一个问题,如果图中防火墙的规则为iptables-AFORWARD-ieth0-pall-s192.168.1.10-jDROP,请问Cracker在192.168.1.10主机上能不能将攻击封包送到192.168.2.50主机上?
以上这个问题是肯定的,因为Cracker只要伪造来源端lP即可轻易骗过防火墙,而将攻击封包注入192.168.2.50主机,因此当我们在设计防火墙规则时,请留意下列几种特定的来源端IP。
LocalhostlP:
在lP欺骗的攻击中,1
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 使用 netfiltiptables 保护 网络