|
级别: 初级
宫一鸣, 中国电信网络安全小组核心成员
2003 年 1 月 01 日
这是理解防火墙文章的第二部分，这一部分将通过实例ipfilter软件的介绍来进一步讨论关于防火墙的几个方面的内容，从而深化读者对防火墙的认识和理解。 第一部分中的一些基本概念在这里可以对照来看，以便更好的理解。
哪些环节需要考虑？
在开始讲述ipfilter以前，有个问题是值得思索的：在防火墙的整个实现过程中，管理员都有哪些环节需要考虑？能够安装防火墙，并让防火墙正常运行起来其实绝非管理员的全部工作。在事关防火墙的全部环节中，有下面几个应该加以考虑的要点：
- 防火墙的功能
这是防火墙实现的最基本的要求，包括两个方面：
首先，也是经常意义上的理解：就是说防火墙是不是提供了必需的功能，如协议分析，地址转换，流量控制，vpn，过滤定制等，无需多讲；
其次，防火墙的关键功能是否被管理员全面认识：在很大意义上这将直接决定防火墙能否工作在一个比较高的水平上。只有管理员能够站在一个比较高的层次上来认识，配置和管理防火墙，防火墙才可能发挥最大的作用。
- 你的防火墙在做什么，测试它
包括四个方面：
- 一个经过仔细配置的的防火墙，可能并不一定会按照管理员的设想顺利工作，一方面可能管理员认为非常完美的配置存在着不容易看出来的差错，另一个非常有可能的情况就是管理员完全错误的理解了一些特定的内容，比如错误的访问控制列规则、first match和last match的不同、混淆了特殊的子网掩码写法等等，这会直接导致和设计思路完全相悖的结果。
- 如有可能，管理员最好能够深入防火墙的内部，去观察和跟踪防火墙的工作状态，比如防火墙对数据包是怎么处理的，防火墙所维护的状态表里面有什么内容，某些要求的功能是如何实现的，防火墙在做这些工作的时候资源消耗情况都是如何等等。
- 管理员必须仔细的考察正在使用，或者可能使用的功能模块，考察这些模块的工作原理，考察这些模块是不是按照你理解和希望的方式工作。一个很好的例子就是：如果防火墙内嵌ids模块，而且ids和防火墙的访问控制联动开关默认是自动打开的，那么一旦ids不能够很好的实现"基于连接"的判断，那么这个糟糕的默认功能会很容易被攻击者利用，通过发送伪造的攻击数据包来使防火墙扮演中断和正常站点的连接的罪魁祸首。
- 无论配置看起来多么简单明了，都要尽可能的去实际测试你的配置，常见的手段都是利用一些特别的软硬件。但是如果对网络安全要求非常高，那么应该考虑将防火墙放置到与被保护网络类似的真实网络环境中（对防火墙而言，看到的都是真实的数据流），然后在防火墙以外尝试对防火墙保护的系统攻击-请注意，此时攻击的数据包是夹杂在真实的数据流中，看防火墙是否如预期的相应，个人认为尤其在配置能够对高层协议和应用进行访问控制的防火墙时，这一点尤其重要。
- 防火墙的弱点
不要相信万无一失的防火墙，不要相信本身没有安全隐患的防火墙。有的时候，防火墙某些模块的工作指标和销售告诉你的是不同的，但这可能也是正常的，作为系统管理员，你必须正视这一点。
具体到防火墙的选择上，checkpoint，netsceen，pix等知名的商用产品当然不错，但是对资金有限的中小型企业，个人用户，很可能这些价格不菲的产品根本无法考虑，怎么办？
对上面的这些用户而言，没有关系，我们还有open source的软件可以使用，这种软件是无需付费的，但是，如果使用得当，这些软件和昂贵的商用产品没有非常明显的差别，一个很好的例子就是本文讲的ipfilter。
ipfilter介绍
在本文的 第一部分中我们定义了几个基本的防火墙类型，大家可以回忆一下基于状态的包过滤防火墙的概念，ipfilter就是属于基于状态的一类软件防火墙，它可以工作在freebsd、openbsd、hpunix、solaris、 irix等多种unix平台上，ipfilter的主页在网址http://coombs.anu.edu.au/~avalon/ip-filter.html，目前的正式版本是3.4.31。
利用ipfilter，管理员可以通过定制多种访问控制规则来管理数据包的进出（基于状态的），此外它还具有地址翻译、负载均衡、透明代理、支持ipv6等等非常实用的功能。
在实际应用中，Ipfilter可以被用于配置在多块网卡的主机上充当网关，对可信和非可信网络实行隔离；此外，ipfilter也可以充当单独的主机防火墙。
软件的安装
软件的安装非常简单，不花费太多的笔墨，读者可以根据软件包里面的readme和install文件的安装步骤做就可以了，不过由于在solaris上有些特殊，有两点需要讲一下，在编译的时候，如果编译64位的包的话，需要使用gcc版本3.0以上的编译器，否则会出现以下错误：
server# make solaris
if [ ! -f netinet/done ] ; then \
(cd netinet; ln -s ../*.h .; ln -s ../ip_*_pxy.c .; ); \
(cd netinet; ln -s ../ipsend/tcpip.h tcpip.h); \
touch netinet/done; \
fi
CC="gcc -Wstrict-prototypes -Wmissing-prototypes" ./buildsunos
Testing compiler gcc for 64 bit object file generation.
No 64 bit capable compiler was found
*** Error code 1
make: Fatal error: Command failed for target `solaris'
|
读者可以从sunfreeware.sun.com上面下载3.0以上的gcc编译器来解决这个问题，目前的gcc3.2就可以。另外有一点要注意，执行完make package后，在SunOS5下面会生成一个ipf.pkg文件，管理员需要使用pkgadd命令分别安装两个模块，如下
server# pkgadd -d ./ipf.pkg
The following packages are available:
1 ipf IP Filter
(sparc) 3.4.31
2 ipfx IP Filter (64-bit)
(sparc) 3.4.31
Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,--,q]: 2
|
注意要先安装ipfx，然后再安装ipf，顺序不可以搞反。两个模块装好后，可以使用如下命令检查是否成功载入内核： server# modinfo | grep ipf 88 102b1e64 27f88 152 1 ipf (IP Filter: v3.4.31)
看到上述输出，这表示ipfilter已经成功载入内核。
访问控制列
下面开始进一步的工作，配置访问控制列，访问控制列对一般的系统管理员而言，应该是不陌生的，我们来看。
Ipfilter可用的访问规则关键字主要包括：端口、源地址/目的地址、TOS、IP OPTION、icmp的类型（type）和代码（code），tcp flags等，一般来说，这些关键字可以单独，也可以混合在一起使用从而完成不同的访问控制功能。
具体的访问控制列是以命令行的方式写在一个配置文件内的，每条访问控制语句一行，以"#"符号开头的表示是注释。配置文件的位置在不同的操作系统有些差别，今天我们所要讲到的solaris环境中默认ipfilter是读取/etc/opt/ipf/目录下的ipf.conf配置文件。
首先从最基本的规则开始： block in all
容易理解，这个规则的意思是拒绝接受所有进入主机的数据包（关键字in，下面会讲到out，对应离开主机的数据包），此时，系统和外界的联系是切断的。这里需要提一下，Ipfilter处理数据包的关键字有两个：block和pass，不象iptables，ipfilter没有drop这个关键字，但实际上block就相当于drop，但配置block时，ipfilter对接收到的数据包悄无声息的丢弃了，而发送数据包的主机得不到任何回应。如果管理员希望给拒绝的主机发送回应，可以在访问控制列内增加icmp error和tcp reset关键字，这个读者可以参考ipfilter文档，不仔细讲述了。
把上面的block替换为pass： pass in all
不用多说，这次允许所有的数据包进入主机。
容易理解是么？ 看看这个规则，
pass in all
block in all
哦，这回有点犯难了，第一条规则允许所有的数据包进入主机，但是紧接着第二条规则又拒绝所有的数据包进入主机，到底结果会是什么样的呢？在回答之前这就要牵涉到一个概念，last match，这是ipfilter对访问控制列处理的原则：如果通过ipfilter的数据包同时符合多条访问控制规则，那么最后一条符合的规则有效，前面符合要求的规则都会被丢弃。
由此，我们就明白了，上面的访问规则中最后一条有效，第一条形同虚设。关于这一点可以再举个极端的例子：
pass in all
pass in all
pass in all
pass in all
block in all
|
虽然写了多条pass in all，但最后一条block in all生效。
再看一个新的关键字quick，上面我们说了：如果通过ipfilter的数据包同时符合多条访问控制规则，那么最后一条符合的规则有效。这里我们还需要补充一点，如果通过ipfilter的数据包同时符合多条访问控制规则，同时这些访问控制规则中都使用了quick关键字，那么对数据包的审核将在第一条使用了quick的访问控制规则处停止，不再继续向下。举例来说明：
pass in quick all
block in all
|
请注意，此时数据包到达防火墙后会在第一条访问控制规则处中止，永远不会去理会第二条。
上面举的都是比较极端的例子，实际的环境中，这种block/pass all的防火墙是没有用处的，下面开始逐步利用访问规则中可用的关键字来充实防火墙的访问控制列。看这个配置：
block in all
pass in from any to any port = 53
block in proto tcp from 192.168.1.1 to any port = 53
|
现在假设客户主机192.168.1.1发送一个tcp类型的数据包到防火墙所在的53端口，会如何？
当数据包到达防火墙时，ipfilter会根据访问控制列对数据包进行审核，首先，这个数据包符合第一条要求，而且没有使用quick，那么继续向下，第二条同样符合要求但是没有使用quick，接着向下比较，符合最后一条要求，好的，最后一条要求生效，最后的结果是这个数据包被屏蔽了-请记住last match。
稍微改动一下第二条规则，如下：
block in all
pass in quick from any to any port = 53
block in proto tcp from 192.168.1.1 to any port = 53
|
请注意第二个访问控制列的关键字quick，因为数据包符合这条访问控制规则，ipfilter对该数据包的处理到此为止，该数据包被允许通过，而不会再向下比较。
仔细的观察上面所写的访问控制列，可以发现所有的访问控制规则在数据包方面上都使用的是in关键字，没有out，那么ipfilter会允许数据包出去么？会的，默认情况下，ipfilter是允许从内部发送任何数据包的（pass out all）。但是从安全性考虑，允许所有的数据包从内部向外发送可不是一个好主意。这是设计防火墙时系统管理员应该考虑到的一个问题。
下面我们来介绍关键字keep state，Ipfilter的状态表的内容包括数据包的来源/目的ip地址、来源/目的端口、时间、以及数据包的sequence number（对于tcp连结）、数据包的标志符等（对于tcp连结）。关于基于状态的概念，在 第一部分已经做了介绍，这里不再重复，ipfilter就是能够跟踪数据流的状态的基于状态的防火墙，为了方便理解我们这里可以这样来看ipfilter的keep state工作原则：任何正常的网络连接，无论使用tcp、udp、还是icmp协议，都必然是有始有终的，如果防火墙的访问控制列允许了通讯的开始数据包，那么就没有理由中断后续的数据包。所以，如果一个网络连接被证明通过了ipfilter的访问控制列，处于了正常的连接状态，那么对后续的数据包将不再花费时间进行整个访问控制列的判断，而是和内存中的状态表进行对比，如果确实是有效的后续包，则立刻放行。这一点我们将在后面观察ipfilter部分来证实。假设本文的 第一部分举的那个例子被ipfilter保护的是一台不向外界提供任何服务的主机，但是主机上的用户有浏览外面的www的要求，如果是配置传统包过滤防火墙的话，虽然本主机不需要向外界提供任何服务，但是因为要允许主机向外发出的web访问的数据包回来，可能需要静态开放1023以上的全部端口。而使用ipfilter的话，在访问控制的out上使用keep state关键字，就不需要考虑回应进入系统的数据包的端口问题，即使访问控制列中禁止了所有的数据包进入！写成访问控制列的话，如下：
block in quick all
pass out proto tcp from any to any port = 80 keep state
|
尽管第一条就是个带quick关键字的block all，但是这丝毫不会影响主机向外浏览www的网络通讯，回送的数据包会毫无障碍的进入主机内。
好了，对keep state理解了，关于访问控制里面的主要内容也就可以结束了，关于各种访问控制关键字的使用及组合很简单，就是在上述基本概念上变化，这里不再多讲，可以参看ipfilter的文档或者多看几个访问控制文件就可以了。
观察ipfilter
防火墙配置完毕，正常运行了，但是到底防火墙工作的状态如何呢？
通过在访问控制列里增加的log关键字，管理员可以观察防火墙的相应访问控制语句对数据包的处理情况，如下例： pass in log level local5.info quick from any to any port =110
防火墙将会将所有的试图连接被保护的机器的110端口网络连接记录下来，注意这里的level local5.info，在ipfilter上默认是使用level local0.info，我们可以象本例改为自己喜欢的level。
实际例子 下面我们来写一个完整的ipfilter访问控制文件，并介绍几个ipfilter比较常用的命令文件，然后我们将利用这个访问控制文件和下面介绍的命令来观察ipfilter的运行情况。
Ipf.conf
pass in quick proto tcp/udp from any to any port = 53 keep state
pass in log level local0.info quick proto tcp from clientA to any flags S keep state
pass in log level local0.info quick proto icmp from any to any icmp-type 3 keep state
block in log level local0.info quick proto tcp all
pass out quick proto tcp/udp from server to any port = 53 keep state
block in log level local0.info quick all
block out log level local0.info quick all
|
这是个非常基本的访问控制文件，从这个文件的内容我们可以看出这个系统需要防火墙提供如下访问控制规则
| 源地址 |
目的地址 |
源端口 |
目的端口 |
数据包类型 |
动作 |
| ANY |
server |
ANY |
53 |
TCP/UDP |
ALLOW(KeepState) |
| clientA |
server |
ANY |
22 |
TCP(带有s标志) |
ALLOW(KeepState) |
| ANY |
server |
\ |
\ |
ICMP（type 3） |
ALLOW(KeepState) |
| Server |
ANY |
ANY |
53 |
TCP/UDP |
ALLOW(KeepState) |
| ANY |
ANY |
ANY |
ANY |
ANY |
BLOCK |
Ipfstat：本程序主要用于对访问控制列相关的内容，常用的有
Ipfstat -in 对访问控制列的input语句进行编号，输出如下：
server# ipfstat -in
@1 pass in quick proto tcp/udp from any to any port = domain keep state
@2 pass in log level local0.info quick proto tcp from clientA to any flags S/FSRPAU keep state
@3 pass in log level local0.info quick proto icmp from any to any icmp-type unreach keep state
@4 block return-rst in log level local0.info quick proto tcp from any to any
@5 block in log level local0.info quick from any to any
|
命令输出了input语句的编号，这个编号利用ipmon监控数据包时会用到，后面我们要讲到。
ipfstat -on 同理，对访问控制列的output语句进行编号
@1 pass out quick proto tcp/udp from server to any port = domain keep state
@2 block out log level local0.info quick from any to any
|
Ipfstat -hi 统计input的访问控制列的hit值
server# ipfstat -hi
10087671 pass in quick proto tcp/udp from any to any port = domain keep state
2 pass in log level local0.info quick proto tcp from clientA to any flags S/FSRPAU keep state
302823 pass in log level local0.info quick proto icmp from any to any icmp-type unreach keep state
5653 block return-rst in log level local0.info quick proto tcp from any to any
283155 block in log level local0.info quick from any to any
|
我们看到这一次每条访问控制语句前面有一个值，这是符合该控制列的网络连结数，比如有10087671次对本机的53端口的tcp/udp网络连接访问。同样道理，ipfstat -ho统计output的访问控制列的hit值
ipfstat -t 用类似unix里面top命令的界面输出ipfilter状态表内的网络连接session内容。
Src = 0.0.0.0 Dest = 0.0.0.0 Proto = any Sorted by = ttl
Source IP Destination IP ST PR #pkts #bytes ttl
clientA,32851 server,22 4/4 tcp 241 57725 119:59:59
clientA,32849 server,22 4/4 tcp 310 31957 119:41:13
clientB,1192 server,53 0/0 udp 2 234 1:03
|
我们可以观察这个输出的内容，除了ST列和ttl列，其他都比较容易理解，对于ST而言，如下表格可以参考
| 数值 |
状态 |
意义 |
| 0 |
TCPS_CLOSED |
closed |
| 1 |
TCPS_LISTEN |
listening for connection |
| 2 |
TCPS_SYN_SENT |
active, have sent syn |
| 3 |
TCPS_SYN_RECEIVED |
have sent and received syn |
| 4 |
TCPS_ESTABLISHED |
established |
| 5 |
TCPS_CLOSE_WAIT |
rcvd fin, waiting for close |
| 6 |
TCPS_FIN_WAIT_1 |
have closed, sent fin |
| 7 |
TCPS_CLOSING |
closed xchd FIN; await FIN ACK |
| 8 |
TCPS_LAST_ACK |
had fin and close; await FIN ACK |
| 9 |
TCPS_FIN_WAIT_2 |
have closed, fin is acked |
| 10 |
TCPS_TIME_WAIT |
in 2*msl quiet wait after close |
而ttl是网络连接session的time to live时间。
ST和ttl是直接和状态有关的，确切的讲，ST的状态直接决定了ttl的时间，对于tcp而言，处于ST 4/4（established）状态的网络连接就进入ttl长时间确认状态，从上面的输出中，可以看到两个tcp的连结都进入了4/4状态，那么，此时连结的idle时间就从120小时开始倒计时。在这120小时内已经连结的网络通讯即使没有任何数据包传送，网络连接也不会中断。一个很有意思的现象是，如果client端非正常中断已经建立的网络连接（比如突然关电），由于server端没有收到任何数据包，在内存中这个连结一直会持续，直到 idle时间到期。
从上面的输出中，我们还可以看出，对于udp而言，没有established这个概念，但是有效的udp连结会进入2分钟的idle状态。
以上我们看到的是正常的进入连结状态的情况，下面来看一个非正常连结的例子：从client连结server端的22端口，但是在client端上我们配置另外一个防火墙无声息的drop到从server端回送给client端的数据包，也就是说对server而言，可以收到client的syn数据包，server随后回送syn/ack，但是由于client端drop掉了syn/ack数据包，client端没有响应server，所以server收不到任何回应，那么server应该处于等待状态，等待三次握手完成。
实际例子如下：在一台redhat主机上利用iptables如下命令 iptables -I INPUT 1 -s clientA -j DROP
屏蔽从server回送的数据包，然后用hping构造一个访问server端口22的标志位为S的数据包 [yiming@clientA]# hping server -S -p 22 -c 1
此时，在server端上ipfstat -t的输出如下 clientA,2073 server,22 2/3 tcp 3 156 3:58
我们看到此时ST为 2/3，对应上面的ST表，左边的2表示client端已经发送了syn，而右边的3表示server收到了client的SYN并回送了SYN，状态表内此次连结就进入了tcp-timeout状态，ttl时间变为4分钟，并开始倒计时。
作者建议有能力的管理员可以利用发送数据包工具对ipfilter所在系统发送不同种类的数据包，观察ipfilter的不同表现和处理方法，从而更好的掌握ipfilter。
ipmon
ipfilter软件本身将日志发送到/dev/ipl，无法直接读取，但是管理员可以通过ipmon命令来对日志进行实时观察，调整ipmon参数可以将可读的日志发送到屏幕，文件或者传给syslog。常见的ipmon的输出如下 Dec 20 11:18:47 server ipmon[8366]: 11:18:46.948876 hme0 @0:5 b clientb -> server PR icmp len 20 88 icmp echo/0 IN 前面几列的都很好理解，我们把后面的单独拿出来看
| hme0 |
@0:5 |
b |
clientb -> server |
PR icmp |
len 20 88 |
icmp echo/0 |
IN |
| 物理端口 |
生效的访问控制语句 |
防火墙动作 |
数据包方向 |
协议类型 |
数据包包头长度，总长度 |
数据包类型 |
数据包方向 |
下面我们将通过ipmon来观察ipfilter对数据包的处理情况，
server#ipmon -a
20/12/2002 10:48:21.899900 STATE:NEW clientA,4970 -> clientA,22 PR tcp
20/12/2002 10:48:21.899905 hme0 @0:2 p clientA,4970 -> clientA,22 PR tcp len 20 64 -S K-S IN
20/12/2002 10:48:21.900035 hme0 @0:2 p clientA,22 -> clientA,4970 PR tcp len 20 64 -AS K-S OUT
20/12/2002 10:48:21.900419 hme0 @0:2 p clientA,4970 -> clientA,22 PR tcp len 20 52 -A K-S IN
20/12/2002 10:48:21.915475 hme0 @0:2 p clientA,22 -> clientA,4970 PR tcp len 20 75 -AP K-S OUT
|
请注意观察上面的内容，第二行里我们看到client向server发送了syn的数据包，并带了KeepState的标志，再看第三行，server给client回送了syn/ack，注意此时server也处于keepstate状态，注意这一条生效的访问控制语句是@0:2，尽管数据包是由向外回送给client的（应该由out部分来检查），但ipfilter根本没有检查控制数据包的out访问控制列，它只是去和内存中的状态表中的session（K-S）对比。
ipfilter的安全问题
本文在一开始的时候就提到了没有绝对安全的防火墙，下面我们来考虑一下ipfilter的可能安全问题，对于ipfilter这样的基于状态的防火墙而言，有一个安全噩梦，那就是拒绝服务攻击，尽管管理员可以采用调整扩大ipfilter的状态表，减小ttl时间从而加快session释放等方法来尽量增加DoS的难度，但是无论如何，状态表的容量总是有限的，发起攻击者通过精心构造数据包，往往能够快速的摧毁ipfilter所在系统的服务。
对基于状态的防火墙而言，目前成熟的拒绝服务攻击核心其实就是两种，构造大量的SYN数据包或者UDP数据包淹没防火墙的状态表。很不幸，ipfilter在这两种攻击下都显得很脆弱，但是，打算使用ipfilter的管理员不要沮丧，商用的checkpoint、pix、netscreen等产品也都有这个问题，就象我们前面讲的，管理员要正视安全产品的问题。
除了上述共性问题外，作者还发现ipfilter的一个安全问题，在ipfilter在状态实现中，对于收到的带有ack标志的tcp数据包如果来源ip是允许的，那么它总是会认为该连结处于TCPS_ESTABLISHED状态，只不过受ipfilter保护的系统根据tcp实现会对孤立的ack复位发送rst数据包，ipfilter看到这个rst数据包后，会将session标记为完成状态，进入1分钟倒计时，计时结束，这个session就从状态表中丢弃；但是，由于ipfilter不检查数据包的checksum，而受ipfilter保护的系统的应用会检查数据包的checksum，假如攻击者故意发送checksum错误的源ip是可信的数据包，防火墙根据访问控制列放过了该数据包，在内存中登记了该状态包，并等待应用程序对该数据包的响应，但是由于checksum错误，应用程序会无声无息的丢弃该数据包，那么问题就来了，防火墙由于没有看到应用程序回应的带rst标志的数据包，会在establish状态中等待ttl长达120小时！
来做个有趣的实验看看：在clientA上用hping发送ack标志的tcp数据包到目的端口22
[yiming@clientA]# hping server -A -s 1234 -p 22 -c 1
HPING server (eth0 server): A set, 40 headers + 0 data bytes
len=46 ip=server flags=R DF seq=0 ttl=62 id=38975 win=0 rtt=0.4 ms
|
同时我们在server上抓包如下：
server#tcpdump host clientA
tcpdump: listening on hme0
17:09:27.566053 clientA.1234 > server.22: . ack 4103395700 win 512
17:09:27.566070 server.22 > clientA.1234: R 1794127092:1794127092(0) win 0 (DF)
|
再用 ipfstat -t看 clientA,1234 server,22 4/0 tcp 2 80 0:52
我们看到这个数据包顺利的通过了防火墙server，并且在单方向上进入了4状态，只是由于防火墙后面server端的ssh复位了单独的ack数据包。连结才变为了等待结束的1分钟倒计时状态。
下面发送错误的checksum数据包，
[yiming@clientA]#hping server -A -s 1235 -p 22 -c 1 -b
HPING server (eth0 server): A set, 40 headers + 0 data bytes
|
抓包看：
server#tcpdump host clientA
tcpdump: listening on hme0
17:11:02.134593 clientA.1235 > server.22: . ack 1421452763 win 512
|
我们看到系统简单的丢弃了数据包，没有响应。此时再看状态表 clientA,1235 server,22 4/0 tcp 1 40 119:59:48
ipfilter的状态表内增加了一条ttl长达120小时的session纪录！
在作者的实验中，利用ipfilter的这个安全隐患，攻击者可以在远程攻击ipfilter主机，并在几分钟内使目标系统彻底瘫痪！
除此以外，目前版本的ipfilter还缺乏流量控制（在4.0版本预计出现），访问控制生效时间等功能，但安全总是动态和相对的，综合来讲，我们依然认为这是个非常好的防火墙软件，在熟练而审慎的管理员手中，如果运用得当，和昂贵的商用产品没有非常明显的差异。
结束语
这是理解防火墙文章的第二部分， 这一部分将通过实例ipfilter软件的介绍来进一步讨论关于防火墙的几个方面的内容，本文力图通过对ipfilter的基本概念、软件安装、使用方法、防火墙测试等几个方面的介绍来探讨关于防火墙应用的几个问题，并希望由此能够进一步深化读者对防火墙的认识和理解。
参考资料
关于作者
|
