Iptables 指南 1119中文版四.docx

上传人:b****7 文档编号:10166058 上传时间:2023-02-09 格式:DOCX 页数:28 大小:138.78KB
下载 相关 举报
Iptables 指南 1119中文版四.docx_第1页
第1页 / 共28页
Iptables 指南 1119中文版四.docx_第2页
第2页 / 共28页
Iptables 指南 1119中文版四.docx_第3页
第3页 / 共28页
Iptables 指南 1119中文版四.docx_第4页
第4页 / 共28页
Iptables 指南 1119中文版四.docx_第5页
第5页 / 共28页
点击查看更多>>
下载资源
资源描述

Iptables 指南 1119中文版四.docx

《Iptables 指南 1119中文版四.docx》由会员分享,可在线阅读,更多相关《Iptables 指南 1119中文版四.docx(28页珍藏版)》请在冰豆网上搜索。

Iptables 指南 1119中文版四.docx

Iptables指南1119中文版四

Iptables指南1.1.19(中文版)(四)

非常不错的iptables帮助指南,值得学习和收藏

转fromhttp:

//iptables-

Chapter7.防火墙配置实例rc.firewall

在本章里,我们将要建立一个防火墙,并且详细地说明了如何去阅读、理解它。

在这个例子中,我们使用的是最基本的配置,对其工作方式和我们在里面做了些什么都有深入的解释。

这个例子应该能在某些方面给你提供基本的思路,比如,如何解决不同的问题(当然是网络方面的),再如,在真正把脚本应用于工作之前应该考虑些什么,等等。

对本例中的变量值做些修改就可能在实际的网络中使用,但不建议你这样做,因为你的网络配置和我在例子中使用的情况可能不一样哦。

但只要你有了这个基本的防火墙规则集,很可能只需要少量的调整就可以把它用于实际了。

可能有效率更高的方法来建立规则集,但这个脚本就是为易读而写的,所以每个人都能理解它,即使没有多少BASH脚本编程的知识。

7.1.关于rc.firewall

好,既然你能从头看到这儿,就说明你已经做好一切准备来检查这个脚本了。

例子rc.firewall.txt(代码在附录示例脚本的代码里)很大,但没有多少注释。

我建议你先大致看看它的内容,留个印象,再来仔细地阅读本章(要有耐心哦)。

7.2.rc.firewall详解

7.2.1.参数配置

本小节要对照着rc.firewall脚本代码来看。

rc.firewall.txt的第一小节是配置选项,包含的都是一些至关重要的信息,它们是随着你的网络的不同而改变的。

比如,每个网络的IP地址都不一样,所有要把它放在这儿。

$INET_IP的值应该是在Internet上能使用的才可以,如果你有$INET_IP的话。

如果没有,你就要看看rc.DHCP.firewall.txt这种配置方法了,里面有很多有趣的东西。

变量$INET_IFACE应该指向连接Internet的真实设备,比如eth0、eth1、ppp0、tr0等等。

这个脚本里没有包含任何DHCP或PPPoE的选项,所以这两节是空白的。

其他空白的部分,也是这样的原因。

之所以保留这些空白,是为了更容易区分这些结构相同而内容不同的脚本。

如果你需要这些部分,可以从其他脚本拷贝过来,或者你自己写了:

LocalAreaNetwork小节包含的是LAN必须的信息,如连接到LAN的网卡的IP、LAN所用的地址段等。

Localhostconfiguration小节里的信息在99%的情况下都不要改变,因为我们总是使用127.0.0.1作为地址,也总是把接口命名为lo。

紧随其后的是IPTablesConfiguration,里面只有一个变量,即$IPTABLES。

它指定的是iptables程序的准确位置,如果是自己编译安装的话,一般都是/usr/local/sbin/iptables。

但更多的发行版都把程序放在另外的地方,如/usr/sbin/iptables,等等。

7.2.2.外部模块的装载

首先,我们要使用命令/sbin/depmod-a使moduledependenciesfiles保持最新,然后,再装载脚本需要的模块。

我们应该始终避免装入不需要的模块,如果可能,还要尽力避免装入无所事事的模块,除非你确实需要它们。

这样做主要是为了安全,因为每增加一个模块都要花费额外的努力以增加新的规则(这样就容易出漏洞哦)。

比如,如果你想支持LOG、REJECT和MASQUERADEtarget,不要把相应的功能静态地编译进内核,我们使用以下模块来完成:

/sbin/insmodipt_LOG

/sbin/insmodipt_REJECT

/sbin/insmodipt_MASQUERADE

注意,本文使用的脚本都是用类似命令装入模块,这可能会引起装载失败(有错误信息显示)。

原因是多方面的,但如果较基本的模块也失败的话,那最大的可能是哪个模块或相应的功能已被静态地编译进内核了。

进一步的信息可以看看附录常见问题与解答中的模块装载问题。

接下来的一行是装载ipt_owner模块,它的作用是“只允许特定的用户创建特定的连接”。

在这个例子中,我没有使用到它,但你可能会用到。

比如,你可能只允许root建立FTP和HTTP连接访问,而其他用户都不可以。

你也可以只允许你自己使用的用户名和root才能访问Internet,这样别人会很烦的,但你的安全性在某些方面会有所提高哦,比如,把你当作发起攻击的跳板的情况。

关于ipt_owner的更多信息,可以看看章节规则是如何练成的里的Ownermatch。

在这儿我们也可以为状态匹配安装扩展模块。

状态匹配和连接跟踪的所有扩展模块的名字都是这样的:

ip_conntrack_*和ip_nat_*。

连接跟踪的helper是一些特殊的模块,正是它们告诉了内核怎样恰当地跟踪特殊的连接。

没有这些helper,内核在处理特殊连接的时候,就不知道该查看些什么东西。

NAThelper就是连接跟踪helper的扩展,它会告诉内核在包里找什么、如何转换它们,这样连接才能真正工作起来。

比如,FTP是一个复杂的协议,它利用包的有效数据部分来发送连接信息。

如果一台需要被NAT的机子(译者注:

也就是说,机子在一个内网里)连接Internet上的FTP服务器,它就会把自己的内网IP地址放在包的数据区内发送出去,以使FTP服务器能连接到那个地址。

但私有地址不能在LAN外使用,所以FTP服务器不知道用它做什么,连接就会断掉了。

FTPNAThelper能完成这些连接中所有的地址转换工作,因此FTP服务器就知道该往哪儿连了。

同样的事情也发生在DCC的文件传输(这里指的是发送)和聊天上,为了建立连接,IP地址和端口都需要利用IRC协议的数据区发送,而且还要做一些转换工作。

没有这些helper的话,FTP和IRC只有一部分工作是正常的,但另一部分根本就无法工作。

例如,你可以通过DCC接收文件,但就是不能发送。

这个问题的原因在于DCC是如何建立连接的。

当DCC想发送文件时,会告诉接收者你要发送文件,并让它知道要连接到什么地方。

如果没有helper,这个DCC连接最终会断开,因为接收者收到的是内网的地址。

这样,当它按那个地址连接时,其实就连到和它在同一内网的机子了。

那为什么可以接收呢?

因为发送者给你的是可在Internet上使用的IP地址(大部分情况下,IRC服务器都有真实的IP地址)。

如果你在通过防火墙使用mIRCDCC时遇到了问题,但和其他IRC客户沟通很正常,看看附录常见问题与解答里的关于mIRCDCC的问题吧。

在这个例子中,我们在这儿装载支持FTP和IRC协议的模块。

有关连接跟踪和nat的详细信息,请查看附录常见问题与解答。

在patch-o-matic中,还有H.323conntrackhelper等其他象NAThelper的模块。

但为了使用它们,你需要使用patch-o-matic提供的补丁,还需要编译内核。

详细的操作信息可以查看章节准备阶段。

注意,为了能对FTP和IRC协议做网络地址转换,需要装载ip_nat_ftp和ip_nat_irc。

在装载NAT模块之前,你还要载入ip_conntrack_ftp和ip_conntrack_irc模块。

NAT模块和conntrack模块以相同的方式被使用,但NAT模块使我们能对这两个协议做NAT。

7.2.3.proc的设置

我们可以使用下面的语句打开IP转发功能(IPforwarding):

echo"1">/proc/sys/net/ipv4/ip_forward

注意,何时何地打开这个功能才算合适是值得好好考虑的一个问题。

在本文所用的脚本中,我都是在创建IP过滤器(在本文里就是指iptables的过滤规则)之前打开它的。

这可能引起这样一种情况,就是在一小段时间内(时间的长短随脚本的复杂程度和机子的性能高低而变化,可能只有一毫秒,也可能会长达一分钟),防火墙可以转发任何包(译者注:

因为这时防火墙的过滤规则还没有被装入)。

这种情况又会导致安全方面的问题,不怀好意的人可能会趁此通过防火墙破坏我们的网络。

也就是说,我们应该在创建所有防火墙的规则之后再打开IP转发功能,我这样做只是为了保正所有脚本的兼容性。

(译者注:

我们在实际应用中一定要注意这一点,尽量不要先开IP转发功能)

万一你使用的是SLIP、PPP或DHCP,也就是说你是动态获取IP的,那还要用下面的命令打开ip_dynaddr:

echo"1">/proc/sys/net/ipv4/ip_dynaddr

如果你还要打开其他的proc选项,也是用类似的方法,但有关那些选项的具体介绍以不是本文的内容,你可以看看其他相关的文章。

在附录其他资源和链接里就有一些介绍了内核proc系统的短小精干的文章。

如果你在本文中找不到想要的资料,就可以到附录其他资源和链接去看看,你会有所收获的。

在本文所用的脚本中还包含了一个名为Non-Requiredprocconfiguration(非必需的proc设置)的小节。

当有什么工作不象你所想象的那么正常时,可以来这儿看看,它能提供给你最基本的一些信息,但在你真正弄明白它们的含义之前不要进行改动。

7.2.4.规则位置的优化

本节简要地描述了针对脚本rc.firewall.txt,我将如何选择、使用内建的链链和自定义的链。

我选择过的一些路径从这个或那个角度看可能是错误的,我会指出这些情况和问题发生在何时何地。

这里还对章节表和链做了简要的回顾,希望能给你一点儿提醒,以使你能想起在实际应用中包是如何表和链的。

为了尽可能地少占用CPU,我们已经替换了所有不同的自定义链,与此同时,我把主要的精力放在了安全性和易读性上。

我不让TCP包去经历ICMP、UDP和TCP规则的洗礼,而是简单地匹配所有的TCP包,然后让它去一个自定义链中旅行。

这种方法并不比让它经历所有的规则开销大。

下图可以解释在Netfilter中,外来的包是如何被处理的(相对于章节表和链的深入讨论,这个图形太粗糙了)。

我希望通过上面的解释和下面的图形能让大家明白写这个脚本的目的,详细的注释在后面几节。

利用这个图形,我们可以弄清楚脚本的目的。

整个脚本基于这样一种假设,我们有一个局域网,一个防火墙及一个Internet连接,且有一个静态IP地址(相对的是动态地址,它们使用的连接是DHCP、PPP、SLIP,等等),还想把防火墙作为Internet上的一台服务器来运行某些服务。

我们完全信任局域网,因此不能阻塞任何从局域网发出的数据传输。

还有一个要优先考虑的事,我们只允许那些被明确说明为可以接受的数据通过。

为了做到这一点,我们就要把缺省策略设为DROP。

这样,那些没有被明确标识为允许进入的数据就都被阻塞了。

在上面的假设里,我们想让局域网能够访问Internet。

因为局域网是被完全信任的,所以我们应该允许所有来自局域网的数据通过。

但Internet是不被信任的,所以我们想阻塞从Internet向我们的局域网发起的连接。

根据上面的所有假设,我们来考虑考虑需要做什么、不需要做什么以及我们想做什么。

首先,我们解决的是局域网要能连接到Internet的问题。

那我们就要对所有数据包做NAT操作,因为局域网内的机子都没有真实的IP地址。

NAT是在PREROUTING链中完成的,这也是脚本最后创建的那个规则所在的链。

这意味着我们必须要在FORWARD链中做过滤工作,否则我们就是允许所有外部的机子都能完全访问局域网了。

因为我们完全信任局域网,所以允许所有由内向外的数据通过。

由于我们假设Internet上的机子都不可以访问局域网内的机子,所以要阻塞所有由外向内的连接,但已经建立的或相关的连接除外,因为它们只是用来回应内网对外网的访问,而不是建立对内网的新连接。

由于资金有限,我们的防火墙只提供了有限的几个服务:

HTTP、FTP、SSH和IDENTD。

因此,我们要在INPUT链里允许这些协议通过,还要在OUTPUT链里允许返回的数据通过。

我们除了完全信任局域网,也信任loopback和它的IP地址,因此我们要有相应的规则来允许所有来自局域网和loopback的数据通过。

但是我们不会允许一些特殊的包或包头通过,也不会接受Internet上某一段IP的访问。

比如,网段10.0.0.0/8是为局域网而保留的,一般来说,我们不允许来自它们的包进入,因为这样的包90%都是用来进行欺骗的。

不过,在实现这条标准之前,还要注意一个问题,就是有一些ISP在他们的网络里使用的恰恰就是这些地址。

在附录常见问题与解答里有这个问题的进一步说明。

因为我们在防火墙上运行FTP服务,而且想让包经历最少的规则,所以要把处理established和related状态的规则放到INPUT链的顶部。

基于同样的原因,我们把这些规则分到子链中。

这样,包就可以尽量少地穿越规则,从而节省时间,也可以降低网络的冗余。

在这个脚本里,我们依据不同的协议(如TCP、UDP或ICMP)把包分到子链中。

用来匹配TCP包的链叫做tcp_packets,它可以匹配所有我们允许通过的TCP端口和子协议(如FTP、HTTP等)。

我们还要建立一个名为allowed的子链,以便在真正接受“那些使用有效端口来访问防火墙的TCP包”之前,对它们进行附加的检查。

至于ICMP包,自有称作icmp_packets的链来处理。

在决定如何建立这个链时,我考虑到如果我们同意接受ICMP包的类型和代码,就没有必要对它们做附加的检查,所以直接接受它们就行了。

最后,UDP包由谁处理呢?

当然就是udp_packets了。

如果包是那种允许被接收的类型,就直接放行了。

因为我们的网络很小,所以防火墙也要作为工作站来用。

这就要求我们要允许一些特殊的协议能和它通信,比如speakfreely和ICQ。

现在,我们来考虑考虑OUTPUT链。

因为很信任防火墙,所以我们允许几乎所有离开它的包通过,而没有阻塞任何用户和协议。

但我们也不想让人利用这台机子进行IP欺骗,因此我们只放行那些从防火墙本身的IP发出的包。

为了实现这一点,我们很可能在ACCEPT链中加入这样一条规则:

如果包是由防火墙的IP发出的,就放行,否则,它们就会被OUTPUT链的缺省策略DROP掉。

7.2.5.缺省策略的设置

在开始写其他规则之前,我们先要用下面的语句建立缺省的策略:

iptables[-P]

每一条链的策略都是用来处理那些在相应的链里没被规则匹配的包。

也就是说,如果有一个包没有被规则集中的任何规则匹配,那策略就有用武之地了。

要谨慎地设置其他表里的链的策略,因为它们不是用来过滤包的,这就可能引起很怪异的行为发生。

7.2.6.自定义链的设置

现在,你对我们的防火墙应该已经有了一个很清晰的印象,心动了吧。

心动不如行动,让我们把它变为现实吧。

这一节我们就要小心仔细地创建所有自定义链和链内的规则。

如前所述,我们要建立这几条自定义链:

icmp_packets、tcp_packets、udp_packets和allowed,其中allowed链是由tcp_packets链调用的。

所有进入$INET_IFACE的ICMP包都会被重定向到icmp_packets链,TCP包是到tcp_packets链,那UDP包自然就是udp_packets链了,详细的解释都在INPUTchain里。

创建自定义链的命令还记得吗?

很简单哦,只要使用选项-N,再指定链的名字即可(不要忘了,新建的链都是空的),如下:

iptables[-Nchain]

在下面的几节里,我们会详尽地介绍上面创建的每一条链,以使你了解它们包含哪些规则、有什么作用。

7.2.6.1.bad_tcp_packets链

这条链包含的规则检查进入包(incomingpacket)的包头是否不正常或有没有其他问题,并进行相应地处理。

但事实上,我们使用它只是为了过滤掉一些特殊的包:

没有设置SYN位但又是NEW状态的TCP包,还有那些设置了SYN/ACK但也被认为是NEW状态的TCP包。

这条链可以用来检查所有可能的不一致的东西,比如上面的包或者XMASport-scans等。

我们还可以为INVALID状态的包增加一条规则的。

如果你想完全了解无SYN位的NEW状态(NEWnotSYN),可以去附录常见问题与解答里看看未设置SYN的NEW状态包一节,它介绍了未设置SYN的NEW状态包通过其他规则的情况。

在某些情况下可以允许这种包通过,但99%的情况是我们不想让它们通过。

因此,我们会先记录这种包,然后再扔掉它们。

我们拒绝SYN/ACK包以NEW状态进入的原因也是非常简单的,深入的说明在附录常见问题与解答的NEW状态的SYN/ACK包里。

基本上,我们这样做是出于对其他主机的好意,因为我们为他们预防了序列号预测攻击(sequencenumberprediction)。

7.2.6.2.allowed链

如果包是从$INET_IFACE进入的,而且是TCP包,那它就要经过tcp_packets链的检验。

如果这个连接就是冲着被允许通过的端口来的,我们还要对它进行一些检查,以确定是否真的要接受它。

这些“最后的审判”都是在allowed链里进行的。

首先,我们看看这个包是否是SYN包,如果是,它很可能是新连接的第一个包,我们当然接受了。

如果不是,那就看看包是否来自某个ESTABLISHED或RELATED状态的连接,是的话,就接受。

ESTABLISHED状态的连接是那种在两个方向上都有流量存在的连接。

依据状态机制的观点,这个连接一定处于是ESTABLISHED状态的,因为我们现在能看到这个包,说明以前肯定收到了相应的SYN包。

最后一条规则将DROP所有其他的包。

当包到达最后这条规则,就几乎意味着所有连接都不会有双向的交流,也就是说,我们不会回应SYN包。

当试图用非SYN包开始新的连接时,包也会走到这条规则。

不用SYN包建立新连接没有什么实际的用处,当然,端口扫描要排除在外。

就我知道的而言,现在没有什么有用的TCP/IP程序会使用SYN包以外的包来打开一个TCP连接。

因此,我们要把这样的包DROP掉,我有99%的把握说它们是端口扫描用的。

7.2.6.3.处理TCP的链

tcp_packets链指定了哪些端口可从Internet访问。

但我们还要对进入的包做更多的检查,因此,每个包都会被发送到上面提到的allowed链。

-Atcp_packets告诉iptables要在哪条链里增加规则,规则被放在指定链的末尾。

-pTCP指定要匹配的是TCP包,-s0/0说明要匹配的源地址是从网络掩码为0.0.0.0的地址0.0.0.0开始的,换句话说,就是所有的地址。

这实际上是默认值,我写出来只是尽可能使你更明白。

--dport21指定目的端口,也就是说如果包是发往端口21的,就会被匹配。

如果所有的标准都匹配了,包就要被送往allowed链。

TCP的21号端口也是允许访问的,也就是FTP的控制端口,它可以控制FTP连接,前面提到过,我还允许所有RELATED状态的连接通过。

这样,我们也就可以使用PASSIVE(主动)和ACTIVE(被动)的连接了,当然,要事先装载ip_conntrack_ftp模块。

如果我们不想再提供FTP服务,就卸载ip_conntrack_ftp模块,并把$IPTABLES-Atcp_packets-pTCP-s0/0--dport21-jallowed这一行从文件rc.firewall.txt里删掉。

22号端口是SSH使用的。

如果你允许外网的如何人都能通过telnet(使用23号端口)访问你的机子,那你还是使用SSH吧,它的安全性要好很多。

注意,你操作的是防火墙,把任何访问权分配给除你自己之外的人都不是什么好主意。

防火墙总是应该尽量少地暴露自己。

80是HTTP端口,也就是说你在防火墙上运行了网页服务。

如果你不提供网页服务,就删掉这条规则吧。

最后我们还提供了IDENTD服务,端口是113。

这个服务对某些协议是必须的,如IRC。

注意,如果你NAT一些在内网里的主机的话,软件oidentd也值得一用,它会把IDENTD请求中继给内网里正确的机子。

如果没有匹配上面任何一条规则,包就会被送回tcp_packets链的父链,也就是把它发到tcp_packets链的那条规则所在的链。

如果你想打开更多的端口,只要对tcp_packets链里的任何一行使用“复制、粘贴大法”,再修改一下端口号即可。

7.2.6.4.处理UDP的链

如果我们在INPUT链中遇到了UDP包,就把它发送到udp_packets链。

在那里,我们只处理UDP包,所以要用-pUDP来指定相应的协议。

我们接受来自任何地址的包,故有-s0/0,这其实就是源地址选项的默认值,但为了更明确,我们还是把它写出来了。

此外,我们只接受发往特定端口的包,这些端口是我们想对Internet开放的。

注意,我们不需要依据发送端的源端口来决定是否打开某个端口,这个工作是由状态机制完成的。

如果我们想运行某个使用UDP端口的服务(如DNS),只要开放相应的端口,其他的端口不需要打开。

那些处于ESTABLISHED状态、正在进入防火墙的包在到达包含--stateESTABLISHED,RELATED的规则(这是INPUT链里那些“处理来自Internet的包的规则”中的第一条规则)之后就会被接受了。

我们不接受外来的以53号端口为目的的UDP包,也就是说,我们不想接受外来的DNS查询。

其实,规则已经写好了,我只是把它给注释掉了。

如果你想把防火墙作为一台允许Internet访问的DNS服务器,那就把注释符号去掉。

就我个人而言,我会打开123号端口,它对应的协议是networktimeprotocol,简称NTP。

我们可以利用这个协议与某台具有精确时间的时间服务器联系,以设置本机的时间。

你们中的大部分可能用不到此协议,所以我也把它注释掉了,虽然我已经写出了规则。

我打开了2074号端口,它是某些实时的多媒体应用程序使用的。

比如speakfreely,你可以用这个程序通过音箱、麦克风或耳麦与其他人进行实时交谈。

如果你不需要,就把这条规则注释掉吧。

端口4000相应的协议是ICQ协议,由ICQ使用,世界上使用最广泛的聊天程序之一,“地球人都知道”。

Linux上至少有2-3种不同的ICQ克隆。

我想不必解释为什么要开放这个端口了吧。

(译者注:

国产的聊天程序,常见的是QQ(端口8000),现在又有了UC(端口3001)等。

如果你正在经历日志满天飞的苦恼,这里有两个额外的规则可以使用,当然,这要看是因为什么引起的了。

我们这里的第一条规则会阻塞目的端口是135到139的广播包。

大部分Microsoft使用者会用到NetBIOS或SMB,而它们就使用这些广播包。

这条规则可以阻塞所有位于外网的那些MicrosoftNetwork产生的广播包,我们的日志也就可以简洁一些了。

第二条规则也是解决日志问题,不过问题的产生者变了,这回是外网的DHCP查询。

如果你的外网是由非交换的以太网组成的,在那里客户机可以通过DHCP得到IP地址,也就是说,如果外网里会有很多DHCP查询广播包,那就启用这条规则吧。

注意,我把最后这两条规则也注释掉了,因为有些人可能想看看相关的记录。

如果你正经历“合法日志过

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 表格模板 > 合同协议

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1