IP Filter Based Firewalls HOWTO（9）

　　 
　　IP Filter Based Firewalls HOWTO
    7.2 ipmon

ipfstat对收集在系统上发生的事情很有用，但是它还不能够方便且及时的查看日志。ipmon是一个工具，它有能力查看包过滤的日志(关键字log产生的日志)，状态日志，或者是nat日志以及由它们三者共同产生的日志。这个工具可以在前台运行也可以在后台运行(将日志传给syslogd或者一个文件)。如果我们想看状态表的当前情况，可以运行ipmon -o S
# ipmon -o S
01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 -> 20.20.20.15,53 PR udp
01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 -> 128.167.1.69,123 PR udp
01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 -> 128.173.14.71,123 PR udp
01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 -> 20.20.20.15,53 PR udp Pkts 4 Bytes 356
01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp
01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp Pkts 63 Bytes 4604

我们可以看到有一条外部机器向我们的dnssever发送dns请求的状态条，两条xntp ping到时间服务器，一条短暂的向外的ssh连接。
ipmon也可以显示哪些数据包被日志记录了。例如
# ipmon -o I
15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp len 20 1488 -A

它们的含义分别是时间戳 接口 规则 阻止 源地址，端口 -> 目的地址，端口 协议 tcp 包长度 20 1488 ACK
最后我们看一下NAT表
# ipmon -o N
01/08/1999 05:30:02.466114 @2 NAT:RDR 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816]
01/08/1999 05:30:31.990037 @2 NAT:EXPIRE 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816] Pkts 10 Bytes 455

这是一条重定向的规则，用于在我们的防火墙后面提供规则的场合。

8．ipfilter的特殊用法

8.1 基于服务器和标志的deep state

保存状态很有用，但是很容易犯错。通常，你在第一条与数据包进行交互的规则中加入keep state，一个普遍的错误是混合了状态跟踪和基于标志的过滤：
block in all
pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S
pass out all keep state

这几条规则的本意是允许客户机与服务器20.20.20.20进行te.net连接，如果你在试验这规则你会发现它能够马上起作用，由于我们是对SYN进行匹配的，状态条是不能够做到4/4的(不完整状态)，这个状态默认的超时是60秒。
我们可以重写规则来解决这个问题：
1)

block in all
pass in quick proto tcp from any to 20.20.20.20/32 port = 23 keep state
block out all

或者
2)

block in all
pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S keep state
pass out all keep state

这两组规则的任何一组都可以为每个连接建立完整的状态条。

8.2 解决ftp

ftp有两种不同的传输模式，防火墙管理员不得不解决ftp的这些问题。更糟的是ftp客户机和服务器的问题是不一样的。
ftp协议里面有两种数据传输模式，主动和被动。主动传输是服务器向客户机的一个开放端口进行连接然后传数据。相反地，被动传输是客户机向服务器发起连接并接受数据。

8.2.1 运行ftp服务

在运行ftp服务中，处理主动ftp的连接是比较简单的。而处理被动ftp则是一个大问题。首先我们先讨论怎样处理主动ftp，然后是被动ftp。通常主动ftp就像一个进入的http或者smtp连接：我们只要打开ftp端口并keep state就可以了：
pass in quick proto tcp from any to 20.20.20.20/32 port = 21 flags S keep state
pass out proto tcp all keep state

这两条规则允许主动ftp连接，这是最常见的类型。
下面是处理被动ftp连接。web浏览器默认是这种情况，它变得越来越流行，因此我们必须支持它。被动ftp的问题是针对每个被动连接，ftp服务器必须重开一个新端口(通常是1023以上)。这就像是在服务器上提供一个新的服务。如果我们的防火墙默认策略是禁止的，那么这个新的服务将被阻止，ftp会话就中断了。但是我们还有别的办法可以解决这个问题。
也许有人会打开所有1023以上的端口来解决这个问题。事实上，这个方法确实能够解决问题，尽管它令人不太满意：
pass in quick proto tcp from any to 20.20.20.20/32 port > 1023 flags S keep state
pass out proto tcp all keep state

打开所有1023以上的端口，我们将面临一些潜在的危险。端口1-1023是提供给服务进程使用的，众多的程序决定使用1023以上的端口，比如nfsd和X
幸运的是ftp服务进程可以自己决定哪个端口分配给被动连接。这意味着你可以仅仅打开15001-19999端口作为ftp的端口，而不是打开所有1023以上的端口。在wu-ftpd里面，可以在ftpaclearcase/" target="_blank" >ccess中指定被动端口。请参考ftpaccess的手册。ipfilter所需要做的仅仅是建立相应的规则：
pass in quick proto tcp from any to 20.20.20.20/32 port 15000 >< 20000 flags S keep state
pass out proto tcp all keep state

如果这样还不能使你满意的话，你只好修改ipf来支持ftp或者修改ftp来支持ipf。

原文转自：http://www.ltesting.net