IPTABLES中文手册.docx

IPTABLES中文手册.docx

《IPTABLES中文手册.docx》由会员分享，可在线阅读，更多相关《IPTABLES中文手册.docx（32页珍藏版）》请在冰豆网上搜索。

IPTABLES中文手册

IPTABLES中文手册

概述

这是一篇以介绍在Linux操作系统平台上构建防火墙系统（Netfilter/Iptables）为主的科技文档，旨在帮助使用者在较短的时间内掌握管理和配置要领，为企业的网络安全提供相关的安全保障。

本文共分为两部分，第一部分具体介绍了Netfilter/Iptables的运行机制和配置管理方法，这是全文中最核心的一部分。

第二部分给出了一些具体的范例脚本供系统管理员参考。

鉴于笔者水平有限，文中有错误的地方望不吝赐教。

适用对象

本文首先是为各个企业的网络系统管理员撰写的，无论是那些已经使用了基于Netfilter/Iptables防火墙系统的企业，还是那些正准备使用它的企业，本文的内容都非常适合为系统管理员们提供参考。

对于那些Linux的个人用户和爱好者，本文也不失为一篇相当有价值的参考文档，其中，相当一部分内容深入浅出的讲解能帮助读者很快的理解和掌握Netfilter/Iptables的精髓。

对于希望通过本文了解Netfilter/Iptables的读者，应至少具备一定的Linux操作系统的应用基础，比如文件操作、网络配置操作等，当然，如果使用者还具备一定的编译核心的能力那是在好不过的了。

为了更好的配置防火墙系统，使用者除了掌握Netfilter/Iptables本身的配置管理技巧外，掌握一定的TCP/IP网络知识也是必须的，比如在缺省情况下，应该知道SMTP（SimpleMailTransferProtocol）协议使用TCP25端口做为其对外提供服务的端口，FTP（FileTransferProtocol）协议在建立连接的整个过程中，会与客户端建立两条连接，一条是用户传输数据的，另一条则是用户控制传输的。

术语

文中包含了一些术语，也许读者对其中的一部分似曾相识，但又并不完全理解其正确的含义，或者和其他相关安全产品的概念混淆了。

这里有一些解释，并说明了本文中如何使用它们。

DNAT-DestinationNetworkAddressTranslation目的网络地址转换。

DNAT是一种改变数据包目的IP地址的技术，这种技术经常用于将内部网络（RFC1918定义的地址段）的服务器通过公有的可路由IP地址发布到Internet上，通过对同一个IP地址分配不同的端口，来决定数据的流向。

SNAT-SourceNetworkAddressTranslation源网络地址转换。

这是一种改变数据包源IP地址的技术，经常用来使多台计算机分享一个Internet地址。

这只在IPv4中使用，因为IPv4的地址已快用完了，IPv6将解决这个问题。

IPv6使得地球上每一粒沙子大小的空间都能够分配到一个IP地址，因此IPv6不存在地址空间短缺的问题。

State-状态指明数据包处于什么状态。

状态在RFC793-TransmissionControlProtocol中定义，或由用户在Netfilter/iptables中自定义。

需要注意的是Netfilter设定了一些关于连接和数据包的状态，但没有完全使用使用RFC793的定义。

Userspace-用户空间，指在内核外部或发生在内核外部的任何东西。

例如，调用iptables-h发生在内核外部，但iptables-AFORWARD-ptcp-jACCEPT（部分地）发生在内核内部，因为一条新的规则加入了规则集。

Kernelspace-内核空间，与用户空间相对，指那些发生在内核内部。

target-这个词在后文中有大量的应用，它表示对匹配的数据包所做的操作，如ACCEPT、DROP、REDIRECT等等。

约定

本文中涉及的命令、范例都是以RedhatLinux操作系统平台为基础的，尽管在绝大多数的情况下，Linux的大多数命令都是独立于发行版本的，但每个发行版本之间或多或少的存在微小的区别。

本文中的命令以黑体5号宋体字表示，如下例：

＃iptables-restore/etc/sysconfig/iptables

本文中涉及到的命令、范例脚本都经过我们的严格测试，能够保证使用者按照文中介绍的做法正确配置防火墙，当然，每一个用户的网络环境都是不一样的，具体的配置还需要用户根据自己的具体情况来适当调整。

致谢

在撰写本文时，参考了OskarAndreasson的《iptablestutorial1.1.19》一文，由于本人英语水平有限，因此额外参考了中国Linux公社里的Linux新鲜社员sllscn的翻译稿，在此向他们两人表示谢意。

第一章构建Netfilter/Iptsbles防火墙系统

1.1获取iptables

iptables可以从filter.org/下载，该网站是netfilter/iptables最专业的网站，由HaraldWelte、JozsefKadlecsik、MartinJosefsson、PatrickMcHardy等核心成员进行维护，此外，还有众多的iptables的使用者和开发者为网站提供了大量的文档和更新代码。

1.2编译内核

在一般情况下，我们采用的Linux的distribution比如Redhat都会帮我们安装好Iptables，而且netfilter的核心层也被以模块（Modules）的方式编译进了核心，所以，在绝大多数的情况下，我们是不需要对核心进行重新编译的。

当然，我们写这篇文档的用意决不仅限于教会用户使用几个命令来管理iptables，所以，我们还是来描述一下如何编译核心以使Linux在核心层能够支持数据包过滤。

编译核心的准备工作当然是必需有LinuxKernel的源代码，在源代码文件的目录/usr/src/linux-2.4（这个目录一般是个链接文件）中输入：

#makemenuconfig

会出现如下的画面：

在图中高亮显示的地方回车进入Networkingoptions的核心配置页面，

将高亮显示的部分编译进核心，在该配置页面内，还有一处需要注意，就是NetfilterConfiguration的配置页面，在该处回车即可进入配置界面：

从图中可以看到，左面尖括号内的“M”代表该选项被编译成核心模块，仅在系统需要时才被装载入核心空间，由于模块化的核心是不占用核心本身的空间的，因此，对于这些选项，除非肯定不会用到的以外，其他的都可以选择编译成核心模块，但有些是必须的，如

Connectiontracking——用于支持状态链接跟踪功能

FTPprotocolsupport——用于支持对Ftp协议的连接跟踪机制

IPtablessupport——用于支持包过滤

Connectionstatematchsupport——用户支持连接状态匹配

MASQUERADEtargetsupport——支持地址伪装功能

Multiportmatchsupport——支持多端口匹配，这对于设置过滤规则非常有好处

REDIRECTtargetsupport——如果你想使用iptables将特定的流量交给特定的代理程序如squid来处理，这个选项需要被编译进核心模块

这些选项选择完成后，按照核心编译的方法对配置好的核心进行编译即可：

＃makedep

＃makebzImage

＃makeinstall

＃makemodules

＃makemodules_install

1.3iptables的编译和安装

就象我们在上节中说到的一样，如果采用诸如Redhat之类的LinuxDistribution，在安装系统时，Iptables已经被做为缺省的软件安装到系统上了，用户不需要另行安装，如果用户需要另外安装新版本的iptables软件，可以到filter.org/的网站下载最新版本的iptables源代码，目前最新的版本是1.2.9。

从网站上下载的源代码是“tar.bz2”格式的，编译源代码的第一步工作是解压缩，命令如下：

＃/bin/tarxjvfiptables-1.2.9.tar.bz2

解压缩后，进入源代码的安装目录，开始编译：

＃makeKERNEL_DIR=/usr/src/linux/

如果一切正常，那么iptables应该编译好了，接下来可以进行安装了，安装命令非常简单：

＃makeinstallKERNEL_DIR=/usr/src/linux/

怎么样？

简单吧，当然，如果这时您的系统核心还没有将netfilter/iptables编译进去，那么安装了iptables软件是没有多大意义的。

1.4iptables的启动和关闭

在RedhatLinux上，由于历史的原因，ipchains和iptables是并存的（ipchains是在kerenl版本2.4.x以前的包过滤防火墙系统），因此ipchains和iptables同时运行是不允许的，我们首先要将ipchains的服务停掉：

#/sbin/chkconfig–level123456ipchainsoff

＃/sbin/serviceipchainsstop

当然，既然不使用ipchains了，我们也可以将ipchains从系统中移除，使用命令：

＃rpm–eipchains

第二步是启动Iptables的服务

#/sbin/chkconfig–level345iptableson

#/sbin/serviceiptablesstart

chkconfig命令表示在系统启动时，ipchains或iptables在相应启动级别的缺省设置，如果是off，则代表系统启动时不启动ipchains或iptables服务。

反之，则启动。

1.5iptables的工作原理和基础架构

iptables被分为两部分，一部分被称为核心空间，另一部分称为用户空间，在核心空间，iptables从底层实现了数据包过滤的各种功能，比如NAT、状态检测以及高级的数据包的匹配策略等，在用户空间，iptables为用户提供了控制核心空间工作状态的命令集。

无论如何，一个数据包都会经过下图所示的路径，并在其中的任何一条路径中被处理。

首先，当一个包进来的时候，也就是从以太网卡进入防火墙，内核首先根据路由表决定包的目标。

如果目标主机就是本机，则如下图直接进入INPUT链，再由本地正在等待该包的进程接收，否则，如果从以太网卡进来的包目标不是本机，再看是否内核允许转发包（可用echo1>/proc/sys/net/ipv4/ip_forward打开转发功能如果不允许转发，则包被DROP掉，如果允许转发，则送出本机，这当中决不经过INPUT或者OUTPUT链，因为路由后的目标不是本机，只被转发规则应用，最后，该linux防火墙主机本身能够产生包，这种包只经过OUTPUT链被送出防火墙。

现在，我们来讨论为什么iptables叫iptables，这句话挺别扭是吗？

但iptables的名字起的确实如其名，我们可以叫它ip表，在iptables中共有三类表，分别是mangle、nat和filter。

mangle表从目前来看，他的作用对于满足常规的防火墙应用作用不大，我们在这里不进行具体的描述。

nat表的作用在于对数据包的源或目的IP地址进行转换，这种应用也许只会在IPv4的网络中适用，nat表又可主要分为三条链，如下：

DNAT：

DNAT操作主要用在这样一种情况下，你有一个合法的IP地址，要把对防火墙的访问重定向到其他的机子上，比如DMZ。

也就是说，我们改变的是目的地址，以使包能重路由到某台主机上。

SNAT：

SNAT改变包的源地址，这在极大程度上可以隐藏你的本地网络或者DMZ等。

一个很好的例子是我们知道防火墙的外部地址，但必须用这个地址替换本地网络地址。

有了这个操作，防火墙就能自动地对包做SNAT，以使LAN能连接到Internet。

如果使用类似192.168.0.0/24这样的地址，是不会从Internet得到任何回应的。

因为RFC1918定义了这些网络为私有的，只能用于LAN内部。

MASQUERADE：

MASQUERADE的作用和SNAT完全一样，只是计算机的负荷稍微多一点。

因为对每个匹配的包，MASQUERADE都要查找可用的IP地址，而不象SNAT用的IP地址是配置好的。

当然，这也有好处，就是如果我们使用诸如PPPOE等拨号的方式连接Internet，这些地址都是由ISP的随机分配的，这时使用MASQUERADE是非常好的一个解决方案。

filter表用来过滤数据包，我们可以在任何时候匹配包并过滤它们。

我们就是在这里根据包的内容对包做DROP或ACCEPT的。

当然，我们也可以预先在其他地方做些过滤，但是这个表才是设计用来过滤的。

几乎所有的target都可以在这儿使用。

1.6状态机制

状态机制是iptables中较为特殊的一部分，这也是iptables和比较老的ipchains的一个比较大的区别之一，运行状态机制（连接跟踪）的防火墙称作带有状态机制的防火墙，以下简称为状态防火墙。

状态防火墙比非状态防火墙要安全，因为它允许我们编写更严密的规则。

在iptables上一共有四种状态，分别被称为NEW、ESTABLISHED、INVALID、RELATED，这四种状态对于TCP、UDP、ICMP三种协议均有效。

下面，我们来分别阐述四种状态的特性。

NEW：

NEW说明这个包是我们看到的第一个包。

意思就是，这是conntrack模块看到的某个连接的第一个包，它即将被匹配了。

比如，我们看到一个SYN包，是我们所留意的连接的第一个包，就要匹配它。

ESTABLISHED：

ESTABLISHED已经注意到两个方向上的数据传输，而且会继续匹配这个连接的包。

处于ESTABLISHED状态的连接是非常容易理解的。

只要发送并接到应答，连接就是ESTABLISHED的了。

一个连接要从NEW变为ESTABLISHED，只需要接到应答包即可，不管这个包是发往防火墙的，还是要由防火墙转发的。

ICMP的错误和重定向等信息包也被看作是ESTABLISHED，只要它们是我们所发出的信息的应答。

RELATED：

RELATED是个比较麻烦的状态。

当一个连接和某个已处于ESTABLISHED状态的连接有关系时，就被认为是RELATED的了。

换句话说，一个连接要想是RELATED的，首先要有一个ESTABLISHED的连接。

这个ESTABLISHED连接再产生一个主连接之外的连接，这个新的连接就是RELATED的了，当然前提是conntrack模块要能理解RELATED。

ftp是个很好的例子，FTP-data连接就是和FTP-control有关联的，如果没有在iptables的策略中配置RELATED状态，FTP-data的连接是无法正确建立的，还有其他的例子，比如，通过IRC的DCC连接。

有了这个状态，ICMP应答、FTP传输、DCC等才能穿过防火墙正常工作。

注意，大部分还有一些UDP协议都依赖这个机制。

这些协议是很复杂的，它们把连接信息放在数据包里，并且要求这些信息能被正确理解。

INVALID：

INVALID说明数据包不能被识别属于哪个连接或没有任何状态。

有几个原因可以产生这种情况，比如，内存溢出，收到不知属于哪个连接的ICMP错误信息。

一般地，我们DROP这个状态的任何东西，因为防火墙认为这是不安全的东西。

每个状态相对于不同的第四层协议来讲，稍微有些区别，对于TCP协议来说，当防火墙收到第一个数据包，也就是SYN报文时，将该会话标记为NEW状态，在系统的/proc/net/目录下，可以查阅文件ip_conntrack，这是在内存空间里存放防火墙当前状态表的临时文件，对于NEW状态的记录如下：

tcp6117SYN_SENTsrc=192.168.1.5dst=192.168.1.35sport=1031dport=23[UNREPLIED]src=192.168.1.35dst=192.168.1.5sport=23dport=1031use=1

从上面的记录可以看出，SYN_SENT状态被设置了，这说明连接已经发出一个SYN包，但应答还没发送过来，这可从[UNREPLIED]标志看出，当服务器端回应了SYN/ACK包后，状态表改写为：

tcp657SYN_RECVsrc=192.168.1.5dst=192.168.1.35sport=1031dport=23src=192.168.1.35dst=192.168.1.5sport=23dport=1031use=1

现在我们已经收到了相应的SYN/ACK包，状态也变为SYN_RECV，这说明最初发出的SYN包已正确传输，并且SYN/ACK包也到达了防火墙。

这就意味着在连接的两方都有数据传输，因此可以认为两个方向都有相应的回应。

接下来，TCP三次握手的随后一个报文ACK包也到达了防火墙，防火墙上的状态表变成了：

tcp6431999ESTABLISHEDsrc=192.168.1.5dst=192.168.1.35sport=1031dport=23src=192.168.1.35dst=192.168.1.5sport=23dport=1031use=1

现在，我们来看看UDP协议的状态描述方法，从协议本身的特性来看，UDP连接是无状态的，因为它没有任何的连接建立和关闭过程。

以某个顺序收到的两个数据包是无法确定它们的发出顺序的。

但内核仍然可以对UDP连接设置状态。

我们来看看是如何跟踪UDP连接的，以及在核心目录/proc/net/ip_conntrack的相关记录。

当第一个UDP的数据包到达防火墙后，防火墙在他的状态表中留下了这样的记录：

udp1720src=192.168.1.2dst=192.168.1.5sport=137dport=1025[UNREPLIED]src=192.168.1.5dst=192.168.1.2sport=1025dport=137use=1

UNREPLIED代表这是一个状态为NEW的数据包，当这条连接的回应数据包到达防火墙后，防火墙立即将修改这条状态记录：

udp17160src=192.168.1.2dst=192.168.1.5sport=137dport=1025src=192.168.1.5dst=192.168.1.2sport=1025dport=137use=1

在这条新的状态记录中，UNREPLIED被删除了，这代表现在防火墙已经建立了一条UDP协议的会话，但这里并没有象TCP协议那样显示ESTABLISHED标记，这是TCP的状态记录和UDP的状态记录稍微不同的一个地方，当然，还有一个地方需要注意，在测试中，还需要有一些数据包经过，防火墙才会将状态记录改写成：

udp17179src=192.168.1.2dst=192.168.1.5sport=137dport=1025src=192.168.1.5dst=192.168.1.2sport=1025dport=137[ASSURED]use=1

ASSURED状态表示当前有数据在进行传输，表面当前连接的状态是ACTIVE的。

如果，在这个状态下数据停止了传输，则这条记录会有一个计时器，也就是记录中的第三个字段，上面这条记录的第三个字段是179，代表当前的ASSURED状态还能够保持179秒，如果还有新的数据包经过，那么计时器会被重新设置成缺省的180秒，如果在180秒内都没有流量，那么这条状态记录就会从状态表中被删除。

最后，我们在来看看Linuxkernel是如何标示ICMP协议的状态的，ICMP也是一种无状态协议，它只是用来控制而不是建立连接。

ICMP包有很多类型，但只有四种类型有应答包，它们是回显请求和应答（Echorequestandreply），时间戳请求和应答（Timestamprequestandreply），信息请求和应答（Informationrequestandreply），还有地址掩码请求和应答（Addressmaskrequestandreply），这些包有两种状态，NEW和ESTABLISHED。

时间戳请求和信息请求已经废除不用了，回显请求还是常用的，比如ping命令就用的到，地址掩码请求不太常用，但是可能有时很有用并且值得使用。

看看下面的图，就可以大致了解ICMP连接的NEW和ESTABLISHED状态了。

如图所示，主机向目标发送一个回显请求，防火墙就认为这个包处于NEW状态。

目标回应一个回显应答，防火墙就认为包处于ESTABLISHED了。

当回显请求被发送时，ip_conntrack里就有这样的记录了：

icmp125src=192.168.1.6dst=192.168.1.10type=8code=0id=33029[UNREPLIED]src=192.168.1.10dst=192.168.1.6type=0code=0id=33029use=1

可以看到，ICMP的记录和TCP、UDP的有点区别，协议名称、超时时间和源、目地址都一样，不同之处在于没有了端口，而新增了三个新的字段：

type，code和id。

字段type说明ICMP的类型。

code说明ICMP的代码，这些代码在附录ICMP类型里有说明。

id是ICMP包的ID。

每个ICMP包被发送时都被分配一个ID，接受方把同样的ID分配给应答包，这样发送方能认出是哪个请求的应答。

[UNREPLIED]的含义和前面一样，说明数的传输只发生在一个方向上，也就是说未收到应答。

再往后，是应答包的源、目地址，还有相应的三个新字段，要注意的是type和code是随着应答包的不同而变化的，id和请求包的一样。

和前面一样，应答包被认为是ESTABLISHED的。

然而，在应答包之后，这个ICMP连接就不再有数据传输了。

所以，一旦应答包穿过防火墙，ICMP的连接跟踪记录就被销毁了。

因此，要想在/proc/ip_conntrack文件中抓到ICMP协议的状态记录实在不是一件容易的事。

您可以用如下的命令来尝试获取这些记录：

＃cat/proc/net/ip_conntrack|grepicmp

如果没有输出，那么就不停的重复这个命令，直到发现icmp的记录为止。

以上各种情况，请求被认为NEW，应答是ESTABLISHED。

换句话说，就是当防火墙看到一个请求包时，就认为连接处于NEW状态，当有应答时，就是ESTABLISHED状态。

1.7规则的保存和恢复

iptables提供了两个命令来对策略进行保存和恢复：

iptables-save和iptables-restore，iptables-save用来保存当前内存空间的策略，iptables-restore用来将iptables配置文件的策略写入内存空间。

iptables-save的命令格式非常简单：

＃iptables-save–c>/etc/sysconfig/iptables

上面的命令表示将内存中的策略写入/etc/sysconfig/iptables文件中，同时将当前内存中针对每条策略的流量统计值也写入该文件。

＃iptables-save–tnat>/etc/sysconfig/iptables

这条命令表明只保存当前内存中的nat表。

＃ip