manページ  — IPFW

ipfw – IP ファイアウォールとトラフィックシェイパの制御プログラム

書式 解説 パケットフロー 文法 ルール書式 ルールアクション ルールボディ ルールオプション (マッチパターン) 検索表 ルールのセット ステートフルファイアウォール トラフィックシェイパ (DUMMYNET) 設定 チェックリスト 細かい事柄 パケットの行き先変更 SYSCTL 変数 FreeBSD 4.x で IPFW2 を使う IPFW2 拡張 使用例 基本的なパケットフィルタリング 動的ルール トラフィックシェイパ ルールセット 関連項目 バグ 作者 歴史

ipfw [-cq] add rule
ipfw [-acdefnNStT] { list | show} [rule | first-last ...]
ipfw [-f | -q] flush
ipfw [-q] { delete | zero | resetlog} [ set] [number ...]
ipfw enable { firewall | one_pass | debug | verbose | dyn_keepalive}
ipfw disable { firewall | one_pass | debug | verbose | dyn_keepalive}

ipfw set [ disable number ... ][ enable number ...]
ipfw set move [ rule] number to number
ipfw set swap number number
ipfw set show

ipfw table number add addr[/masklen ][value]
ipfw table number delete addr[/masklen]
ipfw table number flush
ipfw table number list

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

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

1 個のパケットが、プロトコルスタックの複数の場所で、 有効なルールセットに対しチェックされます。このチェックは いくつかの sysctl 変数に基づきます。 これらの場所と変数を以下に示します。 ルールセットを正しく設計するためには、この図をよく理解する ことが大切です。

      ^     to upper layers   V
      |                       |
      +----------->-----------+
      ^                       V
 [ip_input]              [ip_output]   net.inet.ip.fw.enable=1
      |                       |
      ^                       V
[ether_demux]    [ether_output_frame]  net.link.ether.ipfw=1
      |                       |
      +-->--[bdg_forward]-->--+        net.link.ether.bridge_ipfw=1
      ^                       V
      |      to devices       |

上図に示されるように、 同一のパケットがファイアウォールを通過する回数は、 パケットの発信元や宛先、システムの設定により、 0 回から 4 回の範囲で変動します。

パケットがスタックを通過するにつれヘッダが削除 / 追加される 可能性があり、ヘッダがチェックに使えたり使えなかったりする ことに注意して下さい。 例えば、外から入ってくるパケットは ether_demux() から ipfw が実行されるときには MAC ヘッダを含んでいるはずですが、 その同じパケットが、 ip_input() から ipfw が実行されたときには MAC ヘッダは取り除かれているはずです。

また、各パケットは常にルールセット全体に対しチェックされることにも 注意してください。 これは、チェックが生じた場所、パケットのソースに関係ありません。 実行された箇所によっては無効となるような マッチパターンやアクション (例えば、 ip_input() 中で MAC ヘッダとマッチを試みるようなもの) をルールが含んでいるなら、そのパターンはマッチしないことになります。 とはいえ、そのようなパターンの前に not オペレータを記述すれば、このパターンは 常に そのようなパケットにマッチすることになります。 したがって、必要に応じ、生じ得る場所の違いを理解して、 適切なルールセットを記述することはプログラマの責任です。 そこで skipto ルールが役に立つことでしょう。 例えば次のようにします。

# ether_demux または bdg_forward からのパケット
ipfw add 10 skipto 1000 all from any to any layer2 in
# ip_input からのパケット
ipfw add 10 skipto 2000 all from any to any not layer2 in
# ip_output からのパケット
ipfw add 10 skipto 3000 all from any to any not layer2 out
# ether_output_frame からのパケット
ipfw add 10 skipto 4000 all from any to any layer2 out

(そうです、今のところ ether_demux と bdg_forward とを 区別する方法はありません)。

一般に、各キーワードもしくは引数は、別々のコマンド行引数として与えられ、 その前や後には空白は付きません。 キーワードは、大文字小文字を区別しますが、 引数は、その性質に依存し、大文字小文字を区別するかもしれませんし、 しないかもしれません (例えば uid は区別しますが、hostname はしません)。

ipfw2 では、コンマ ',' の後に空白を入れ、行を読み易くできます。 また、コマンド全体 (フラグを含む) を、単一引数に入れられます。 例えば、次の書式は等価です:

ipfw -q add deny src-ip 10.0.0.0/24,127.0.0.1/8
ipfw -q add deny src-ip 10.0.0.0/24, 127.0.0.1/8
ipfw "-q add deny src-ip 10.0.0.0/24, 127.0.0.1/8"

ipfw ルールの書式は次の通りです。 [rule_number] [ set set_number] [ prob match_probability]
action [ log [ logamount number]] body

この中で、ルールのボディ (body) は次の中からどの情報を使用して パケットをフィルタするかを指定します。

レイヤ 2 ヘッダフィールド	可能ならば
IPv4 プロトコル	TCP, UDP, ICMP など
送信元および宛先のアドレスとポート 方向
	セクション パケットフロー を参照して下さい
送信および受信インタフェース	名前またはアドレス
その他の IP ヘッダフィールド	バージョン、サービスタイプ、データグラム長、識別子、 フラグメントフラグ (0 でない IP オフセット)、 生存時間
IP オプション その他の TCP ヘッダフィールド
	TCP フラグ (SYN, FIN, ACK, RST など)、 シーケンス番号、確認応答番号、ウィンドウ
TCP オプション ICMP タイプ
	ICMP パケットの場合
ユーザ/グループ ID	パケットをローカルソケットに関連づけることが可能な場合

上記の情報のうち幾つか、 例えば、送信元 MAC アドレスまたは IP アドレスと TCP/UDP ポート は容易に詐称が可能であることに注意して下さい。 したがって、これらのフィールドのみでフィルタすることは 必ずしも望ましい結果を保証しません。

rule_number
	各ルールは、1 から 65535 の範囲の rule_number に関連づけられており、 後者は デフォルト ルールのために予約されています。 ルールはルール番号の順にチェックされます。 複数のルールが同一の番号を持つことが可能で、 その場合は追加された順序でチェックされます (表示する場合も同様です) 。 番号の指定なしでルールが入力された場合、 カーネルは、そのルールが デフォルト ルールより前にあるルールの中で最後になるように割り当てます。 自動的につけられるルール番号は、 デフォルトを除いた中で最後となるルール番号を、 sysctl 変数 net.inet.ip.fw.autoinc_step の値だけ増加させて割り当てられます。 この変数のデフォルトは 100 です。 もし、この操作が (例えば許可された最大ルール番号を越えるといった理由で) 不可能であれば、 最後のデフォルトでない値が代わりに使用されます。
set set_number
	各ルールは 0 から 31 の範囲の set_number に関連づけられています。 セットは個別に無効化したり有効化したりすることができます。 したがって、このパラメータは不可分なルールセット操作を行うために 必要不可欠なものです。 このパラメータを使うことで、ルールをまとめて削除することを 単純にすることもできます。 セット番号を指定せずにルールを入力した場合、 セット 0 が使用されます。 セット 31 は特別であり、無効化できませんし、この中のルールは ipfw コマンドで削除できません (しかし、 ipfw コマンドで削除するこはできます)。 セット 31 はまた、 デフォルト ルールとしても使用されます。
prob match_probability
	指定した確率 (0 から 1 までの浮動小数点数です) でしかマッチしないマッチを宣言します。 ランダムにパケットを落とす応用や、 ((dummynet) 4 と共に使用して) パケット到達順序の乱れを引き起こす複数経路の効果をシミュレートする 応用など、多くの応用に有用です。 注: この条件は、他の条件の前にチェックされます。 これには、keep-state や check-state といった副作用のあるものも含まれます。
log [ logamount number]
	パケットが log キーワードを持ったルールにマッチした場合、 メッセージが syslogd(8) に LOG_SECURITY ファシリティで記録されます。 sysctl 変数 net.inet.ip.fw.verbose が 1 (カーネルが IPFIREWALL_VERBOSE でコンパイルされていればこれがデフォルトです) に設定されており、 そのルールについてこれまで記録されたパケットの数が その logamount パラメータを越えていなければ、記録が行われます。 logamount が指定されていなければ、制限は sysctl 変数 net.inet.ip.fw.verbose_limit から参照されます。 両者の値が 0 であれば記録の制限は取り除かれます。 一度制限に達したなら、 このエントリに対するロギングカウンタかパケットカウンタをクリアすれば 記録を再び有効にすることができます。 resetlog コマンドを参照して下さい。 注: ログが実行されるのは、 すべてのパケットマッチ条件が成功裏に確認された後であり、 最後の動作 (受理や拒否等) をパケットに実施する前です。

ルールは次に示すアクションの 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[,port]
	マッチしたパケットの次のホップを ipaddr に変更します。 これには IP アドレスとして、数字 4 つ組形式 またはホスト名が使用できます。 このルールにマッチした場合、検索は終了します。 ipaddr がローカルアドレスの場合、マッチしたパケットはローカルマシンの port (または、ルールで指定されていない場合はそのパケットのポート番号) に転送されます。 ipaddr がローカルアドレスでない場合、 ポート番号は (指定されていても) 無視され、 パケットは ローカルな経路テーブルに存在するその IP に対する経路を使用して リモートアドレスに転送されます。 fwd ルールはレイヤ 2 パケット (それらは ether_input, ether_output, bridged で受信されます) にはマッチしません。 fwd アクションはパケットの内容をまったく変更しません。 実際、宛先アドレスが修正されずに残るので、 転送先システムがそのようなパケットを取り込むルールを持たない限り、 他のシステムに転送されたパケットは、通常転送先のシステムで拒否されます。 ローカルに転送されるパケットの場合、 ソケットのローカルアドレスはパケットが元々持っていた 宛先アドレスに設定されます。 このことによって netstat(1) が出力するエントリは若干奇妙な見え方になりますが、 これは透過プロキシサーバでの使用を意図しています。 fwd を有効にするには、カーネルを オプション options IPFIREWALL_FORWARD を付けてコンパイルすることが必要です。 追加のオプション options IPFIREWALL_FORWARD_EXTENDED を指定することで、安全策がすべて外され、 ローカルに設定された IP アドレス宛のパケットをリダイレクトすることも 可能になります。 そのようなルールはローカルに生成されたパケットにも適用されるので、 ICMP メッセージサイズ超過などのような自動的に生成されるパケットが 適切に振る舞うよう細心の注意が必要なことに注意して下さい。
pipe pipe_nr
	パケットを dummynet(4) "パイプ" (バンド幅制限、遅延などに使用されます) へ渡します。 詳しい情報については トラフィックシェイパ (DUMMYNET) 設定 セクションを参照してください。 検索は終了します。 しかし、パイプから抜けたときに sysctl(8) 変数 net.inet.ip.fw.one_pass がセットされていない場合、 パケットは、すぐ次のルールから始まるファイアウォールコードへ 再度渡されます。
queue queue_nr
	パケットを dummynet(4) "キュー" (WF2Q+ を使ったバンド幅制限に使用されます) へ渡します。
reject
	(非推奨)。 unreach host と同義です。
reset	このルールにマッチしたパケットを破棄します。 さらに、そのパケットが TCP パケットであれば、 TCP リセット (RST) 通知を送出しようと試みます。 検索は終了します。
skipto number
	それ以降のルールのうち number より小さな番号のものすべてを飛び越して、 number 以上の番号のルールで最初に存在するものから、検索を継続します。
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 。 検索は終了します。

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

    ipfw add 100 allow ip from not 1.2.3.4 to any

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

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

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

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

ルールボディは以下の書式で指定します。 [proto from src to dst] [options]

最初の部分 (proto from src to dst) は ipfw1 との後方互換のためにあります。 ipfw2 では、任意のマッチパターン (MAC ヘッダ、IPv4 プロトコル、アドレス、ポートを含む) が options セクションで指定できます。

ルールフィールドは以下の意味を持ちます。

proto : protocol | { protocol or ... } protocol : [ not ]protocol-name | protocol-number
	IPv4 におけるプロトコル を、数字や名前で指定します (完全なリストは /etc/protocols を参照して下さい)。 ip または all のキーワードを使用すると、すべてのプロトコルがマッチします。 { protocol or ... } 書式 ( 論理和ブロック) は、簡便さのためだけに提供されており、価値が低下しています。
src and dst : { addr | { addr or ... } }[[ not ]ports]
	単一のアドレス (またはリスト、後述) で、 オプションとして、その後に ports 指示子を続けて置くことができます。 第 2 の書式 (複数アドレス付きの 論理和ブロック) は、簡便さのためだけに提供されており、価値が低下しています。
addr : [ not ]{
	any | me | table(number[,value]) | addr-list | addr-set }
any	任意の IP アドレスがマッチします。
me	システムのインタフェースに設定された任意の IP アドレスがマッチします。 アドレスのリストはパケットが解析されるときに評価されます。
table(number[,value])
	検索表 number に存在するエントリに対応する任意の IP アドレスがマッチします。 オプションの 32 ビット符号なし整数 value も指定された場合には、その値のエントリにのみマッチします。 検索表に関する詳細は下記の 検索表 セクションを参照して下さい。
addr-list : ip-addr[,addr-list] ip-addr:
	次の方法で指定される、ホストもしくはサブネットのアドレス:
numeric-ip | hostname
	ドットで区切った数字 4 つ組またはホスト名で指定した、 1 つの IPv4 アドレスがマッチします。 ホスト名の名前解決は、そのルールがファイアウォールのリストに 追加されるときに行われます。
addr/masklen
	ベースとなる addr (ドットで区切った数字 4 つ組またはホスト名で指定します) と masklen ビット幅のマスク に一致する全てのアドレスがマッチします。 例えば、1.2.3.4/25 は 1.2.3.0 から 1.2.3.127 までの 全ての IP アドレスがマッチすることになります。
addr:mask
	ベースアドレスが addr (ドットで区切った 4 つの数字またはホスト名で指定されます) であり、マスクが mask (ドットで区切った 4 つの数字で指定されます) である全てのアドレスにマッチします。 例えば、1.2.3.4:255.0.255.0 は、1.*.3.* にマッチします。 この形式は、連続でないマスクの場合にだけ使用することを推奨します。 連続なマスクの場合は、よりコンパクトでより間違いにくい、 addr/masklen を使います。

addr-set : addr[/masklen ] {list } list : {num | num-num }[,list]
	ベースアドレスが addr (ドットで区切った数字 4 つ組またはホスト名で指定します) であり、最後のバイトがブレース {} の中に列挙されている 全てのアドレスがマッチします。 ブレースと数字の間には空白を置いてはいけないことに注意して下さい (コンマの後の空白は許されています)。 リストの要素は、単一項目もしくは範囲が指定可能です。 masklen フィールドはアドレスのセットのサイズに制限をつけるために使用され、 24 から 32 の間の任意の値をとることができます。 指定されない場合 24 が仮定されます。 この書式は 1 つのルールでまばらなアドレス群を取り扱うときに 特に便利です。 ビットマスクを使用してマッチを行うので、 定数時間で処理でき、ルールセットの複雑さが劇的に減少します。 例えば、アドレスを 1.2.3.4/24{128,35-55,89} として指定した場合、 次のアドレスがマッチします: 1.2.3.128, 1.2.3.35 to 1.2.3.55, 1.2.3.89 .
ports : {port | portamp;-port}[,ports]
	(TCP や UDP などのように) ポート番号をサポートしている プロトコルについて、オプションとして、 ports を指定することができます。 1 つ以上のポートまたはポートの範囲を空白なしのコンマ区切りで指定します。 さらにオプションとして、 not オペレータを付加して指定することができます。 記号 ‘amp;-’ による表現は、ポート範囲 (両端含む) を指定します。 ポート数値の代わりに (ファイル /etc/services から取った) サービス名を使用できます。 ポートリストの長さは 30 ポートまたはポート範囲に制限されていますが、 ルールの options セクションで 論理和ブロック を使用することにより、より広い範囲を指定することができます。 バックスラッシュ (‘\’) を使用することにより、サービス名中のダッシュ (‘-’) 文字をエスケープ可能です (シェルから入力するとき、 シェル自身がバックスラッシュをエスケープ文字として解釈するのをさけるために、 バックスラッシュを 2 回タイプしなければなりません)。     ipfw add count tcp from any ftp\\-data-ftp to any 断片化されたパケットでオフセットが非 0 のもの (すなわち、最初の断片ではないもの) は、 1 つ以上のポート指定を持つルールにはマッチしません。 断片化されたパケットへのマッチングに関する詳細は frag オプションを参照してください。

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

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

// this is a comment.
	指定したテキストを、ルール中にコメントとして挿入します。 // に続くすべてがコメントとして扱われ、ルール中に格納されます。 コメントのみのルールを持つことも可能であり、それは count アクションに続いてコメントが表示されます。
bridged
	layer2 の別名です。
dst-ip ip-address
	宛先 IP アドレスが引数で指定したアドレスの 1 つである IP パケットにマッチします。
dst-port ports
	宛先ポートが引数で指定したポートの 1 つである IP パケットにマッチします。
established
	RST か ACK ビットがセットされている TCP パケットにマッチします。
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)
in | out
	それぞれ到着または送出パケットにマッチします。 in と out は互いに排他的です (実際、 out は not in として実装されています)。
ipid id-list
	ip_id フィールドが id-list に含まれる IP パケットにマッチします。 id-list は、単一の値か、 ports と同等の方法で指定される、値のリストか範囲です。
iplen len-list
	ヘッダとデータを含んだ全体の長さが len-list に含まれる IP パケットにマッチします。 len-list は、単一の値か、 ports と同等の方法で指定される、値のリストか範囲です。
ipoptions spec
	spec で指定したコンマ区切りリストオプションを含む IP ヘッダを持つ パケットにマッチします。 IP オプションは次のものがサポートされています: ssrr (ストリクトソースルーティング), lsrr (ルーズソースルーティング), rr (レコードルート), ts (タイムスタンプ)。 ‘amp;!’ を置くことで特定のオプションが存在しないという記述ができます。
ipprecedence precedence
	先行フィールドが precedence に等しい IP パケットにマッチします。
ipsec	IPSEC ヒストリを持つパケットにマッチします (すなわち、入力パケットが IPSEC でカプセル化されており、 カーネルが IPSEC と IPSEC_FILTERGIF のオプションをサポートし、 正しくパケットのカプセル化を解除できた場合です)。 ipsec を指定することは、 proto ipsec を指定することとは違います。 何故なら後者は、IPSEC カーネルサポートの有無および IPSEC データの正当性 にかかわらず、特定の IP プロトコルフィールドのみを見るからです。 更に、IPSEC サポート無しのカーネルでは、 このオプションは黙って無視されることに注意してください。 この場合、このフラグを指定してもルール処理に影響が無く、あたかも ipsec フラグが指定されていないかのように当該ルールが処理されます。
iptos spec
	spec で指定したコンマ区切りリストのサービスタイプを含む tos フィールドを持つ IP パケットにマッチします。 サポートされているサービスの IP タイプは次の通りです。 lowdelay ( IPTOS_LOWDELAY), throughput ( IPTOS_THROUGHPUT), reliability ( IPTOS_RELIABILITY), mincost ( IPTOS_MINCOST), congestion ( IPTOS_CE) 。 ‘amp;!’ を置くことで特定のオプションが存在しないという記述ができます。
ipttl ttl-list
	生存時間が ttl-list に含まれる IP パケットにマッチします。 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 つ以上の発信元と宛先アドレスおよびポートが指定できます。
{ MAC | mac } dst-mac src-mac
	与えられた dst-mac アドレスと src-mac アドレスを持つパケットにマッチします。 アドレスは、 any キーワード (任意の MAC アドレスにマッチします) または コロンで区切った 16 進数 6 個の組で指定します。 この 6 個組アドレスの後ろには、オプションとして、 重要なビットを表現するマスクをつけることができます。 マスクは次のいずれかの方法で指定可能です: スラッシュ (/) に続けて、重要なビット数を指定します。 例えば、重要なビットが 33 ビットであるアドレスは次のように指定します:     MAC 10:20:30:40:50:60/33 any アンパサンド (&) に続けて、 コロン区切りの 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
	対応する IPv4 のプロトコルを持つパケットがマッチします。
recv | xmit | via {ifX | if * | 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" の短縮形です。
src-ip ip-address
	引数で指定したアドレスの 1 個を発信元 IP として持つ IP パケットがマッチします。
src-port ports
	引数で指定したポートの 1 個を発信元ポートとして持つ IP パケットがマッチします。
tcpack ack
	TCP パケットのみです。 TCP ヘッダの確認応答番号フィールドが ack に設定されていればマッチします。
tcpflags spec
	TCP パケットのみです。 TCP ヘッダが spec で指定したコンマ区切りのフラグのリストを含んでいればマッチします。 サポートされている TCP フラグは次の通りです。 fin, syn, rst, psh, ack, urg 。 ‘amp;!’ を置くことで特定のフラグが存在しないという記述ができます。 tcpflags の指定を含むルールは、0 でないオフセットを持つフラグメントパケットには 決してマッチすることはありえません。 フラグメントパケットのマッチについての詳細は frag オプションを参照して下さい。
tcpseq seq
	TCP パケットのみです。 TCP ヘッダのシーケンス番号フィールドが seq に設定されていればマッチします。
tcpwin win
	TCP パケットのみです。 TCP ヘッダのウィンドウフィールドが win に設定されていればマッチします。
tcpoptions spec
	TCP パケットのみです。 spec で指定したコンマ区切りのオプションのリストが TCP ヘッダに含まれていればマッチします。 サポートされている TCP オプションは次の通りです。 mss (最大セグメントサイズ), window (TCP ウィンドウ広告), sack (選択的 ACK), ts (RFC1323 タイムスタンプ), cc (RFC1644 T/TCP コネクションカウント)。 ‘amp;!’ を置くことで特定のオプションが存在しないという記述ができます。
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 と似ていますが、ソースアドレスすべての代わりに、 直接接続されたネットワークのソースアドレスを持つパケットを対象とするので より限定的です。

検索表は分散した大量のアドレス、典型的には 100 から数千のエントリを 取り扱うのに便利です。 0 から 127 までの 128 個の異なる検索表を持てます。

各エントリは addr[/masklen] で表され、 (ドットで区切った数字 4 つ組もしくはホスト名で指定された) ベースアドレス addr と masklen ビット幅のマスクで表されるアドレスすべてにマッチします。 masklen が指定されていなければ、デフォルトは 32 です。 表で IP アドレスを検索する場合には、最も限定されたエントリがマッチします。 各エントリには、32 ビット符号なし整数 value が関連づけられ、ルールマッチコードによりチェックされる場合があります。 ルールが追加された時に value が指定されていなければ、デフォルトは 0 です。

エントリは ( add) で表に追加でき、 ( delete) で表から削除できます。 表は ( list) で確認でき、 ( flush) でフラッシュします。

内部的には、各表は経路テーブル ((route) 4 を参照して下さい) と同じように基数木で保持されています。

各ルールは 32 個の異なる セット のひとつに属しています。セットには 0 から 31 までの番号をつけられています。 セット 31 はデフォルトルールのために予約されています。

デフォルトでは、 新規のルールを入力する際に set N アトリビュートを使用しなければ、 ルールはセット 0 に置かれます。 セットは個別に、かつ、不可分に有効化したり無効化したりできるので、 この機構によって、ファイアウォールの設定を複数個格納し、 それらを素早く (かつ不可分に) 切り替えるための方法が 簡単になります。 セットを有効化/無効化するコマンドは次の通りです。 ipfw set [ disable number ... ][ enable number ...]

ここでは複数の enable または disable セクションが指定可能です。 コマンドで指定したセット全てについて、 コマンドは不可分に実行されます。 デフォルトでは全てのセットは有効化された状態です。

セットを無効化すると、ファイアウォールの設定中にそのルールが 存在しないかのように振る舞います。 ただし例外が 1 つだけあります。 無効化される以前にルールから生成された動的ルールは、 期限切れとなるまではまだ活動可能な状態です。 動的ルールを削除するためには、 そのルールを生成した親ルールを明示的に削除しなければなりません。

ルールのセット番号は次のコマンドで変更できます。 ipfw set move { rule rule-number | old-set} to new-set

また、次のコマンドを使用して 2 つのルールセットを 不可分に入れ換えることができます。 ipfw set swap first-set second-set

ルールのセットの使い方のいくつかは、 使用例 セクションを参照して下さい。

ステートフルオペレーションは、 与えられたパターンにマッチするパケットが検出されたときに、 ファイアウォールが特定のフローについてのルールを動的に 作成するための方法です。 ステートフルオペレーションに対するサポートは ルール の check-state, keep-state, limit オプションを通じて提供されます。

動的ルールが生成されるのは、パケットが keep-state や limit ルールにマッチしたときで、その結果、 与えられた protocol を持ち、 src-ip/src-port dst-ip/dst-port のアドレスの組の間のパケット全てのみにマッチする 動的 ルールが生成されます ( src と dst はここでは最初にマッチしたアドレスを区別するためにのみ 使用しています。その後、両者は完全に等価になります)。 動的ルールは最初に check-state, keep-state, limit が生じたところでチェックされ、 マッチした際に実行されるアクションは親ルールと同じものになります。

動的ルールでは、プロトコル、IP アドレス、ポート以外の 属性がチェックされないことに注意して下さい。

動的ルールの典型的な使い方は、 ファイアウォールの設定を閉じた状態にしておきつつ、 内部ネットワークからの最初の TCP SYN パケットに、 そのフローに対する動的ルールをインストールさせ、 そのセッションに属するパケットがファイアウォールを 通過できるようにするというものです。

    ipfw add check-state

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

    ipfw add deny tcp from any to any

同様なアプローチが UDP に対しても使えます。 内部から来た UDP パケットに動的ルールをインストールさせ、 その応答がファイアウォールを通過するようにします。

    ipfw add check-state

    ipfw add allow udp from my-subnet to any keep-state

    ipfw add deny udp from any to any

動的ルールは、ある時間の後、期限切れとなります。 その時間は、 フローの状態といくつかの sysctl 変数の設定に依存します。 詳細はセクション sysctl 変数 を参照して下さい。 TCP セッションでは、 動的ルールに対し、定期的にキープアライブパケットを送出させるように 指示し、期限切れになる頃にルールの状態をリフレッシュさせることが できます。

動的ルールの使用方法に関する他の例は セクション 使用例 を参照して下さい。

ルールを構成する際に考慮すべき重要な点をいくつか述べます。

• かならず 送信パケットと受信パケット の両方のパケットをフィルタリングします。 ほとんどのネットワークコネクションではパケットが双方向に流れることが必要です。
• テストは細心の注意を払って行ないます。 テストの際にはコンソールの近くにいるのがよいでしょう。 コンソールに近寄れない場合、 /usr/share/examples/ipfw/change_rules.sh にあるような自動回復スクリプトを使用してください。
• ループバックインタフェースのことを忘れてはなりません。

ipfw2 は、 FreeBSD 5.x と 6.0 で標準となっていますが、 FreeBSD 4.x では、カーネルを options IPFW2 を付けてコンパイルし、 /sbin/ipfw と /usr/lib/libalias を -DIPFW2 を付け (buildworld の前に /etc/make.conf に IPFW2=TRUE を追加しておくことで同じ効果を得ることができます) 再コンパイル、再インストールしない限り、 今でも ipfw1 を使用します。

このセクションでは ipfw2 で導入され、 ipfw1 には存在しなかった機能の一覧を示します。 ここではルールセットを記述する際に影響が大きいと思われる順に示します。 より効果的なやり方でルールセットを記述するために これらの機能を使用したいと思うかもしれません。

文法とフラグ
	ipfw1 は、-n フラグ (文法チェックのみ) をサポートしませんし、 コンマの後の空白をサポートしませんし、 単一引数中での全ルールフィールドをサポートしません。 ipfw1 では -p フラグ (プリプロセッサ) とともに -f フラグ (強制) を指定することはできません。 ipfw1 は -c (コンパクト) フラグをサポートしません。
非 IPv4 のパケットの取り扱い
	ipfw1 は全ての非 IPv4 パケットを黙って受け付けます ( ipfw1 は net.link.ether.bridge_ipfw=1 の場合にのみ非 IPv4 パケットを参照します)。 ipfw2 は 全てのパケット (非 IPv4 パケットを含む) を ルールセットにしたがってフィルタします。 ipfw1 と同じような動作をさせたい場合は ルールセットの先頭で次のようにします。     ipfw add 1 allow layer2 not mac-type ip layer2 オプションは冗長であるように見えますが、必要です。 レイヤ 3 からファイアウォールを通るパケットは MAC ヘッダを持たないので、 mac-type ip パターンはレイヤ3のパケットに対して常に失敗します。 つまり、 not オペレータをおくと全てを通過させるルールになってしまいます。
宛先	ipfw1 はアドレスセットや宛先リストをサポートしていません。
ポートの指定
	ipfw1 では TCP と UDP のポートを指定する際に 指定できるポート範囲は 1 つだけでした。 また、 ipfw2 で 30 エントリ可能であるのに対し、10 エントリに制限されていました。 また、 ipfw1 では tcp または udp パケットを要求するルールの場合に限って ポートを指定することが可能です。 ipfw2 では全てのパケットにマッチさせるルールでポートの指定を行うことが可能で、 マッチはポート識別子を含んだプロトコルを運ぶパケットのみに適用されます。 最後に、 ipfw1 では 最初のポートエントリを port:mask と指定することができました。 ここで mask は任意の 16 ビットマスクが使用可能です。 この文法が有用であるかどうかは疑問なので ipfw2 ではもはやサポートされていません。
論理和ブロック
	ipfw1 は論理和ブロックをサポートしていません。
キープアライブ
	ipfw1 は状態依存セッションのためのキープアライブを生成しません。 結果として、 休止状態のセッションは 動的ルールの生存時間が期限切れとなるために 落されることがあります。
ルールセット
	ipfw1 はルールセットを実装していません。
MAC ヘッダによるフィルタとレイヤ 2 のファイアウォール
	ipfw1 は MAC ヘッダフィールドによるフィルタを実装していませんし、 ether_demux() と ether_output_frame() からのパケットによっても起動しません。 sysctl 変数 net.link.ether.ipfw はここでは何の効果もありません。
オプション	ipfw1 では、次のオプションは単一値のみ受け付けます: ipid, iplen, ipttl 次のオプションは ipfw1 では実装されていません: dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port さらに、次のオプションは RELENG_4 の ipfw1 では実装されていません: ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack, tcpseq, tcpwin
dummynet オプション
	dummynet パイプ/キュー用の次のオプションはサポートされていません: noerror

ipfw はあまりにも多くの使用方法があるので このセクションでは使用例のほんの一部を示すのみにしておきます。

次のコマンドは 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 つ以上のサブネットの管理者なら、 ipfw2 の文法の利点を活用して アドレスセットと論理和ブロックを指定することで、 次のように、 クライアントのブロックにサービスを選択的に利用可能とする 極めてコンパクトなルールセットを記述することができます。

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

    badguys=q10.1.2.0/24{8,38,60}q

   

    ipfw add allow ip from ${goodguys} to any

    ipfw add deny ip from ${badguys} to any

    ... normal policies ...

ipfw1 の文法では、 上の例では各 IP に別々のルールを用意する必要があります。

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

    ipfw add deny ip from any to any not verrevpath in

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

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

    ipfw add deny ip from any to any not antispoof in

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

ルールセットを不可分に追加するには、 例えばセット 18 なら、次のようにします。

    ipfw set disable 18

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

    ipfw set enable 18

ルールセットを不可分に削除するには、単に次のコマンドでよいです。

    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

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

年月とともに文法が大きくなり、ときどき訳がわからないところも あるかもしれません。 不幸にして、後方互換性のために昔しでかした文法定義の誤りを 訂正できないでいます。

!!! 警告 !!!

ファイアウォールを誤って設定するとコンピュータが 使用不能な状態になり、 ことによると、ネットワークサービスを停止させてしまい、 制御を回復するためにコンソールアクセスが必要となってしまう 可能性があります。

divert によって行き先を変更された入力パケットの断片 (フラグメント) は、 ソケットに配送される前に再構成されます。 これらのパケットで使用されるアクションは パケットの最初のフラグメントにマッチしたルールのものです。

ユーザランドへ向けられ、 ユーザランドのプロセス によって再投入されるパケットは、 パケットの発信元インタフェースを含む パケット属性のいろいろを失っています。 パケットの始点インタフェース名は、8 バイト未満であって、 ユーザランドのプロセスが保存しこれを sockaddr_in で再使用するのであれば、 保持されます ((natd) 8 はそうします)。 さもなくば、この情報は失われます。 パケットがこの方法で再投入された場合、 後のルールは正しく適用されないかもしれません。 ルールの並びにおける divert ルールの順序は非常に重要なものとなります。