iptables手册.docx

上传人:b****1 文档编号:589005 上传时间:2023-04-29 格式:DOCX 页数:38 大小:39.71KB
下载 相关 举报
iptables手册.docx_第1页
第1页 / 共38页
iptables手册.docx_第2页
第2页 / 共38页
iptables手册.docx_第3页
第3页 / 共38页
iptables手册.docx_第4页
第4页 / 共38页
iptables手册.docx_第5页
第5页 / 共38页
iptables手册.docx_第6页
第6页 / 共38页
iptables手册.docx_第7页
第7页 / 共38页
iptables手册.docx_第8页
第8页 / 共38页
iptables手册.docx_第9页
第9页 / 共38页
iptables手册.docx_第10页
第10页 / 共38页
iptables手册.docx_第11页
第11页 / 共38页
iptables手册.docx_第12页
第12页 / 共38页
iptables手册.docx_第13页
第13页 / 共38页
iptables手册.docx_第14页
第14页 / 共38页
iptables手册.docx_第15页
第15页 / 共38页
iptables手册.docx_第16页
第16页 / 共38页
iptables手册.docx_第17页
第17页 / 共38页
iptables手册.docx_第18页
第18页 / 共38页
iptables手册.docx_第19页
第19页 / 共38页
iptables手册.docx_第20页
第20页 / 共38页
亲,该文档总共38页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

iptables手册.docx

《iptables手册.docx》由会员分享,可在线阅读,更多相关《iptables手册.docx(38页珍藏版)》请在冰点文库上搜索。

iptables手册.docx

iptables手册

iptables手册

作者:

EvilKnight 来源:

 类别:

unix/linux技术 日期:

2006-10-30 今日/总浏览:

6/705

前言

概述

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

本文是《Linux安全应用——构建以防火墙为核心的安全管理系统》一文的姐妹篇,如果把那篇文章看成是Whatisit?

那么,本文则以技术细节为主,即Howtodo?

关于为什么要使用基于Linux操作系统平台的防火墙系统的原因,

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

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

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

适用对象

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

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

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

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

资源列表

Netfilter/Iptables的官方网站:

filter.org

在Netfilter的官方网站,用户能够下载Iptables的最新的源代码,Iptables的使用说明文档,FAQ和MailList,这个站点是有关Netfilter/Iptables最权威、最全面的地方,在这里,你几乎能够找到和Netfilter/iptables相关的所有帮助和技术支持。

术语

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

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

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.3    iptables的编译和安装

就象我们在上节中说到的一样,如果采用诸如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.4    iptables的启动和关闭

在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.5    iptables的工作原理和基础架构

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状态的记录如下:

tcp  6117SYN_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]的含义和前面一样,说明数的传输只发生在一个方向上,也就是

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

当前位置:首页 > 总结汇报 > 学习总结

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2