ファイアウォール設定

ipfw	[ -cq] add rule

ipfw	[ -acdefnNStT][ set N]{ list | show}[ rule | first-last ...]

ipfw	[ -f | -q][ set N] flush

ipfw	[ -q][ set N]{ delete | zero | resetlog}[ number ...]

ipfw	set [ disable number ...][ enable number ...]

ipfw	set move [ rule] number to number

ipfw	set swap number number

ipfw

set show

SYSCTL ショートカット

ipfw	enable { firewall | altq | one_pass | debug | verbose | dyn_keepalive}

ipfw	disable { firewall | altq | one_pass | debug | verbose | dyn_keepalive}

検索テーブル

ipfw	table number add addr[ / masklen][ value]

ipfw	table number delete addr[ / masklen]

ipfw	table { number | all} flush

ipfw	table { number | all} list

DUMMYNET 設定 (トラフィックシェイパとパケットスケジューラ)

ipfw	{ pipe | queue | sched} number config config-options

ipfw	[ -s [ field]]{ pipe | queue | sched}{ delete | list | show}[ number ...]

カーネル内 NAT

ipfw	[ -q] nat number config config-options

ipfw	[ -cfnNqS][ -p preproc [ preproc-flags]] pathname

コマンドオプション

ipfw を呼び出すとき、次の一般的なオプションが利用可能です:

-a

規則をリストするとき、カウンタ値を表示します。 show コマンドは、このオプションの意味も含みます。

-b

アクションとコメントのみを表示します。規則のボディは、表示しません。 -c が暗黙のうちに指定されます。

-c

規則を入力したり参照したりするときに、コンパクトな書式で規則を表示します。すなわち、規則が何の追加情報も持たないとき、"ip from any to any"文字列を省略します。

-d

リストするとき、静的規則に加えて動的規則も表示します。

-e

リストし、 -d オプションが指定されているとき、期限切れの動的規則も表示します。

-f

誤って使用すると問題を起すかもしれないコマンド、すなわち、 flush、に対して確認を求めません。プロセスに関連する tty がないなら、これが、暗黙のうちに意味されます。

-i

テーブルをリストするとき、 (検索テーブルに関する詳しい情報については、下記の 検索テーブル セクションを参照) 形式は、IP アドレスとして評価します。デフォルトで、値は、整数として表示されます。

-n

コマンド文字列の文法だけをチェックし、実際には、カーネルには渡しません。

-N

出力に含まれるアドレスとサービス名の名前解決を試みます。

-q

add, nat, zero, resetlog または flush コマンドを実行するとき、静かにします。 ( -f の意味も含みます)。スクリプト (例えば、‘ sh /etc/rc.firewall’) で複数の ipfw コマンドを実行することによって、またはリモートログインセッションに経由で多くの ipfw 規則があるファイルを処理することによって規則セットを更新するとき、これは役に立ちます。また、(追加の場合) エントリが既に存在しているか、または (削除の場合) 存在していないならテーブルの追加または削除を停止します。

このオプションが重要である理由は、 ipfw がメッセージを印刷する、これらのアクションのいくつかのためにです。アクションがリモートクライアントへのトラフィックをブロックする結果となるなら、リモートログインセッションは、クローズされ、規則セットの残りは、処理されません。次に、コンソールへのアクセスが、回復するために必要とされます。

-S

規則をリストするとき、各規則が属する セット を表示します。このフラグが指定されていなければ、無効化されている規則は、表示されません。

-s [ field]

パイプでリストするとき、4 つのカウンタの 1 つについて整列させます (総パケット数/バイト数または現在のパケット数/バイト数)。

-t

リストするとき、最後に適合したタイムスタンプを表示します (ctime() で変換されます)。

-T

リストするとき、最後に適合したタイムスタンプを表示します (基準時点からの秒で表示されます)。この書式の方が、スクリプトでの後処理に向いています。

規則と前処理のリスト

冒頭の書式の行で示したように、設定を簡単にするため、規則を ipfw に処理させるファイルに記述することができます。 pathname には、絶対パス名を使用する必要があります。このファイルからは、1 行ずつ読み込まれ、 ipfw ユーティリティの引数として受け付けられます。

-p preproc を使用して、 pathname がパイプされるプリプロセッサを指定することもできます。有用なプリプロセッサには、 cpp(1) と m4(1) があります。 preproc の最初の文字がスラッシュ (‘ /’) から始まらない場合、 PATH を使用した通常の名前検索が行われます。 ipfw が実行されるときまでに全ファイルシステムが (まだ) マウントされないような環境 (例えば NFS 経由でマウントされる場合) では、このことに注意してください。いったん -p が指定されると、任意の追加引数は、解釈のためのプリプロセッサに渡されます。これにより、(ローカルホスト名により条件付けするなど) 柔軟性のある設定ファイルを作成可能となり、IP アドレスのように頻繁に必要となる引数を集中管理するためのマクロを使用可能となります。

トラフィックシェイパの設定

ipfw の pipe, queue と sched コマンドは、トラフィックシェイパとパケットスケジューラを設定するために使用されます。詳細については、下記の トラフィックシェイパ (DUMMYNET) 設定 セクションを参照してください。

世界とカーネルの調子が外れると、 ipfw ABI が壊れてしまい、いかなる規則も追加できなくなります。これは、ブートに悪影響があり得ます。 ipfw disable firewall で、一時的にファイアウォールを無効化することで、ネットワークアクセスを再取得して問題解決できます。

規則アクション

規則は、次に示すアクションの 1 つと関連づけることができます。これは、パケットが規則のボディに適合したときに実行されます。

allow | accept | pass | permit

規則に適合するパケットを受け付けます。検索は、終了します。

check-state

動的規則セットに対してパケットのチェックを行ないます。適合した場合、その動的規則を生成した規則に関連づけられたアクションを実行し、適合しなかった場合、次の規則に移ります。

 

check-state 規則は、ボディを持ちません。 check-state 規則が見つからないときは、動的規則セットは、最初の keep-state 規則、もしくは limit 規則の場所でチェックされます。

count

規則に適合した全てのパケットのカウンタを更新します。検索は、次の規則へ続行します。

deny | drop

規則に適合した全てのパケットを破棄します。検索は、終了します。

divert port

規則に適合するパケットをポート port にバインドされている divert(4) ソケットに送出します。検索は、終了します。

fwd | forward ipaddr | tablearg[ , port]

マッチしているパケットで次のホップ (中継点) を、 IP アドレスまたはホスト名であるかもしれない、 ipaddr に変更します。また、IPv4 に関して、明白なアドレスの代わりに tablearg キーワードを使用することによってパケットを検索する最後のテーブルによって、次のホップ (中継点) を供給することができます。この規則にマッチするなら、検索は、終わります。

ipaddr がローカルアドレスの場合、適合したパケットは、ローカルマシンの port (または、規則で指定されていない場合は、そのパケットのポート番号) に転送されます。

 

ipaddr がローカルアドレスでない場合、ポート番号は、(指定されていても) 無視され、パケットは、ローカルな経路テーブルに存在するその IP に対する経路を使用してリモートアドレスに転送されます。

 

fwd 規則は、レイヤ 2 パケット (それらは、ether_input, ether_output, bridged で受信されます) には適合しません。

 

fwd アクションは、パケットの内容をまったく変更しません。実際、宛先アドレスが修正されずに残るので、転送先システムがそのようなパケットを取り込む規則を持たない限り、他のシステムに転送されたパケットは、通常転送先のシステムで拒否されます。ローカルに転送されるパケットの場合、ソケットのローカルアドレスは、パケットが元々持っていた宛先アドレスに設定されます。このことによって netstat(1) が出力するエントリは、若干奇妙な見え方になりますが、これは、透過プロキシサーバでの使用を意図しています。

nat nat_nr | tablearg

(ネットワークアドレス変換、アドレスリダイレクション、その他のために) パケットを nat インスタンスに渡します: さらなる詳細については、 ネットワークアドレス変換 (NETWORK ADDRESS TRANSLATION (NAT)) セクションを参照してください。

pipe pipe_nr

パケットを dummynet “パイプ” (バンド幅制限、遅延などに使用されます) へ渡します。詳しい情報については、 トラフィックシェイパ (DUMMYNET) 設定 セクションを参照してください。検索は、終了します。しかし、パイプから抜けたときに sysctl(8) 変数 net.inet.ip.fw.one_pass がセットされていない場合、パケットは、すぐ次の規則から始まるファイアウォールコードへ再度渡されます。

queue queue_nr

パケットを dummynet “キュー” (WF2Q+ を使ったバンド幅制限に使用されます) へ渡します。

reject

(非推奨)。 unreach host と同義です。

reset

この規則に適合したパケットを破棄します。さらに、そのパケットが TCP パケットであれば、 TCP リセット (RST) 通知を送出しようと試みます。検索は、終了します。

reset6

この規則に適合したパケットを破棄します。さらに、そのパケットが TCP パケットであれば、 TCP リセット (RST) 通知を送出しようと試みます。検索は、終了します。

skipto number | tablearg

それ以降の規則のうち number より小さな番号のものすべてを飛び越して、 number 以上の番号の規則で最初に存在するものから、検索を継続します。 計算された skipto のために skipto がある tablearg キーワードを使用することができますが、宛先キャッシュが、この場合可能でないので、規則は、 skipto から始めて、それを見つけるために常に探し回るとき、注意するべきです。

call number | tablearg

現在の規則番号は、内部スタックに保存され、規則セット処理は、 number 以上に番号付けされた最初の規則で継続します。 return アクションがある後の規則に遭遇するなら、処理は、この call 規則と 1 以上の数で最初の規則に戻ります ( divert アクションの後で divert(4) ソケットから戻るパケットのような同じ振る舞い)。これは、アセンブリ言語“subroutine”呼び出しにやや似た、異なったインタフェースなどの共通のチェックで規則付けを行うために使用されます。

任意の数がある規則は、 skipto のように前方にただジャンプするのではなく、呼び出されます。それで、誤りの場合の永久ループを防ぐために、 call と return アクションの両方は、メモリが割り付けできないか、またはスタックがオーバフローするかアンダフローするなら、どんなジャンプも行われず、単に次の規則に行きます。

内部的に、規則番号のためのスタックは、 mbuf_tags(9) 機能を使用して実装され、現在、16 エントリのサイズがあります。 mbuf タグがパケットがカーネルから出るとき、失われるように、 divert は、永久ループと他の望ましくない影響を避けるためにサブルーチンで使用されるべきではありません。

return

最後の call アクションによって内部のスタックに保存された規則番号を取り、対応する call 規則の数より大きい数がある最初の規則に規則セット処理を返します。その他の詳細については、 call アクションの説明を参照してください。

return 規則は、通常、“subroutine”を終わらせて、その結果、無条件ですが、 ipfw コマンドラインユーティリティは、現在本体を所有するために check-state 以外のあらゆるアクションを必要とすることに注意してください。いくつかのパケットでのみ戻るために時々役に立ちますが、通常、読み易さのために単に“return”を印刷することを必要とします。この回避方法は、次のように新しい構文と -c スイッチを使用することです:

# 実際の本体なしで規則を追加します 
ipfw add 2999 return via any 
 
# "from any to any"部分なしで規則をリストします 
ipfw -c list

この表面的な問題は、将来のリリースで修正されるかもしれません。

tee port

この規則に適合したパケットの複製を、ポート port にバインドされた divert(4) ソケットに送出します。検索は、その次の規則へ継続されます。

unreach code

この規則に適合したパケットを破棄し、コード code の ICMP 到達不可通知を送出しようと試みます。ここで code は、0 から 255 の数字、または次のエイリアスのいずれかです: net, host, protocol, port, needfrag, srcfail, net-unknown, host-unknown, isolated, net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence, precedence-cutoff。検索は、終了します。

unreach6 code

この規則に適合したパケットを破棄し、コード code の ICMPv6 到達不可通知を送出しようと試みます。ここで code は、0, 1, 3, 4 の数字、または次のエイリアスのいずれかです: no-route, admin-prohib, address または port。検索は、終了します。

netgraph cookie

パケットに与えられた cookie をつけて netgraph に送出します。パケットが後に netgraph から返ってきたなら、 net.inet.ip.fw.one_pass sysctl 変数に依存して、次の規則に受け付けまたは継続のどちらかとなります。

ngtee cookie

パケットのコピーは、netgraph に送出され、オリジナルのパケットは、次の規則で継続します。 netgraph と ngtee アクションの詳細については、 ng_ipfw(4) を参照してください。

setfib fibnum | tablearg

パケットは、その後の決定を進める FIB (ルーティングテーブル, 経路表) fibnum を使用するためにタグ付けをされます。現在の実装は、これは、値 0 から 15 に制限されます、 setfib(2) を参照してください。処理は、次の規則を続行します。 setfib がある tablearg キーワードを使用することは可能です。 tablearg 値がコンパイルされた fib の範囲内でないなら、パケットの fib な、0 に設定されます。

setdscp DSCP | number | tablearg

IPv4/IPv6 パケットのための指定された DiffServ codepoint を設定します。処理は、次の規則で継続します。サポートされている値は、次の通りです:

CS0 ( 000000), CS1 ( 001000), CS2 ( 010000), CS3 ( 011000), CS4 ( 100000), CS5 ( 101000), CS6 ( 110000), CS7 ( 111000), AF11 ( 001010), AF12 ( 001100), AF13 ( 001110), AF21 ( 010010), AF22 ( 010100), AF23 ( 010110), AF31 ( 011010), AF32 ( 011100), AF33 ( 011110), AF41 ( 100010), AF42 ( 100100), AF43 ( 100110), EF ( 101110), BE ( 000000)。さらに、数値 (0..64) によって DSCP 値を指定することができます。また、 setdscp がある tablearg キーワードを使用することができます。 tablearg 値が 0..64 の範囲内にないなら、供給された下位 6 ビットが使用されます。

reass

IP フラグメントをキューに入れて、再構築します。パケットがフラグメント化されていないなら、カウンタは、更新され、処理は、次の規則で続行します。パケットが最後の論理的なフラグメントであるなら、パケットは、再構築され、 net.inet.ip.fw.one_pass が 0 に設定されているなら、処理は、次の規則で続行します。そうでなければ、パケットは、渡すことが許可され、検索は、終了します。パケットがフラグメントの論理グループの中間のフラグメントであるなら、それは、消費され、処理は、直ちに停止します。

net.inet.ip.maxfragpackets と net.inet.ip.maxfragsperpacket を通して、それぞれ、処理できるフラグメントの最大数 (デフォルト: 800) とパケット毎のフラグメントの最大数 (デフォルト: 16) を制限する、フラグメントの取り扱いを調整することができます。

注意: フラグメントがポート番号をを含んでいないので、それらを、 reass 規則で避けるべきです。もう一つの方法として、 ( in / out のような) 方向ベース (direction-based) と ( via (経由) のような) ソースベース (source-based) のマッチパターンは、フラグメントを選択するために使用することができます。

通常、次のような簡単な規則です:

# 着信フラグメントを再構築する 
ipfw add reass all from any to any in

は、すべて、規則セットの始めに必要とします。

規則ボディ

規則のボディは、0 個以上のパターン (発信元と宛先アドレスやポートの指定、プロトコルオプション、受信または送信インタフェースの指定など) を含みます。このパターンは、パケットを識別するために適合しなければならないものです。一般に、パターンは、(暗黙的に) and オペレータで接続されます -- つまり、規則が適合するためには、全てが適合しなければなりません。個々のパターンには、適合の結果を反転させるために not オペレータを前置することができます。これは、次のようになります。

ipfw add 100 allow ip from not 1.2.3.4 to any

さらに、次のように or オペレータを使用し、丸括弧 () やブレース {} で括られた内部にパターンを列挙することで、新しい適合パターンのセット ( 論理和 (OR) ブロック) を構築することができます:

ipfw add 100 allow ip from { x or not y or z } to any

括弧のレベルは、1 つのみが可能です。ほとんどのシェルが丸括弧やブレースに特別な意味を持たせていることに注意して下さい。したがって、そのような解釈が起こらないようにバックスラッシュ \ をその前に置くことを勧めます。

規則のボディは、一般に発信元と宛先アドレスの指定を含まなければなりません。キーワード any は、必須フィールドの内容が重要でないことを指定するために様々な箇所で使用することができます。

規則ボディは、以下の書式で指定します。

最初の部分 (proto from src to dst) は、 FreeBSD の初期のバージョンとの後方互換性のためのものです。最近の FreeBSD では、 options セクションで (MAC ヘッダ、IP プロトコル、アドレスとポートを含んで) 任意のマッチパターンを指定することができます。

規則フィールドには、次の意味があります:

proto: protocol | { protocol or ... }

protocol: [ not] protocol-name | protocol-number

数値または名前 (完全なリストについては、 /etc/protocols を参照) によって指定された IP プロトコル、または次のキーワードの 1 つ:

ip4 | ipv4

IPv4 パケットに適合する。

ip6 | ipv6

IPv6 パケットに適合する。

ip | all

あらゆるパケットに適合する。

proto オプションの ipv6 は、内部のプロトコルとして取り扱われます。そして、 ipv4 は、 proto オプションで利用可能ではありません。

{ protocol or ... } 書式 ( 論理和 (OR) ブロック) は、簡便さのためだけに提供されており、価値が低下しています。

src and dst: { addr | { addr or ... }}[ [ not] ports]

単一のアドレス (またはリスト、後述) で、オプションとして、その後に ports 指示子を続けて置くことができます。

第 2 の書式 (複数アドレス付きの 論理和 (OR) ブロック) は、簡便さのためだけに提供されており、価値が低下しています。

addr: [ not]{ any | me | me6 | table( number[ , value]) | addr-list | addr-set}

any

任意の IP アドレスが適合します。

me

システムのインタフェースに設定された任意の IP アドレスが適合します。

me6

システムのインタフェースに設定された任意の IPv6 アドレスが適合します。アドレスのリストは、パケットが解析されるときに評価されます。

table( number[ , value])

検索テーブル number に存在するエントリに対応する任意の IPv4 アドレスが適合します。オプションの 32 ビット符号なし整数 value も指定された場合には、その値のエントリにのみ適合します。検索テーブルに関する詳細は、下記の 検索テーブル セクションを参照して下さい。

addr-list: ip-addr[ , addr-list]

ip-addr:

次の方法で指定される、ホストもしくはサブネットのアドレス:

numeric-ip | hostname

ドットで区切った数字 4 つ組またはホスト名で指定した、 1 つの IPv4 アドレスが適合します。ホスト名の名前解決は、その規則がファイアウォールのリストに追加されるときに行われます。

addr/ masklen

ベースとなる addr (IP アドレス、ネットワーク番号、またはホスト名で指定します) と masklen ビット幅のマスクに適合する全てのアドレスが適合します。例えば、1.2.3.4/25 または 1.2.3.0/25 は、1.2.3.0 から 1.2.3.127 までの全ての IP アドレスが適合することになります。

addr: mask

ベースアドレスが addr (IP アドレス、ネットワーク番号、またはホスト名で指定します) であり、マスクが mask (ドットで区切った 4 つの数字で指定されます) である全てのアドレスに適合します。例えば、1.2.3.4:255.0.255.0 または 1.0.3.0:255.0.255.0 は、1.*.3.* に適合します。この形式は、連続でないマスクの場合にだけ使用することを推奨します。連続なマスクの場合は、よりコンパクトでより間違いにくい、 addr/ masklen を使います。

addr-set: addr[ / masklen] { list }

list: { num | num-num}[ , list]

ベースアドレスが addr (IP アドレス、ネットワーク番号、またはホスト名で指定します) であり、最後のバイトがブレース {} の中に列挙されている全てのアドレスが適合します。ブレースと数字の間には空白を置いてはいけないことに注意して下さい (コンマの後の空白は、許されています)。リストの要素は、単一項目もしくは範囲が指定可能です。 masklen フィールドは、アドレスのセットのサイズに制限をつけるために使用され、 24 から 32 の間の任意の値をとることができます。指定されない場合 24 が仮定されます。

 

この書式は、1 つの規則でまばらなアドレス群を取り扱うときに特に便利です。ビットマスクを使用して適合を行うので、定数時間で処理でき、規則セットの複雑さが劇的に減少します。

 

例えば、1.2.3.4/24{128,35-55,89} または 1.2.3.0/24{128,35-55,89} として指定したアドレスは、次の IP アドレスに適合します:

 

1.2.3.128, 1.2.3.35 to 1.2.3.55, 1.2.3.89 .

addr6-list: ip6-addr[ , addr6-list]

ip6-addr:

ホストまたはサブネットを以下の方法のうちのどれかで指定します:

numeric-ip | hostname

単一の inet_pton(3) で認められている IPv6 アドレス、またはホスト名に適合します。ホスト名は、規則がファイアウォールリストに追加される時に解決されます。

addr/ masklen

ベースアドレスが addr ( inet_pton で認められている、またはホスト名) で、マスクの幅が masklen ビットである全ての IPv6 アドレスに適合します。

IPv6 アドレスは、一般に最初のプレフィックスの後はランダムなので、 IPv6 アドレスのセットに対するサポートは、提供されません。

ports: { port | port- port}[ , ports]

(TCP や UDP などのように) ポート番号をサポートしているプロトコルについて、オプションとして、 ports を指定することができます。 1 つ以上のポートまたはポートの範囲を空白なしのコンマ区切りで指定します。さらにオプションとして、 not オペレータを付加して指定することができます。記号‘ -’による表現は、ポート範囲 (両端含む) を指定します。

ポート数値の代わりに (ファイル /etc/services から取った) サービス名を使用できます。ポートリストの長さは、30 ポートまたはポート範囲に制限されていますが、規則の options セクションで 論理和 (OR) ブロック を使用することにより、より広い範囲を指定することができます。

バックスラッシュ (‘ \’) を使用することにより、サービス名中のダッシュ (‘ -’) 文字をエスケープ可能です (シェルから入力するとき、シェル自身がバックスラッシュをエスケープ文字として解釈するのをさけるために、バックスラッシュを 2 回タイプしなければなりません)。

ipfw add count tcp from any ftp\\-data-ftp to any

断片化されたパケットでオフセットが非 0 のもの (すなわち、最初の断片ではないもの) は、 1 つ以上のポート指定を持つ規則には適合しません。断片化されたパケットの適合に関する詳細については、 frag オプションを参照してください。

規則オプション (適合パターン)

規則内で追加の適合パターンを使用することができます。これらは、規則内に 0 個以上置けるので オプション と呼ばれており、オプションで not オペランドを前置することができ、 論理和 (OR) ブロック としてグループ化することが可能です。

以下の適合パターンが使用できます (アルファベット順に並べています)。

// this is a comment.

指定したテキストを、規則中にコメントとして挿入します。 // に続くすべてがコメントとして扱われ、規則中に格納されます。コメントのみの規則を持つことも可能であり、それは、 count アクションに続いてコメントが表示されます。

bridged

layer2 の別名です。

diverted

divert ソケットによって生成されたパケットのみ適合します。

diverted-loopback

配信のための IP スタック入力に戻された divert ソケットから来るパケットだけ適合します。

diverted-output

配信のための IP スタック出力に戻された divert ソケットから行くパケットだけ適合します。

dst-ip ip-address

宛先 IP アドレスが引数で指定したアドレスの 1 つである IPv4 パケットに適合します。

{ dst-ip6 | dst-ipv6} ip6-address

宛先 IP アドレスが引数で指定したアドレスの 1 つである IPv6 パケットに適合します。

dst-port ports

宛先ポートが引数で指定したポートの 1 つである IP パケットに適合します。

established

RST か ACK ビットがセットされている TCP パケットに適合します。

ext6hdr header

header で与えられた拡張ヘッダを含む IPv6 パケットに適合します。サポートされているヘッダは、次の通りです:

フラグメント, ( frag), Hop-to-hop オプション ( hopopt), 任意のタイプのルーティングヘッダ ( route), ルーティングヘッダタイプ 0 のソースルーティング ( rthdr0), ルーティングヘッダタイプ 2 のモバイル IPv6 ( rthdr2), 宛先オプション ( dstopt), IPSec 認証ヘッダ ( ah), IPsec カプセル化セキュリティペイロードヘッダ ( esp)。

fib fibnum

与えられた FIB (ルーティングテーブル) 番号を使用するためにタグ付けされたパケットにマッチします。

flow-id labels

labels で与えられた任意のフローラベルを含む IPv6 パケットに適合します。 labels は、フローラベルの数値をコンマで区切られたリストです。

frag

IP データグラムのフラグメントであり、かつ、最初のフラグメントでないパケットに適合します。これらのパケットは、次のプロトコルヘッダ (例えば TCP, UDP) を持たないので、これらのヘッダを調べるオプションは、適合することができないことに注意して下さい。

gid group

group によって送信された、またはそれに対して受信された全ての TCP もしくは UDP パケットに適合します。 group は、名前か数値で指定することができます。

jail prisonID

prison ID が prisonID である jail によって送信された、またはそれに対して受信された全ての TCP もしくは UDP パケットに適合します。

icmptypes types

types で指定したリスト中に存在する ICMP タイプを持つ ICMP パケットに適合します。リストは、タイプおのおのをコンマで区切ったものです。 範囲は許されません。サポートされている ICMP タイプは、次の通りです。

エコー応答 ( 0), 宛先到達不可 ( 3), 発信元抑制 ( 4), リダイレクト ( 5), エコー要求 ( 8), ルータ広告 ( 9), ルータ要請 ( 10), 時間超過 ( 11), IP ヘッダ異常 ( 12), タイムスタンプ要求 ( 13), タイムスタンプ応答 ( 14), インフォメーション要求 ( 15), インフォメーション返答 ( 16), アドレスマスク要求 ( 17), アドレスマスク応答 ( 18)

icmp6types types

ICMP6 タイプが types のリストに含まれる ICMP6 パケットに適合します。リストは、コンマで区切られた別々のタイプ (数値) の任意の数の組み合わせで指定されます。 範囲指定は認められていません。

in | out

それぞれ到着または送出パケットに適合します。 in と out は、互いに排他的です (実際、 out は、 not in として実装されています)。

ipid id-list

ip_id フィールドが id-list に含まれる IPv4 パケットに適合します。 id-list は、単一の値か、 ports と同等の方法で指定される、値のリストか範囲です。

iplen len-list

ヘッダとデータを含んだ全体の長さが len-list に含まれる IP パケットに適合します。 len-list は、単一の値か、 ports と同等の方法で指定される、値のリストか範囲です。

ipoptions spec

spec で指定したコンマ区切りリストオプションを含む IPv4 ヘッダを持つパケットに適合します。 IP オプションは、次のものがサポートされています:

ssrr (ストリクトソースルーティング), lsrr (ルーズソースルーティング), rr (レコードルート), ts (タイムスタンプ)。‘ !’を置くことで特定のオプションが存在しないという記述ができます。

ipprecedence precedence

先行フィールドが precedence に等しい IPv4 パケットに適合します。

ipsec

IPSEC ヒストリを持つパケットに適合します (すなわち、入力パケットが IPSEC でカプセル化されており、カーネルが IPSEC と IPSEC_FILTERTUNNEL のオプションをサポートし、正しくパケットのカプセル化を解除できた場合です)。

ipsec を指定することは、 proto ipsec を指定することとは違います。何故なら後者は、IPSEC カーネルサポートの有無および IPSEC データの正当性にかかわらず、特定の IP プロトコルフィールドのみを見るからです。

更に、IPSEC サポート無しのカーネルでは、このオプションは、黙って無視されることに注意してください。この場合、このフラグを指定しても規則処理に影響が無く、あたかも ipsec フラグが指定されていないかのように当該規則が処理されます。

iptos spec

spec で指定したコンマ区切りリストのサービスタイプを含む tos フィールドを持つ IPv4 パケットに適合します。サポートされているサービスの IP タイプは、次の通りです。

lowdelay ( IPTOS_LOWDELAY), throughput ( IPTOS_THROUGHPUT), reliability ( IPTOS_RELIABILITY), mincost ( IPTOS_MINCOST), congestion ( IPTOS_ECN_CE)。‘ !’を置くことで特定のオプションが存在しないという記述ができます。

dscp spec[ , spec]

DS フィールド値が spec マスクに含まれている IPv4/IPv6 パケットにマッチします。コンマで区切られたリストによって複数の値を指定することができます。値は、 setdscp アクションまたは正確な数で使用されるキーワードの 1 つを指定できます。

ipttl ttl-list

生存時間が ttl-list に含まれる IPv4 パケットに適合します。 ttl-list は、単一の値か、 ports と同等の方法で指定される、値のリストか範囲です。

ipversion ver

IP バージョンフィールドが ver である IP パケットに適合します。

keep-state

適合する際に、ファイアウォールは、動的規則を作成します。作成される規則は、デフォルトでは、同じプロトコルを使用している発信元と宛先 IP/ポート間での双方向のトラフィックに適合するような動作となります。この規則には、有限の生存時間 ( sysctl(8) 変数の集合により制御されます) があり、生存時間は、適合するパケットが見つかるたびにリフレッシュされます。

layer2

レイヤ 2 のパケット、つまり、 ether_demux() と ether_output_frame() から ipfw へ渡されるパケットのみに適合します。

limit { src-addr | src-port | dst-addr | dst-port} N

ファイアウォールは、この規則で指定したものと同じパラメータの集合を持つ接続を、 N 個だけ許可します。 1 つ以上の発信元と宛先アドレスおよびポートが指定できます。現在のところ、IPv4 フローのみサポートされています。

lookup { dst-ip | dst-port | src-ip | src-port | uid | jail} N

引数として指定されたフィールドに適合する検索テーブル N のエントリを検索します。見つからなければ、適合は、失敗します。そうでなければ、適合は、成功し、 tablearg は、テーブルから抽出された値に設定されます。

特定のパケットフィールドに基づくトラフィックをすばやくディスパッチする (送り出す) ためにこのオプションを役立てることができます。検索テーブルの詳しい情報については、下記の 検索テーブル セクションを参照してください。

{ MAC | mac } dst-mac src-mac

与えられた dst-mac アドレスと src-mac アドレスを持つパケットに適合します。アドレスは、 any キーワード (任意の MAC アドレスに適合します) またはコロンで区切った 16 進数 6 個の組で指定します。この 6 個組アドレスの後ろには、オプションとして、重要なビットを表現するマスクをつけることができます。マスクは、次のいずれかの方法で指定可能です:

1. スラッシュ (/) に続けて、重要なビット数を指定します。例えば、重要なビットが 33 ビットであるアドレスは、次のように指定します:

   MAC 10:20:30:40:50:60/33 any

2. アンパサンド (&) に続けて、コロン区切りの 6 組の 16 進数として指定されるビットマスクを指定します。例えば、最後の 16 ビットが重要であるアドレスは、次のように指定します:

   MAC 10:20:30:40:50:60&00:00:00:00:ff:ff any

   多くのシェルでアンパサンド文字は、特別な意味を持ちますので、普通は、エスケープが必要であることに注意してください。

MAC アドレスの順序 (宛先が最初で 2 番目に発信元) は、物理的な線上のものと同じですが、 IP アドレスで使用されるものとは反対であることに注意して下さい。

mac-type mac-type

イーサネットタイプフィールドが引数で指定したものの 1 つと適合するパケットに適合します。 mac-type は、 port numbers と同じ方法で指定します (つまり、単一の値または範囲が、1 個以上コンマで区切られたものです)。 vlan, ipv4, ipv6 のような既知の値に対しては、シンボル名称を使用することができます。値は、10 進数か 16 進数 (0x が頭につく場合) で入力することができ、常に 16 進数で出力されます (これは、 -N オプションが使用されていない場合です。 -N オプションが使用されるとシンボル名称の解決が試みられます)。

proto protocol

対応する IP のプロトコルを持つパケットが適合します。

recv | xmit | via { ifX | if * | table( number[ , value | ipno | any])}

指定したインタフェースから受信したパケット、送信したパケット、通過したパケットがそれぞれ適合します。インタフェースの指定は、正確な名前 ( ifX)、またはデバイス名 ( if*)、IP アドレスで行なうか、もしくは何らかのインタフェースを通じて行ないます。

via キーワードにより、指定したインタフェースが常にチェックされることになります。 recv や xmit が via の代わりに使用された場合、それぞれ、受信インタフェースのみ、または送信インタフェースのみがチェックされます。両方とも指定した場合、送信インタフェースと受信インタフェースの両方に基づくパケットの適合が可能になります。例えば次のようになります。

ipfw add deny ip from any to any out recv ed0 xmit ed1

recv インタフェースは、到着または送出パケットのどちらかについて検査することができますが、 xmit インタフェースは、送出パケットのみについて検査することができます。したがって xmit を使用する場合には、 out は、必須です (そして in は、無効となります)。

パケットが受信インタフェースや送信インタフェースを持たないかもしれません: ローカルホストから発生したパケットは、受信インタフェースを持ちませんし、ローカルホストに到着する予定のパケットは、送信インタフェースを持ちません。

setup

SYN ビットがセットされているが ACK ビットを持たない TCP パケットに適合します。これは、“ tcpflags syn,!ack”の短縮形です。

sockarg

ローカルのソケットに関連づけられたパケットと SO_USER_COOKIE ソケットオプションが 0 以外の値に設定されたことに対しマッチします。副作用として、オプションの値は、 skipto または pipe 番号として順番に使用できる、 tablearg 値として利用可能にします。

src-ip ip-address

引数で指定したアドレスの 1 個を発信元 IP として持つ IPv4 パケットが適合します。

src-ip6 ip6-address

引数で指定したアドレスの 1 個を発信元 IP として持つ IPv6 パケットが適合します。

src-port ports

引数で指定したポートの 1 個を発信元ポートとして持つ IP パケットが適合します。

tagged tag-list

単一の値、値のリストまたは、 ports と同様に指定された範囲である、 tag-list に含まれているタグがあるパケットに適合します。 tag 規則アクションパラメータを使用して、タグをパケットに適用することができます (タグに関する詳細のための説明を参照してください)。

tcpack ack

TCP パケットのみです。 TCP ヘッダの確認応答番号フィールドが ack に設定されていれば適合します。

tcpdatalen tcpdatalen-list

TCP データの長さが tcpdatalen-list である TCP パケットに適合します。単一の値、値のリスト、または ports と同様の形式の範囲、のどれかを指定します。

tcpflags spec

TCP パケットのみです。 TCP ヘッダが spec で指定したコンマ区切りのフラグのリストを含んでいれば適合します。サポートされている TCP フラグは、次の通りです。

fin, syn, rst, psh, ack, urg。‘ !’を置くことで特定のフラグが存在しないという記述ができます。 tcpflags の指定を含む規則は、0 でないオフセットを持つフラグメントパケットには、決して適合することはありえません。フラグメントパケットの適合についての詳細は、 frag オプションを参照して下さい。

tcpseq seq

TCP パケットのみです。 TCP ヘッダのシーケンス番号フィールドが seq に設定されていれば適合します。

tcpwin tcpwin-list

ヘッダのウィンドウフィールドが、単一の値または ports と同じ方法で指定された値または範囲のリストのいずれかである、 tcpwin-list に設定される TCP パケットと一致します。

tcpoptions spec

TCP パケットのみです。 spec で指定したコンマ区切りのオプションのリストが TCP ヘッダに含まれていれば適合します。サポートされている TCP オプションは、次の通りです。

mss (最大セグメントサイズ), window (TCP ウィンドウ広告), sack (選択的 ACK), ts (RFC1323 タイムスタンプ), cc (RFC1644 T/TCP コネクションカウント)。‘ !’を置くことで特定のオプションが存在しないという記述ができます。

uid user

user が送信したまたは受信する、すべての TCP パケットと UDP パケットに適合します。 user は、名前でも ID 番号でも適合します。

verrevpath

内向きパケットに対しては、パケットのソースアドレスに対し、経路テーブルが検索されます。パケットがシステムに入って来たインタフェースと、経路の出力インタフェースが適合する場合、パケットは、適合します。インタフェースが適合しない場合、パケットは、適合しません。外向きパケットや、入力インタフェースを持たないパケットは、適合します。

このオプションの名称と機能は、意図的に下記 Cisco IOS コマンドと同じです:

ip verify unicast reverse-path

本オプションは、このインタフェースのものではないソースアドレスを持つパケットをすべて拒否する対スプーフィング規則を作成するのに使用可能です。 antispoof オプションも参照して下さい。

versrcreach

内向きパケットに対しては、パケットのソースアドレスに対し、経路テーブルが検索されます。ソースアドレスへの経路は、存在するが、デフォルトの経路でない場合やブラックホール経路、拒否されてる経路である場合に、パケットは、適合します。そうでなければ、パケットは、適合しません。外向きパケットは、すべて適合します。

このオプションの名称と機能は、意図的に下記 Cisco IOS コマンドと同じです:

ip verify unicast source reachable-via any

本オプションは、ソースアドレスが到達可能でないパケットをすべて拒否する対スプーフィング規則を作成するのに使用可能です。

antispoof

内向きパケットに対しては、パケットのソースアドレスが直接接続されているネットワークに属するものかどうか確認します。ネットワークが直接接続されていれば、パケットを受信したインタフェースは、ネットワークに接続されているインタフェースと比較されます。受信インタフェースと直接接続されているインタフェースが同一でなければ、パケットは、適合しません。そうでなければパケットは、適合します。外向きパケットは、すべて適合します。

本オプションは、直接接続されたネットワークから来たふりをしているのにそのインタフェース経由で入ってきていないパケットをすべて拒否する対スプーフィング規則を作成するのに使用可能です。本オプションは、 verrevpath と似ていますが、ソースアドレスすべての代わりに、直接接続されたネットワークのソースアドレスを持つパケットを対象とするのでより限定的です。

                 (flow_mask|sched_mask)  sched_mask 
         +---------+   weight Wx  +-------------+ 
         |         |->-[flow]-->--|             |-+ 
    -->--| QUEUE x |   ...        |             | | 
         |         |->-[flow]-->--| SCHEDuler N | | 
         +---------+              |             | | 
             ...                  |             +--[LINK N]-->-- 
         +---------+   weight Wy  |             | +--[LINK N]-->-- 
         |         |->-[flow]-->--|             | | 
    -->--| QUEUE y |   ...        |             | | 
         |         |->-[flow]-->--|             | | 
         +---------+              +-------------+ | 
                                    +-------------+

パイプ、キューとスケジューラの設定

pipe, queue と scheduler の設定コマンドは、次の通りです:

次のパラメータをパイプに対して設定可能です。

bw bandwidth | device

バンド幅で、単位は、[ K| M]{ bit/s| Byte/s}です。

値 0 (デフォルト) は、無限のバンド幅を意味します。単位は、次の

ipfw pipe 1 config bw 300Kbit/s

のように、数値の直後に続けて書く必要があります。次の

ipfw pipe 1 config bw tun0

のように、数値の代りにデバイス名を指定した場合、送信クロックは、指定したデバイスから与えられます。現在のところ、 tun(4) デバイスのみがこの機能を提供しており、 ppp(8) と組み合わせて使用します。

delay ms-delay

伝達遅延時間であり、ミリ秒単位で指定します。値は、クロックチック (clock tick) の倍数 (典型的には、10ms ですが、カーネルを“options HZ=1000”で動作させて精度を 1ms かそれ以下にすると良いことが経験的に知られています) に丸められます。デフォルト値は、0 であり、遅延無しを意味します。

burst size

送信されるデータが、パイプの帯域幅の制限を超えている、 (パイプが、以前に、使用されていなかった) なら、データの size バイトまで dummynet スケジューラをバイパスさせることができ、物理的なリンクが許容するのと同じくらい速く送信されます。任意の追加データは、 pipe 帯域幅によって指定されたレート (速度) で転送されます。バースト (burst) サイズは、パイプがどのくらい長く使用されていなかったかに依存します。有効なバースト (burst) サイズは、次のように計算されます: MAX( size, bw * pipe_idle_time)。

profile filename

リンクにおけるパケットの転送で被られる追加のオーバヘッドを指定するファイル。

いくつかのリンクタイプは、パケットの転送での特別の遅延、例えば、 MAC レベルフレーミング、チャネルの使用の競合、 MAC レベル再伝送などを導入します。私たちの観点からは、チャネルは、リンクタイプに従って、定数であるか、または変数である、この特別の時間を効果的に利用不可能です。さらに、パケットは、(例えば、あまりに多くの再伝送の後、無線リンクで) この時以降に落されるかもしれません。私たちは、分布を表す実験曲線で追加遅延をモデル化できます。

      累積確立 
      1.0 ^ 
          | 
      L   +-- loss-level          x 
          |                 ****** 
          |                * 
          |           ***** 
          |          * 
          |        ** 
          |       * 
          +-------*-------------------> 
                      遅延

実験曲線には、垂直線と水平線があります。垂直線は、確率の範囲に対する一定の遅延を表します。水平線は、遅延分布での不連続性に対応しています: パイプは、与えられた確率に対して最も大きな遅延を使用します。

ファイル形式は、セパレータとしての空白類とコメントの始めを示す '#' の作用があり、次の通りです:

name identifier

("ipfw pipe show"でリストされる) 遅延分布を識別するオプションの名前。

bw value

パイプのために使用される帯域幅。ここで指定されないなら、パイプのための設定パラメータとして明白に存在していなければなりません。

loss-level L

パケットが失われる上記の確率。 (0.0 <= L <= 1.0, デフォルト 1.0 すなわち、損失なし)。

samples N

内部の表現 (2..1024;デフォルト 100) で使用されるサンプルの数。

delay prob | prob delay

これらの 2 つの線の 1 つは、強制的であり、データポイントがある次の線の形式を定義します。

XXX YYY

選ばれた形式に従って、最初の遅延または確率のいずれかがある、曲線の点で表される 2 つ以上の線。遅延の単位は、ミリ秒です。データポイントは、ソートされる必要はありません。また、実際の線の数は、"samples"パラメータの値と異なっているかもしれません: ipfw ユーティリティは、必要に応じて曲線をソートして、補間します。

プロファイルの例は、次の通りです:

name    bla_bla_bla 
samples 100 
loss-level    0.86 
prob    delay 
0       200 # 最小のオーバヘッドは、200ms 
0.5     200 
0.5     300 
0.8     1000 
0.9     1300 
1       1300 
#設定ファイルの終わり

次のパラメータをキューに対して設定できます。

pipe pipe_nr

キューを指定したパイプに接続します。複数のキュー (同じ重みの場合も異なる重みの場合もあります) を同一のパイプに接続することができます。パイプは、キューの集合に対する集約されたレートを指定します。

weight weight

このキューに適合するフローに適用する重みを指定します。重みは、1 から 100 の範囲でなければならず、デフォルトは、1 です。

スケジューラのために次の大文字と小文字を区別しないパラメータを設定することができます:

type {fifo | wf2q+ | rr | qfq}

使用するスケジューリングアルゴリズムを指定します。

fifo

は、(すべてのパケットが、スケジューラに到着するとき、同じキューに格納されることを意味する) まさに FIFO スケジューラです。 FIFO は、(2GHz のデスクトップマシンで 60-80 ナノ秒と評価される) 非常に低い定数があるパケットごとに O(1) の時間の複雑さがありますが、サービスの保証は、与えられません。

wf2q+

は、重み付け従って帯域幅を共有するためにフローを許可する、 Weighted Fair Queueing アルゴリズムである、 WF2Q+ アルゴリズムを実装しています。重み付けは、優先順位でないことに注意してください。極めて小さい重み付けがあるフローでさえ、決して飢えません。 WF2Q+ には、パケットごとに O(log N) の処理コストがあります、ここで、N は、フローの数であり、以前のバージョンの dummynet のキューで使用されるデフォルトアルゴリズムです。

rr

は、O(1) の処理コスト (おおよそ、1 パケットあたり 100-150 ナノ秒) があり、重み付けに従って帯域幅の割り付けを許可しますが、不十分なサービス保証である、 Deficit Round Robin アルゴリズムを実装しています。

qfq

は、同様のサービス保証があり、O(1) 処理コスト (おおよそ、1 パケットあたり 200-250 ナノ秒) の WF2Q+ の非常に速い変異型である、QFQ アルゴリズムを実装しています。

タイプに加えて、スケジューラのためにパイプのために許可されたすべてのパラメータもまた指定することできます。

最後に、次のパラメータをパイプやキューに対して設定できます。

buckets hash-table-size

様々なキューを格納するハッシュ表のサイズを指定します。デフォルトは、64 で、 sysctl(8) 変数 net.inet.ip.dummynet.hash_size によって制御されます。指定可能な範囲は、16 から 65536 までです。

mask mask-specifier

ipfw 規則により指定したパイプもしくはキューに対して送られたパケットを、さらに複数のフローにクラス分けすることができます。その後、それぞれのパケットは、異なる 動的な パイプもしくはキューに送られます。フロー識別子は、パイプもしくはキューの設定中の mask オプションの指定に応じて IP アドレス、ポート、プロトコルタイプをマスクすることにより構築されます。異なるフロー識別子それぞれに対し、新しいパイプもしくはキューが元となるオブジェクトと同一のパラメータとともに生成され、適合するパケットがそこに送られます。

このようにして、 動的パイプ を使用するとき、フローそれぞれは、パイプで指定したものと同じバンド幅を得ます。一方、 動的キュー を使用する時、フローそれぞれは、同じキューにより生成された他のフローと、親パイプのバンド幅を均等に山分けします (異なる重みを持つ他のキューが同じパイプに接続される場合があることに注意して下さい)。

 

使用可能なマスク指定子は、次を組み合わせたものです。

dst-ip mask, dst-ip6 mask, src-ip mask, src-ip6 mask, dst-port mask, src-port mask, flow-id mask, proto mask または all

最後の指定子は、すべてのフィールドのすべてのビットが検査されることを意味しています。

noerror

パケットが dummynet のキューやパイプによって落されたとき、通常は、デバイスキューが一杯になったときに生じるのと同様な形で、エラーがカーネル内の呼び出し元ルーチンに報告されます。このオプションを設定すると、パケットの配送に成功したかのように報告されます。これは、遠隔地にあるルータでの損失や輻輳をシミュレートしたいという一部の実験的な設定のために必要とされています。

plr packet-loss-rate

パケットの損失率です。引数 packet-loss-rate は、0 から 1 までの浮動小数点数で、 0 は、損失がないことを、1 は、100% 失われることを意味します。損失率は、内部的には、31 ビットで表現されています。

queue { slots | size Kbytes}

スロット数 slots または KBytes で表したキューのサイズです。デフォルトは、50 スロットで、これは、イーサネットデバイスにおける典型的なキューのサイズです。低速リンクのためにキューのサイズを小さいままにしておくことが推奨されます。そうしないとキューの遅延がトラフィックに及ぼす影響が著しくなるかもしれません。例えば、最大サイズのイーサネットパケット (1500 バイト) が 50 個のとき、 600Kbit、つまり 30Kbit/秒のパイプで 20 秒ということになります。それよりもずっと大きな MTU を持ったインタフェース (例えば、ループバックインタフェースは、16KB パケットです) からパケットを受け取る場合、さらに悪い結果となることがあります。 sysctl(8) 変数 net.inet.ip.dummynet.pipe_byte_limit と net.inet.ip.dummynet.pipe_slot_limit は、指定できる最大の長さを制御します。

red | gred w_q/ min_th/ max_th/ max_p

RED (Random Early Detection) キュー管理アルゴリズムを使用します。 w_q と max_p は、0 から 1 (0 を含みません) の範囲の浮動小数点数であり、 min_th と max_th は、キュー管理用の閾値を指定する整数です (キューがバイト数で指定された場合は、閾値は、バイトで計算され、そうでない場合は、スロット数で計算されます)。 dummynet は、gentle RED という変型 (gred) もサポートします。 RED の動作を制御するために、3 個の sysctl(8) 変数を使用可能です。

net.inet.ip.dummynet.red_lookup_depth

リンクがアイドルの時の、平均キューの計算精度を指定します (デフォルトは、256 であり、0 より大きい必要があります)

net.inet.ip.dummynet.red_avg_pkt_size

パケットサイズの平均の期待値を指定します (デフォルトは、512 であり、0 より大きい必要があります)

net.inet.ip.dummynet.red_max_pkt_size

パケットサイズの最大値の期待値を指定します。キューの閾値がバイトの場合のみ使用されます (デフォルトは、1500 であり、0 より大きい必要があります)

IPv6 データと共に使用した場合、 dummynet には現在いくつかの制限があります。インタフェースへのリンクローカルパケットを経路変更するために必要な情報は、 dummynet によって処理した後に利用可能でないので、それらのパケットは、出力経路 (path) で落とされます。リンクローカルパケットを dummynet に渡さないことを保証するよう心がけるべきです。

IPFW のリダイレクションと LSNAT サポート

リダイレクトと LSNAT サポートは、 natd(8) で使用される構文に厳密に従います。リダイレクトと lsnat を行う方法のいくつかの例については、セクション 使用例 を参照してください。

SCTP NAT サポート

ipfw コマンドラインツールを通して TCP と同様の方法で sctp nat を設定することができます。主な違いは、 sctp nat がポート変換しないということです。ローカル側とグローバル側のポートが同じになるので、両方を指定する必要はありません。ポートは、次のようにリダイレクトされます:

sysctl(8) インタフェースを通して、リアルタイムに、ほとんどの sctp nat 設定を行うことができます。すべて動的に変更されますが、 hash_table サイズは、新しい nat インスタンスのためにだけ変更します。詳しい情報については、 SYSCTL 変数 を参照してください。

基本的なパケットフィルタリング

次のコマンドは、 cracker.evil.org から wolf.tambov.su の telnet ポートへ送られるすべての TCP パケットを拒否する規則を追加します。

ipfw add deny tcp from cracker.evil.org to wolf.tambov.su telnet

次のコマンドは、クラッカーのネットワーク全体からホスト my へのすべてのコネクションを拒否します。

ipfw add deny ip from 123.45.67.0/24 to my.host.org

最初に効率良く (動的規則を用いずに) アクセスを制限する方法は、次の規則を用いることです。

ipfw add allow tcp from any to any established

ipfw add allow tcp from net1 portlist1 to net2 portlist2 setup

ipfw add allow tcp from net3 portlist3 to net3 portlist3 setup

...

ipfw add deny tcp from any to any

最初の規則は、通常の TCP パケットにすぐに適合しますが、最初の SYN パケットには適合しません。指定した発信元/宛先の組の SYN パケットのみ、次の setup 規則に適合します。これら以外の SYN パケットは、最後の deny 規則により却下されます。

1 つ以上のサブネットの管理者であるなら、アドレスセットと論理和 (OR) ブロックをうまく利用し、下記のように、クライアントのブロックへのサービスを選択的に有効にする非常にコンパクトな規則セットを記述することができます。

goodguys="{ 10.1.2.0/24{20,35,66,18} or 10.2.3.0/28{6,3,11} }"

badguys="10.1.2.0/24{8,38,60}"

ipfw add allow ip from ${goodguys} to any

ipfw add deny ip from ${badguys} to any

... normal policies ...

verrevpath オプションを使用し、下記を規則セットの先頭に置くことで、自動的な対スプーフィングが可能になります:

ipfw add deny ip from any to any not verrevpath in

この規則は、変なインタフェースからシステムに来たように見える内向きパケットをすべて落とします。例えば、保護された内部ネットワーク上のホストに属するソースアドレスを持つパケットは、外部インタフェースからシステムに入ろうとした場合、落とされます。

antispoof オプションを下記を規則セットの先頭に追加することで、同様のことが行なえますが、より限定された対スプーフィングが可能になります:

ipfw add deny ip from any to any not antispoof in

この規則は、他の直接接続されたシステムから変なインタフェースに来たように見える内向きパケットをすべて落とします。例えば、 fxp1 で着信するけれども、 fxp0 で設定された 192.168.0.0/24 のソースアドレスがあるパケットは、落とされます。

規則セットの適切な場所に次を追加することによって、ユーザのトラフィックを (再)マークするために setdscp オプションを使用できるかもしれません:

ipfw add setdscp be ip from any to any dscp af11,af21

動的規則

にせの TCP パケットを含む怒涛の攻撃 (flood attack) からサイトを保護するために、次の動的規則を用いた方が安全です。

ipfw add check-state

ipfw add deny tcp from any to any established

ipfw add allow tcp from my-net to any setup keep-state

これらの規則により、ファイアウォールは、自分たちのネットワークの内側から到着する通常の SYN パケットで始まるコネクションに対してのみ動的規則を組み込みます。動的規則は、 check-state, keep-state または limit 規則の最初の発生に遭遇したときにチェックされます。規則セットのスキャン量を最小にするために、 check-state 規則は、規則セットの最初のほうに置くことになるのが普通です。実際の燃費は、変動します。

ユーザが開ける接続数を制限するには、次のタイプの規則を使用可能です。

ipfw add allow tcp from my-net/24 to any setup limit src-addr 10

ipfw add allow tcp from any to me setup limit src-addr 4

前者 (ゲートウェイ上で動作することを仮定) は、/24 ネット上の各ホストが最大 10 個の TCP 接続を開くことを許します。後者は、サーバ上に設定可能であり、単一のクライアントが同時に 4 個を越える接続を使用できないようにします。

注意: ステートフルな規則は、怒涛の SYN 攻撃により極めて大量の動的規則を作ってしまい、サービス不能攻撃を受けることになる可能性があります。ファイアウォールの動作をコントロールする sysctl(8) 変数に従いファイアウォールが動作することによって、このような攻撃の影響を部分的にでも制限することはできます。

ここで、カウントされている情報とタイムスタンプ情報を見る list コマンドのよい例を示します。

ipfw -at list

これは、タイムスタンプを省略して次のように指定できます。

ipfw -a list

これは、次の指定と等価です。

ipfw show

次の規則は、192.168.2.0/24 からのすべての受信パケットを、5000 番のポートに行き先変更するものです。

ipfw divert 5000 ip from 192.168.2.0/24 to any in

トラフィックシェイパ

次の規則は、 ipfw と dummynet をシミュレーションなどで使う際の使用方法を示しています。

この規則は、5% の確率でランダムにパケットを落します。

ipfw add prob 0.05 deny ip from any to any in

同様の効果は、 dummynet パイプで実現可能です。

ipfw add pipe 10 ip from any to any

ipfw pipe 10 config plr 0.05

人工的にバンド幅を制限するためにパイプを使用可能です。例えばルータとして動作するマシン上で、 192.168.2.0/24 上のローカルクライアントからのトラフィックを制限したい場合、次のようにします。

ipfw add pipe 1 ip from 192.168.2.0/24 to any out

ipfw pipe 1 config bw 300Kbit/s queue 50KBytes

out 指示子を使用して、規則が 2 度使われないようにしていることに注意してください。 ipfw 規則は、実際には、入力パケットと出力パケットの両方に適用されることを覚えておいてください。

バンド幅の制限がある双方向リンクをシミュレートするなら、正確な方法は、次の通りです:

ipfw add pipe 1 ip from any to any out

ipfw add pipe 2 ip from any to any in

ipfw pipe 1 config bw 64Kbit/s queue 10Kbytes

ipfw pipe 2 config bw 64Kbit/s queue 10Kbytes

例えば、あなたの装飾的なウェブページが低速リンクのみで接続されている在宅ユーザにどう見えているか知りたい場合などに、上述の方法は、非常に有用かもしれません。半二重メディア (例えば appletalk, Ethernet, IRDA) をシミュレートしたい場合を除き、単一のパイプを両方の方向に使用すべきではありません。両方のパイプが同じ設定である必要はないので、非対称リンクもシミュレート可能です。

RED キュー管理アルゴリズムでネットワーク性能を検証するならば、次の通りです:

ipfw add pipe 1 ip from any to any

ipfw pipe 1 config bw 500Kbit/s queue 100 red 0.002/30/80/0.1

トラフィックシェイパの他の典型的な応用は、いくばくかの通信遅延を導入することです。これは、バンド幅よりも接続のラウンドトリップ時間が制約要因となることがしばしばという状況下で、遠隔手続き呼び出しを多用するアプリケーションに対し非常に大きな影響を与えます。

ipfw add pipe 1 ip from any to any out

ipfw add pipe 2 ip from any to any in

ipfw pipe 1 config delay 250ms bw 1Mbit/s

ipfw pipe 2 config delay 250ms bw 1Mbit/s

フローごとのキューは、さまざまな用途に有用です。非常に単純な用途は、トラフィックの集計です。

ipfw add pipe 1 tcp from any to any

ipfw add pipe 1 udp from any to any

ipfw add pipe 1 ip from any to any

ipfw pipe 1 config mask all

上述の規則セットは、すべてのトラフィックに対するキューを生成 (して統計情報を収集) します。パイプには制限をつけていないので、統計情報を集める効果しかありません。最後の規則だけでなく 3 個の規則が必要なことに注意してください。 ipfw が IP パケットの適合を試みるときにポートを考慮しないため、別々のポート上の接続が違うものとして見えません。

より洗練された例は、ネットワークごとの制限ではなく、ホストごとの制限があるネットで外向きのトラフィックを制限しています:

ipfw add pipe 1 ip from 192.168.2.0/24 to any out

ipfw add pipe 2 ip from any to 192.168.2.0/24 in

ipfw pipe 1 config mask src-ip 0x000000ff bw 200Kbit/s queue 20Kbytes

ipfw pipe 2 config mask dst-ip 0x000000ff bw 200Kbit/s queue 20Kbytes

検索テーブル

次の例では、いくつかのトラフィック帯域幅のクラスを作成する必要があり、異なったホスト/ネットワークを異なったクラスにする必要があります。各クラスごとに 1 つのパイプを作成し、それぞれそれらを設定します。次に、1 つのテーブルを作成し、IP サブネットとアドレスをそれに書き込みます。各サブネット/ホストのために、それが使用するべきであるパイプの数と同じ数の引数を設定します。次に、1 つの規則を使用してトラフィックを分類します:

ipfw pipe 1 config bw 1000Kbyte/s

ipfw pipe 4 config bw 4000Kbyte/s

...

ipfw table 1 add 192.168.2.0/24 1

ipfw table 1 add 192.168.0.0/27 4

ipfw table 1 add 192.168.0.2 1

...

ipfw add pipe tablearg ip from table(1) to any

fwd アクションを使用して、テーブルエントリは、ホスト名と IP アドレスを含むことができます。

ipfw table 1 add 192.168.2.0/24 10.23.2.1

ipfw table 1 add 192.168.0.0/27 router1.dmz

...

ipfw add 100 fwd tablearg ip from any to table(1)

次の例で、インタフェースごとのファイアウォールが作成されます:

ipfw table 10 add vlan20 12000

ipfw table 10 add vlan30 13000

ipfw table 20 add vlan20 22000

ipfw table 20 add vlan30 23000

..

ipfw add 100 ipfw skipto tablearg ip from any to any recv 'table(10)' in

ipfw add 200 ipfw skipto tablearg ip from any to any xmit 'table(10)' out

規則セット

規則セットを不可分に追加するためには、次の通りです、例えば、セット 18:

ipfw set disable 18

ipfw add NN set 18 ... # 必要に応じて繰り返す

ipfw set enable 18

規則セットを不可分に削除するためには、コマンドは、単に次の通りです: To delete a set of rules atomically the command is simply:

ipfw delete set 18

規則セットをテストし、それを無効にし、何かうまく行かない場合に、制御を回復するためには、次の通りです:

ipfw set disable 18

ipfw add NN set 18 ... # 必要に応じて繰り返す

ipfw set enable 18; echo done; sleep 30 && ipfw set disable 18

ここで各設定がうまくいった場合、"sleep"が終了する前に control-C を押すと、規則セットは、活動状態のままとなります。そうでない場合、たとえ箱にアクセスすることができなかったとしても、規則セットは、sleep が終了した後で無効な状態になるので以前の状態が復元されます。

特定のセットの規則を表示するためには:

ipfw set 18 show

無効にされた規則を表示するためには:

ipfw -S set 18 show

特定のセットの特定の規則のカウンタをクリアするためには:

ipfw set 18 zero NN

特定のセットの特定の規則を削除するためには:

ipfw set 18 delete NN

NAT, リダイレクトと LSNAT

最初に、nat インスタンス 123 へのすべてのトラフィックをリダイレクトします:

ipfw add nat 123 all from any to any

次に、IP 192.168.0.123 ですべての発信トラフィックをエイリアスするために nat インスタンス 123 を設定するためには、次のように、すべての着信接続をブロックし、両側の同じポートを保持することを試み、アドレスの変更でエイリアシングテーブルをクリアして、トラフィック/リンク統計のログを保持します。

ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports

または、インスタンス 123 のアドレスを変更するるためには、エイリアシングテーブルを、クリアします (リセットオプションを参照):

ipfw nat 123 config ip 10.0.0.1

nat インスタンス 123 の設定を見るためには:

ipfw nat 123 show config

範囲 111-999 のすべてのインスタンスのログを表示するためには:

ipfw nat 111-999 show

すべてのインスタンスの設定を見るためには:

ipfw nat show config

または、mixed モードでリダイレクトの規則は、次のようになるでしょう:

ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66

redirect_port tcp 192.168.0.1:80 500

redirect_proto udp 192.168.1.43 192.168.1.1

redirect_addr 192.168.0.10,192.168.0.11

10.0.0.100 # LSNAT

redirect_port tcp 192.168.0.1:80,192.168.0.10:22

500 # LSNAT

または、次のように分割することができるでしょう:

ipfw nat 1 config redirect_addr 10.0.0.1 10.0.0.66

ipfw nat 2 config redirect_port tcp 192.168.0.1:80 500

ipfw nat 3 config redirect_proto udp 192.168.1.43 192.168.1.1

ipfw nat 4 config redirect_addr 192.168.0.10,192.168.0.11,192.168.0.12

10.0.0.100

ipfw nat 5 config redirect_port tcp

192.168.0.1:80,192.168.0.10:22,192.168.0.20:25 500