ipfw(8) FreeBSD 一般コマンドマニュアル

ipfw

前のページ 上に戻る 次のページ

ipfw


     ipfw [-f | -q] flush
     ipfw [-q] {zero | resetlog | delete} [number ...]
     ipfw [-s [field]] [-aftN] {list | show} [number ...]
     ipfw [-q] add [number] rule-body
     ipfw pipe number config pipe-config-options
     ipfw pipe {delete | list | show} [number ...]
     ipfw queue number config queue-config-options
     ipfw queue {delete | list | show} [number ...]


解説

     ipfw は、 FreeBSD の ipfirewall(4)dummynet(4) トラフィックシェイパを
     制御するユーザインタフェースです。

     各入出力パケットは ipfw ルールを通されます。ホストがゲートウェイとして動
     作している場合、ゲートウェイが転送するパケットは ipfw が 2 度処理します。
     ホストがブリッジとして動作している場合、ブリッジが転送するパケットは ipfw
     が 1 度処理します。

     ファイアウォール設定は、番号付けされたルールのリストからなります。あるル
     ールにマッチしそれに関連する動作が実行されるまで、各パケットはルールのリ
     ストに対し照合されます。動作とシステムの設定によっては、マッチしたルール
     の直後で、パケットがファイアウォールに再注入され、更に処理が継続すること
     もあります。全てのルールが全てのインタフェースに適用されますので、チェッ
     クの回数が最小となるようなルール集合を書くのはシステム管理者の責任です。

     どの設定も常に、 DEFAULT ルール (番号 65535) を含みます。このルールはプロ
     グラマが変更できず、常にパケットにマッチします。デフォルトルールに関連付
     けるルールは denyallow のどちらかになりますが、これはどのようにカーネ
     ルを設定したかに依存します。

     ルール集合が keep-state オプション付きのルールを含む場合、 ipfw は ステー
     トフル (状態依存型) で動作します。すなわち、あるマッチの結果、マッチした
     パケットのパラメータにちょうど一致するルールが動的に生成されます。

     これらの動的ルールの寿命は有限で、 check-state または keep-state ルールが
     最初に生じた場所でチェックされます。動的ルールは、合法的なトラフィックを
     オンデマンドでファイアウォールを通過させるために用いることが普通です。
     ipfw のステートフルな動作について更に情報が必要ならば、以下の ルール書式
     または 使用例セクションを参照して下さい。

     動的ルールも含めすべてのルールは、それに関連するカウンタをいくつか持って
     います。それは、パケットカウント、バイトカウント、ログカウント、最後に
     マッチした時刻を示すタイムスタンプです。カウンタは、 ipfw コマンドによっ
     て、表示およびリセット可能です。

     ルールの追加は add コマンドにて可能です。個々のルールの削除は delete コマ
     ンドにて可能であり、すべてのルールの削除は flush コマンドにて可能です。ル
     ールの表示は、 show コマンドおよび list コマンドにて可能です。これらによ
     り、オプションでカウンタ内容も含めて表示させることができます。最後に、カ
     ウンタのリセットは zero コマンドおよび resetlog コマンドにて可能です。

     次のオプションが利用可能です:
             す。通常 (冗長) モードで (デフォルトカーネル設定で) flush を行っ
             た場合、メッセージを表示します。すべてのルールが捨てられますの
             で、メッセージはログインセッションへ渡せません。つまり、リモート
             ログインセッション経由の場合、セッションはクローズされ、残りのル
             ールセットは処理されません。この状態から回復するためにはコンソー
             ルへのアクセスが必要になります。

     -t      リスト作成時に、最後にマッチしたタイムスタンプを表示します。

     -N      出力中のアドレスとサービス名を解決しようとします。

     -s [field]
             パイプ経由でリスト出力している際に、4つのカウンタの1つについて整
             列させます (現在のパケット数)。

     設定を簡単にするために、ルールをファイルに記述して、これを ipfw の最初の
     書式行を使って処理します。 pathname には絶対パス名を使用する必要がありま
     す。このファイルからは 1 行ずつ読み込まれ、 ipfw ユーティリティへの引数と
     なります。

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

     後述の トラフィックシェイパ設定の節で示すように、 ipfw pipe コマンドを使
     用して、トラフィックシェイパを構築可能です。


ルール書式

     ipfw ルールフォーマットは次の通りです。

     [prob match_probability] action [log [logamount number]] proto from src
     to dst [interface-spec] [options]

     各パケットをフィルタする際には、以下の情報に基づくことができます。

           送受信インタフェース          (名前またはアドレス)
           方向                          (入力または出力)
           送信元および宛先 IP アドレス  (マスク使用可)
           プロトコル                    (TCP, UDP, ICMP 等)
           送信元および宛先ポート        (リスト、範囲、マスクのいずれか)
           TCP フラグ
           IP フラグメントフラグ
           IP オプション
           ICMP タイプ
           パケットに関連付けられたソケットのユーザ ID とグループ ID

             deny    マッチするパケットを破棄し、マッチングを終了します。 dropdeny の別名です。

             reject  (この使用は推奨されません) マッチするパケットを破棄し、
                     ICMP の host unreachable を送信し、マッチングを終了しま
                     す。

             unreach code
                     マッチするパケットを破棄し、 ICMP の unreachable に code
                     を付けて送信します。ここで、 code は、0 から 256 までの数
                     字、もしくは、以下に列挙する別名のいずれかです: net,
                     host, protocol, port, needfrag, srcfail, net-unknown,
                     host-unknown, isolated, net-prohib, host-prohib, tosnet,
                     toshost, filter-prohib, host-precedence,
                     precedence-cutoff 。マッチングは終了します。

             reset   TCP パケットのみ対象。パケットを破棄し、TCP の reset
                     (RST) を送信し、マッチングを終了します。

             count   ルールにマッチするパケットすべてのカウンタを更新し、引続
                     きマッチングを行ないます。

             check-state
                     動的ルール集合に対してパケットのチェックを行ないます。
                     マッチした場合、マッチングは終了します。マッチしなかった
                     場合、次のルールに移ります。 check-state ルールが見つから
                     ないときは、動的ルール集合は最初の keep-state ルールの場
                     所でチェックされます。

             divert port
                     マッチするパケットを port で指定されたポートにバインドさ
                     れている divert(4) ソケットに送り、マッチングを終了しま
                     す。

             tee port
                     マッチするパケットのコピーを port で指定されたポートにバ
                     インドされている divert(4) ソケットに送ります。検索を終了
                     し、元のパケットは受理されます (ただし後述の バグを参照し
                     てください)。

             fwd ipaddr[,port]
                     マッチしたパケットの次のホップを ipaddr に変更します。こ
                     れはドット付き 4 つ組の IP アドレスでもホスト名でもよいで
                     す。 ipaddr が直接到達可能なアドレスではない場合、その IP
                     に対してローカルルーティングテーブルでみつかった経路を使
                     用します。 ipaddr がローカルアドレスの場合、リモートホス
                     トからこのシステムにパケットが到着すると、そのパケットを
                     ローカルマシンの port に転換します。その際、ソケットのロ
                     ーカルアドレスは、パケットの元々の宛先の IP アドレスのま
                     まとします。これは透過的プロキシサーバのためにあります。
                     IP が ローカルアドレスではない場合、ポート番号は (指定さ
                     net.inet.ip.fw.one_pass がセットされていない場合、パケッ
                     トはファイアウォールコードへ再度渡されて次のルールから開
                     始します。

             queue queue_nr
                     パケットを dummynet(4) ``queue'' へ渡します (WF2Q を使っ
                     たバンド幅制限用)。

             skipto number
                     number より小さな番号のルールを飛び越して、 number 以上の
                     番号のルールで最初に存在するものから、マッチングを継続し
                     ます。

     log [logamount number]
             カーネルが IPFIREWALL_VERBOSE オプション付きでコンパイルされてい
             る場合に、 log キーワードが指定されているルールとマッチした時、
             メッセージを LOG_SECURITY ファシリティで syslogd(8) でログしま
             す。 注: デフォルトでは、ログは /var/log/security ファイルに追加
             されます ( syslog.conf(5) を参照してください)。カーネルが、
             IPFIREWALL_VERBOSE_LIMIT オプション付きでコンパイルされている場
             合、デフォルトでは、一連のルールに対し指定されたパケット数を受信
             した後、メッセージの表示を中止し、 net.inet.ip.fw.verbose_limit
             がその数に設定されます。しかし logamount number が使用された場
             合、 net.inet.ip.fw.verbose_limit の代りにこの number がデフォル
             トのログ制限になり、値 ``0'' を指定すると、ロギングの制限は取り除
             かれます。このエントリに対するロギングカウンタまたはパケットカウ
             ンタをクリアすれば、ロギングは再び有効になります。

             コンソールログとデフォルトログ制限数は、 sysctl(8) を通じて MIB
             ベース net.inet.ip.fw にて動的に設定できます。

     proto   名前または数値で指定する IP プロトコル (詳細は /etc/protocols の
             リストを参照のこと)。 ip または all のキーワードを使用すると、す
             べてのプロトコルがマッチします。

     srcdst:
             any | me | [not] <address/mask> [ports]

             any を指定すると、ルールはすべての IP 番号とマッチします。

             me を指定すると、ルールはシステム上で構成されたすべての IP 番号と
             マッチします。これは、計算量的にかなり高価なチェックですので、注
             意して使用してください。

             <address/mask> は以下のように指定できます。

             ipno       IP 番号を 1.2.3.4 の形式で指定します。この IP 番号にの
                        みマッチします。

             ipno/bits  IP 番号とネットマスクの幅を 1.2.3.4/24 の形式で指定し
                        ます。この例の場合は 1.2.3.0 から 1.2.3.255 のアドレス
                        がマッチします。

             記号 `:' による表現は、ポートとマスクを指定します。マッチが宣言さ
             れるのは、パケット中のポート番号がルール中のポート番号にマッチす
             るときですが、マッチ対象のビットはマスク中で指定されたものに限定
             されます。

             ポート番号の代わりに (ファイル /etc/services から取った) サービス
             名を使用できます。ポート範囲指定の書式は、最初の値としてのみ指定
             できます。列挙出来るポート数は /usr/src/sys/netinet/ip_fw.h で
             IP_FW_MAX_PORTS として定義されています。バックスラッシュ (`\') を
             使用することにより、サービス名中の (`-') 文字をエスケープ可能で
             す:

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

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

     interface-spec
             次の指定子の組み合わせを使用可能です:

             in        入力パケットにのみマッチします。

             out       出力パケットにのみマッチします。

             via ifX   パケットはインタフェース ifX を通過せねばなりません。

             via if*   パケットはインタフェース ifX を通過せねばなりません。こ
                       の X はどんなユニット番号でもかまいません。

             via any   パケットは いずれかのインタフェースを通過せねばなりませ
                       ん。

             via ipno  パケットは、 IP アドレス ipno を持つインタフェースを通
                       過せねばなりません。

             via を用いると、常時指定されたインタフェースがチェックされます。
             recvxmit を、 via の代わりに指定すると、受信、もしくは送信イ
             ンタフェースのみが (おのおの) チェックされます。両方を指定すれ
             ば、受信インタフェースと送信インタフェースの両方に基づきパケット
             をマッチさせることが可能になります。例 :

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

             recv で指定したインタフェースでは、受信と送信、両方のパケットを
             チェックできます。それに対し、 xmit で指定したインタフェースで
             は、送信パケットのみとなります。それゆえに、 xmit を指定すると
             out が、必須です ( in は不可)。 via と共に xmit もしくは、 recv
             を指定する事はできません。


                     実際の動作は、異なる method を指定することにより変更が可
                     能です。

             bridged
                     ブリッジされるパケットにのみマッチします。これはマルチ
                     キャストやブロードキャストのパケットを扱う際に有用です。
                     これ以外の方法では、パケットは、ブリッジの際に一度、ロー
                     カルスタックに渡される際にもう一度と、ファイアウォールを
                     2 度通過してしまいます。

                     パフォーマンス上のわずかな損失はともかく、 pipe を用いる
                     際にも問題になります。これは、バンド幅、キュー占有度など
                     のカウンタに関して、同じパケットが 2 度カウントされてしま
                     うためです。

             frag    パケットが断片 (フラグメント) 化されたデータグラムの一部
                     で、かつデータグラムの先頭の断片でない場合にマッチしま
                     す。 frag を、 tcpflags や TCP/UDP ポート指定と共に使用す
                     ることはできません。

             ipoptions spec
                     IP ヘッダが、 spec に指定されたコンマで区切られたオプショ
                     ンのリストを含む場合にのみマッチします。サポートされてい
                     る IP オプションは

                     ssrr (strict source route), lsrr (loose source route), rr
                     (record packet route), ts (timestamp) です。 `!' によっ
                     て、特定のオプションを含まない指定が記述できます。

             tcpoptions spec
                     TCP ヘッダが、 spec に指定されたコンマで区切られたオプ
                     ションのリストを含む場合にのみマッチします。サポートされ
                     ている TCP オプションは

                     mss (maximum segment size), window (tcp window advertise-
                     ment), sack (selective ack), ts (rfc1323 timestamp), cc
                     (rfc1644 t/tcp connection count) です。 `!' によって、特
                     定のオプションを含まない指定が記述できます。

             established
                     TCP パケットのみに適用されます。 RST または ACK ビットが
                     セットされているパケットのみマッチします。

             setup   TCP パケットのみに適用されます。 SYN ビットがセットされ
                     ACK がセットされていないパケットのみマッチします。

             tcpflags spec
                     TCP パケットのみに適用されます。 TCP ヘッダが spec に指定
                     されたコンマで区切られたフラグのリストを含む場合にのみ
                     マッチします。サポートされているフラグは、

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

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

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


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

     ipfw ユーティリティは、 dummynet(4) トラフィックシェイパへのユーザインタ
     フェースも提供します。シェイパは、ユーザが指定したマスクを IP ヘッダの異
     なったフィールドに適用することにより、パケットを フロー (flow) に分割しま
     す。同じフローに属するパケットは 2 つの異なったオブジェクトへ渡されます。
     それは パイプ (pipe) または キュー (queue) と呼ばれるものです。 パイプ
     は、与えられたバンド幅、遅延時間、キューの長さ、パケット喪失率をもつリン
     クをエミュレートします。このパラメータに従い、パケットはパイプ中を遷移し
     ます。

     キューは、WF2Q+ ポリシを実装するために使用する抽象化です。キューは、各フ
     ローに対し、重みと参照パイプを関連付けます。それから、同じパイプに結び付
     けられたすべてのフローは、 WF2Q+ ポリシに従い、パイプによって固定されたレ
     ートでスケジュールされます。

     ipfw パイプ設定書式は次の通りです。

     pipe number config [bw bandwidth | device] [delay ms-delay] [queue {slots
     | size}] [plr loss-probability] [mask mask-specifier] [buckets
     hash-table-size] [red | gred w_q/min_th/max_th/max_p]

     ipfw キュー設定書式は次の通りです。

     queue number config [pipe pipe_nr] [weight weight] [queue {slots | size}]
     [plr loss-probability] [mask mask-specifier] [buckets hash-table-size]
     [red | gred w_q/min_th/max_th/max_p]

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

     bw bandwidth | device
             バンド幅であり、単位は [K|M]{bit/s|Byte/s} で測定します。

             値 0 (デフォルト) は無限のバンド幅を意味します。単位は数値の直後
             に続けて書く必要があり、次のようにします。

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

             す。低速リンクではキューの大きさを短くすべきことに注意してくださ
             い。さもないと、トラフィックは甚大なキュー遅延による影響を受けて
             しまいます。例えば、 50 個の最大イーサネットパケット (1500 バイ
             ト) は 600Kbit であり、 30Kbit/s のパイプでは 20 秒のキューを意味
             します。より大きな MTU のインタフェースからパケットを受け取るとき
             には、より悪い結果となります。例えば、ループバックインタフェース
             において 16KB パケットを受け取るときです。

     plr packet-loss-rate
             パケット喪失率です。引数 packet-loss-rate は 0 と 1 の間の浮動小
             数点数であり、 0 は喪失無しを意味し、1 は 100% の喪失を意味しま
             す。喪失率は内部的には 31 ビットで表現されます。

     mask mask-specifier
             dummynet(4) では、フローごとのキューを生成可能です。フロー識別子
             は、パイプ設定において指定される IP アドレス、ポート、プロトコル
             タイプでマスクすることで構築されます。マスク後に同じ識別子を持つ
             パケットは、同じキューに落ちます。使用可能なマスク指定子は、次を
             組み合わせたものです: dst-ip mask, src-ip mask, dst-port mask,
             src-port mask, proto mask, all 。最後の指定子は、すべてのフィール
             ドのすべてのビットが重要であることを意味しています。 pipe 設定中
             で使用される場合、各フローにはパイプのレートに等しいレートが割り
             当てられます。 queue 設定中で使用される場合、各フローにはキューの
             重みに等しい重みが割り当てられ、同じパイプを構成するキューは重み
             に比例してバンド幅を共有します。

     buckets hash-table-size
             様々なキューを格納するために使用するハッシュ表の大きさを指定しま
             す。デフォルト値は 64 であり、 sysctl(8) 変数
             net.inet.ip.dummynet.hash_size で制御され、使用可能な範囲は 16 か
             ら 1024 です。

     pipe pipe_nr
             キューを指定したパイプに接続します。複数のキュー (通常は異なった
             重み) を同一のパイプに接続可能です。この場合、このキュー集合に対
             する集約レートを、このパイプが指定します。

     weight weight
             このキューに適合するフローに使用する重みを指定します。重みは
             1..100 の範囲であることが必要であり、デフォルトは 1 です。

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

             net.inet.ip.dummynet.red_lookup_depth
                     リンクがアイドルの時の、平均キューの計算精度を指定します

     o   かならず送信パケットと受信パケットの両方のパケットをフィルタリングし
         ます。ほとんどのネットワークコネクションではパケットが双方向に流れる
         ことが必要です。

     o   テストは細心の注意を払って行ないます。テストの際にはコンソールの近く
         にいるのがよいでしょう。コンソールに近寄れない場合、
         /usr/share/examples/ipfw/change_rules.sh にあるような自動回復スクリプ
         トを使用してください。

     o   ループバックインタフェースのことを忘れてはなりません。


長所

     o   ファイアウォールが常に破棄するパケットが 1 種類あります。フラグメント
         オフセットが 1 の TCP パケットフラグメントです。これはパケットとして
         は有効なものですが、利用目的はファイアウォールをかいくぐることしかあ
         りません。ログが有効な場合、これらのパケットはルール -1 により破棄さ
         れたと報告されます。

     o   ネットワーク越しにログインしている場合、 kld(4) バージョンの ipfw を
         ロードすることはそれほど単純なことではありません。以下のコマンドを奨
         めます。

               kldload /modules/ipfw.ko && \
               ipfw add 32000 allow ip from any to any

         これに引続き、同じような状況で

               ipfw flush

         とするのは良くありません。

     o   システムセキュリティレベルが 3 以上に設定されている場合、 IP フィルタ
         リストを変更できません (システムセキュリティレベルについては init(8)
         を参照してください)。


パケットの行き先変更

     指定されたポートにバインドされた divert(4) ソケットは、そのポートへ行き先
     変更されたパケットを、全部受けとります。宛先ポートにバインドされたソケッ
     トがない場合や、カーネルがパケットの行き先変更ソケットをサポートするよう
     にはコンパイルされていない場合、パケットは破棄されます。


SYSCTL 変数

     ファイアウォールの動作を制御する sysctl(8) 変数の集合があります。これら
     を、デフォルトの値と意味とともに以下に示します。

     net.inet.ip.fw.debug: 1
             ipfw が生成するデバッグメッセージを制御します。

     net.inet.ip.fw.one_pass: 1
             セットされると、 dummynet(4) パイプから出て来たパケットは、ふたた
             びファイアウォールを通さないようにします。セットされない場
             合、pipe 処理のあと、パケットは再びファイアウォールに挿入され、次

     net.inet.ip.fw.curr_dyn_buckets: 256
             動的ルールを保持するために使用するハッシュ表の設定サイズと現在の
             サイズです。この値は 2 のべき乗にする必要があります。ハッシュ表の
             サイズの変更は、表が空の場合のみ行なわれます。したがって、実行中
             に表のサイズを変更するためには、 flush してルール集合を再ロードす
             る必要があるでしょう。

     net.inet.ip.fw.dyn_count: 3
             現在の動的ルールの数です (読み込み専用)。

     net.inet.ip.fw.dyn_max: 1000
             動的ルールの最大値です。この限界にいきつくと、古いルールが無効に
             なるまでは、それ以上、動的ルールを組み込むことはできません。

     net.inet.ip.fw.dyn_ack_lifetime: 300

     net.inet.ip.fw.dyn_syn_lifetime: 20

     net.inet.ip.fw.dyn_fin_lifetime: 20

     net.inet.ip.fw.dyn_rst_lifetime: 5

     net.inet.ip.fw.dyn_short_lifetime: 30
             これらの値は、動的ルールの生存期間を秒単位でコントロールします。
             最初の SYN 交換の際に、生存期間が short になり、 SYN を両方とも見
             た後に増やされ、最後の FIN 交換の間、または RST が生じる際に再び
             減らされます。


使用例

     次のコマンドは 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
     とになるのが普通です。実際の燃費は変動します。

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

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

           ipfw -at l

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

           ipfw -a l

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

           ipfw divert 5000 ip from 192.168.2.0/24 to any in

     次のルールは、 ipfwdummynet(4) をシミュレーションなどで使う際の使用方
     法を示しています。

     このルールは 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

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

           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


関連項目

     cpp(1), m4(1), bridge(4), divert(4), dummynet(4), ip(4), ipfirewall(4),
     protocols(5), services(5), init(8), kldload(8), reboot(8), sysctl(8),
     syslogd(8)


バグ

     この数年で文法が大きくなってしまい、非常にすっきりしているとは言い難いで
     す。

     WARNING!!WARNING!!WARNING!!WARNING!!WARNING!!WARNING!!WARNING!!

     このプログラムはコンピュータをかなり使いにくい状態にしてしまう可能性があ
     ります。はじめて使用する時はコンソール上で実行し、理解していない操作は 絶
     対に実行しないようにして下さい。

     連続したエントリの操作もしくは追加に際し、サービス名やプロトコル名は使用
     できません。

     API は Daniel Boulet が BSDI 用に記述したコードに基づいています。

     dummynet(4) トラフィックシェイパは Akamba Corp がサポートしました。


歴史

     ipfw は、 FreeBSD 2.0 で最初に現れました。 dummynet(4) は FreeBSD 2.2.8
     から導入されました。ステートフル拡張は、 FreeBSD 4.0 から導入されました。

FreeBSD 4.4                    February 16, 2000                   FreeBSD 4.4

ABELNET VPSサービス