Iptables 结构化防火墙

       近来看了一些关于linux iptables 防火墙的资料，本人也是对iptables属于开始起步学的，先将自己学习后的一些心得和大家分享一下，希望能共勉（限于本人水平有限，文中难免有些不确之处，希望大家能指出（邮箱：ygycec@sina.com））

     为什么我这里提到是一个结构化的防火墙了，这只是我自己本人的一个便于理解而已，但我觉得这样更容易我们理解。想必你肯定也知道了 linux iptables 防火墙，为我们提供了3种类型的表：filter(默认表)，nat和mangle。

          filter表：这个表为我们提供了3个内建链（chains）,分别是INPUT,FORWARD,OUTPUT. 也许你从他们的名字也多少看出来了他们的主要作用或者说用途。

    INPUT 链是管理进入的一个链（INPUT:通过路由表后目的地为本机），比如我们有一台服务器做了openssh-server 服务，我们就可以通过ssh 连接到服务器上面去管理我们的服务器，那么我们是不是首先需要开放我们的服务器的某个ssh 端口（默认为22 port），然后我们的客户机随即分配一个源端口通过TCP协议去连接那个ssh端口了。这里我们通过TCP去连接的时候，我们是不是已经涉及到了通过服务器的某个外网卡进入服务器才能和ssh端口连接了。因此这里我们就用到了INPUT链，如果我们要主动去连接或访问的话，这只是一个列子，这样的INPUT连接是非常多的哦。

  OUTPUT链是管理出去的一个链（由本机产生，向外转发），这个出去是相对于iptables防火墙的。正如上面你看见的，我们通过ssh去连接服务器是，我们已经用到了INPUT链。现在如果服务器接收到了我们发出的连接请求，那它是不是应该给我们一个应答，才能建立起连接了。因此服务器产生一个应答，通过我们的防火墙然后告诉我们是不是可以连接，这样的一个应答就会通过防火墙出来，这里我们是不是又用到了OUTPUT了。这样的情况也是非常多的，比如http等等应答。

  FORWARD 链（通过路由表后，目的地不为本机）是一个应用于转发管理的一个链。我们来做一个假设，比如你是一个内网里面的客户机，你使用的是一个私有地址，这事你需要去访问Internet 上面的一个网站，刚好我们的防火墙就是用一台有iptables代替的。根据你的网络知识，想必你是知道，我们是不能直接访问到这个网站的，我们必须通过NAT才能访问，这里防火墙既不是目标地址，也不是源地址。它只是负责地址转换和转发包，此时我们是不是又会用到FORWARD这个链的功能了。

      nat 表包含有3个内建的链：PREROUTING, POSTROUTING,OUTPUT 链

PREROUTING:可以在这里定义进行目的NAT的规则，因为路由器进行路由时只检查数据包的目的ip地址，所以为了使数据包得以正确路由，我们必须在路由之前就进行目的NAT;

POSTROUTING:可以在这里定义进行源NAT的规则，系统在决定了数据包的路由以后在执行该链中的规则。

OUTPUT:定义对本地产生的数据包的目的NAT规则。

 提醒：nat 表我们一般只做地址转换，不做具体的过滤操作，过滤基本都是有filter表来完成，如果你在nat里做一些过滤的话，可能会带来一些你意想不到的情况发生。

mangle表包含有5条内建的链：PREROUTING,INPUT,FORWARD,OUTPUT,POSTROUTING.

 具体的作用我这里就不详细的阐述了，如果有不清楚的地方，请查阅相关资料。

说了这么多接下来才是我们本文的要说的重点：iptables 结构化防火墙

   简单说明一下为什么我们用结构化的好处：

     1：让你或者其他人更易于读

     2：不同协议的包，放在我们自定义的不同对应链中，这样此种协议就只通过我们知道的链去进行过滤。这样我们不同协议链中的规则数目就减少了，提高了处理性能。（比如我们让TCP包只经过我们定义的TCP链中，通过TCP链处理后，它不必再交与UDP或其他的规则再去检验，这样我们就提高了处理的效率）

   3：后期我们更便于修改或移植到别的地方

马上我们来看看我们采用什么样的结构化（只是我自己比较习惯这样规划，也许你有更好的方式）

 

声明：以下部分内容转载了Oskar Andreasson的iptables 指南，在此非常感谢

1：Configuration —— 首先是一个配置选项区，里面的变量在脚本中会用到。        几乎任何脚本（shell-script）的第一部分都是配置选项区

    1.  Internet —— 有关Internet连接的配置。如果我们没有任何Internet连接，这一部分就可以跳过去。注意，相比我们列出来的，这一部分可能会包含更多小节，虽然我们这里只有了了几个，但足够应对我们已有的各种Internet连接了。

1.  DHCP —— 如果脚本用到了DHCP，我们就要在此添加相应的配置。

2.  PPPoE —— 如果想把脚本用于PPPoE连接，就要在此添加相应的配置。

2.  LAN —— 如果防火墙后有局域网，就要使用这里的配置了。大部分情况下都会用到这儿，因为局域网几乎总是存在的。

3.  DMZ —— 对非军事区（DMZ zone）的配置。大部分脚本不会用到这个设置，因为这些脚本针对的主要是一些普通的家庭网络，或小企业的网络。

4.  Localhost —— 本地（local-host）的有关设置。虽然我把它们写成变量的形式，但一般不会被改变，也不应该有什么理由要改变它们。

5.  iptables —— 有关iptables的设置。大部分情况下，这里只设置一个变量，用来指向iptables程序的位置。

6.  Other —— 如果还有什么信息，首先应该把它们放在相应的小节里，实在没有相应的小节，就放这儿吧。

2.  Module loading —— 脚本应该维护一个模块列表。它分为两部分，第一部分包含必需的模块，同时第二部分要包含不必要的模块的列表。

注意，这些模块可能会提高安全性，或为管理者、客户添加某些服务，还有一些模块不是必需的，但它们可能也被加入了列表。不过，在本例中，我已经注意了这个问题。

1.  Required modules —— 这里装载的是必要的模块，它们可能会提高安全性或为管理者、客户增加某些服务。

2.  Non-required modules —— 这里列出的是不必要的模块，所以它们都被注释掉了。如果你用到了它们提供的功能，就可以启用它们。

3.  proc configuration —— 这儿关心的是有关proc系统的设置。如果一些选项是必须的，我们就启用它，如果不是，就把它注释掉。大部分有用的proc配置都列在这儿了，但远远不是全部的。

1.  Required proc configuration —— 包含了使脚本能正常工作的所有必需的proc配置，它也可以包含一些能提高安全性或为管理者、客户增加特定服务的选项。

2.  Non-required proc configuration —— 这里提到的选项不是必需的，虽然它们可能很有用。因此，我把它们都注释掉了。当然，这里并没有包括所有这样的选项。

4.  rules set up —— 现在，应该添加规则了。我把所有的规则都明确地分配到了与表、链相应的小节里。所有自定义的规则都写在系统内建的链之前（译者注：当然要写在前面了，因为后面要调用它们哦）。另外，我是按照命令iptables -L输出的顺序来安排此脚本里表与链的出现顺序的（译者注：这样，便于我们查看哦）。

1.  Filter table —— 首先是filter表，而且我们先要设置策略。

1.  Set policies —— 为所有系统内建的链设置策略。通常，我会设置 DROP，对于允许使用的服务或流会在后面明确地给以ACCEPT。这样，我们就可以方便地排除所有我们不想让人们使用的端口。

2.  Create user specified chains —— 在这里创建所有以后会用到的自定义链。如果没有事先建立好，后面是不能使用它们的，所以我们要尽早地建立这些链。

3.  Create content in user specified chains —— 建立自定义链里使用的规则。其实你也可以在后面的某个地方写这些规则，之所以写在这儿，唯一的原因是这样做规则和链会离得近些，便于我们查看。

4.  INPUT chain —— 创建INPUT链的规则。

从这里开始，我就是遵循iptables -L的输出格式来创建规则的，这样做的唯一原因就是为了便于阅读，避免混淆。

5.  FORWARD chain —— 为FORWARD链创建规则。

6.  OUTPUT chain —— 为OUTPUT链创建规则。其实，在这里要建的规则很少。

2.  nat table —— 在处理完filter表之后，该设置nat表了。我们这样做是有一定原因的。首先，我们不想太早地打开转发机制（译者注：注意，filter表设定的是过滤机制，而不是转发）和NAT功能，因为它们可能导致数据会在错误的时间（也就是这样的时刻：我们打开了NAT，但过滤规则还没有运行）通过防火墙。还有，我把nat表看作是围绕filter表的一个层。也就是说，filter表是核心， nat表是它外部的一个层，mangle表是第二层。从某些观点来看，这可能有点不对，但也八九不离十了。

1.  Set policies —— 与filter一样，我们先来设置策略。一般说来，缺省的策略，即ACCEPT，就很好。这个表不应该被用来做任何过滤，而且我们也不应该在这儿丢弃任何包，因为对我们假设的网络情况来说，可能会发生一些难以应付的事情。我把策略设为ACCEPT，因为没有什么原因不这样做。

2.  Create user specified chains —— 在这儿创建nat表会用到的自定义链。一般情况下，我没有任何规则要在这儿建立，但我还是保留了这个小节，以防万一罢了。注意，在被系统内建链调用之前一定要建好相应的自定义链。

3.  Create content in user specified chains —— 建立自定义链的规则。

4.  PREROUTING chain —— 要对包做DNAT操作的话，就要用到此链了。大部分脚本不会用到这条链，或者是把里面的规则注释掉了，因为我们不想在不了解它的情况下就在防火墙上撕开一个大口子，这会对我们的局域网造成威胁。当然，也有一些脚本默认使用了这条链，因为那些脚本的目的就是提供这样的服务。

5.  POSTROUTING chain —— 如果使用SNAT操作，就要在此建立规则。你可能有一个或多个局域网需要防火墙的保护，而我就是依据这样的情况来写此脚本的，所以这个脚本中使用的 POSTROUTING链是相当实用的。大部分情况下，我们会使用SNAT target，但有些情况，如PPPoE，我们不得不使用MASQUERADE target。

6.  OUTPUT chain —— 不管什么脚本都几乎不会用到这个链。迄今为止，我还没有任何好的理由使用它，如果你有什么理由用它了的话，麻烦你把相应的规则也给我一份，我会把它加到本指南里的。

3.  mangle table —— 最后要做的就是处理mangle表了。通常，我不会使用这个表，因为一般情况下，它不会被任何人要到，除非他们有什么特殊的需要，比如为了隐藏一条连接后的多台机子，我们要统一设置TTL或TOS等。在这个脚本里，此表是空白的。但在此指南中还是有个小小的例子说明了mangle表的用处。

1.  Set policies —— 设置策略。这里的情形和nat表几乎完全相同。这里不应该做过滤，也不应该丢弃任何包。在任何脚本里我都不会把mangle表的策略设为其他的值，也不鼓励你这样做。

2.  Create user specified chains —— 建立自定义链。我几乎不会用到这个链，所以没有建立任何规则。保留此小节，只是已备后用。

3.  Create content in user specified chains —— 建立自定义链的规则。

4.  PREROUTING —— 本指南的所有脚本都未在此链建立规则。

5.  INPUT chain —— 本指南的所有脚本都未在此链建立规则。

6.  FORWARD chain —— 本指南的所有脚本都未在此链建立规则。

7.  OUTPUT chain —— 本指南的所有脚本都未在此链建立规则。

8.  POSTROUTING chain —— 本指南的所有脚本都未在此链建立规则。

这应该可以较详细地解释每个脚本的结构是怎样的以及它们为什么要使用这个结构了。

  以下是一个脚本：这个脚本是由Copyright © 2001-2003 by Oskar Andreasson所写，这里贴出了只是希望和大家相互学习以下，切勿用于商业，盈利等用途。