http://www.laotao.cn/default.asp?cat=9

一、功能：1、状态检测包过滤（packet filtering)。2、地址转换(NAT)。3、负载均衡(load alancing)。4、保护敏感信息。5、服务质量保证（QoS）. （我在这里只是简单的说明一些功能，具体的应用，我将在以后的具体实例中说明）
二、在OPENBSD2.9以前，默认的GENERIC内核里面已经包还了ipfilter，这个要看你的内核配置文件里面是不是有OPTIONS IPFILTER 和
OPTIONS IPFILTER_LOG选项，至于ipfilter的使用，在这里就不再详细说明，有兴趣的朋友可以参考FREEBSD的ipfilter的使用方法。 在3.0以后，因为某些这里不再说明的原因，内核中去除了对ipfilter的支持，使用pf来代替他。如果你要使用pf，应该确保你的内核配置文件里面 有如下选项：pseudo-device pf 1 和 pseudo-device pflog 1。在我们现在的版本OPENBSD3.5里面，默认是已经配置了pf的选项。
三、如果要在开机的情况下就启动pf的功能，那么需要修改你的rc.conf文件，包含以下几个内容：
pf=YES,pf_rules=/etc/pf.conf,pflogd_flags= 。
如果你的系统已经启动，而在这个时候，你要开启pf的功能，可以使用#pfctl -e命令来开启，以及#pfctl -d来关闭。并且可以使用#pfctl -e -f /etc/pf.conf来直接开启pf功能并且启动过滤，地址翻译等规则文件。
两外，你需要更改你的sysctl变量：sysctl -w net.inet.ip.forwarding=1 。
四、下面，我们主要来看pf.conf这个主要配置文件的格式以及解释，这个文件可以分为5个部分：1、宏定义部分。2、各个选项。3、scrub。4、地址转换。5、过滤规则。就如同下面的格式划分：
#################################################################
# macro definitions
#################################################################
# options: "set"
#################################################################
# scrub rules: "scrub"
#################################################################
# NAT rules: "rdr", "nat", "binat"
#################################################################
# filtering rules: "antispoof", "block", "pass"
#################################################################
1、对于宏定义部分，大家顾名思义就可以知道，就是定义几个有意义的变量，比如你的服务器ip ，你的内网的各个ip地址段，你的各个网卡所处的位置等。下面举出几个例子：
ser_ip = "192.168.0.1" ##定义了服务器的ip地址
ext_if = "dc0" ##定义了外网卡设备
…………等等。
然后，在下面的各个规则文件就可以直接引用，而不用每次都需要输入一堆的文字。这里就不多说了。需要注意的是，你要引用这里定义的宏，那么需要在变量前面加上“$”符号来表示。
2、下面看一下各个有用的选项，主要包含以下几个关键词：limit , loginterface , optimization , timeout。
在这里有一个技巧，如果你只是更改了options部分的设置，你可以使用#pfctl -f /etc/pf.conf -O仅仅调入options部分的设置，其

他的部分不刷新。这样就不会造成网络的中断。
limit有两个可以设置的量：frags和states后面跟数值。设置一些内存缓冲的规定。1、frags的含义是：可以保存数据包碎片的个数，数据 包碎片会保存在内存中，直到最终超出范围或者重组应用scrub规则。2、states是状态表可以保存的最到的条目数量。这个和下面的规则里面包含的 keep state有关。
下面举一个例子：
set limit frags 30000 ##可以保存30000个数据包碎片。
set limit states 25000 ##可以保存的状态表的条目数量为25000条。
另外的一种格式为：set limit ( frags 3000, states 25000)
可以使用：#pfctl -s memory命令来查看limits的设置。在3.3以前的版本，修改了limits的设置，你需要重新引导机器才能使其起总用，现在使我们高兴的是3.5版本不需要重新引导就可以修改。
loginterface的含义是统计一个网卡经过的数据包的各项数据，比如进入的，发出的，通过的，阻断的等等信息。格式例子为：
set loginterface $ext_if ##这里引用了上面的宏定义，统计外网卡的数据包各项数据。
可以使用：#pfctl -s info命令来查看统计信息。
optimization是一个优化选项，主要是对连接的超时情况，主要有以下几种(options)：
default: 是一个默认的优化选项。
normal: 同上
high-latency: 长连接选项，设置超时时间较长。一般使用在银行系统或者其他卫星系统连接。
satellite: 同上。
aggressive: 定义了比较实时的连接，如果不活跃，就断开。
conservative: 和上面的意思一样，就跟我们拨号上网不活动就断开的意思一样。这个是对一个tcp连接来说的。
optimization options
timeout更加仔细的定义了一些协议的超时情况，不过仅仅对于下面的filter rules中含有keep state的规则起作用。主要的变量有以

下几个(options)：tcp.first ，tcp.opening ，tcp.established ，tcp.closing ，tcp.finwait ，tcp.closed ，udp.first ，udp.single

，udp.multiple ，icmp.first ，icmp.error ，other.first ，other.single ，other.multiple ，frag ，interval。
格式如下：set timeout options time
3、然后介绍scrub规则，这个规则的作用是过滤一些不规则的数据包，这些数据包可能会引起系统的不正常或者是其他程序的错误，

主要还是抵御攻击，一般我们会在所有的interface上面都做上数据包的scrub规则，一般如下：
scrub in all 或者仅仅在你的外网卡做过滤：scrub in on $ext_if all
两外，scrub规则还有更改修复部分数据包的功能，这个暂时我还没有用到，以后再说这一部分。
4、NAT rules，应该知道NAT是干什么用的，我们可以使用命令：#pfctl -f /etc/pf.conf -N 来仅仅调入NAT部分的规则信息，使用

：#pfctl -s nat 来查看NAT的状态，使用：#pfctl -F nat 来刷新规则。下面就具体看一下他的规则格式以及解释，实际应用，我们将再以后

说到：
nat on (if_name) proto (proto_name) from (ip_addreee) to any -> (ip_address)
binat on (if_name) proto tcp from (ip_address) to any -> (ip_address)
rdr on (if_name) proto (proto_name) from any to (ip_addreee) port 80 -> (ip_address) port 8080
我们以一个例子来说明：
#################################################################
# macro definitions
ext_if = "dc0"
ext_ad = "202.202.202.202/32"
ext_ad_1 = "202.202.202.203/32"
dmz_ad="10.10.0.1/32"
ont_ip="10.10.0.2/32"
prv_ads = "{ 192.168.0.0/24, 172.16.0.0/24 }"
nat_p = "{tcp, udp, icmp}"
#################################################################
# NAT rules: "rdr", "nat", "binat"
nat on $ext_if proto $nat_p from $prv_ads to any -> $ext_ad
#就是当内网ip发起对外的请求时（所有的协议）转换内网的地址为外网卡的地址，
binat on $ext_if proto tcp from $ext_ad_1 to any -> $one_ip
#将外网口的一个ip地址与DMZ区域的一个ip地址互相对应。
rdr on $ext_if proto tcp from any to $ext_ad port 80 -> $dmz_ad port 8080
#将所有的向外网口的http请求转换到DMZ区域的$dmz_ad机器的8080端口。
#################################################################
5、ipfilter rules,过滤规则，其实也就是一个访问规则列表，上面的NAT规则可以说是一个通讯规则列表。具体的格式可以参照下面

的列表具体的应用，我们将在以后提到。
#################################################################
过滤动作
pass, 允许
block, 阻塞
选项
log，记录日志
quick,快速匹配规则列表
方向
in, 进来的
out, 出去的
协议
proto, 包括：
tcp, TCP 协议
udp, UDP 协议
icmp, ICMP 协议
[number], 指定其他的IP协议号
[空], 所有协议
源地址
from [addr], 指定一个IPv4地址
from [subnet/mask],指定一个网络
源端口（仅限TCP/UDP协议）
port [表达式] [端口号]
表达式包括：
=
>=
>
<=
<
>< 端口范围
目标地址
to [addr], 指定一个IPv4地址
to [subnet/mask],指定一个网络
目标端口（仅限TCP/UDP协议）
port [表达式] [端口号]
表达式包括：
=
>=
>
<=
<
>< 端口范围
ICMP类型和代码
icmp-type [type]
icmp-code [code]
TCP连接建立
keep state, 建立状态列表，阻塞只有SYN标志位而没有ACK标志位的TCP包，放在规则末尾表示
只允许连接建立后的TCP包通过。
##################################################################

OpenBSD 3.x 防火墙 PF配置新手指南
级别:初学者
Eric Bullen. (ericb-howto@thedeepsky.com)
Sr. Unix Systems Administrator, Incyte Genomics
September 17, 2003

翻译: pengcz (aoma1999@126.com）

从OpenBSD3.0开始，OpenBSD开发团队就采用PF来取代原有IPF。现在，PF已经成为世界级的防火墙解决方案。PF本身提供了许多优秀的 工具来帮助网络工程师创建一个健壮的防护方案来保护公司 的私有网络免受不安全的Internet的侵害。本篇文章的目的是引导你如何一步一步地配置你的PF防火墙，并对每一步进行详细解释，但又不会过于深入免 得初学者混淆。
在继续这篇文章之前你需要弄清楚一些事情，我会概述这些事情使得我们可以深入这篇文章的重要部分。第一件事情是你要有一个OpenBSD 3.0的系统，至小，你应该已经安装了OpenBSD系统。本文是以OpenBSD 3.3系统为例作说明的，当然你也可以找到很多有关配置防火墙的入门书，我的主要目的是教你如何正确地创建和设置PF防火墙。
首先，你要把你的防火墙接入到网络中去（至少网络中有一台电脑）。这样这台电脑可以接收和发送数据包。如果你没有具备这些条件，我们将很难进行测试。通 常，如果一个网络不可用，而你有两台电脑，你可以让两台电脑直接相连（网卡对网卡，用交叉线相连），有关交叉线的制作请参考相关网络资料，通常在电脑配件 市场有这种产品可供购买。如果你计划配置NAT（网络地址转换，这样可以让多台电脑共享一个公网IP地址），那么你的OpenBSD系统要安装有两块网 卡。
没有任何可以比防火墙更保护网络安全的了。当你创建/配置/测试你的防火墙时，对于互联网上的用户来说（理想情况下）这个防火墙应该是不可到达的，这个防 火墙应该位于一个企业网内部。请参考RFC1918 有关私有地址块的事。通常，大部份的内部网络会是192.168.0.0/16 或者10.0.0.0/8。你会发觉设置这些是多么容易的一件事情。如果你发觉设置这些网络有困难，那么我会建议你不要再阅读下去，你应该先去看一些有关 IP网络基础方面参考书。
配置
要激活 PF, 并让系统在启动时自动地加载，请编辑文件你的 /etc/rc.conf.local文件,并添加下面一行到文件中去： pf=YES。 尽管,你也可以编辑 /etc/rc.conf 文件（这个文件中设置的都是系统的默认值）。但我并不建议你去修改它，我建议你修改/etc/rc.conf.local,系统会在最后阅读 /etc/rc.conf.local文件，并用它的值去覆盖系统的默认设置。在我的OpenBSD 系统上的上，/etc/rc.conf.local 文件内容如下：
例1 . /etc/rc.conf.local
#!/bin/sh -pf=YES # Packet filter / NATpf_rules=/etc/pf.conf # Packet filter rules filepflogd_flags= # add more flags, ie. "-s 256"
下一步，创建一个 "pass all" pf.conf 文件，这样在系统启动时，OpenBSD 会读取里面的内容，下面是一个供你使用的好例子：
例2 . /etc/pf.conf
## Macros 宏定义SYN_ONLY="S/FSRA"## TABLES 表## GLOBAL OPTIONS 全局选项## TRAFFIC NORMALIZATION 流量正常化## QUEUEING RULES队列## TRANSLATION RULES (NAT)网络地址转换## FILTER RULES 过滤pass in log all keep state pass out log all keep state
在例2中，你可以看到一些地方是以"##"开头的，它主要用来注释从而让配置文件可读。这些“##”放在这里的一个好处是让你明白PF 是按怎样的顺序如何处理这些规则的。当你看到最后两行以“pass”开头的句子时，你会明白它是记录所有进出防火墙的 。当你的系统创建或者收到连接时，防火墙会记录这些内容到你的/var/log/pflog文件中去。我会告诉你如何读取这些内容(它时一个二进制文件， 对于文本编辑器来说它是不可读的) 。理想情况下，当你配置你的防火墙，机器不会收发到什么数据流除非你的机器自身产生的数据流。如果你是制造数据流的人，你可以看到系统是如何记录日志的. 说到这里,我们应该重启机器并让系统让修改生效,并确认所有设置自动启动.
一旦你的系统重启后，你就可以进行检查你所进行的修改有否生效。你需要象例3一样做，确保接口pflog0已经启用和你的规则已经装载到PF中去
Listing 3. Checking the pflog0 interface and pfctl -s rules output
cerberus:~# /sbin/ifconfig pflog0pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33224cerberus:~# cerberus:~# pfctl -s rulespass in log all keep statepass out log all keep statecerberus:~#
在例3中,你可以看到接口pflog0已经 "UP"了.这会让你让你接上TCPdump到接口，并实时观察流量。正如我上面所说，如果你的系统负荷过重，显示的信息就会一闪而过，你根本看不到什么 有用的信息。你也可以运行 pfctl -s rules,这样你可以看到你的PF装载了那些基本规则（注意在上面我们只用允许让所有流量通过的规则而已）。
Taking it for a Spin
现在,你可以观察一些网络流量了，尽管它们看起来有点困难,但我会告诉你将如何看这些代码。一旦你学会看这些代码，你就能更好地调整你的防火墙来处理网络 的流量。下面的输出是来自TCPdump的一些输出，你只要在命令行下输入TCPdump -n -e -ttt -i 就可以看到防火墙是如何工作的了。
例 4. Reading the output of TCPdump -n -e -ttt -i pflog0
cerberus:~# TCPdump -n -e -ttt -i pflog0TCPdump: WARNING: pflog0: no IPv4 address assignedTCPdump: listening on pflog0Sep 17 17:07:07.833264 rule 37/0(match): pass in on fxp0: 11.22.33.44 > 192.168.1.2: icmp: echo request Sep 17 17:07:07.833486 rule 56/0(match): pass in on fxp1: 192.168.1.2 > 11.22.33.44: icmp: echo reply Sep 17 17:07:32.725126 rule 6/0(match): block in on fxp0: 55.66.77.88.14350 > 66.92.15.252.7777: S 3925150538:3925150538(0) win 5840 <mss 1460,sackOK,timestamp 311538809 0,nop,wscale 0> (DF) Sep 17 17:07:37.443421 rule 14/0(match): pass in on fxp0: 55.66.77.88.14373 > 66.92.15.252.22: S 3920978973:3920978973(0) win 5840 <mss 1460,sackOK,timestamp 311539281 0,nop,wscale 0> (DF) Sep 17 17:07:38.115817 rule 37/0(match): pass in on fxp0: 55.66.77.88 > 192.168.1.2: icmp: echo request Sep 17 17:07:38.116021 rule 56/0(match): pass in on fxp1: 192.168.1.2 > 55.66.77.88: icmp: echo reply^C6 packets received by filter0 packets dropped by kernel
Ok, IP地址为 11.22.33.44 和55.66.77.88 都是假的，是经过我修改真实的IP地址而来的，真实的IP地址不会出现在这里了。IP地址 192.168.1.2是一个内部系统的IP地址，属于一个私有的网络并且经过了防火墙的NAT作业。我会在后面告诉你为什么会在日志记录中出现内部私有 地址而不是外部公网IP地址，如果你等不及的话请参考文档最后部份NAT转换章节。我会从下面的一行中进行分析并解释这一行中各个参数的具体含义：
Sep 17 17:07:37.443421 rule 14/0(match): pass in on fxp0: 55.66.77.88.14373 > 66.92.15.252.22: S 3920978973:3920978973(0) win 5840 (DF)
Sep 17 17:07:37.443421 当前的日期/时间，详细到毫秒级别
rule 14/0(match): 捕捉到的包匹配的规则集号码。你可以输入pfctl -g -s rules| grep '^@'来看PF为那一条规则分配了那一个号码。
pass in on fxp0: 这说明这个包匹配规则并通过，来自fxp0接口， (fxp 是 Intel Pro100 接口). 你可能使用不同的网卡，因此可能会是不同的接口。
55.66.77.88.14373 > 66.92.15.252.22: S 提示源ip:端口 >目的ip:端口，说明一个包的来龙去脉。最后面的S表明这个包的旗帜，在这里表明是SYN旗帜
3920978973:3920978973(0) win 5840 (DF) 忽略这些，这已超出本文档的讨论范围
上面的示例给了你一些基础的认知，教你如何创建你的规则集，如何通过TCPdump来监控网络，你将能够根椐你的具体环境对自己的防火墙进行修订。
现在，我们对TCPdump有了感性的认识并知道如何理解它的输出，同时对pf.conf文件架构有了一些基础的认知，现在让我们来学习pfctl命令的一些开关参数（在这里我只会讨论我们常用到的一些参数） 。
pfctl -d 关闭PF
pfctl -e 启用PF
pfctl -Fa -f /etc/pf.conf 刷新所有 (NAT，过滤，队列，状态，通知，表)规则并得重新装载文件 /etc/pf.conf
pfctl -s rules 报告当前装载的过滤规则集
pfctl -s nat 报告当前装载的过NAT规则集
pfctl -s state 报告当前运行的状态表(非常有用)
pfctl -v -n -f /etc/pf.conf 这并不装载什么规则，它只是让你在装载文件前对文件进行检查，对于测试来说这是非常有用的
Building Something Useful
现在，就让我们卷起袖子，好好深入钻研如何创建一个有用的PF配置文件。在这里，我建议你将你的/etc/pf.conf文件放在一边（做好备份）。我们 从一无所有开始创建我们的配置文件。我们将新配置的文件命名为：/etc/pf.conf-new。刚开始我们以一个简单的配置开始，如果你热心一开始就 创建一个复杂的例子，但运行时所得结果与你设想的不一样，你就会很难发现你的配置错在那里了。好了，让我们开始吧，我们让它来实现一个简单的功能。
通常有两条规则：一是所有末经拒绝的都是允许的，另一条是所有末经允许的都是拒绝的，这两条规则有很大的不同。我会讨论第二条规则，因为相对而言它是更安全的规则，-^-
第一步，你要写下那些端口你是想要开放的。至少，我建议你开放下面的端口： ssh (port 22/TCP), auth (port 113/TCP)和ICMP pings，这是一个好的开始。如果你的机子运行额外的服务（在防火墙上你应该有选择地开启你要的服务，理想情况下你不应该开启额外的服务）你也要打开相 应的服务端口。在下面，我们会用新的规则代替例二中的最后两行规则。
Listing 5. /etc/pf.conf-new
## Macros SYN_ONLY="S/FSRA"EXT_NIC="fxp0"INT_NIC="fxp1"# Your Internet IP goes in the EXT_IP variableEXT_IP="11.22.33.44"# Your private network IP goes in the INT_IP variable# if you have two NICs on the machineINT_IP="192.168.1.1"## TABLES ## GLOBAL OPTIONS ## TRAFFIC NORMALIZATION ## QUEUEING RULES## TRANSLATION RULES (NAT)## FILTER RULES # Block everything (inbound AND outbound on ALL interfaces) by default (catch-all)block all# Default TCP policyblock return-rst in log on $EXT_NIC proto TCP all pass in log quick on $EXT_NIC proto TCP from any to $EXT_IP port 22 flags $SYN_ONLY keep state pass in log quick on $EXT_NIC proto TCP from any to $EXT_IP port 113 flags $SYN_ONLY keep state# Default UDP policyblock in log on $EXT_NIC proto udp all # It's rare to be hosting a service that requires UDP (unless you are hosting # a dns server for example), so there typically won't be any entries here.# Default ICMP policyblock in log on $EXT_NIC proto icmp all pass in log quick on $EXT_NIC proto icmp from any to $EXT_IP echoreq keep stateblock out log on $EXT_NIC all pass out log quick on $EXT_NIC from $EXT_IP to any keep state# Allow the local interface to talk unrestrictedpass in quick on lo0 allpass out quick on lo0 all
在这里我并没有用到PF内置的很酷的特性，因为我们是从最简单开始的。对用户来说可能最困惑的是有关过滤规则中的in与out，通常in与out是相对防 火墙而言的，当你看到一个包是out的，那就意味着它是离开防火墙的，这与接口无关的。如果一个包是in的，那就意味着它是走向防火墙的。
另外一件事我会坚持已见的会是保持规则集易于理解（阅读）。这可能会过于冗余，但方便将近似的规则组成一组，这样人们可以很容易描述意境图，特别是在你创建一个较多规则时特别有用。好了，现在我们继续下面的讨论
# Block everything (inbound AND outbound on ALL interfaces) by default (catch-all)
block all
上面的规则会拒绝所有接口上所有协议的数据，这就确保只有你显式注明的规则、接口才能让数据通过。
block return-rst in log on $EXT_NIC proto TCP all
pass in log quick on $EXT_NIC proto TCP from any to $EXT_IP port 22 flags $SYN_ONLY keep state
pass in log quick on $EXT_NIC proto TCP from any to $EXT_IP port 113 flags $SYN_ONLY keep state

上面三行包括了与TCP相关的所有流量。这三行最大的不同在于关键词“quick”，如果没有“quick”选项，规则会将匹配的包作标记，并按规则处 理，但后面的规则会继续匹配这个包，如果没有什么新规则匹配这个包，那么这个包就由匹配的包标记，如果有新规则匹配这个包，则这个包由新规则标记。这对于 你想对包过滤设置默认行为来说非常方便，接着你可以在后续的规则中设置你想对包进行的处理。但在这里，后面的二行有“quick”选项，那么，如果一个包 匹配了端口22/TCP或者 113/TCP (其他的在规则里面指明的端口也一样处理), 接着它们允许通过防火墙 (因为在规则的开头用的是pass)它不会进行其他额外的处理，理解这一点非常重要。在继续下面的讨论前请好好理解它。
block in log on $EXT_NIC proto udp all
# It's rare to be hosting a service that requires UDP (unless you are hosting
# a dns server for example), so there typically won't be any entries here.

这三行与上面三行非常类似，只不过在这里讨论的不再是ＴＣＰ，而是ＵＤＰ罢了。正如规则所说，很少机器需要监听ＵＤＰ端口，除非你的机器提供ＤＮＳ服务。 通常来说，这部份你不需要过多理会。在这一小节中你应该注意到没有了“quick”选项。因为没有规则匹配，UDP数据包会被静静地丢弃。对于CP端口， 在一端如果端口没有开放，那么对于服务端正确的做法是发回一个 return-reset 信号。但由于UDP 和 ICMP是无状态的，你不用返馈任何其他信息，这也是非常合理的。我想隐藏你有防火墙的事实与你有一个防火墙是一样重要的。没有人需要知道你有一个防火 墙，因为这会给潜在的攻击者提供“你有什么”这方面的信息，如果你有一个服务器在网络上，而这台服务器收到一个UDP包，这个包的目的端口并没有打开监 听，服务器只会丢弃这个包，并不会返馈什么信息。但如果服务器收到的是一个TCP包，服务器会返回一个tcp-reset包告知发送者服务器的发送端并没 有打开这个端口和进行监听。因此，在这点上，如果你的防火墙对一个关闭的UDP端口返馈信息，攻击者就会认为这很大程度上是一个防火墙在目标上，而不是服 务器。
block in log on $EXT_NIC proto icmp all
pass in log quick on $EXT_NIC proto icmp from any to $EXT_IP echoreq keep state

这时这我们讨论ICMP章节。你应该对它有一个清晰的认识，在这里我简单地说一下，正如上所说， ICMP是无状态的， PF可以灵活地处理UDP和ICMP。例如。如果你限制带外ICMP流量，只允许 ICMP-pings，如果你在规则中加上了 "keep state"旗帜，那么PF就会聪明地允许ICMP-replies返回而不用你额外指定一条规则，怎 么样？
block out log on $EXT_NIC all
pass out log quick on $EXT_NIC from $EXT_IP to any keep state

还记得在你的配置文件/etc/pf.conf-new 中第一行就是block all吗，这意味着会阻止所有外出流量和进入的数据（例如：你不能发送任何数据到防火墙外，上面两行表明允许无限制的流量离开防火墙）如果你是极端主义 者，你可以进一步限制网络的流量，只允许指定的数据离开防火墙。如WEB访问。
# Allow the local interface to talk unrestricted
pass in quick on lo0 all
pass out quick on lo0 all

正好上面小节所说， block all规则会阻碍外有接口的所有流量，而这也包括本地接口，我相信你注意到这两行里没有了 "keep state"选项，因为这个选项会占用更多的CPU资源来处理，因此在允许所有流量进出的时候，保持状态没太大的意义。
Final Touches
在这里，使用pfctl命令来来激活你的新规则，并测试它们是否如你所想般工作。由于我喜欢在所有规则上加上“log”选项，因此在pflog0接口上运 行tcpdump时，你会看到记录到的日志条目会记录所有进出的数据，而不论它是允许的还是被拒绝的。如果你看到某些数据被拒绝，现在你想允许它通过，你 可以向你的新配置文件添加规则，并重新装载它，接着你会看到新的规则会起作用了。怎么样，是不是很有成就感呢。
更进一步
完成了上面，你就对PF的基础有了一个很好的理解了，在这里，我会介绍一些有关PF更常用的特性，我想最好的方法是将这些特性添加到你的新的配置文件中去，OK。Let ‘s go
宏
首先让我来介绍PF中的宏，它常用来创建命名（变量），并赋值给它们。如果你要修改这些IP地址什么的 , 那么你要手动更改这些设置.如果你到处使用宏,这些宏不会存在于pf.conf文件中,你只要修改宏定义,接着得新装载配置文件就行了.记住,你可以用宏 来提交任何事情,这包括接口,端口,IP地址,规则等…
表
表是PF提供的一个比较特别的特性。象宏，但你可以更改表而不用重新装载配置文件。如果表中有很多IP（如1000个或以上），PF会做一系列的优化，而这方面宏是没有提供的。你也可以在命令行中添加/删除命令行。PF会自动获取这些新配置。
## TABLES
table <block_hosts> persist
table <private> const { 10/8, 172.16/12, 192.168/16, 224/8 }

通常,你会创一个表，并命名，如"block_hosts",你也可以为这个表添加一个可选的旗帜，如const 或者 persist。 const 意味着一旦你装载了这个表，你就不能从命令行中修改这个表中的值。Persist意味着你这个表是装载到随机访问存储器中去的，因此即使这个表没有什么条 目你也可以加载它，并可向它添加/删除/修改条目或者某些值。通常，如果一个表没有什么条目，PF会卸载它，但persist 这个参数阻止这样的事发生。要想真正在你的规则中添加表，你会象下面的示例一样添加相应的内容，我通常把下面的内容加到我过滤规则 的最头部中去。
# Global filter stuff
block in log quick on $EXT_NIC from <block_hosts> to any
block in log quick on $EXT_NIC from <private> to any

全局选项
这个小段是你定义PF行为的地方。你会发现在这里PF向你提供了大量的选项，我们不会全部涉及，但我会讲一些我们感兴趣的东西。
## GLOBAL OPTIONS
set loginterface $EXT_NIC
set block-policy return

第一行 (set loginterface $EXT_NIC) 通常是每一个用防火墙做解决方案时所必须的选项。这让你能收集一些你感兴趣的统计。通常这些统计是不提供的。下面是一个有关这个统计的输出，我想你也不用我多说到底是什么意思了吧？--
cerberus:~/# pfctl -s info
Status: Enabled for 69 days 07:04:35 Debug: None

Interface Stats for fxp0 IPv4 IPv6
Bytes In 385597759 0
Bytes Out 179194907 0
Packets In
Passed 801631 0
Blocked 190642 0
Packets Out
Passed 713633 0
Blocked 4 0

State Table Total Rate
current entries 16
searches 15272773 2.6/s
inserts 218763 0.0/s
removals 218747 0.0/s
Counters
match 13746071 2.3/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 0 0.0/s
normalize 0 0.0/s
memory 37403 0.0/s

第二行 (set block-policy return)可以看作是 "catch-all"选项，尽管你会在你的规则选项中指定如何处理每个包,一般较为注重安全的网络均为添加这选项,因为当有一些较新的数据网络时,你不 一定会在你的规则中添加有处理这些新出现的数据包的规则
流量正常化
PF不仅仅是传递包的进出,它同时也提供修正错误包(被篡改的包)的能力。下面是一些有关修正错误包的选项。
## TRAFFIC NORMALIZATION
scrub in on $EXT_NIC all fragment reassemble
scrub out on $EXT_NIC all fragment reassemble random-id no-df

# For NFS
scrub in on $INT_NIC all no-df
scrub out on $INT_NIC all no-df

注意我洗刷了进出我的“external”接口的所有数据包。 选项 random-id 用于阻止他人监控系统从而得知有多小台电脑了进行NAT转换。使用random-id ，其他人无法监测这些内容。no-df选项主要是针对使用了NFS服务的接口（如在我自己的内部接口上）。尽管这些没有指明在流量正常化规范里面，但你最 好还是这样做。当你在你的过滤规则后面添加上 modulate state 选项时，它隐藏了某些操作系统的网络堆栈的缺陷。优点是当你的系统是进行端口转发流量时到不同端口时（如80端口的流量发到linux,而25端口的流量 发到Solaros）， 外部监控系统可以检测到这些：1：你运行了两个不同的服务器。每个服务器占用一个端口号。2：你的服务器运行的操作系统。请注意，如果你在TCP过滤规则 中使用了modulate state，你就不需要再使用keep state 选项，同时 modulate state 只与TCP一起工作。
队列
要想清楚地表达PF中有关队列的内容,我想并不是一两句话就可以完成的,在这里我并不想深入地讲述有关队列方面的事,我会专门写一篇PF中队列内容的文档以Unfortunately, to properly discuss PF's
翻译 (NAT)
一个防火墙没有NAT就象一张台只有三条脚一样。防火墙通常是与ＮＡＴ一起工作的。当然，在你的机器上通常有两块网卡，它们会配有不同网段的ＩＰ地址和子 网掩码。在一个典型的防火墙上，你通常会有一个外网接口，用于连接到internet上去，另一个是内网接口，用于连接到内部局域网络，通常这会是集线器 或者交换机。通过ＮＡＴ，你可以做一些非常酷的工作。如公网ＩＰ到私有ＩＰ地映射；将从公网上通发过来的流量根据指定的端口请求转发到内网指定的服务器 上；允许私有网络上的机器通过一个公共的ＩＰ来共享上网。我会对这三个特性进行一一说明。
rdr on $EXT_NIC proto TCP from any to 33.11.33.55 port 25 -> 192.168.1.33 port 25
binat on $EXT_NIC from 192.168.1.55 to any -> 11.22.44.33
nat on $EXT_NIC from 192.168.0.0/16 to any -> 22.33.11.55

你应该还记得上面的宏，第一行基本上说的是将来自外网接口传递给33.11.33.55端口 25 的数据会传给192.168.1.33 端口25。
第二行表明电脑自身IP为192.168.1.55会有属于它的外网IP地址 11.22.44.33 ，这意味着所有离开92.168.1.55的数据包会发往11.22.44.33，同时注意到，所有的过滤规则仍然有效。
最后一行指明NAT在192.168.0.0/16子网内有效。网内机器对外表现为IP地址是 22.33.11.55的机器
注解:这一小节是人们常会用到的 ，请明白NAT发生在所任何过滤之前，这意味着如果你如果对已进行了NAT的IP地址进行过滤，那么你的过滤规则应该指明过滤后的IP地址，而不是它的外部IP地址（你在端口重定向中会用到），好，让我们再看一下下面的范例
pass in log quick on $EXT_NIC proto TCP from any to 192.168.1.33 port 25 keep state

组
尽管，这算不上一个小节，但组的确算是PF一个非常好的特性，它让你组合简单的近似的规则成为一条规则，这样会使你的规则变得简单整洁，用不着我多说，看看下面的例子你就会明白的了:
例一
pass in log quick on $EXT_NIC proto tcp from any to 11.22.33.44 port 80 keep state
pass in log quick on $EXT_NIC proto tcp from any to 11.22.33.44 port 443 keep state
成为
pass in log quick on $EXT_NIC proto tcp from any to 11.22.33.44 port { 80, 443 } keep state

例二
pass in log quick on $EXT_NIC proto tcp from any to 192.168.1.33 port 53 keep state
pass in log quick on $EXT_NIC proto udp from any to 192.168.1.33 port 53 keep state
成为
pass in log quick on $EXT_NIC proto { tcp, udp } from any to 192.168.1.33 port 53 keep state

怎么样？这可以节省文件空间，同时让你的防火墙配置管理更加容易，在上面的表定义中我就用到{ } ，你也可以在你的pf.conf文件中使用这个特性，在任何地方都可以，哈哈。
结论
我希望本文章对你配置PF防火墙有所帮助。通过这篇文章你可以创建一个坚固的PF防火墙，当然，PF还提供了许多的功能还有说到，当你熟悉了PF后你可以尝 试配置使用这些功能。如果你对本文章有任何建议，请发到本文上面所提到的邮箱中，谢谢。
资源
· man 5 pf.conf
· man 8 pfctl

1. 以太网最初基于同轴电缆．1972年发明，1979年Xeroxinter和DEC提出DIX版.

　　2. 1983年，IEEE802.3标准提出.

　　3. CSMA/CD 通讯过程，传输—监听—干扰—随机等待—传输。

　　4. 传统以太网用网桥来分割主机，用路由器连接网段。

　　5. 交换式以太网，平时主机都不连通，当需要通信时，通过交换设备连接对端主机，完成后断开。交换设备包括，交换式集线器和交换机。

　　6. 交换式以太网物理逻辑均为星型。分割冲突域，将网络冲突限制到最小范围。

　　7. RMON共九组，常用的端口统计、历史、告警、事件4组。

　　8. 数据流量区分，按组织行政构成、按主机类型、按物理分布、根据应用类型。

　　9. 80／20规则，80％在本地，20％其他网段。20／80规则，相反。

　　10. 交换机单个百兆口64字节包转发1488810pps，路由器整机64字节包转发小与100100pps。

　　11. 三层交换技术的实现硬件的路由转发，转发路由表也是由软件通过路由协议建立的。

　　12. 三层交换与路由均为根据逻辑地址确定路径、运行三层校验和、使用TTL、对信息处理和相应，分析报文、用MIB更新SNMP管理。

　　13. 三层交换优点：基于硬件包转发、低时延、低花费。

　　14. 四层交换基于数据流，实现一次路由，多次交换。考虑端口号和协议字段。

　　15. 局域网设计原则，考察物理链路、分析数据流特征、采用层次化模型、考虑冗余

　　16. 局域网管理系统功能：配置功能、监控功能、故障隔离。

　　17. 必须保证的网络性能，带宽和时延。其取决的一个重要因素，线缆的类型和布局。

　　18. 为用户增加带宽，增加总体带宽&减少在一个共享介质上的用户数量。

　　19. 快速以太网（100M）标准为802.3u。

　　20. 自协商使用物理芯片来完成，不需要专用的数据报文。发送16bi的报文，整个保文按16ms间隔重复。

　　21. 速率不通过自协商一样可完成，但工作方式会产生问题。一段强制10m全双工，另一端会自协商为10m半双工。

　　22. 自协商优先级：100BASE-TX全双工、100BASE-T4、100BASE-TX、10BASE-T全双工、10BASE-T

　　23. 千兆以太网自协商已经实现，但光纤上的以太网自协商不能成功。

　　24. 交换机属于MDIX设备，PC为MDI设备。物理芯片实现。

　　25. 半双工采用后推压力（backpressure）技术实现，流量控制。

　　26. 全双工流控遵行802.3x标准，采用64字节“PAUSE” MAC帧。该帧采用组播地址01-80-c2-00-00-01。

　　27. PAUSE应用于终端和交换机之间，不能解决稳定状态的拥塞，端到端的流量控制和比简单停－起更复杂的操作。

　　28. 端口聚合只适用于802.3协议族的MAC机制。

　　29. 流控命令 flow－control

　　30. 配置端口聚合（干路）link－aggregation port_num1 to port_num2

　　31. 3526可实现3个以太网分组和一个光分组，每组8个。E0/1、e0/9、e0/17、G1/1

　　32. vlan划分：基于端口、基于mac、基于协议、基于子网

　　33. 虚拟桥接局域网（VLAN）标准－802.1Q。

　　34. 802.1Q定义了vlan的架构（MAC帧格式）、所提供的服务、实施中涉及的协议和算法。

　　35. dot1q标签头包含了2字节标签协议标识（TPID）和两字节标签控制信息（TCL）。TPID固定值0x8100。TCL包括priority、CFI和VLAN ID。

　　36. 所有具有dot1q的标签头的帧为tagged 帧。

　　37. GARP通用属性注册协议，其应用为GVRP和GMRP

　　38. GARP消息有5种，join in、leave、empty、join empty、leave all。

　　39. GVRP是动态VLAN注册协议，开启为gvrp。

　　40. GVRP 分3类：normal 可动态创建、注册和注销vlan。Fixed 允许手工创建和注册vlan，防止vlan的注销和其他接口注册此接口所知vlan。 Forbidden 注销除了vlan1以外的所有vlan，禁止在接口上创建和注册其他vlan。

　　41. PVLAN配置，isolate-user-vlan enable ，建立映射关系后要对接口进行操作必须先解除原来的映射关系。

　　42. trunk只允许缺省vlan不打标签，hybird允许多个vlan 不打标签通过。

　　43. 以太网帧长固定，三层交换机采用与路由器最长地址掩码匹配不同的方法－精确地址匹配处理报文。

　　44. 基于流的交换，第一个报文经过三层处理，其他的进行2次转发。包交换，每个包都要进行三层检查。

　　45. 802.1D生成树协议，在网桥间传递一种特殊的配置信息BPDU。功能：选择根桥、计算最短路径、选出指定网桥、选择个端口、选择包含在生成树上的端口。

　　46. BPDU包括：根桥ID、最小路径开销、指定网桥ID、指定端口ID。

　　47. 网桥ID用网桥优先级和mac地址组合来表示。

　　48. BPDU采用固定mac地址01-80-c2-00-00-00来作为目的地址。SAP值0x42。

　　49. 根桥为网桥ID最小的那个。

　　50. BPDU优先级比较原则：4者依次，最小的为优。

　　51. 拓扑改变消息包括拓扑改变通知消息、拓扑改变应答消息、拓扑改变消息。

　　52. STP定时发送的周期为hello time，配置消息生存周期为message age，最大生存周期为max age。

　　53. 避免临时回路的方法：设置中间状态，阻塞态经过一个forward delay进入中间状态，中间状态经过一个forward delay进入转发态。

　　54. stp 端口的几种状态：disabled 不收发任何报文。Blocking 不接收和发送数据，接受但 不发送bpdu，不进行地址学习。Listening不接收和发送数据，接受并发送bpdu，不进行地址学习。Learning 不接收或转发数据，接受并发送bpdu，开始地址学习。 Forwarding 接受并转发数据，接受并发送bpdu，学习地址。

　　55. mac地址表老化时间值大于生成树重新计算所需时间，一盘情况使用较长值15min，生成树重新计算后使用较短的缓冲区超时值。

　　56. 快速生成树改进：1. 若旧的根端口已经阻塞，新的根端口连接网段的指定端口正好处于转发态，那新的根端口可无延时进入转发。2. 等待进入转发的指定非边缘接口向下游发送一个握手报文，下游若回应赞同，则此接口无延时进入转发。握手必须在点对点链路中，会向下传递握手直到网络边缘。 3. 边缘接口无时延进入转发。

　　57. 点对点链路，1.为聚合链路。2. 端口自协商在全双工模式。3. 端口被配置为全双工。

　　58. STP与RSTP区别：协议版本不同、端口状态转换方式不同、配置消息报文格式不同、拓扑改变消息传播方式不同。

　　59. RSTP也是单生成树实例，网络直径最好不要超过7。

　　60. STP可配参数，网桥优先级32768　步长4096、端口优先级128 步长16、路径开销2w、hellotime 2s／max age 20s／forward delay 15s、交换网络直径7。

　　61. STP 可debug error、packet、event。

　　62. 组播向一组主机发送消息，存在于某个组的所有主机都可接受到消息。组播源只发送一份数据报，杂需要复制的地方会被复制分发，每个网段内都保持有一分数据流。

　　63. 组播应用，多媒体会议、数据分发、实时数据组播、游戏与仿真。

　　64. 组播优势在与提高效率、优化性能和分布式应用。

　　65. 组播基于udp、尽最大努力传送、无阻塞控制、数据报重复和无序缴付。

　　66. 组成员关系协议为主机与路由器间包括IGMP。

　　67. 组播路由协议为路由器与路由器之间包括域内组播路由协议和域间组播路由协议。

　　68. 域内组播密集型 DVMRP 、PIM-DM 、MOSPF。

　　69. 域内组播稀疏性 CBT、PIM-SM。

　　70. 二层组播协议，IGMP snooping、HGMP、HMVR、RGMP、GMRP等。常用的为IGMP snooping。

　　71. 组播地址224.0.0.0 到239.255.255.255。保留组播224.0.0.0 到 224.0.0.255。本地管理组地址239.0.0.0到239.255.255.255. 用户组播地址224.0.1到238.255.255.255.

　　72. 组播mac前三位01-00-5e，后面三位为ip地址后三位10进制转成16进制。

　　73. 224.0.0.1全体用户，224.0.0.2全体路由器，224.0.0.13全体pim路由器。

　　74. 组播转发采用RPF（逆向路径转发），查找组播报是否是从连接相应源地址的接口上转发而来的。而对源地址的检查是通过查询单模路由表来实现的。

　　75. 二层交换机组播功能实现：目的地址为组播mac，端口包含所有接受组播数据的主机端口。

　　76. IGMP V1 RFC1112、IGMP V2 RFC2236。

　　77. IGMP当中，路由器定时发送普通查询消息，根据组成员发送的关系报告来确定特定组是否由主机存在。当主机想加入组，主动发送组成员关系报告。当主机要离 开组时，如果他是组内的最后一个成员则发送离开组消息，若不是则安静的离开。在一定时间内路由器没收到该组的报告，则删除组。

　　78. IGMP当有多个组播路由器时选择查询器，ip最小的为查询器。

　　79. IGMP报告抑制，主机受到查询消息并不立即发送响应报告，随机等待一段时间发送，若在等待当中该组有一个成员发送响应报告了，则就不再发送响应报告。

　　80. IGMP消息有三种，0x11 组播组查询、0x16 版本二组播组查询报告 0x17 表示离开组播组、0x12 表示版本1组播组报告

　　81. IGMP消息封装在IP报文内，协议号为2

　　82. IGMP v2与v1兼容，自动变为v1。

　　83. 解决2层交换机实现组播功能的办法，IGMP监听，针对ipv4，作好用IGMP snooping来避免不必要的组播泛滥。

　　84. 启动组播 multicast routing-enable

　　85. 协议无关多播PIM UDP端口号103 组播地址224.0.0.13

　　86. PIM-DM 密集模式，默认所有接口上都有接收者。扩散－减枝－嫁接。

　　87. 断言机制（assert）当路由器受到其他路由器发来的重复组播数据时，向其发出断言消息，含有本路由器优先级、到源的路径开销、IP地址等信息，到对端比较：优先级低、路由开销小、ip地址大的获胜。本端获胜，对方减枝。

　　88. 周期性发送hello报文到所有PIM路由器，通过hello报文比较，优先级低的为DR，优先级相同IP地址大的获胜。

　　89. 启动PIM-DM，在每个vlan接口上起pim dm。

　　90. PIM-SM稀疏模式，默认没有接受者，所有数据由源发向RP再由RP向网络中转发。SM转发项依靠主机和RPF下游显式发送加入消息建立起来。

　　91. 组播分发树包括最短路径树SPT和汇接点树RPT。切换由最后一跳DR发起，常用流量统计来决定是否切换。

　　92. ACL主要用途：包过滤、报文监控、景像、流量限制CAR、流量统计、分配对列优先级。

　　93. 二层流分类根据帧的数据类型、源／目的mac、封装格式、vlan id、出／入端口。

　　94. 三／四层流分类根结协议类型、源／目的ip、源／目的端口号、dscp。

　　95. 配置时间段 time-range

　　96. ACL 1－99基本 100－199 高级 1000－1999 接口 200－299 基于二层的

　　97. eq 等于gt 大于 it 小于 neq 不等于 range 介于

　　98. 匹配 auto 深度优先 数据报范围最小的语句排在最前。 Config 按用户配置顺序。

　　99. 激活ACL firewall enable packet-filter

　　100. 802.1x基于端口的网络接入控制协议包括用户接入设备、接入控制单元、认证服务器。

　　101. EAP报文四种消息 1 request 2 response 3 success 4 failure

　　102. EAP type字段固定为88－8E

　　103. 802.1x非受控端口传递EAP认证报文，受控端口传递业务报文，只有在通过认证后才会切换到授权状态。状态有：forceAuthorized 一直维持授权状态 ForceUnauthorized 长关模式 Auto 协议控制模式

　　104. 端口受控方式 基于端口（一人过，全过） 基于MAC 基于VLAN

　　105. 802.1x配置 dot1q

　　106. QoS quality of service 服务质量

　　107. 交换QoS优先级标记 流量监管 CAR 端口限速 LR 对列调度

　　108. IP优先级在报文头部TOS域前3bit 取值0－7 802.1P优先级在802.1Q帧头标签的TCL中的priory，3bit 取值0－7。

　　109. 流量监管CAR，使用令牌桶，在输入端口对特定业务流进行监管。CAR在IP层实现。

　　110. traffic－limit 3526没有定义方向，根据ACL来区分。3526E只定义了in方向。

　　111. 端口限速LR，也基于令牌桶，处理二层以下。Line-rate只有3526E支持。

　　112. 3000系列分4个优先队列，3026只支持high和low两个对列。

　　113. 优先级与队列映射 0－1 1－2 2－2 3－2 4－3 5－3 6－4 7－4。

　　114. 严格优先调度，先走高的，在走低的。

　　115. 加权轮循调度 高低的根据比例走。

　　116. 带最大时延的加权轮循调度 高低根据比例，若等待maxdelay后，高的抢占传输。

异常流量监测系统详解

信息来源: ccw

作为一名系统管理员，您是否经常遭遇下列问题？

　　问题一：网络利用率很高，宽带被大量占用，经常有流量暴涨导致网络拥堵——到底是谁在使用网络，在使用网络运行什么程序，导致拥堵的原因是什么，如何找到“凶手”？

　　问题二：网络带宽不足，需要优化，但缺乏统计数据为未来网络建设计划及决策做支撑。

　　问题三：用户抱怨服务器不响应请求，网络中断，但是原因不详——到底是服务器负载太高的原因，还是网络拥堵呢？

　　问题四：希望获得详细的网络管理报表，如：IP地址，服务端口及协议的流量分布等。

　　应用异常流量分析可以解决上述问题，这是网络性能管理重要的一环。其原理就如同医生使用X光、超声波一样，可以透视企业内部网络运作情况，对网络威胁做到一目了然。

　　一、网络异常流量监测技术现状和发展趋势

　　根据对网络异常流量的采集方式可将网络异常流量监测技术分为：基于网络流量全镜像的监测技术、基于SNMP的监测技术和基于Netflow的监测技术三种常用技术。

　　基于网络流量全镜像的监测技术。网络流量全镜像采集是目前IDS主要采用的网络流量采集模式，其原理是通过交换机等网络设备的端口镜像或者通过分光器、网络探针等附加设备，实现网络流量的无损复制和镜像采集。和其他两种流量采集方式相比，流量镜像采集的最大特点是能够提供丰富的应用层信息。

　　基于SNMP的流量监测技术。基于SNMP的流量信息采集实质上是通过提取网络设备Agent提供的MIB（管理对象信息库）中收集一些具体设备及流量信息有关的变量。基于SNMP收集的网络流量信息包括：输入字节数、输入非广播包数、输入广播包数、输入包丢弃数、输入包错误数、输入未知协议包数等。

　　基于Netflow的流量监测技术。Netflow流量信息采集是基于网络设备提供的Netflow机制实现的网络流量信息采集，在此基础上实现的流量信息采集效率和效果均能够满足网络流量异常监测的需求。

　　目前网络异常流量监测技术呈现迅猛发展的态势，技术和产品不断推陈出新，正朝着越来越智能化的方向发展，具体表现在：流量自学习能力，可以更加精确地掌握网络中实际的正常流量的情况，为判断异常流量提供有力的依据；蠕虫攻击特征检测，可以提高已知蠕虫特征的攻击监测准确性，也可以提高监测未知蠕虫攻击的能力；攻击源的自动追溯，可以提高攻击源的定位效率，从而大大提高应急响应的速度。

二、天阗网络异常流量监测系统

　　作为国内IDS行业的领导厂商，启明星辰公司在解决高速入侵检测和实现IDS报警的细、全、准的基础上，推出了用于对网络流量进行宏观监测的产品——天阗异常流量监测系统。天阗异常流量监测系统基于网络流量全镜像的监测技术，同时采用高速的网络流量采集技术、全面的协议识别和分析技术、流量统计和排名分析技术、恶意流量的分析提取技术、流量事件的定义描述技术和自学习的异常检测和发现技术等，天阗异常流量监测系统能够全面地统计和分析网络流量状况，显示网络中不同流量信息的变化和分布趋势，并采用自学习的异常发现模型，及时发现由于蠕虫、拒绝服务攻击等安全事件带来的流量异常并及时报警。

　　系统特点

　　天阗异常流量监测系统是三层分布式结构，由管理控制中心、流量监测中心、流量监测引擎组成。管理控制中心提供集中化的组件管理、图形化的拓扑显示、灵活的流量事件自定义和参数调整以及全面严格的用户管理和审计功能。流量监测中心支持多样化的流量显示方式，并自动生成异常流量的报警信息和异常流量图谱以供查看。流量监测引擎是一台软件与硬件紧密集成的设备，适合部署在千兆级高速网络环境中，全面采集网络流量并形成流量事件上报。

　　天阗异常流量监测系统通过旁路侦听的方式对网络数据流进行采集、分析和识别，实时监视网络系统的运行状态，记录网络中的实时流量信息，发现网络流量的异常变化，并对带有具体特征的恶意流量进行有效提取和连续性监测。系统自动存储网络流量的变化过程的相关信息，并通过分析形成详细的分析报表。这对于用户把握具体攻击事件产生的异常流量的威胁程度或地址分布具有独特的价值。

　　一般的网络带宽占用都比较均匀，如果通过流量监测系统发现某一个IP的流量突然剧增，则原因可能是该主机在进行网络扫描，或者是该主机正在对外大量传播网络蠕虫。如此一来，网络管理员就可以有针对性地对该主机进行检查，以避免恶意扫描攻击或大规模蠕虫传播等事件的发生。以下是天阗异常流量监测系统在实际应用中对网络流量监控的效果图。
 

图一：正常网络流量
 
    
图二：异常网络流量

  
图三：IP流量排名

图四：蠕虫爆发导致的流量异常

系统功能

　　分布式管理和流量查看：可以同时管理部署在不同区域的多个流量监测引擎，支持分引擎的流量信息监测和查询。

　　多样化的全面流量监测和多类型的流量统计模式：流量可以采用多种统计模式，包括协议流量、端口流量、IP地址流量（包括源IP统计、目的IP统计、IP对统计、IP统计）、长度流量、流行蠕虫流量监测、攻击报文流量，时间间隔可以由用户调整。

　　多样化的流量显示图谱：能够产生不同类型的流量状况图谱，用户可以采用曲线图、折线图、柱图等多种方式查看，也可以对比查看详细的流量统计数据。
特定数据内容和攻击报文的流量监测：对于带有特定内容的流量信息，可以采集并显示其统计数据和趋势变化；支持对已知蠕虫、拒绝服务攻击的特征定义，显示恶意流量的变化趋势和统计分布。

　　异常流量发现和报警：能够通过对一个时间窗内历史数据的自动学习，获取包括总体网络流量水平、流量波动、流量跳变等在内的多种网络流量测度，并自动建立当前流量的置信度区间作为流量异常监测的基础。

　　基于滑动时间窗置信区间的检测模型和方法：可以在实际运行中不断自我调整和逼近，自动剔除历史时间窗内的异常历史数据，实现历史时间窗数据与网络实际正常流量行为特征的高度吻合，从而提高了对异常流量报警的准确性。

　　专业化的流量报表：提供了专业的流量数据分析工具，可以设置多种查询条件，按不同流量类型产生统计结果，生成图形化报告，并可根据时间段进行分图输出。

　　流量细化监测和显示：流量细化监测和显示可以帮助用户发现某种可疑流量后，进行细化监测，发现造成可疑流量的具体原因。流量细化监测是指流量监测者得到一种统计流量类型的各个流量分曲线的显示界面，需要其某个单独流量曲线按照另外的分类方式进行分组统计，实现深入流量分析。

　　自定义特征流量监测：用户可以根据自己关心的内容进行重点监测定义，如重要服务器的IP流量、端口流量，显示其状态和变化趋势。用户还可以基于漏洞机理特征、攻击特征定义以及特定入侵检测的事件来监测流量事件，用来发现可能出现的未知攻击或者是某种最新攻击流量的变化趋势。

　　自定义异常流量报警：用户可以根据流量的波动变化范围和不同流量曲线的相对比值，来定义流量的异常报警。自定义异常流量按定义方式分为流量波动异常和流量对比异常。

　　历史流量分析和报告输出：管理控制中心将流量引擎产生的流量统计数据记录到相应的数据库中，通过流量日志分析可以对历史流量查询，了解不同类型的历史流量变化，显示指定时间段的各种流量的报文数、字节数的统计结果和或平均流量大小；通过报表分析还可以产生不同时间段的异常报警事件的详细查询报告；查询结果可以生成对应的报告，输出支持Word、Excel、HTML的常用格式。

　　天阗异常流量监测系统可以通过使用单独的硬件化流量引擎来进行流量监测，也可以作为天阗网络入侵检测系统的附加模块进行使用，是对天阗网络入侵检测系统的有效补充，也是启明星辰所倡导的入侵管理中一个重要组成部分。

　　天阗网络流量异常监测系统可以扩展到骨干网上形成异常流量监测阵列，能够对高速网络进行全面的异常流量监测，目前已在国家级的骨干网上得到成功应用，在预警和抑制“冲击波”、“震荡波”等大规模网络事件中发挥了重要作用。

Linux Advanced Routing & Traffic Control HOWTOBert Hubert

   Netherlabs BV

   bert.hubert@netherlabs.nl

Thomas Graf (Section Author)

   tgraf%suug.ch

Gregory Maxwell (Section Author)
Remco van Mook (Section Author)

   remco@virtu.nl

Martijn van Oosterhout (Section Author)

   kleptog@cupid.suninternet.com

Paul B Schroeder (Section Author)

   paulsch@us.ibm.com

Jasper Spaans (Section Author)

   jasper@spaans.ds9a.nl

Pedro Larroy (Section Author)

   piotr%member.fsf.org

   A very hands-on approach to iproute2, traffic shaping and a bit of
   netfilter.
  _______________________________________________________________________

   Table of Contents
   1. Dedication
   2. Introduction

        2.1. Disclaimer & License
        2.2. Prior knowledge
        2.3. What Linux can do for you
        2.4. Housekeeping notes
        2.5. Access, CVS & submitting updates
        2.6. Mailing list
        2.7. Layout of this document

   3. Introduction to iproute2

        3.1. Why iproute2?
        3.2. iproute2 tour
        3.3. Prerequisites
        3.4. Exploring your current configuration

              3.4.1. ip shows us our links
              3.4.2. ip shows us our IP addresses
              3.4.3. ip shows us our routes

        3.5. ARP

   4. Rules - routing policy database

        4.1. Simple source policy routing
        4.2. Routing for multiple uplinks/providers

              4.2.1. Split access
              4.2.2. Load balancing

   5. GRE and other tunnels

        5.1. A few general remarks about tunnels:
        5.2. IP in IP tunneling
        5.3. GRE tunneling

              5.3.1. IPv4 Tunneling
              5.3.2. IPv6 Tunneling

        5.4. Userland tunnels

   6. IPv6 tunneling with Cisco and/or 6bone

        6.1. IPv6 Tunneling

   7. IPSEC: secure IP over the Internet

        7.1. Intro with Manual Keying
        7.2. Automatic keying

              7.2.1. Theory
              7.2.2. Example
              7.2.3. Automatic keying using X.509 certificates

        7.3. IPSEC tunnels
        7.4. Other IPSEC software
        7.5. IPSEC interoperation with other systems

              7.5.1. Windows
              7.5.2. Check Point VPN-1 NG

   8. Multicast routing
   9. Queueing Disciplines for Bandwidth Management

        9.1. Queues and Queueing Disciplines explained
        9.2. Simple, classless Queueing Disciplines

              9.2.1. pfifo_fast
              9.2.2. Token Bucket Filter
              9.2.3. Stochastic Fairness Queueing

        9.3. Advice for when to use which queue
        9.4. Terminology
        9.5. Classful Queueing Disciplines

              9.5.1. Flow within classful qdiscs & classes
              9.5.2. The qdisc family: roots, handles, siblings and
                      parents

              9.5.3. The PRIO qdisc
              9.5.4. The famous CBQ qdisc
              9.5.5. Hierarchical Token Bucket

        9.6. Classifying packets with filters

              9.6.1. Some simple filtering examples
              9.6.2. All the filtering commands you will normally need

        9.7. The Intermediate queueing device (IMQ)

              9.7.1. Sample configuration

   10. Load sharing over multiple interfaces

        10.1. Caveats
        10.2. Other possibilities

   11. Netfilter & iproute - marking packets
   12. Advanced filters for (re-)classifying packets

        12.1. The u32 classifier

              12.1.1. U32 selector
              12.1.2. General selectors
              12.1.3. Specific selectors

        12.2. The route classifier
        12.3. Policing filters

              12.3.1. Ways to police
              12.3.2. Overlimit actions
              12.3.3. Examples

        12.4. Hashing filters for very fast massive filtering
        12.5. Filtering IPv6 Traffic

              12.5.1. How come that IPv6 tc filters do not work?
              12.5.2. Marking IPv6 packets using ip6tables
              12.5.3. Using the u32 selector to match IPv6 packet

   13. Kernel network parameters

        13.1. Reverse Path Filtering
        13.2. Obscure settings

              13.2.1. Generic ipv4
              13.2.2. Per device settings
              13.2.3. Neighbor policy
              13.2.4. Routing settings

   14. Advanced & less common queueing disciplines

        14.1. bfifo/pfifo

              14.1.1. Parameters & usage

        14.2. Clark-Shenker-Zhang algorithm (CSZ)
        14.3. DSMARK

              14.3.1. Introduction
              14.3.2. What is Dsmark related to?
              14.3.3. Differentiated Services guidelines
              14.3.4. Working with Dsmark
              14.3.5. How SCH_DSMARK works.
              14.3.6. TC_INDEX Filter

        14.4. Ingress qdisc

              14.4.1. Parameters & usage

        14.5. Random Early Detection (RED)
        14.6. Generic Random Early Detection
        14.7. VC/ATM emulation
        14.8. Weighted Round Robin (WRR)

   15. Cookbook

        15.1. Running multiple sites with different SLAs
        15.2. Protecting your host from SYN floods
        15.3. Rate limit ICMP to prevent dDoS
        15.4. Prioritizing interactive traffic
        15.5. Transparent web-caching using netfilter, iproute2, ipchains
                and squid

              15.5.1. Traffic flow diagram after implementation

        15.6. Circumventing Path MTU Discovery issues with per route MTU
                settings

              15.6.1. Solution

        15.7. Circumventing Path MTU Discovery issues with MSS Clamping
                (for ADSL, cable, PPPoE & PPtP users)

        15.8. The Ultimate Traffic Conditioner: Low Latency, Fast Up &
                Downloads

              15.8.1. Why it doesn't work well by default
              15.8.2. The actual scrīpt (CBQ)
              15.8.3. The actual scrīpt (HTB)

        15.9. Rate limiting a single host or netmask
        15.10. Example of a full nat solution with QoS

              15.10.1. Let's begin optimizing that scarce bandwidth
              15.10.2. Classifying packets
              15.10.3. Improving our setup
              15.10.4. Making all of the above start at boot

   16. Building bridges, and pseudo-bridges with Proxy ARP

        16.1. State of bridging and iptables
        16.2. Bridging and shaping
        16.3. Pseudo-bridges with Proxy-ARP

              16.3.1. ARP & Proxy-ARP
              16.3.2. Implementing it

   17. Dynamic routing - OSPF and BGP

        17.1. Setting up OSPF with Zebra

              17.1.1. Prerequisites
              17.1.2. Configuring Zebra
              17.1.3. Running Zebra

        17.2. Setting up BGP4 with Zebra

              17.2.1. Network Map (Example)
              17.2.2. Configuration (Example)
              17.2.3. Checking Configuration

   18. Other possibilities
   19. Further reading
   20. Acknowledgements
     _________________________________________________________________

Chapter 1. Dedication

This document is dedicated to lots of people, and is my attempt to do
something back. To list but a few:

     * Rusty Russell
     * Alexey N. Kuznetsov
     * The good folks from Google
     * The staff of Casema Internet
     _________________________________________________________________

Chapter 2. Introduction

Welcome, gentle reader.

This document hopes to enlighten you on how to do more with Linux 2.2/2.4
routing. Unbeknownst to most users, you already run tools which allow you to
do spectacular things. Commands like route and ifconfig are actually very
thin wrappers for the very powerful iproute2 infrastructure.

I hope that this HOWTO will become as readable as the ones by Rusty Russell
of (amongst other things) netfilter fame.

You can always reach us by writing to the HOWTO team. However, please
consider posting to the mailing list (see the relevant section) if you have
questions which are not directly related to this HOWTO. We are no free
helpdesk, but we often will answer questions asked on the list.

Before losing your way in this HOWTO, if all you want to do is simple
traffic shaping, skip everything and head to the Other possibilities
chapter, and read about CBQ.init.
     _________________________________________________________________

2.1. Disclaimer & License

This document is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

In short, if your STM-64 backbone breaks down and distributes pornography to
your most esteemed customers - it's never our fault. Sorry.

Copyright (c) 2002 by bert hubert, Gregory Maxwell, Martijn van Oosterhout,
Remco van Mook, Paul B. Schroeder and others. This material may be
distributed only subject to the terms and conditions set forth in the Open
Publication License, v1.0 or later (the latest version is presently
available at http://www.opencontent.org/openpub/).

Please freely copy and distribute (sell or give away) this document in any
format. It's requested that corrections and/or comments be forwarded to the
document maintainer.

It is also requested that if you publish this HOWTO in hardcopy that you
send the authors some samples for "review purposes" :-)
     _________________________________________________________________

2.2. Prior knowledge

As the title implies, this is the "Advanced" HOWTO. While by no means rocket
science, some prior knowledge is assumed.

Here are some other references which might help teach you more:

   Rusty Russell's networking-concepts-HOWTO
          Very nice introduction, explaining what a network is, and how
          it is connected to other networks.

   Linux Networking-HOWTO (Previously the Net-3 HOWTO)
          Great stuff, although very verbose. It teaches you a lot of
          stuff that's already configured if you are able to connect to
          the Internet. Should be located in
          /usr/doc/HOWTO/NET3-4-HOWTO.txt but can be also be found
          online.
     _________________________________________________________________

2.3. What Linux can do for you

A small list of things that are possible:

     * Throttle bandwidth for certain computers
     * Throttle bandwidth TO certain computers
     * Help you to fairly share your bandwidth
     * Protect your network from DoS attacks
     * Protect the Internet from your customers
     * Multiplex several servers as one, for load balancing or enhanced
       availability
     * Restrict access to your computers
     * Limit access of your users to other hosts
     * Do routing based on user id (yes!), MAC address, source IP
       address, port, type of service, time of day or content

   Currently, not many people are using these advanced features. This is
   for several reasons. While the provided documentation is verbose, it
   is not very hands-on. Traffic control is almost undocumented.
     _________________________________________________________________

2.4. Housekeeping notes

There are several things which should be noted about this document. While I
wrote most of it, I really don't want it to stay that way. I am a strong
believer in Open Source, so I encourage you to send feedback, updates,
patches etcetera. Do not hesitate to inform me of typos or plain old errors.
If my English sounds somewhat wooden, please realize that I'm not a native
speaker. Feel free to send suggestions.

If you feel you are better qualified to maintain a section, or think that
you can author and maintain new sections, you are welcome to do so. The SGML
of this HOWTO is available via CVS, I very much envision more people working
on it.

In aid of this, you will find lots of FIXME notices. Patches are always
welcome! Wherever you find a FIXME, you should know that you are treading in
unknown territory. This is not to say that there are no errors elsewhere,
but be extra careful. If you have validated something, please let us know so
we can remove the FIXME notice.

About this HOWTO, I will take some liberties along the road. For example, I
postulate a 10Mbit Internet connection, while I know full well that those
are not very common.
     _________________________________________________________________

2.5. Access, CVS & submitting updates

The canonical location for the HOWTO is here.

We now have anonymous CVS access available to the world at large. This is
good in a number of ways. You can easily upgrade to newer versions of this
HOWTO and submitting patches is no work at all.

Furthermore, it allows the authors to work on the source independently,
which is good too.
$ export CVSROOT=:pserver:anon@outpost.ds9a.nl:/var/cvsroot
$ cvs login
CVS password: [enter 'cvs' (without 's)]
$ cvs co 2.4routing
cvs server: Updating 2.4routing
U 2.4routing/lartc.db

   If you made changes and want to contribute them, run cvs -z3 diff
   -uBb, and mail the output to <howto@ds9a.nl>, we can then integrate it
   easily. Thanks! Please make sure that you edit the .db file, by the
   way, the other files are generated from that one.

   A Makefile is supplied which should help you create postscrīpt, dvi,
   pdf, html and plain text. You may need to install docbook,
   docbook-utils, ghostscrīpt and tetex to get all formats.

   Be careful not to edit 2.4routing.sgml! It contains an older version
   of the HOWTO. The right file is lartc.db.
     _________________________________________________________________

2.6. Mailing list

The authors receive an increasing amount of mail about this HOWTO. Because
of the clear interest of the community, it has been decided to start a
mailinglist where people can talk to each other about Advanced Routing and
Traffic Control. You can subscribe to the list here.

It should be pointed out that the authors are very hesitant of answering
questions not asked on the list. We would like the archive of the list to
become some kind of knowledge base. If you have a question, please search
the archive, and then post to the mailinglist.
     _________________________________________________________________

2.7. Layout of this document

We will be doing interesting stuff almost immediately, which also means that
there will initially be parts that are explained incompletely or are not
perfect. Please gloss over these parts and assume that all will become
clear.

Routing and filtering are two distinct things. Filtering is documented very
well by Rusty's HOWTOs, available here:

     * Rusty's Remarkably Unreliable Guides

   We will be focusing mostly on what is possible by combining netfilter
   and iproute2.
     _________________________________________________________________

Chapter 3. Introduction to iproute2

3.1. Why iproute2?

Most Linux distributions, and most UNIX's, currently use the venerable arp,
ifconfig and route commands. While these tools work, they show some
unexpected behaviour under Linux 2.2 and up. For example, GRE tunnels are an
integral part of routing these days, but require completely different tools.

With iproute2, tunnels are an integral part of the tool set.

The 2.2 and above Linux kernels include a completely redesigned network
subsystem. This new networking code brings Linux performance and a feature
set with little competition in the general OS arena. In fact, the new
routing, filtering, and classifying code is more featureful than the one
provided by many dedicated routers and firewalls and traffic shaping
products.

As new networking concepts have been invented, people have found ways to
plaster them on top of the existing framework in existing OSes. This
constant layering of cruft has lead to networking code that is filled with
strange behaviour, much like most human languages. In the past, Linux
emulated SunOS's handling of many of these things, which was not ideal.

This new framework makes it possible to clearly express features previously
beyond Linux's reach.
     _________________________________________________________________

3.2. iproute2 tour

Linux has a sophisticated system for bandwidth provisioning called Traffic
Control. This system supports various method for classifying, prioritizing,
sharing, and limiting both inbound and outbound traffic.

We'll start off with a tiny tour of iproute2 possibilities.
     _________________________________________________________________

3.3. Prerequisites

You should make sure that you have the userland tools installed. This
package is called 'iproute' on both RedHat and Debian, and may otherwise be
found at ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??????.tar.gz".

You can also try here for the latest version.

Some parts of iproute require you to have certain kernel options enabled. It
should also be noted that all releases of RedHat up to and including 6.2
come without most of the traffic control features in the default kernel.

RedHat 7.2 has everything in by default.

Also make sure that you have netlink support, should you choose to roll your
own kernel. Iproute2 needs it.
     _________________________________________________________________

3.4. Exploring your current configuration

This may come as a surprise, but iproute2 is already configured! The current
commands ifconfig and route are already using the advanced syscalls, but
mostly with very default (ie. boring) settings.

The ip tool is central, and we'll ask it to display our interfaces for us.
     _________________________________________________________________

3.4.1. ip shows us our links
[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp

   Your mileage may vary, but this is what it shows on my NAT router at
   home. I'll only explain part of the output as not everything is
   directly relevant.

   We first see the loopback interface. While your computer may function
   somewhat without one, I'd advise against it. The MTU size (Maximum
   Transfer Unit) is 3924 octets, and it is not supposed to queue. Which
   makes sense because the loopback interface is a figment of your
   kernel's imagination.

   I'll skip the dummy interface for now, and it may not be present on
   your computer. Then there are my two physical network interfaces, one
   at the side of my cable modem, the other one serves my home ethernet
   segment. Furthermore, we see a ppp0 interface.

   Note the absence of IP addresses. iproute disconnects the concept of
   'links' and 'IP addresses'. With IP aliasing, the concept of 'the' IP
   address had become quite irrelevant anyhow.

   It does show us the MAC addresses though, the hardware identifier of
   our ethernet interfaces.
     _________________________________________________________________

3.4.2. ip shows us our IP addresses
[ahu@home ahu]$ ip address show
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp
    inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0

   This contains more information. It shows all our addresses, and to
   which cards they belong. 'inet' stands for Internet (IPv4). There are
   lots of other address families, but these don't concern us right now.

   Let's examine eth0 somewhat closer. It says that it is related to the
   inet address '10.0.0.1/8'. What does this mean? The /8 stands for the
   number of bits that are in the Network Address. There are 32 bits, so
   we have 24 bits left that are part of our network. The first 8 bits of
   10.0.0.1 correspond to 10.0.0.0, our Network Address, and our netmask
   is 255.0.0.0.

   The other bits are connected to this interface, so 10.250.3.13 is
   directly available on eth0, as is 10.0.0.1 for example.

   With ppp0, the same concept goes, though the numbers are different.
   Its address is 212.64.94.251, without a subnet mask. This means that
   we have a point-to-point connection and that every address, with the
   exception of 212.64.94.251, is remote. There is more information,
   however. It tells us that on the other side of the link there is, yet
   again, only one address, 212.64.94.1. The /32 tells us that there are
   no 'network bits'.

   It is absolutely vital that you grasp these concepts. Refer to the
   documentation mentioned at the beginning of this HOWTO if you have
   trouble.

   You may also note 'qdisc', which stands for Queueing Discipline. This
   will become vital later on.
     _________________________________________________________________

3.4.3. ip shows us our routes

Well, we now know how to find 10.x.y.z addresses, and we are able to reach
212.64.94.1. This is not enough however, so we need instructions on how to
reach the world. The Internet is available via our ppp connection, and it
appears that 212.64.94.1 is willing to spread our packets around the world,
and deliver results back to us.
[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0  proto kernel  scope link  src 212.64.94.251
10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via 212.64.94.1 dev ppp0

   This is pretty much self explanatory. The first 3 lines of output
   explicitly state what was already implied by ip address show, the last
   line tells us that the rest of the world can be found via 212.64.94.1,
   our default gateway. We can see that it is a gateway because of the
   word via, which tells us that we need to send packets to 212.64.94.1,
   and that it will take care of things.

   For reference, this is what the old route utility shows us:
[ahu@home ahu]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
212.64.94.1     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         212.64.94.1     0.0.0.0         UG    0      0        0 ppp0
     _________________________________________________________________

3.5. ARP

ARP is the Address Resolution Protocol as described in RFC 826. ARP is used
by a networked machine to resolve the hardware location/address of another
machine on the same local network. Machines on the Internet are generally
known by their names which resolve to IP addresses. This is how a machine on
the foo.com network is able to communicate with another machine which is on
the bar.net network. An IP address, though, cannot tell you the physical
location of a machine. This is where ARP comes into the picture.

Let's take a very simple example. Suppose I have a network composed of
several machines. Two of the machines which are currently on my network are
foo with an IP address of 10.0.0.1 and bar with an IP address of 10.0.0.2.
Now foo wants to ping bar to see that he is alive, but alas, foo has no idea
where bar is. So when foo decides to ping bar he will need to send out an
ARP request. This ARP request is akin to foo shouting out on the network
"Bar (10.0.0.2)! Where are you?" As a result of this every machine on the
network will hear foo shouting, but only bar (10.0.0.2) will respond. Bar
will then send an ARP reply directly back to foo which is akin bar saying,
"Foo (10.0.0.1) I am here at 00:60:94:E9:08:12." After this simple
transaction that's used to locate his friend on the network, foo is able to
communicate with bar until he (his arp cache) forgets where bar is
(typically after 15 minutes on Unix).

Now let's see how this works. You can view your machines current
arp/neighbor cache/table like so:
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

   As you can see my machine espa041 (9.3.76.41) knows where to find
   espa042 (9.3.76.42) and espagate (9.3.76.1). Now let's add another
   machine to the arp cache.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms

--- espa043.austin.ibm.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms

[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

   As a result of espa041 trying to contact espa043, espa043's hardware
   address/location has now been added to the arp/neighbor cache. So
   until the entry for espa043 times out (as a result of no communication
   between the two) espa041 knows where to find espa043 and has no need
   to send an ARP request.

   Now let's delete espa043 from our arp cache:
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0  nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale

   Now espa041 has again forgotten where to find espa043 and will need to
   send another ARP request the next time he needs to communicate with
   espa043. You can also see from the above output that espagate
   (9.3.76.1) has been changed to the "stale" state. This means that the
   location shown is still valid, but it will have to be confirmed at the
   first transaction to that machine.
     _________________________________________________________________

Chapter 4. Rules - routing policy database

If you have a large router, you may well cater for the needs of different
people, who should be served differently. The routing policy database allows
you to do this by having multiple sets of routing tables.

If you want to use this feature, make sure that your kernel is compiled with
the "IP: advanced router" and "IP: policy routing" features.

When the kernel needs to make a routing decision, it finds out which table
needs to be consulted. By default, there are three tables. The old 'route'
tool modifies the main and local tables, as does the ip tool (by default).

The default rules:
[ahu@home ahu]$ ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

   This lists the priority of all rules. We see that all rules apply to
   all packets ('from all'). We've seen the 'main' table before, it is
   output by ip route ls, but the 'local' and 'default' table are new.

   If we want to do fancy things, we generate rules which point to
   different tables which allow us to override system wide routing rules.

   For the exact semantics on what the kernel does when there are more
   matching rules, see Alexey's ip-cref documentation.
     _________________________________________________________________

4.1. Simple source policy routing

Let's take a real example once again, I have 2 (actually 3, about time I
returned them) cable modems, connected to a Linux NAT ('masquerading')
router. People living here pay me to use the Internet. Suppose one of my
house mates only visits hotmail and wants to pay less. This is fine with me,
but they'll end up using the low-end cable modem.

The 'fast' cable modem is known as 212.64.94.251 and is a PPP link to
212.64.94.1. The 'slow' cable modem is known by various ip addresses,
212.64.78.148 in this example and is a link to 195.96.98.253.

The local table:
[ahu@home ahu]$ ip route list table local
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
local 10.0.0.1 dev eth0  proto kernel  scope host  src 10.0.0.1
broadcast 10.0.0.0 dev eth0  proto kernel  scope link  src 10.0.0.1
local 212.64.94.251 dev ppp0  proto kernel  scope host  src 212.64.94.251
broadcast 10.255.255.255 dev eth0  proto kernel  scope link  src 10.0.0.1
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 212.64.78.148 dev ppp2  proto kernel  scope host  src 212.64.78.148
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1

   Lots of obvious things, but things that need to be specified
   somewhere. Well, here they are. The default table is empty.

   Let's view the 'main' table:
[ahu@home ahu]$ ip route list table main
195.96.98.253 dev ppp2  proto kernel  scope link  src 212.64.78.148
212.64.94.1 dev ppp0  proto kernel  scope link  src 212.64.94.251
10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via 212.64.94.1 dev ppp0

   We now generate a new rule which we call 'John', for our hypothetical
   house mate. Although we can work with pure numbers, it's far easier if
   we add our tables to /etc/iproute2/rt_tables.
# echo 200 John >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table John
# ip rule ls
0:      from all lookup local
32765:  from 10.0.0.10 lookup John
32766:  from all lookup main
32767:  from all lookup default

   Now all that is left is to generate John's table, and flush the route
   cache:
# ip route add default via 195.96.98.253 dev ppp2 table John
# ip route flush cache

   And we are done. It is left as an exercise for the reader to implement
   this in ip-up.
     _________________________________________________________________

4.2. Routing for multiple uplinks/providers

A common configuration is the following, in which there are two providers
that connect a local network (or even a single machine) to the big Internet.
                                                                 ________
                                          +------------+        /
                                          |            |       |
                            +-------------+ Provider 1 +-------
        __                  |             |            |     /
    ___/  \_         +------+-------+     +------------+    |
  _/        \__      |     if1      |                      /
 /             \     |              |                      |
| Local network -----+ Linux router |                      |     Internet
 \_           __/    |              |                      |
   \__     __/       |     if2      |                      \
      \___/          +------+-------+     +------------+    |
                            |             |            |     \
                            +-------------+ Provider 2 +-------
                                          |            |       |
                                          +------------+        \________

   There are usually two questions given this setup.
     _________________________________________________________________

4.2.1. Split access

The first is how to route answers to packets coming in over a particular
provider, say Provider 1, back out again over that same provider.

Let us first set some symbolical names. Let $IF1 be the name of the first
interface (if1 in the picture above) and $IF2 the name of the second
interface. Then let $IP1 be the IP address associated with $IF1 and $IP2 the
IP address associated with $IF2. Next, let $P1 be the IP address of the
gateway at Provider 1, and $P2 the IP address of the gateway at provider 2.
Finally, let $P1_NET be the IP network $P1 is in, and $P2_NET the IP network
$P2 is in.

One creates two additional routing tables, say T1 and T2. These are added in
/etc/iproute2/rt_tables. Then you set up routing in these tables as follows:

          ip route add $P1_NET dev $IF1 src $IP1 table T1
          ip route add default via $P1 table T1
          ip route add $P2_NET dev $IF2 src $IP2 table T2
          ip route add default via $P2 table T2

Nothing spectacular, just build a route to the gateway and build a default
route via that gateway, as you would do in the case of a single upstream
provider, but put the routes in a separate table per provider. Note that the
network route suffices, as it tells you how to find any host in that
network, which includes the gateway, as specified above.

   Next you set up the main routing table. It is a good idea to route
   things to the direct neighbour through the interface connected to that
   neighbour. Note the `src' arguments, they make sure the right outgoing
   IP address is chosen.
            ip route add $P1_NET dev $IF1 src $IP1
            ip route add $P2_NET dev $IF2 src $IP2


   Then, your preference for default route:
            ip route add default via $P1


   Next, you set up the routing rules. These actually choose what routing
   table to route with. You want to make sure that you route out a given
   interface if you already have the corresponding source address:
            ip rule add from $IP1 table T1
            ip rule add from $IP2 table T2


   This set of commands makes sure all answers to traffic coming in on a
   particular interface get answered from that interface.

   Warning

   Reader Rod Roark notes: 'If $P0_NET is the local network and $IF0 is
   its interface, the following additional entries are desirable:
ip route add $P0_NET     dev $IF0 table T1
ip route add $P2_NET     dev $IF2 table T1
ip route add 127.0.0.0/8 dev lo   table T1
ip route add $P0_NET     dev $IF0 table T2
ip route add $P1_NET     dev $IF1 table T2
ip route add 127.0.0.0/8 dev lo   table T2


   '

   Now, this is just the very basic setup. It will work for all processes
   running on the router itself, and for the local network, if it is
   masqueraded. If it is not, then you either have IP space from both
   providers or you are going to want to masquerade to one of the two
   providers. In both cases you will want to add rules selecting which
   provider to route out from based on the IP address of the machine in
   the local network.
     _________________________________________________________________

4.2.2. Load balancing

The second question is how to balance traffic going out over the two
providers. This is actually not hard if you already have set up split access
as above.

Instead of choosing one of the two providers as your default route, you now
set up the default route to be a multipath route. In the default kernel this
will balance routes over the two providers. It is done as follows (once more
building on the example in the section on split-access):
            ip route add default scope global nexthop via $P1 dev $IF1 weight 1
 \
            nexthop via $P2 dev $IF2 weight 1


This will balance the routes over both providers. The weight parameters can
be tweaked to favor one provider over the other.

   Note that balancing will not be perfect, as it is route based, and
   routes are cached. This means that routes to often-used sites will
   always be over the same provider.

   Furthermore, if you really want to do this, you probably also want to
   look at Julian Anastasov's patches at http://www.ssi.bg/~ja/#routes ,
   Julian's route patch page. They will make things nicer to work with.
     _________________________________________________________________

Chapter 5. GRE and other tunnels

There are 3 kinds of tunnels in Linux. There's IP in IP tunneling, GRE
tunneling and tunnels that live outside the kernel (like, for example PPTP).
     _________________________________________________________________

5.1. A few general remarks about tunnels:

Tunnels can be used to do some very unusual and very cool stuff. They can
also make things go horribly wrong when you don't configure them right.
Don't point your default route to a tunnel device unless you know EXACTLY
what you are doing :-). Furthermore, tunneling increases overhead, because
it needs an extra set of IP headers. Typically this is 20 bytes per packet,
so if the normal packet size (MTU) on a network is 1500 bytes, a packet that
is sent through a tunnel can only be 1480 bytes big. This is not necessarily
a problem, but be sure to read up on IP packet fragmentation/reassembly when
you plan to connect large networks with tunnels. Oh, and of course, the
fastest way to dig a tunnel is to dig at both sides.
     _________________________________________________________________

5.2. IP in IP tunneling

This kind of tunneling has been available in Linux for a long time. It
requires 2 kernel modules, ipip.o and new_tunnel.o.

Let's say you have 3 networks: Internal networks A and B, and intermediate
network C (or let's say, Internet). So we have network A:
network 10.0.1.0
netmask 255.255.255.0
router  10.0.1.1

   The router has address 172.16.17.18 on network C.

   and network B:
network 10.0.2.0
netmask 255.255.255.0
router  10.0.2.1

   The router has address 172.19.20.21 on network C.

   As far as network C is concerned, we assume that it will pass any
   packet sent from A to B and vice versa. You might even use the
   Internet for this.

   Here's what you do:

   First, make sure the modules are installed:
insmod ipip.o
insmod new_tunnel.o

   Then, on the router of network A, you do the following:
ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0

   And on the router of network B:
ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0

   And if you're finished with your tunnel:
ifconfig tunl0 down

   Presto, you're done. You can't forward broadcast or IPv6 traffic
   through an IP-in-IP tunnel, though. You just connect 2 IPv4 networks
   that normally wouldn't be able to talk to each other, that's all. As
   far as compatibility goes, this code has been around a long time, so
   it's compatible all the way back to 1.3 kernels. Linux IP-in-IP
   tunneling doesn't work with other Operating Systems or routers, as far
   as I know. It's simple, it works. Use it if you have to, otherwise use
   GRE.
     _________________________________________________________________

5.3. GRE tunneling

GRE is a tunneling protocol that was originally developed by Cisco, and it
can do a few more things than IP-in-IP tunneling. For example, you can also
transport multicast traffic and IPv6 through a GRE tunnel.

In Linux, you'll need the ip_gre.o module.
     _________________________________________________________________

5.3.1. IPv4 Tunneling

Let's do IPv4 tunneling first:

Let's say you have 3 networks: Internal networks A and B, and intermediate
network C (or let's say, Internet).

So we have network A:
network 10.0.1.0
netmask 255.255.255.0
router  10.0.1.1

The router has address 172.16.17.18 on network C. Let's call this network
neta (ok, hardly original)

   and network B:
network 10.0.2.0
netmask 255.255.255.0
router  10.0.2.1

   The router has address 172.19.20.21 on network C. Let's call this
   network netb (still not original)

   As far as network C is concerned, we assume that it will pass any
   packet sent from A to B and vice versa. How and why, we do not care.

   On the router of network A, you do the following:
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb

   Let's discuss this for a bit. In line 1, we added a tunnel device, and
   called it netb (which is kind of obvious because that's where we want
   it to go). Furthermore we told it to use the GRE protocol (mode gre),
   that the remote address is 172.19.20.21 (the router at the other end),
   that our tunneling packets should originate from 172.16.17.18 (which
   allows your router to have several IP addresses on network C and let
   you decide which one to use for tunneling) and that the TTL field of
   the packet should be set to 255 (ttl 255).

   The second line enables the device.

   In the third line we gave the newly born interface netb the address
   10.0.1.1. This is OK for smaller networks, but when you're starting up
   a mining expedition (LOTS of tunnels), you might want to consider
   using another IP range for tunneling interfaces (in this example, you
   could use 10.0.3.0).

   In the fourth line we set the route for network B. Note the different
   notation for the netmask. If you're not familiar with this notation,
   here's how it works: you write out the netmask in binary form, and you
   count all the ones. If you don't know how to do that, just remember
   that 255.0.0.0 is /8, 255.255.0.0 is /16 and 255.255.255.0 is /24. Oh,
   and 255.255.254.0 is /23, in case you were wondering.

   But enough about this, let's go on with the router of network B.
ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set net